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

[JuanLeon Lahoz <juanleon.lahoz@gmail.com>]

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