- Jun 06, 2017
-
-
Pulkit Goyal authored
Currently when we have multiple heads on the same branch, update tells us that there some more heads for the current branch but does not tells us the head to which the repository has been updated to. It makes more sense showing the head we updated to and then telling there are some more heads.
-
- Feb 02, 2016
-
-
Pierre-Yves David authored
A concern around the user experience of Mercurial is user getting stuck on there own topological branch forever. For example, someone pulling another topological branch, missing that message in pull asking them to merge and getting stuck on there own local branch. The current way to "address" this concern was for bare 'hg update' to target the tipmost (also latest pulled) changesets and complain when the update was not linear. That way, failure to merge newly pulled changesets would result in some kind of failure. Yet the failure was quite obscure, not working in all cases (eg: commit right after pull) and the behavior was very impractical in the common case (eg: issue4673). To be able to change that behavior, we need to provide other ways to alert a user stucks on one of many topological head. We do so with an extra message after bare update: 1 other heads for branch "default" Bookmark get its own special version: 1 other divergent bookmarks for "foobar" There is significant room to improve the message itself, and we should augment it with hint about how to see theses other heads or handle the situation (see in-line comment). But having "a" message is already a significant improvement compared to the existing situation. Once we have it we can iterate on a better version of it. As having such message is an important step toward changing the default destination for update and other nicety, I would like to move forward quickly on getting such message. This was discussed during London - October 2015 Sprint.
-
- Sep 23, 2011
-
-
Yann E. MORIN authored
This patch adds two new revset descriptions: - 'goods': the list of topologicaly-good csets: - if good csets are topologically before bad csets, yields '::good' - else, yields 'good::' - and conversely for 'bads' Signed-off-by:
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
-
- Sep 20, 2011
-
-
Yann E. MORIN authored
The 'ignored' changesets are outside the bisection range, but are changesets that may have an impact on the outcome of the bisection. For example, in case there's a merge between the good and bad csets, but the branch-point is out of the bisection range, and the issue originates from this branch, the branch will not be visited by bisect and bisect will find that the culprit cset is the merge. So, the 'ignored' set is equivalent to: ( ( ::bisect(bad) - ::bisect(good) ) | ( ::bisect(good) - ::bisect(bad) ) ) - bisect(range) - all ancestors of bad csets that are not ancestors of good csets, or - all ancestors of good csets that are not ancestors of bad csets - but that are not in the bisection range. Signed-off-by:
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
-
Yann E. MORIN authored
Use repo.set() wherever possible, instead of locally trying to reproduce complex graph computations. 'pruned' now means 'all csets that will no longer be visited by the bisection'. The change is done is this very patch instead of its own dedicated one becasue the code changes all over the place, and the previous 'pruned' code was totally rewritten by the cleanup, so it was easier to just change the behavior at the same time. The previous series went in too fast for this cleanup pass to be included, so here it is. ;-) Signed-off-by:
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
-
- Sep 17, 2011
-
-
Yann E. MORIN authored
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>
-
Yann E. MORIN authored
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>
-
Yann E. MORIN authored
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>
-
- Jul 16, 2011
-
-
Alexander Krauss authored
The included test used to report "inconsistent state", which is incorrect. While this situation cannot occur when the user sticks to the suggested bisect sequence. However, adding more consistent good/bad information to the bisect state should be tolerated as well.
-
- Mar 12, 2011
-
-
Benoit Boissinot authored
When bisect ends in a merge point, and one of the parent wasn't checked, this usually means the culprit is in a branch that wasn't scanned. For this case we provide a new command which extends the range of the bisect search to the common ancestor of the parents of the merge.
-
- Sep 16, 2010
-
-
Matt Mackall authored
-
- Sep 08, 2010
-
-
Dirkjan Ochtman authored
-
- Aug 21, 2010
-
-
Matt Mackall authored
-
- Aug 14, 2010
-
-
Martin Geisler authored
-
- Aug 02, 2008
-
-
Bernhard Leiner authored
-