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