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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Aaron Schrab <aaron@schrab.com> writes:
>
>> It's perhaps worth noting that submodules are already considered dirty
>> when untracked files are added:
>>
>> $ git diff vim/bundle/fugitive
>>
>> $ echo foo >vim/bundle/fugitive/foo
>>
>> $ git diff vim/bundle/fugitive
>> diff --git i/vim/bundle/fugitive w/vim/bundle/fugitive
>> --- i/vim/bundle/fugitive
>> +++ w/vim/bundle/fugitive
>> @@ -1 +1 @@
>> -Subproject commit caf3b1d5696e8d39a905e48f1e89d8c0c565168c
>> +Subproject commit caf3b1d5696e8d39a905e48f1e89d8c0c565168c-dirty
>
> In other words, if we do this in the state:
>
>   $ git -C vim/bundle/fugitive describe --dirty
>
> the submodule directory is not reported as dirty.
>
> 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.

"git diff" family of commands know the "--ignore-submodules=<what>"
option, and it seems that by default they do not ignore "untracked".

This seems to be what causes its output fail to pretend as if output
from "git describe --dirty" in the submodule directory were used on
the working-tree side of the comparison and leads to this
inconsistency.  Obviously we can tweak the default of "diff" family
of commands to ignore untracked paths in submodules and that would
make them consistent with "git describe --dirty", but that would not
give us a new way to tweak behaviour of "git describe" like we can
do with "git diff --ignore-submodules=<what>".

The current "untracked files do not count as part of dirtiness"
default behaviour of "git describe --dirty" is relied upon by
people's existing scripts, and changing it from under them would
cause unnecessary breakage.  But that does not have to stop us from
teaching "git describe --dirty" an optional "--ignore=<what>"
option, similar to what "diff --ignore-submodules=<what>" option
does to the submodules.

The first step would be to allow those who want their "git describe
--dirty --ignore=none" (untracked files are counted as dirtiness, to
be consistent with how "git diff" sees submodule directories by
default) to use presence of untracked files as dirty.  This is a
safe first step and can be done without breaking any existing users.

After that materializes and users gain experience, we may want to
discuss if we want to change the default behaviour of "git describe
--dirty" or what value the future default should be, how bad the
compatibility breakage would be if we change the default, and what
the transition plan and schedule looks like.  But we do not have to
do such a longer-term planning before the first step happens.