Junio C Hamano <gitster@xxxxxxxxx> writes: > Aaron Schrab <aaron@xxxxxxxxxx> 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.
