Inconsistent results obtained regarding how git decides what commits modifies a given path

Inconsistent results obtained regarding how git decides what commits modifies a given path

[JuanLeon Lahoz]

When I use git rev-list (or git log) with the -- option to restrict commits to
those that modify a path, I am getting resuls where I fail to see the
consistency. Worse than that, results vary with git version (pre 1.8.4, results
were consistent; in 1.8.4 or 2.5.0 they don't seem consistent to me, and they
are different than in older versions; I rather like more the pre 1.8.4
behaviour).

Inconsistencies (inside same git version) or differences (across versions)
affects only to merge commits that affect (depending on definition) to a file.

As per manual, "Commits are included if they are not TREESAME to any parent",
but I think I am getting false positives with git versions >= 1.8.4.

Here is an example where I find the results that confuse me:

-------------------------------------------

#!/bin/bash -e
git init
git commit --allow-empty -m initial

# Create four branches, each one enclosing the previous one
echo v1 > version
git add version
git commit -m v1
git branch b1

echo v2 > version
git add version
git commit -m v2
git branch b2

echo v3 > version
git add version
git commit -m v3
git branch b3

echo v4 > version
git add version
git commit -m v4
git branch b4

git tag checkpoint
# We create a couple of merges
git checkout -b b2_3 b2
git merge --no-ff b3

git checkout -b b1_4 b1
git merge --no-ff b4

# This prints nothing on git < 1.8.4; prints a commit that corresponds with
# "Merge branch 'b3' into b2_3" in git >= 1.8.4 (tested with 1.8.4 and 2.5.0)
echo COMMITS checkpoint..b2_3: $(git rev-list checkpoint..b2_3 -- version)
# This prints nothing on any git version I tested.
echo COMMITS checkpoint..b1_4: $(git rev-list checkpoint..b1_4 -- version)

-------------------------------------------

Is that a bug or I am misunderstanding something basic?

Thanks
juanleon

Re: Inconsistent results obtained regarding how git decides what commits modifies a given path

[Jeff King]

On Fri, Aug 07, 2015 at 08:42:52AM +0200, JuanLeon Lahoz wrote:

> # This prints nothing on git < 1.8.4; prints a commit that corresponds with
> # "Merge branch 'b3' into b2_3" in git >= 1.8.4 (tested with 1.8.4 and 2.5.0)
> echo COMMITS checkpoint..b2_3: $(git rev-list checkpoint..b2_3 -- version)

I would expect the current behavior (to show the merge). The fix bisects
to d0af663 (revision.c: Make --full-history consider more merges,
2013-05-16). See that commit message, or the thread at:

  http://thread.gmane.org/gmane.comp.version-control.git/220624

for more detail. Though I'm not 100% it was intentional...

> # This prints nothing on any git version I tested.
> echo COMMITS checkpoint..b1_4: $(git rev-list checkpoint..b1_4 -- version)

This looks like a bug to me. It should be the exact same simplification
case as b2_3 (we have a merge whose outcome matches the second parent,
but not the first). One obvious difference, if you look at:

  git log --oneline --graph --decorate checkpoint b2_3 b1_4

is that in the b1_4 case, the immediate parent of the merge is marked as
UNINTERESTING|BOTTOM, because it is "checkpoint". Whereas in the b2_3
case, it is simply UNINTERESTING, as it is the _parent_ of checkpoint,
and we propagated the flag.

This difference matters in relevant_commit(). In the b2_3 case, we
consider the second parent irrelevant, because it is "just"
UNINTERESTING. But in the b1_4 case, we consider it relevant, due to the
BOTTOM flag. This code comes from 4d82660 (revision.c: discount side
branches when computing TREESAME, 2013-05-16).

And that commit claims that we exclude irrelevant parents when
determining TREESAME. Meaning the b2_3 case has only one relevant parent
(which is different, making the merge !TREESAME). Whereas b1_4 has two
relevant parents, we realize we are TREESAME to the second one, and
simplify away the merge.

At this point, I'm pretty confused (and reading the comments added by
4282660 only confused me further). I would have thought the TREESAME was
independent of the limiting of the traversal, but clearly it is not
intended to be. But this weird BOTTOM exception makes even less sense to
me.

So I'll give up for now. Maybe somebody else can pick it up from there,
or perhaps it will make more sense to me in the morning.

-Peff