It acts like it’s going to call git, but doesn’t call TRAVIS_PULL_REQUEST_BRANCH. The reason I think is because it’s on a forked repo, and I possibly didn’t rebase correctly and then in turn using git rev-parse then after do what ppl on git called a “double back” do git cherry-pick - this is all to try and have git and call TRAVIS_PULL_REQUEST_BRANCH.
The structure of our project (I work for a fairly large sized company), t paths in which the git change applied cleanly are updated both in the index file and in our working tree, with a few branches like main, master and testing.
I also gave it a try with git rev-list and $TRAVIS_COMMIT_RANGE but it includes also the new commits on the master branch.
Any idea how to get the files that are modified exclusively by the PR. I’ve been trying for hours now. @Montana I tag you because you seem to help me every time!
From the flow I’m seeing to branches to the actual checkouts (which I’m assuming you switched back and forth between branches, this is sometimes called ‘branch flipping’) there’s no reason to be using the environment variable $TRAVIS_PULL_REQUEST_BRANCH in this scenario. You’ve caused yourself a quagmire in that regard.
If I were you, I’d use git log --oneline grab the SHA1 value, then reset it using the obvious git reset. As usual make sure there’s also nothing stashed, if there is use git stash pop to relieve that issue.
The source tree within Travis will be your pull request merged back into the most recent target branch (whether that be master, main, test, etc). So for example, ( $TRAVIS_BRANCH , likely master ). That is, HEAD is your pull request merged into $TRAVIS_BRANCH. I hope you’re still following.
What you want are only the changes between your pull request and `master. Any other branch at this point can be disregarded, this ultimately can be retrieved with:
$(git diff --name-only HEAD $(git merge-base HEAD $TRAVIS_BRANCH))
If you want a quicker way and less verbose route of using this method you can do: