log: fix --follow FILE ancestry calculation
Currently, --follow FILE looks for a FILE filelog, scans it and collects
linkrevs and renames, then filters them. The problem is the filelog scan does
not start at FILE filenode in parent revision but at the last filelog revision.
So:
- Files not in the parent revision can be followed, the starting node is
unexpected
- Files in the parent revision can be followed from an incorrect starting
node.
This patch makes log --follow FILE fail if FILE is not in parent revision, and
computes ancestors of the parent revision FILE filenode.
test-glog: extend a test before fixing --follow issues
The changes add a lot of noise to the test output, I prefer to separate it from
the changes which are to be introduced by --follow fixes.
graft: use proper revisions for copy detection (
issue3265)
graphlog: paths/-I/-X handling requires a new revset
The filtering logic of match objects cannot be reproduced with the existing
revsets as it operates at changeset files level. A changeset touching "a" and
"b" is matched by "-I a -X b" but not by "file(a) and not file(b)".
To solve this, a new internal "_matchfiles(...)" revset is introduced. It works
like "file(x)" but accepts more than one argument and its arguments are
prefixed with "p:", "i:" and "x:" to be used as patterns, include patterns or
exclude patterns respectively.
The _matchfiles revset is kept private for now:
- There are probably smarter ways to pass the arguments in a user-friendly way
- A "rev:" argument is likely appear at some point to emulate log command
behaviour with regard to filesets: they are evaluated for the parent revision
and applied everywhere instead of being reevaluated for each revision.