Bug 5376 - hg log -pf FILE does not print patches sometimes when it should
Summary: hg log -pf FILE does not print patches sometimes when it should
Status: RESOLVED FIXED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: default branch
Hardware: All All
: wish bug
Assignee: Bugzilla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-22 12:58 UTC by Jun Wu
Modified: 2016-11-05 13:39 UTC (History)
3 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jun Wu 2016-09-22 12:58 UTC
Test case:

  $ cat >> $HGRCPATH << EOF
  > [diff]
  > git=1
  > [experimental]
  > evolution = createmarkers
  > EOF

  $ hg init repo
  $ cd repo

  $ for i in 1 2; do
  >   echo $i >> a
  >   hg commit -A a -m $i
  > done

  $ hg update 0 -q
  $ echo 2 >> a
  $ touch b
  $ hg commit -A b -A a -m '2 with b' -q

the following works as expected

  $ hg log -G -p -T '{rev}:{node|short} {desc}'
  @  2:281cd4d94b56 2 with bdiff --git a/a b/a
  |  --- a/a
  |  +++ b/a
  |  @@ -1,1 +1,2 @@
  |   1
  |  +2
  |  diff --git a/b b/b
  |  new file mode 100644
  |
  | o  1:1ed24be7e7a0 2diff --git a/a b/a
  |/   --- a/a
  |    +++ b/a
  |    @@ -1,1 +1,2 @@
  |     1
  |    +2
  |
  o  0:eff892de26ec 1diff --git a/a b/a
     new file mode 100644
     --- /dev/null
     +++ b/a
     @@ -0,0 +1,1 @@
     +1

with -p FILE, it produces wrong output:

  $ hg log -G -p -f a -T '{rev}:{node|short} {desc}'
  @  2:281cd4d94b56 2 with b
  |
  o  0:eff892de26ec 1diff --git a/a b/a
     new file mode 100644
     --- /dev/null
     +++ b/a
     @@ -0,0 +1,1 @@
     +1

expected output is:

  $ hg log -G -p -f a -T '{rev}:{node|short} {desc}'
  @  2:281cd4d94b56 2 with b
  |  --- a/a
  |  +++ b/a
  |  @@ -1,1 +1,2 @@
  |   1
  |  +2
  |
  o  0:eff892de26ec 1diff --git a/a b/a
     new file mode 100644
     --- /dev/null
     +++ b/a
     @@ -0,0 +1,1 @@
     +1
Comment 1 Jun Wu 2016-09-22 18:45 UTC
The related code is at https://www.mercurial-scm.org/repo/hg-committed/file/tip/mercurial/cmdutil.py#l1952. I'm going to find a way to fix it.
Comment 2 Pierre-Yves David 2016-09-22 19:20 UTC
I confirm the test case fails ('hg log -pr X' differ from 'hg export X')
Comment 3 Yuya Nishihara 2016-09-23 09:29 UTC
Perhaps the start revs should be taken from fctx.introrev().

Coincidentally, I'm working on follow(pattern, multi-startrevs) revset.
Comment 4 Pierre-Yves David 2016-09-23 17:15 UTC
Yuya, your comment seems to point out that you know what is going on here. However is a bit too scarce for me to actually get what is going on. Can you expand your explanation a bit?
Comment 5 Yuya Nishihara 2016-09-23 19:23 UTC
_makefollowlogfilematcher() should track ancestors in the same way
as follow() revset. Otherwise fcache[rev] wouldn't be populated correctly.

https://www.mercurial-scm.org/repo/hg-committed/file/3.9.1/mercurial/revset.py#l1013

In the example of this issue, the first revision is missed because
fctx.linkrev() != fctx.introrev().

IMHO, they should use a common function to track file ancestors to avoid
this kind of bugs.
Comment 6 HG Bot 2016-09-28 19:45 UTC
Fixed by https://selenic.com/repo/hg/rev/2963fba2d18a
Yuya Nishihara <yuya@tcha.org>
log: copy the way of ancestor traversal to --follow matcher (issue5376)

We can't use fctx.linkrev() because follow() revset tries hard to simulate
the traversal of changelog DAG, not filelog DAG. This patch fixes
_makefollowlogfilematcher() to walk file ancestors in the same way as
revset._follow().

I'll factor out a common function in future patches.

(please test the fix)
Comment 7 Jun Wu 2016-11-05 13:39 UTC
I can confirm it is fixed. The related code path should be also interesting to resolve bug 5411.