stringutil: move _formatsetrepr() from smartset
I'll add a matcher subclass wrapping a boolean function, which will use
buildrepr() to provide debugging information in a similar way to
smartset.filteredset.
pycompat: move rapply() from util
I want to use rapply() in utils.* modules, but that would introduce a
reference cycle util -> utils.* -> util. Moving rapply() to pycompat
should be okay since it mostly serves as a compatibility helper.
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
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
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.
test-bzr: use a fixed commit time
This will help stabilize the hashes when converting to a Mercurial repo.
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.
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.