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

[Ash Holland <ash@sorrel.sh>]

On Sat, 19 Sep 2020 at 19:12, Junio C Hamano <gitster@pobox.com> 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 :)