On Tue, Jan 2, 2018 at 8:40 PM, Lars Schneider <larsxschnei...@gmail.com> wrote:
>
>> On 31 Dec 2017, at 17:02, SZEDER Gábor <szeder....@gmail.com> wrote:
>>
>> Every once in a while our explicit .gitignore files get out of sync
>> when our build process learns to create new artifacts, like test
>> helper executables, but the .gitignore files are not updated
>> accordingly.
>>
>> Use Travis CI to help catch such issues earlier: check that there are
>> no untracked files at the end of any build jobs building Git (i.e. the
>> 64 bit Clang and GCC Linux and OSX build jobs, plus the GETTEXT_POISON
>> and 32 bit Linux build jobs) or its documentation, and fail the build
>> job if there are any present.
>>
>> Signed-off-by: SZEDER Gábor <szeder....@gmail.com>
>> ---
>> ci/lib-travisci.sh | 10 ++++++++++
>> ci/run-linux32-docker.sh | 2 ++
>> ci/run-tests.sh | 2 ++
>> ci/test-documentation.sh | 6 ++++++
>> 4 files changed, 20 insertions(+)
>>
>> diff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh
>> index 1543b7959..07f27c727 100755
>> --- a/ci/lib-travisci.sh
>> +++ b/ci/lib-travisci.sh
>> @@ -67,6 +67,16 @@ skip_good_tree () {
>> exit 0
>> }
>>
>> +check_unignored_build_artifacts ()
>> +{
>> + ! git ls-files --other --exclude-standard --error-unmatch \
>> + -- ':/*' 2>/dev/null ||
>
> What does "-- ':/*'" do?
It makes the whole thing work :)
':/*' is a pattern matching all paths, and '--others --exclude-standard'
limit the command to list files that are both untracked and unignored.
'--error-unmatch' causes the command to error out if any of the files
given on the command line doesn't match anything in the working tree,
in this case if there are no untracked-unignored files. Without a path
given on the cmdline '--error-unmatch' has basically no effect[1].
In a clean worktree:
$ git ls-files --other --exclude-standard --error-unmatch ; echo $?
0
$ git ls-files --other --exclude-standard --error-unmatch ':/*' ; echo $?
error: pathspec ':/*' did not match any file(s) known to git.
Did you forget to 'git add'?
1
The disambiguating double-dash is not really necessary, because the :/*
pattern can't be confused with any --options, but doesn't hurt, either.
> Plus, why do you redirect stderr?
To prevent the above error message from appearing in the trace log of a
successful build.
[1] - Which makes me think whether we should consider '--error-unmatch'
without any paths given on the command line as an error.
On a related note: that error message doesn't seem to make much
sense with '--other'...
