hg log 'filename' not showing merges?

[Alexis S. L. Carvalho]

Thus spake Matt Mackall:
> On Mon, May 21, 2007 at 02:57:59PM +0200, Lars Marowsky-Bree wrote:
> > Hi all,
> > 
> > I'm a bit surprised by hg log 'filename' not showing merges.
> > 
> > We use hg for the Linux HA project; the repository in question is
> > http://hg.linux-ha.org/dev. (My client is using 0.9.3.)
> > 
> > In da3a73d1d6d4, changes were made to lrm/lrmd/lrmd.c. It was pulled and
> > merged into a different workspace by Alan in cc868e409675. (That merge,
> > accidentially, reverted the changes to lrmd.c, but not the others.)
> > 
> > They were merged and pushed to our dev repo again in d2639cbc3351. From
> > this point on, the "dev" repo has backed out those changes as well.
> > 
> > Further changes to lrmd.c were made in other changesets.
> > 
> > Now, that all works as expected, and the merge reversing the changes is
> > a clear pilot error.
> > 
> > But, "hg log -p lrm/lrmd/lrmd.c" does not show cc868e409675 as part of
> > the file's history, so it wasn't exactly obvious to spot the changeset
> > which had screwed up.
> > 
> > Is this expected behaviour?
> 
> Probably. If there wasn't an actual three-way merge in the merge
> changeset, then there wasn't a file-level change for that changeset.

I think there should've been a three-way merge of lrm/lrmd/lrmd.c in
changeset cc868e409675:

$ hg log -v -r cc868e409675
changeset:   10578:cc868e409675
parent:      10577:7052caef59e5
parent:      10527:0d11597b384f
user:        Alan Robertson <alanr at unix.sh>
date:        Sat Apr 28 14:46:40 2007 -0600
description:
Upstream (/dev) merge


$ hg up -C 7052caef59e5                 #first parent
3 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ HGMERGE=true hg merge 0d11597b384f    #second parent
merging lrm/lrmd/lrmd.c
2 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)


The "merging lrm/lrmd/lrmd.c" message shows that $HGMERGE was called for
this file, and debugstate confirms that it's left in state "m":


$ hg debugstate | grep lrm/lrmd/lrmd.c
m 644      99460 05/21/07 15:31:34 lrm/lrmd/lrmd.c

$ hg status
M include/clplumbing/proctrack.h
M lib/clplumbing/proctrack.c
M lrm/lrmd/lrmd.c


Since, if I run "hg commit" here, a new revlog entry is added for
lrm/lrmd/lrmd.c and it's mentioned in the changelog, I think the actual
commit command was something like 

hg commit include/clplumbing/proctrack.h lib/clplumbing/proctrack.c

(i.e. it listed every file except lrm/lrmd/lrmd.c).  Because of the way
we construct the new manifest, the new revision would end up inheriting
the lrm/lrmd/lrmd.c file revision from its first parent.

If we look at the revlog for lrm/lrmd/lrmd.c, we see that it has 2
heads, even though the repo has only 1 head:
- c475c0795, which is the file revision present in tip
- 5b574de33, which is the file revision present in the second parent of
  that merge.

This is consistent with my theory above.

We should probably refuse to commit a merge if it doesn't touch all
files in state "m" in the dirstate, either in localrepo.commit or in
commands.commit (is there's a legitimate reason to create a commit like
that?).

Alexis