Clarify whether or not there are untracked changes

[mjrlee]

Refer to issue #990 for an instance where this has caused confusion.

[cpu]

Hi @MartinLeedotOrg,

Thanks for the PR!

I tried this locally and I think it doesn't quite work the way you intended and now reports no untracked changes when there are in fact some.

$> git status
HEAD detached at se/pr/1006
nothing to commit, working tree clean

$> touch foobar.txt

$> git status
HEAD detached at se/pr/1006
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	foobar.txt

nothing added to commit but untracked files present (use "git add" to track)

$> git diff-index --quiet HEAD -- && echo "no" || echo "yes";
no

It might be easier to try and address this at the Jinja2 layer by using a default filter or some kind of check for an empty value.

Or maybe it's easier to try and unravel this weird Bash boolean logic. Up to you!

[mjrlee]

I think this is because we're using git diff-index instead of git status.

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
$ git diff-index  HEAD
$ touch foo
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    foo

nothing added to commit but untracked files present (use "git add" to track)
$ git diff-index HEAD
$ git add foo
$ git diff-index HEAD
:000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A  foo

[cpu]

I think this is because we're using git diff-index instead of git status.

@MartinLeedotOrg Ahhh! That makes sense! Thanks for explaining. I understand now why an untracked file doesn't flip the status (and agree that it shouldn't). 👍

[cpu]

Thanks again @MartinLeedotOrg 🏆