Re: `git describe --dirty` doesn't consider untracked files to be dirty

On Sat, 19 Sep 2020 at 19:12, Junio C Hamano [off-list ref] wrote:

This is worth fixing.  I am leaning towards saying that `diff` is
wrong in this case, but I am OK to consider unifying the behaviour
the other way and making `describe --dirty` more strict.

fwiw, my preference would be for the second behaviour; I have a release
script which complains at me if I've forgotten to commit something, and
to avoid making a release with new uncommitted files I currently have to
use both `git describe --dirty` (to check for modifications to tracked
files) and also `git ls-files --others --exclude-standard` (to check for
untracked files).

maybe there's a better plumbing command I should be using in a script,
but your example of the wildcard build rule also would suggest that
`describe` should be changed, not `diff`:

Having said all that, a source that was forgotten to be added, yet
affects the built product by a build rule with wildcard e.g.
"compile all *.c files and link them into a single binary", would
happen in real life, so from that point of view, appending "-dirty"
only when there is a local modification may not be all that useful,
and tweaking the "--dirty" option to also pay attention to untracked
(but not ignored) might have merit.

lastly, by appeal to `git clean`'s documentation: "Remove untracked
files from the working tree"

if you clean a repository by removing untracked files, then untracked
files surely make the working tree dirty :)