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

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