Patchwork [1,of,5,RFC] tests: show added/modified/removed files when logging repos converted from bzr

login
register
mail settings
Submitter Yuya Nishihara
Date July 28, 2018, 2:59 p.m.
Message ID <20180728235912.7a873d7d3238aea4d0c012d6@tcha.org>
Download mbox | patch
Permalink /patch/32961/
State New
Headers show

Comments

Yuya Nishihara - July 28, 2018, 2:59 p.m.
On Sat, 28 Jul 2018 10:37:37 -0400, Matt Harbison wrote:
> 
> > On Jul 28, 2018, at 3:05 AM, Yuya Nishihara <yuya@tcha.org> wrote:
> > 
> >> On Fri, 27 Jul 2018 14:14:27 -0400, Matt Harbison wrote:
> >> On Fri, 27 Jul 2018 14:10:08 -0400, Matt Harbison <mharbison72@gmail.com>  
> >> wrote:
> >> 
> >>> # HG changeset patch
> >>> # User Matt Harbison <matt_harbison@yahoo.com>
> >>> # Date 1531499586 14400
> >>> #      Fri Jul 13 12:33:06 2018 -0400
> >>> # Branch stable
> >>> # Node ID 3da5d60bf6e7ad121cea897e2f59846007f3cc9f
> >>> # Parent  0f948d821fe7e5ed18e6106c162375a11e8b0546
> >>> tests: show added/modified/removed files when logging repos converted  
> >>> from bzr
> >> 
> >> I know we're in the middle of a freeze, but I didn't get a chance to  
> >> figure out this memctx status filtering.  I'm on vacation, so the chances  
> >> of me getting back to it are quite slim.  Since it affects more than a  
> >> corner case with convert[1], and it permanently affects the repo, it's  
> >> probably worth someone who understands the status calculating to take a  
> >> run at it.
> >> 
> >> [1]  
> >> https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-July/118907.html
> > 
> > Does the hack in the previous thread solve your problem?
> 
> IIRC, the hack you posted just printed a message when the problem occurred- it didn’t try to fix it.  I remember running it, and I think the message came out a couple of times.  (I thought far fewer times than the number of commits that I had to hack to fix up, but it’s possible that this is a cascading problem.)  I don’t recall if it printed in the problem *.t test in this series.

Really. I saw several hash changes in test outputs including
test-convert-bzr-merges.t, so I thought it would catch at least a certain
type of manifest mis-reuse. Maybe there would be the other ones.
Matt Harbison - July 28, 2018, 3:46 p.m.
> On Jul 28, 2018, at 10:59 AM, Yuya Nishihara <yuya@tcha.org> wrote:
> 
>> On Sat, 28 Jul 2018 10:37:37 -0400, Matt Harbison wrote:
>> 
>>>> On Jul 28, 2018, at 3:05 AM, Yuya Nishihara <yuya@tcha.org> wrote:
>>>> 
>>>> On Fri, 27 Jul 2018 14:14:27 -0400, Matt Harbison wrote:
>>>> On Fri, 27 Jul 2018 14:10:08 -0400, Matt Harbison <mharbison72@gmail.com>  
>>>> wrote:
>>>> 
>>>>> # HG changeset patch
>>>>> # User Matt Harbison <matt_harbison@yahoo.com>
>>>>> # Date 1531499586 14400
>>>>> #      Fri Jul 13 12:33:06 2018 -0400
>>>>> # Branch stable
>>>>> # Node ID 3da5d60bf6e7ad121cea897e2f59846007f3cc9f
>>>>> # Parent  0f948d821fe7e5ed18e6106c162375a11e8b0546
>>>>> tests: show added/modified/removed files when logging repos converted  
>>>>> from bzr
>>>> 
>>>> I know we're in the middle of a freeze, but I didn't get a chance to  
>>>> figure out this memctx status filtering.  I'm on vacation, so the chances  
>>>> of me getting back to it are quite slim.  Since it affects more than a  
>>>> corner case with convert[1], and it permanently affects the repo, it's  
>>>> probably worth someone who understands the status calculating to take a  
>>>> run at it.
>>>> 
>>>> [1]  
>>>> https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-July/118907.html
>>> 
>>> Does the hack in the previous thread solve your problem?
>> 
>> IIRC, the hack you posted just printed a message when the problem occurred- it didn’t try to fix it.  I remember running it, and I think the message came out a couple of times.  (I thought far fewer times than the number of commits that I had to hack to fix up, but it’s possible that this is a cascading problem.)  I don’t recall if it printed in the problem *.t test in this series.
> 
> Really. I saw several hash changes in test outputs including
> test-convert-bzr-merges.t, so I thought it would catch at least a certain
> type of manifest mis-reuse. Maybe there would be the other ones.

I’ll have to try it again, because I ran so many conversions I may be getting my wires crossed. But I won’t be back for another week.  There are some truly crazy things in this repo, like merging commits with their parent (it’s like this in the bar source).  So it may end up being a combination of things.
Matt Harbison - Aug. 11, 2018, 3 a.m.
On Sat, 28 Jul 2018 10:59:12 -0400, Yuya Nishihara <yuya@tcha.org> wrote:

> On Sat, 28 Jul 2018 10:37:37 -0400, Matt Harbison wrote:
>>
>> > On Jul 28, 2018, at 3:05 AM, Yuya Nishihara <yuya@tcha.org> wrote:
>> >
>> >> On Fri, 27 Jul 2018 14:14:27 -0400, Matt Harbison wrote:
>> >> On Fri, 27 Jul 2018 14:10:08 -0400, Matt Harbison  
>> <mharbison72@gmail.com>
>> >> wrote:
>> >>
>> >>> # HG changeset patch
>> >>> # User Matt Harbison <matt_harbison@yahoo.com>
>> >>> # Date 1531499586 14400
>> >>> #      Fri Jul 13 12:33:06 2018 -0400
>> >>> # Branch stable
>> >>> # Node ID 3da5d60bf6e7ad121cea897e2f59846007f3cc9f
>> >>> # Parent  0f948d821fe7e5ed18e6106c162375a11e8b0546
>> >>> tests: show added/modified/removed files when logging repos  
>> converted
>> >>> from bzr
>> >>
>> >> I know we're in the middle of a freeze, but I didn't get a chance to
>> >> figure out this memctx status filtering.  I'm on vacation, so the  
>> chances
>> >> of me getting back to it are quite slim.  Since it affects more than  
>> a
>> >> corner case with convert[1], and it permanently affects the repo,  
>> it's
>> >> probably worth someone who understands the status calculating to  
>> take a
>> >> run at it.
>> >>
>> >> [1]
>> >>  
>> https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-July/118907.html
>> >
>> > Does the hack in the previous thread solve your problem?
>>
>> IIRC, the hack you posted just printed a message when the problem  
>> occurred- it didn’t try to fix it.  I remember running it, and I think  
>> the message came out a couple of times.  (I thought far fewer times  
>> than the number of commits that I had to hack to fix up, but it’s  
>> possible that this is a cascading problem.)  I don’t recall if it  
>> printed in the problem *.t test in this series.
>
> Really. I saw several hash changes in test outputs including
> test-convert-bzr-merges.t, so I thought it would catch at least a certain
> type of manifest mis-reuse. Maybe there would be the other ones.
>
> diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
> --- a/mercurial/localrepo.py
> +++ b/mercurial/localrepo.py
> @@ -2028,6 +2028,7 @@ class localrepository(object):
>                  # reuse an existing manifest revision
>                  mn = ctx.manifestnode()
>                  files = ctx.files()
> +                self.ui.debug('reusing known manifest')
>              elif ctx.files():
>                  m1ctx = p1.manifestctx()
>                  m2ctx = p2.manifestctx()
> @@ -2064,16 +2065,26 @@ class localrepository(object):
>                          raise
>                 # update manifest
> -                self.ui.note(_("committing manifest\n"))
>                  removed = [f for f in sorted(removed) if f in m1 or f  
> in m2]
>                  drop = [f for f in removed if f in m]
>                  for f in drop:
>                      del m[f]
> -                mn = mctx.write(trp, linkrev,
> -                                p1.manifestnode(), p2.manifestnode(),
> -                                added, drop)
> +                # if no files actually changed, try hard to detect  
> unmodified
> +                # manifest entry caused by error in memctx or  
> workingcommitctx
> +                # with bad copy information
> +                if (changed or removed
> +                    or m1.diff(m, scmutil.matchfiles(self,  
> ctx.files()))):
> +                    self.ui.note(_("committing manifest\n"))
> +                    mn = mctx.write(trp, linkrev,
> +                                    p1.manifestnode(),  
> p2.manifestnode(),
> +                                    added, drop)
> +                else:
> +                    self.ui.debug('reusing manifest form p1  
> (inconsistency '
> +                                  'found in %r)\n' % ctx)
> +                    mn = p1.manifestnode()
>                  files = changed + removed
>              else:
> +                self.ui.debug('reusing manifest from p1 (no file  
> change)\n')
>                  mn = p1.manifestnode()
>                  files = []

I applied this, adjusted the 3 'reusing' lines to ui.status(), reconverted  
 from bzr, and then converted that from hg -> hg.  I also printed p1.node()  
to have some idea of where it was when grepping.

For the bzr -> hg leg, grepping the output for 'reusing' revealed 7  
instances of "reusing manifest from p1 (no file change)".  When I  
converted that to hg again, I got 13 instances of that line.  I wasn't  
expecting the number to change.  The first two instances lined up with  
identical p1 hashes.  The next 5 had different p1 hashes, but they're the  
same commit, demonstrated by comparing 'convert_source'.  The rest are  
commits that weren't flagged in the bzr -> hg convert.

I ran `hg log -r $bad --debug` on the first divergent changeset in these  
two repos, and everything matches but the changeset hash.  I ran `hg  
debugindex -m` on both repos and diffed.  That output is identical, well  
past the divergence point.  The output of `hg debugindex -c` differs on  
the divergent changesets, even though the files listed with `log --debug`  
match.  Not sure what that means.

Finally, I reconverted the original production hg repo (originally  
converted with ~3.7.1) using a vanilla 4.6.1.  The result of this is  
identical to the output of the above hg -> hg conversion with your hack.   
So I guess the story here is that in trying to illustrate the problem I  
was having via a simple test, I swerved into a different problem with the  
manifest.  It seems that your hack is worth
submitting, because it helps a particular problem.  My problem seems  
changelog related.

The previous RFC series[1] gets the conversion further along than this  
manifest node hacking, avoids early changelog differences, and it diverges  
in the second half of an octopus merge.  But it clearly isn't correct,  
given some of the test failures.

Since I redirected the convert output to a file for the bzr -> hg run, I  
now see there are a couple of messages related to missing files, which  
correspond to files missing from the `hg log -r $octopus_fixup --debug`  
output:

warning: can't find ancestor for  
'Linux/Uboot/XC8600/uboot_bsp/devicetree_externalfpgaconfig.dts' copied  
 from 'Linux/Uboot/XC8600/uboot_bsp/devicetree_serialpromfpga.dts'!
warning: can't find ancestor for  
'Linux/Uboot/XC8600/uboot_bsp/settings_externalfpgaconfig.bsp' copied from  
'Linux/Uboot/XC8600/uboot_bsp/settings_serialpromfpga.bsp'!

That doesn't happen with 3.7.1, from the original conversion.

[1]  
https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-July/119438.html
Matt Harbison - Aug. 21, 2018, 1:35 a.m.
On Fri, 10 Aug 2018 23:00:39 -0400, Matt Harbison <mharbison72@gmail.com>  
wrote:

> Finally, I reconverted the original production hg repo (originally  
> converted with ~3.7.1) using a vanilla 4.6.1.  The result of this is  
> identical to the output of the above hg -> hg conversion with your  
> hack.  So I guess the story here is that in trying to illustrate the  
> problem I was having via a simple test, I swerved into a different  
> problem with the manifest.  It seems that your hack is worth
> submitting, because it helps a particular problem.  My problem seems  
> changelog related.
>
> The previous RFC series[1] gets the conversion further along than this  
> manifest node hacking, avoids early changelog differences, and it  
> diverges in the second half of an octopus merge.  But it clearly isn't  
> correct, given some of the test failures.
>
> Since I redirected the convert output to a file for the bzr -> hg run, I  
> now see there are a couple of messages related to missing files, which  
> correspond to files missing from the `hg log -r $octopus_fixup --debug`  
> output:
>
> warning: can't find ancestor for  
> 'Linux/Uboot/XC8600/uboot_bsp/devicetree_externalfpgaconfig.dts' copied  
>  from 'Linux/Uboot/XC8600/uboot_bsp/devicetree_serialpromfpga.dts'!
> warning: can't find ancestor for  
> 'Linux/Uboot/XC8600/uboot_bsp/settings_externalfpgaconfig.bsp' copied  
> from 'Linux/Uboot/XC8600/uboot_bsp/settings_serialpromfpga.bsp'!
>
> That doesn't happen with 3.7.1, from the original conversion.
>
> [1]  
> https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-July/119438.html

I finally figured out what's going wrong, and how to fix it, but I'm  
unclear on the *why*.  I also re-ran the conversion with 3.7.1, and now  
see the above warnings.  I must have missed them in the wall of text when  
converting the first time.

The problem is that since 216fa1ba9993, the source repo has been passing a  
set of files clean against p2 to the sink.  But only for hg sources.  If I  
unconditionally substitute an empty set (or update to the parent of  
216fa1ba9993), the changelog problems go away, and I hit the later  
manifest issue for which I was able to create a test[1].  The commit makes  
it sound like the divergence is unintentional, so it sounds like the hg ->  
hg conversion where the changelog is different is wrong?

Sadly, I haven't been able to create a simple test for this changelog  
divergence yet.  The graph in the production repo (i.e. the initial bzr ->  
hg conversion) related to the divergent file entry in the changelog is:

$ hg log -r '((follow("scripts/busybox/busybox")) & ancestors(259)) + 259  
+ ancestor(258,145)' -G -Tcompact
o    259:258,145   3b73ac59a3dd   2016-12-02 15:44 -0500   dorr
|\     Merged down 4K from project trunk.
| :
o :  145   11b13dc01078   2016-12-01 17:58 -0500   msteiner
: :    04K: Other, Moved busybox to scripts directory.
: :
o :  96   d7a5d6cabef2   2016-10-26 15:12 -0400   dpalmerton
:/     02Q: Feature Added root filesystem source to source control.
:
o  95   ac2a46a295b6   2016-10-21 18:04 -0400   pbolin
|    02P: Other, fixed LIO HPS interface deleting task ID zero upon  
failure to init.
~

The file was added in 96, renamed in 145, and then some other stuff was  
merged into it at 259.  So it seems like pretty standard stuff, and I'm  
not sure what is special about this file.

Like the manifest divergence below, I assume this is a problem for more  
than just bzr conversions.  I probably won't spend too much more time on  
it because my goal was to preserve the original hashes, and I think I  
figured out how to do that.  But if anyone wants to throw code or ideas at  
this, I'd be happy to try them.

[1]  
https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-August/120837.html

Patch

diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
--- a/mercurial/localrepo.py
+++ b/mercurial/localrepo.py
@@ -2028,6 +2028,7 @@  class localrepository(object):
                 # reuse an existing manifest revision
                 mn = ctx.manifestnode()
                 files = ctx.files()
+                self.ui.debug('reusing known manifest')
             elif ctx.files():
                 m1ctx = p1.manifestctx()
                 m2ctx = p2.manifestctx()
@@ -2064,16 +2065,26 @@  class localrepository(object):
                         raise
 
                 # update manifest
-                self.ui.note(_("committing manifest\n"))
                 removed = [f for f in sorted(removed) if f in m1 or f in m2]
                 drop = [f for f in removed if f in m]
                 for f in drop:
                     del m[f]
-                mn = mctx.write(trp, linkrev,
-                                p1.manifestnode(), p2.manifestnode(),
-                                added, drop)
+                # if no files actually changed, try hard to detect unmodified
+                # manifest entry caused by error in memctx or workingcommitctx
+                # with bad copy information
+                if (changed or removed
+                    or m1.diff(m, scmutil.matchfiles(self, ctx.files()))):
+                    self.ui.note(_("committing manifest\n"))
+                    mn = mctx.write(trp, linkrev,
+                                    p1.manifestnode(), p2.manifestnode(),
+                                    added, drop)
+                else:
+                    self.ui.debug('reusing manifest form p1 (inconsistency '
+                                  'found in %r)\n' % ctx)
+                    mn = p1.manifestnode()
                 files = changed + removed
             else:
+                self.ui.debug('reusing manifest from p1 (no file change)\n')
                 mn = p1.manifestnode()
                 files = []
 
diff --git a/tests/test-convert-bzr-merges.t b/tests/test-convert-bzr-merges.t
--- a/tests/test-convert-bzr-merges.t
+++ b/tests/test-convert-bzr-merges.t
@@ -83,20 +83,17 @@  test multiple merges at once
   $ hg -R hg2hg out source-hg -T compact
   comparing with source-hg
   searching for changes
-  5[tip]:4,3   6bd55e826939   2009-10-10 08:00 +0100   foo
-    (octopus merge fixup)
-  
-XXX: The manifest lines should probably agree, to avoid changing the hash when
-converting hg -> hg
+  no changes found
+  [1]
 
   $ hg -R source-hg log --debug -r tip
-  changeset:   5:b209510f11b2c987f920749cd8e352aa4b3230f2
+  changeset:   5:6bd55e8269392769783345686faf7ff7b3b0215d
   branch:      source
   tag:         tip
   phase:       draft
   parent:      4:1dc38c377bb35eeea4fa955056fbe4440d54a743
   parent:      3:4aaba1bfb426b8941bbf63f9dd52301152695164
-  manifest:    5:1109e42bdcbd1f51baa69bc91079011d77057dbb
+  manifest:    4:daa315d56a98ba20811fdd0d9d575861f65cfa8c
   user:        Foo Bar <foo.bar@example.com>
   date:        Sat Oct 10 08:00:04 2009 +0100
   extra:       branch=source
diff --git a/tests/test-convert-filemap.t b/tests/test-convert-filemap.t
--- a/tests/test-convert-filemap.t
+++ b/tests/test-convert-filemap.t
@@ -780,7 +780,7 @@  example because filemap changed.
   converting...
   0 3
   $ hg -R .-hg log -G -T '{shortest(node)} {desc}\n{files % "- {file}\n"}\n'
-  o    e9ed 3
+  o    bbfe 3
   |\
   | o  33a0 2
   | |  - f
diff --git a/tests/test-convert-svn-branches.t b/tests/test-convert-svn-branches.t
--- a/tests/test-convert-svn-branches.t
+++ b/tests/test-convert-svn-branches.t
@@ -85,8 +85,8 @@  Convert again
   $ hg branches
   newbranch                     11:a6d7cc050ad1
   default                       10:6e2b33404495
-  old                            9:93c4b0f99529
-  old2                           8:b52884d7bead (inactive)
+  old                            9:1b494af68c0b
+  old2                           8:5be40b8dcbf6 (inactive)
   $ hg tags -q
   tip
   $ cd ..
diff --git a/tests/test-convert-svn-encoding.t b/tests/test-convert-svn-encoding.t
--- a/tests/test-convert-svn-encoding.t
+++ b/tests/test-convert-svn-encoding.t
@@ -52,6 +52,7 @@  Convert while testing all possible outpu
   5 init projA
   source: svn:afeb9c47-92ff-4c0c-9f72-e1f6eb8ac9af/trunk@1
   converting: 0/6 revisions (0.00%)
+  reusing manifest from p1 (no file change)
   committing changelog
   updating the branch cache
   4 hello
@@ -118,6 +119,7 @@  Convert while testing all possible outpu
   converting: 4/6 revisions (66.67%)
   reparent to file:/*/$TESTTMP/svn-repo/branches/branch%C3%A9 (glob)
   scanning paths: /branches/branch\xc3\xa9 0/1 paths (0.00%) (esc)
+  reusing manifest from p1 (no file change)
   committing changelog
   updating the branch cache
   0 branch to branch?e
@@ -125,6 +127,7 @@  Convert while testing all possible outpu
   converting: 5/6 revisions (83.33%)
   reparent to file:/*/$TESTTMP/svn-repo/branches/branch%C3%A9e (glob)
   scanning paths: /branches/branch\xc3\xa9e 0/1 paths (0.00%) (esc)
+  reusing manifest from p1 (no file change)
   committing changelog
   updating the branch cache
   reparent to file:/*/$TESTTMP/svn-repo (glob)
diff --git a/tests/test-fix.t b/tests/test-fix.t
--- a/tests/test-fix.t
+++ b/tests/test-fix.t
@@ -830,9 +830,9 @@  no ancestors that are replaced.
   
   $ hg fix -r 0:2
   $ hg log --graph --template '{node|shortest} {files}'
-  o  3801 bar.whole
+  o  b4e2 bar.whole
   |
-  o  38cc
+  o  59f4
   |
   | @  bc05 bar.whole
   | |
diff --git a/tests/test-graft.t b/tests/test-graft.t
--- a/tests/test-graft.t
+++ b/tests/test-graft.t
@@ -699,8 +699,23 @@  Transplants of grafts can find a destina
   summary:     2
   
 ... grafts of grafts unfortunately can't
-  $ hg graft -q 13
+  $ hg graft -q 13 --debug
+  scanning for duplicate grafts
+  grafting 13:7a4785234d87 "2"
+    searching for copies back to rev 12
+    unmatched files in other (from topological common ancestor):
+     g
+    unmatched files new in both:
+     b
+  resolving manifests
+   branchmerge: True, force: True, partial: False
+   ancestor: b592ea63bb0c, local: 7e61b508e709+, remote: 7a4785234d87
+  committing files:
+  b
   warning: can't find ancestor for 'b' copied from 'a'!
+  reusing manifest form p1 (inconsistency found in <workingcommitctx 7e61b508e709+>)
+  committing changelog
+  updating the branch cache
   $ hg log -r 'destination(13)'
 All copies of a cset
   $ hg log -r 'origin(13) or destination(origin(13))'
@@ -731,7 +746,7 @@  All copies of a cset
   date:        Thu Jan 01 00:00:00 1970 +0000
   summary:     2
   
-  changeset:   22:d1cb6591fa4b
+  changeset:   22:3a4e92d81b97
   branch:      dev
   tag:         tip
   user:        foo
@@ -743,8 +758,8 @@  graft works on complex revset
 
   $ hg graft 'origin(13) or destination(origin(13))'
   skipping ancestor revision 21:7e61b508e709
-  skipping ancestor revision 22:d1cb6591fa4b
-  skipping revision 2:5c095ad7e90f (already grafted to 22:d1cb6591fa4b)
+  skipping ancestor revision 22:3a4e92d81b97
+  skipping revision 2:5c095ad7e90f (already grafted to 22:3a4e92d81b97)
   grafting 7:ef0ef43d49e7 "2"
   warning: can't find ancestor for 'b' copied from 'a'!
   grafting 13:7a4785234d87 "2"
@@ -758,7 +773,7 @@  graft with --force (still doesn't graft 
   $ hg graft 19 0 6
   skipping ungraftable merge revision 6
   skipping ancestor revision 0:68795b066622
-  skipping already grafted revision 19:9627f653b421 (22:d1cb6591fa4b also has origin 2:5c095ad7e90f)
+  skipping already grafted revision 19:9627f653b421 (22:3a4e92d81b97 also has origin 2:5c095ad7e90f)
   [255]
   $ hg graft 19 0 6 --force
   skipping ungraftable merge revision 6
@@ -773,12 +788,12 @@  graft --force after backout
   $ hg ci -m 28
   $ hg backout 28
   reverting a
-  changeset 29:53177ba928f6 backs out changeset 28:50a516bb8b57
+  changeset 29:9d95e865b00c backs out changeset 28:cc20d29aec8d
   $ hg graft 28
-  skipping ancestor revision 28:50a516bb8b57
+  skipping ancestor revision 28:cc20d29aec8d
   [255]
   $ hg graft 28 --force
-  grafting 28:50a516bb8b57 "28"
+  grafting 28:cc20d29aec8d "28"
   merging a
   $ cat a
   abc
@@ -788,7 +803,7 @@  graft --continue after --force
   $ echo def > a
   $ hg ci -m 31
   $ hg graft 28 --force --tool internal:fail
-  grafting 28:50a516bb8b57 "28"
+  grafting 28:cc20d29aec8d "28"
   abort: unresolved conflicts, can't continue
   (use 'hg resolve' and 'hg graft --continue')
   [255]
@@ -801,7 +816,7 @@  graft --continue after --force
   (no more unresolved files)
   continue: hg graft --continue
   $ hg graft -c
-  grafting 28:50a516bb8b57 "28"
+  grafting 28:cc20d29aec8d "28"
   $ cat a
   abc
 
@@ -822,8 +837,8 @@  Empty graft
   $ hg tag -f something
   $ hg graft -qr 27
   $ hg graft -f 27
-  grafting 27:ed6c7e54e319 "28"
-  note: graft of 27:ed6c7e54e319 created no changes to commit
+  grafting 27:17d42b8f5d50 "28"
+  note: graft of 27:17d42b8f5d50 created no changes to commit
 
   $ cd ..