Re: Locating merge that dropped a change

Kevin Bracey [off-list ref] writes:

I think I've found the problem. It only doesn't work _if you specify
the file_.

Specifically, if I was missing an addition, my first attempt to find
it would be

  git log -p -m -S<addition> <file>

If the addition was lost in a merge, that doesn't even show the
addition, which is surprising, but intentional. The addition isn't
part of the HEAD version of <file>, so no point going down that path
of the merge. Fine. However, I expected this to work:

  git log --full-history -p -m -S<addition> <file>

But it doesn't. It finds the addition, but _not_ the loss in the merge
commit.

But this does work:

  git log -p -m -S<addition>

That really feels like a bug to me. By specifying a file, I've made it
miss the change, and I can see no way to get the change without making
it a full-tree operation.
... But I'd like some way to find merges
that drop code in a specified file, and surely "--full-history" is it?

Yeah, I think that is a bug.

    $ echo first >file
    $ git add file && git commit -m initial
    $ git checkout -b side
    $ echo second >file && git commit -a -m side
    $ git checkout - && >file && git add file && git commit -m lose
    $ git merge -s ours -m lost side
    $ git log -p -m --full-history -Ssecond -1 file

does not seem to find the commit that lost the line.

History simplification previously always treated merges as TREESAME
if they were TREESAME to any parent.

While the desired default behaviour, this could be extremely unhelpful
when searching detailed history, and could not be overridden. For
example, if a merge had ignored a change, as if by "-s ours", then:

  git log -m -p --full-history -Schange file

would successfully locate "change"'s addition but would not locate the
merge that resolved against it.

This patch changes the simplification so that when --full-history is
specified, a merge is treated as TREESAME only if it is TREESAME to
_all_ parents. This means the command above locates a merge that dropped
"change".

Signed-off-by: Kevin Bracey <redacted>
---
This would address my problem case - it passes existing tests, and covers
my (all-too-common) problem. But it would also need documentation changes and
a new test.

 revision.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/revision.c b/revision.c
index eb98128..96fe3f5 100644
--- a/revision.c
+++ b/revision.c

@@ -516,8 +516,14 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
 		}
 		die("bad tree compare for commit %s", sha1_to_hex(commit->object.sha1));
 	}
-	if (tree_changed && !tree_same)
-		return;
+
+	if (tree_changed) {
+		if (!tree_same)
+			return;
+
+		if (!revs->simplify_history && !revs->simplify_merges)
+			return;
+	}
 	commit->object.flags |= TREESAME;
 }
 

-- 
1.8.2.255.g39c5835