#!/usr/bin/env bash
CHANGED_FILES=`git diff --name-only master src/`
for CHANGED_FILE in $CHANGED_FILES; do
echo ../$CHANGED_FILE
done
Ordinarily, this works fine but for some branches, Travis doesn’t recognize master and fails with this:
fatal: ambiguous argument ‘master’: unknown revision or path not in the working tree.
Use ‘–’ to separate paths from revisions, like this:
‘git […] – […]’
Is master (the target branch) not guaranteed to exist? Is a repository not necessarily cloned by the time items under env are set?
Is there a configuration step to ensure a clone that contains the target branch to diff against is performed?
Not that I’m aware of, but of course you can run any commands in .travis.yml or in your script, including a git fetch to
(preferably shallow) fetch the master branch.
Have you tried reproducing this issue with a fresh clone locally?
I have and have not been able to recreate this error locally. master exists and git diff --name-only master src/ in my feature branch correct report the file-paths that have changed.
The output of the above command should be visible in the job’s log,
and should look like this:
git fetch
From https://github.com/....
* [new branch] master -> origin/master
So while it does fetch the remote’s master branch, it does not
create a master branch in the local repository, but stores it under refs/remotes/origin/master, because that’s what the previous git remote ... command told it to do.
You could either:
Leave your before_script as is, and update your other script to
diff against origin/master instead.
Update your before_script to run git fetch --depth=50 origin refs/heads/master:refs/heads/master.