match: remove ctx argument from code path down to _buildmatch()
'ctx' was there only for filesets.
match: compose 'set:' pattern as matcher
Baby step towards porting fileset to matcher composition.
We can't use the exactmatcher since it would provide a computed set as exact
paths. That's why we use the predicatematcher with fset.__contains__. This
will be cleaned up later.
The test change in test-glog.t means that the "set:copied()" pattern is no
longer be processed as a slow path. That's because the fset is empty. This
will also change in future patches.
match: resolve 'set:' patterns first in _buildmatch()
This just makes the next patch less complicated. The order of 'set:' and
'subinclude:' expansion doesn't matter.
match: add basic wrapper for boolean function
This serves as a generic wrapper for fileset predicates. In future patches,
a fileset expression will be mapped to a tree of matchers for a better support
of match attributes such as visitdir(). For example,
$ hg debugwalk -v 'set:contrib/** and binary()'
* matcher:
<intersectionmatcher
m1=<patternmatcher patterns='(?:contrib/.*$)'>,
m2=<predicatematcher pred=binary>>
...
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