Thu, 05 Jul 2018 09:53:00 +0530 strip: improve help text for --no-backup option
Sushil khanchi <sushilkhanchi97@gmail.com> [Thu, 05 Jul 2018 09:53:00 +0530] rev 38574
strip: improve help text for --no-backup option Help text is modified to clearly define the meaning of --no-backup option. Differential Revision: https://phab.mercurial-scm.org/D3886
Thu, 05 Jul 2018 15:07:29 -0400 test-convert: demonstrate an unstable hash issue for bzr -> hg -> hg
Matt Harbison <matt_harbison@yahoo.com> [Thu, 05 Jul 2018 15:07:29 -0400] rev 38573
test-convert: demonstrate an unstable hash issue for bzr -> hg -> hg It looks like the manifest value changing is the only difference, but I'm not sure why it's happening. I've got a similar divergence in a production repo that was also converted from bzr and has an octopus merge[1]. Unlike here, the manifest values for the destination merge commits reflect the initial merge only, instead of all four merges agreeing like this test. $ hg -R src_repo manifest -r 310 --debug | grep file # octopus fixup merge 2d8775bc2481bd28ac87038ecdf33e1dbddc80e9 644 file1 6adb9353a55bb8be76e71382efc724ec3ccf7ed5 644 file2 $ hg -R src_repo manifest -r 309 --debug | grep file # first merge 362e7cb5163153c4989daad1a834871ae849f205 644 file1 2c65d947191938c3ea616b7ceb7648ff3843261f 644 file2 $ hg -R dst_repo manifest -r 273 --debug | grep file # octopus fixup merge 362e7cb5163153c4989daad1a834871ae849f205 644 file1 2c65d947191938c3ea616b7ceb7648ff3843261f 644 file2 $ hg -R dst_repo manifest -r 272 --debug | grep file # first merge 362e7cb5163153c4989daad1a834871ae849f205 644 file1 2c65d947191938c3ea616b7ceb7648ff3843261f 644 file2 This divergence is espcially annoying because unlike changelog differences, I haven't figured out a way to fix this in code. The only way I found to work around it is to convert up to the point of divergence, `hg bundle` the bad revision in the source, apply it to the destination, add a line to the shamap, and fire off the conversion again. But I suspect that there's more to it than just the octopus merge because I also have a commit in the same repo, done in Mercurial (well after the conversion) that is exhibiting a similar issue (and it's not a merge commit). I'm almost positive that it was created with 4.4 or later. Any ideas? [1] https://www.mercurial-scm.org/pipermail/mercurial/2018-June/050924.html
Thu, 05 Jul 2018 15:07:29 -0400 convert: add a config knob for not saving the bzr revision
Matt Harbison <matt_harbison@yahoo.com> [Thu, 05 Jul 2018 15:07:29 -0400] rev 38572
convert: add a config knob for not saving the bzr revision Now that the timestamp is fixed, the log of the Mercurial repo is still unstable with --debug, because the bzr commit ID keeps changing. Both hg and git implement `convert.*.saverev`, so do the same here.
Thu, 05 Jul 2018 15:07:29 -0400 test-bzr: use a fixed commit time
Matt Harbison <matt_harbison@yahoo.com> [Thu, 05 Jul 2018 15:07:29 -0400] rev 38571
test-bzr: use a fixed commit time This will help stabilize the hashes when converting to a Mercurial repo.
Wed, 23 May 2018 15:31:44 +0200 diff: use `context.diff` to produce diff
Boris Feld <boris.feld@octobus.net> [Wed, 23 May 2018 15:31:44 +0200] rev 38570
diff: use `context.diff` to produce diff We want to make sure `context.diff` if full featured. Using it in the main diff code path is a good way to do so. The end goal is to be able to easily compute diff between in-memory context.
Sat, 23 Jun 2018 15:03:05 +0200 context: no longer accept diff options as dictionnary
Boris Feld <boris.feld@octobus.net> [Sat, 23 Jun 2018 15:03:05 +0200] rev 38569
context: no longer accept diff options as dictionnary Since we already broke the API earlier in this stack, there are no point to introducing a new deprecation warning.
Sat, 23 Jun 2018 15:00:16 +0200 obsutil: pass a diffopts object to context.diff
Boris Feld <boris.feld@octobus.net> [Sat, 23 Jun 2018 15:00:16 +0200] rev 38568
obsutil: pass a diffopts object to context.diff
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip