[PATCH] update: resurrect bare update from null parent to tip-most branch head

Yuya Nishihara yuya at tcha.org
Fri Apr 15 12:03:29 UTC 2016


# HG changeset patch
# User Yuya Nishihara <yuya at tcha.org>
# Date 1460720231 -32400
#      Fri Apr 15 20:37:11 2016 +0900
# Node ID ecfb768ecf5b62f8a40291dfe8e688a55bb09d55
# Parent  72f683260f31e398a7b8f5a723ebb2936a2ffc6d
update: resurrect bare update from null parent to tip-most branch head

The situation is tricky if repository has no "default" branch, because "null"
revision belongs to non-existent "default" branch.

Before e1dd0de26557, bare update from null would bring us to the tip-most
non-closed branch head. e1dd0de26557 removed the special handling of missing
"default" branch since we wanted to stick to the uncommitted branch in that
case. But, if the parent is "null" revision, and if the missing branch is
"default", it shouldn't be an uncommitted branch. In this case, bare update
should bring us to the tip-most head as before.

This should fix the test breakage introduced by e1dd0de26557.

diff --git a/mercurial/destutil.py b/mercurial/destutil.py
--- a/mercurial/destutil.py
+++ b/mercurial/destutil.py
@@ -101,6 +101,10 @@ def _destupdatebranch(repo, clean, check
             node = repo.revs('max(.::(%ln))', heads).first()
         if bookmarks.isactivewdirparent(repo):
             movemark = repo['.'].node()
+    elif currentbranch == 'default' and not wc.p1():
+        # "null" parent belongs to "default" branch, but it doesn't exist, so
+        # update to the tipmost non-closed branch head
+        node = repo.revs('max(head() and not closed())').first()
     else:
         node = repo['.'].node()
     return node, movemark, None
diff --git a/tests/test-newbranch.t b/tests/test-newbranch.t
--- a/tests/test-newbranch.t
+++ b/tests/test-newbranch.t
@@ -391,3 +391,75 @@ We expect that bare update on new branch
   commit: (new branch)
   update: (current)
   phases: 3 draft
+
+  $ cd ..
+
+We need special handling for repositories with no "default" branch because
+"null" revision belongs to non-existent "default" branch.
+
+  $ hg init nodefault
+  $ cd nodefault
+  $ hg branch -q foo
+  $ touch 0
+  $ hg ci -Aqm0
+  $ touch 1
+  $ hg ci -Aqm1
+  $ hg update -qr0
+  $ hg branch -q bar
+  $ touch 2
+  $ hg ci -Aqm2
+  $ hg update -qr0
+  $ hg branch -q baz
+  $ touch 3
+  $ hg ci -Aqm3
+  $ hg ci --close-branch -m 'close baz'
+  $ hg update -q null
+  $ hg log -GT'{rev} {branch}\n'
+  _  4 baz
+  |
+  o  3 baz
+  |
+  | o  2 bar
+  |/
+  | o  1 foo
+  |/
+  o  0 foo
+  
+
+ a) updating from "null" should bring us to the tip-most branch head as
+ there is no "default" branch:
+
+  $ hg update -q null
+  $ hg id -bn
+  -1 default
+  $ hg update
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ hg id -bn
+  2 bar
+
+ b) but if we are at uncommitted "default" branch, we should stick to the
+ current revision:
+
+  $ hg update -q 0
+  $ hg branch default
+  marked working directory as branch default
+  $ hg id -bn
+  0 default
+  $ hg update
+  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ hg id -bn
+  0 default
+
+ c) also, if we have uncommitted branch at "null", we should stick to it:
+
+  $ hg update -q null
+  $ hg branch new
+  marked working directory as branch new
+  $ hg id -bn
+  -1 new
+  $ hg update
+  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ hg id -bn
+  -1 new
+
+  $ cd ..


More information about the Mercurial-devel mailing list