Skip to content
Snippets Groups Projects
  1. Jun 06, 2017
  2. Feb 02, 2016
    • Pierre-Yves David's avatar
      update: warn about other topological heads on bare update · 72072cfc7e91
      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.
      72072cfc7e91
  3. Sep 23, 2011
  4. Sep 20, 2011
    • Yann E. MORIN's avatar
      revset.bisect: add 'ignored' set to the bisect keyword · 395ca8cd2669
      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: default avatar"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
      395ca8cd2669
    • Yann E. MORIN's avatar
      hbisect.get: use simpler code with repo.set(), fix 'pruned' set · b39d85be78a8
      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: default avatar"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
      b39d85be78a8
  5. Sep 17, 2011
  6. Jul 16, 2011
  7. Mar 12, 2011
    • Benoit Boissinot's avatar
      bisect: new command to extend the bisect range (issue2690) · 0388e3e36693
      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.
      0388e3e36693
  8. Sep 16, 2010
  9. Sep 08, 2010
  10. Aug 21, 2010
  11. Aug 14, 2010
  12. Aug 02, 2008
Loading