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

From: Ash Holland <ash@sorrel.sh>
Date: Sep 20, 2020, 00:17 UTC
Message-ID: <CAHJUbDjSS-fWjeJkD49yEPmRKZQLYSW0R9-PhzFem1QsEuJUOQ@mail.gmail.com>
In-Reply-To: <xmqqo8m1k542.fsf@gitster.c.googlers.com>

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`:

Show 7 quoted lines

> 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 :)