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.
some problematic encoding (e.g.: cp932) uses ASCII alphabet characters
in byte sequence of multi byte characters.
"str.lower()" on such byte sequence may treat distinct characters as
same one, and cause unexpected log matching.
this patch uses "encoding.lower()" instead of "str.lower()" to
normalize strings for compare.
The use of "{datetime}" was unfortunate since I as a user never knew
if I was expected to do
hg log -d '>{2011-04-01}'
or
hg log -d '>2011-04-01'
The word "datetime" is also confusing -- calling it a date it much
simpler.
Regression from 9f0026001bfd. That previous commit is not supposed
to affect log calls without --follow, so we step out of this
codepath if follow is not True, and it's enough to fix the
regression.
When --follow is given, we fix the issue by taking into account
changesets that have a rev > maxrev to build the filegraph: even if
those files are not included in the final result, it's still needed
to walk correctly the graph from the end of the filelog to minrev, to
track accurately renames.
Without specifying the parent revision of the working copy, users will
update to tip, which is most likely the other head they were trying to
merge, not the revision they were at before the merge.
