Mon, 19 Sep 2011 16:28:44 -0500 revset: add 'l' flag to formatspec for args
Matt Mackall <mpm@selenic.com> [Mon, 19 Sep 2011 16:28:44 -0500] rev 15140
revset: add 'l' flag to formatspec for args This makes it easy to calculate a revset with lists: good = [1, 2, 3] bad = [10, 11, 12] between = repo.set('%ld::%ld', good, bad)
Sun, 18 Sep 2011 23:57:49 +0200 bisect: add some bisection examples, and some log revset.bisect() examples
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Sun, 18 Sep 2011 23:57:49 +0200] rev 15139
bisect: add some bisection examples, and some log revset.bisect() examples Add a few examples on how to use bisect: - a few bisection examples Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Sat, 17 Sep 2011 14:33:20 +0200 revset.bisect: add new 'untested' set to the bisect keyword
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Sat, 17 Sep 2011 14:33:20 +0200] rev 15138
revset.bisect: add new 'untested' set to the bisect keyword The 'untested' set is made of changesets that are in the bisection range but for which the status is still unknown, and that can later be used to further decide on the bisection outcome. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Sat, 17 Sep 2011 17:30:35 +0200 revset.bisect: add new 'pruned' set to the bisect keyword
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Sat, 17 Sep 2011 17:30:35 +0200] rev 15137
revset.bisect: add new 'pruned' set to the bisect keyword The 'pruned' set is made of changesets that did participate to the bisection. They are made of - all good changesets - all bad changsets - all skipped changesets, provided they are in the bisection range Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Sat, 17 Sep 2011 17:33:34 +0200 revset.bisect: add new 'range' set to the bisect keyword
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Sat, 17 Sep 2011 17:33:34 +0200] rev 15136
revset.bisect: add new 'range' set to the bisect keyword The 'range' set is made of all changesets that make the bisection range, that is - csets that are ancestors of bad csets and descendants of good csets or - csets that are ancestors of good csets and descendants of bad csets That is, roughly equivalent of: bisect(good)::bisect(bad) | bisect(bad)::bisect(good) Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Sat, 17 Sep 2011 00:20:45 +0200 revset.bisect: move bisect() code to hbisect.py
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Sat, 17 Sep 2011 00:20:45 +0200] rev 15135
revset.bisect: move bisect() code to hbisect.py Computing the ranges of csets in the bisection belongs to the hbisect code. This allows for reusing the status computation from many places, not only the revset code, but also to later display the bisection status of a cset... Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Sun, 18 Sep 2011 22:54:11 +0200 revset: rename bisected() to bisect()
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Sun, 18 Sep 2011 22:54:11 +0200] rev 15134
revset: rename bisected() to bisect() Rename the 'bisected' keyword to simply 'bisect'. Still accept the old name, but no longer advertise it. As discussed with Matt on IRC. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Sun, 18 Sep 2011 10:07:51 +0200 revset.bisected: remove 'unknown' state
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Sun, 18 Sep 2011 10:07:51 +0200] rev 15133
revset.bisected: remove 'unknown' state 'unknown' is not a valid bisect state, so causes a traceback. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Mon, 19 Sep 2011 16:57:13 +0200 rebase: allow rebase to ancestor (issue3010)
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 19 Sep 2011 16:57:13 +0200] rev 15132
rebase: allow rebase to ancestor (issue3010) We only deny rebasing onto direct parent. Thanks to the ancestor argument of merge. the "implementation" of this feature only consist in loosing the check and imply detach when rebasing on ancestor.
Sun, 18 Sep 2011 19:59:33 -0400 rollback: only restore dirstate and branch when appropriate.
Greg Ward <greg@gerg.ca> [Sun, 18 Sep 2011 19:59:33 -0400] rev 15131
rollback: only restore dirstate and branch when appropriate. If the working dir parent was destroyed by rollback, then the old behaviour is perfectly reasonable: restore dirstate, branch, and bookmarks. That way the working dir moves back to an existing changeset rather than becoming an orphan. But if the working dir parent was unaffected -- say, you updated to an older changeset and then did rollback -- then it's silly to restore dirstate and branch. So don't do that. Leave the status of the working dir alone. (But always restore bookmarks, because that file refers to changeset IDs that may have been destroyed.)
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip