TRAVIS_COMMIT_RANGE includes commits unrelated to PR

[jawshooah]

The commit range stored in the TRAVIS_COMMIT_RANGE environment variable uses the triple-dot syntax r1...r2, which equates to "the set of commits that are reachable from either one of r1 or r2 but not from both".

This does not fit the description given in the documentation, which claims that TRAVIS_COMMIT_RANGE is "the range of commits that were included in the push or pull request".

In order to be accurate to that description, the commit range should use the double-dot syntax, r1..r2, which equates to "commits that are reachable from r2 excluding those that are reachable from r1". Otherwise, commits made to the target branch after the PR branch was created will be included in the commit range.

Refs Homebrew/homebrew-cask#12903

[wking]

I'm working around this with ${TRAVIS_COMMIT_RANGE/.../..} in my .travis.yml.

[jawshooah]

Any comment on this, maintainers?

[spuder]

+1

[LinusU]

@BanzaiMan any updates on this? ❤️ It would be nice to at least get the problem confirmed by someone working at Travis, maybe add the workaround to the documentation

[s9gf4ult]

Here the quote from git diff --help

       git diff [--options] <commit>...<commit> [--] [<path>...]
           This form is to view the changes on the branch containing and up to the second <commit>, starting at a common ancestor of both <commit>. "git diff A...B" is equivalent to "git
           diff $(git-merge-base A B) B". You can omit any one of <commit>, which has the same effect as using HEAD instead.

and here from git logrevisions

       The .. (two-dot) Range Notation
           The ^r1 r2 set operation appears so often that there is a shorthand for it. When you have two commits r1 and r2 (named according to the syntax explained in SPECIFYING
           REVISIONS above), you can ask for commits that are reachable from r2 excluding those that are reachable from r1 by ^r1 r2 and it can be written as r1..r2.

       The ... (three dot) Symmetric Difference Notation
           A similar notation r1...r2 is called symmetric difference of r1 and r2 and is defined as r1 r2 --not $(git merge-base --all r1 r2). It is the set of commits that are reachable
           from either one of r1 (left side) or r2 (right side) but not from both.

So git diff and git log undertstands three dots differently. In fact three dots for git diff is like two dots for git log. The common syntax which works same is ^rev1 rev2

git log ^rev1 rev2
git diff ^rev1 rev2

will work with same commits set.

[marc-h38]

tl;dr: convert ${TRAVIS_COMMIT_RANGE} to double dots only for git log, not for git diff

The commit range stored in the TRAVIS_COMMIT_RANGE environment variable uses the triple-dot syntax r1...r2, which equates to "the set of commits that are reachable from either one of r1 or r2 but not from both".

That's true for git log but as explained by @s9gf4ult , the triple dots mean something different (and very useful) for git diff. In fact the triple dotted ${TRAVIS_COMMIT_RANGE} is the perfect argument for git diff --name-only.

[marc-h38]

So git diff and git log undertstands three dots differently. In fact three dots for git diff is like two dots for git log.

and vice-versa!

          *---*---PR pull request
         /
--*---base---*----upstream

     Double dots        |  Triple dots
       upstream..PR     |        upstream...PR
------------------------+--------------------------
diff   upstream  PR "V" |  base             PR "/" 
log    ^base     PR "/" | ^base  upstream   PR "V"

[pprindeville]

Sounds like there's an issue with git. Has a bug been filed against it?

[marc-h38]

Git user interface issues like this one are unfixable, imagine how many things this would break.

OK, one way to "fix" interface issues like this is to add new commands and leave the old ones as they are. For instance the new git switch helps you avoid the confusing and dangerous git checkout : https://www.infoq.com/news/2019/08/git-2-23-switch-restore/
So maybe there could be new git helps revisions syntaxes that don't use dots? I don't know.

For similar backward compatibility reasons it's way too late to change TRAVIS_COMMIT_RANGE. This issue should stay closed.

On the other hand Travis could/should have additional variables, for instance Gitlab has CI_COMMIT_REF_NAME, CI_COMMIT_SHA, CI_COMMIT_BRANCH and a good few others. Feel free to file a new Travis issue if none yet.