> On 03 Jan 2018, at 00:12, SZEDER Gábor <szeder....@gmail.com> wrote:
>
> 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].
That was the missing piece. Thank you! I've used the exact command before
but I've never looked at the exit code. I just assumed that it would
behave like grep if there is no match (as you described in [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.
Makes sense. As I never specified the path, I did never see the error :-)
> [1] - Which makes me think whether we should consider '--error-unmatch'
> without any paths given on the command line as an error.
Agreed!
- Lars
