Re: [PATCH] builtin/describe.c: ignore untracked changes in submodules

[Jens Lehmann <Jens.Lehmann@web.de>]

>Do you agree that there is an inconsistency between how untracked content is
>treated at the super-project level and at the submodule level? 

Yes, but I - and others included in that discussion some time ago - could not
come up with a sane and simple solution to that problem.


> Any thoughts
>about how the behavior should be made to be consistent?

The core of this issue is that for git a file is either untracked, modified or clean.
But submodules can have every combination of all these states - as they consist
of multiple files - and additionally their HEAD can differ from the commit recorded
in the superproject. So basically I see two ways to handle that:
a) add new states for an entry to represent all missing combinations of possible
   states for submodules and tell all porcelain to handle these.
b) simplify this problem by having a submodule show up as modified when
   either of these three conditions are met (and enable the user to choose what
   conditions she wants to see and what not).

Obviously a) will complicate all git by a large degree just for the sake of submodules.
I am arguing for b), because submodules itself can be seen as a bunch of files which
don't interest me as single entities until I want to take a closer look. I think the issue
we are discussing here is the price we have to pay for this abstraction. I am very
open to proposals how to better handle that but so far I haven't seen any.


>Perhaps the default setting of submodule.<name>.ignore should be 'untracked'?

I still vote for none. I think the default should be to not have untracked files in
your projects (like you should not have warnings when compiling your project).
If that is not wanted, just use the configuration options git provides to change it.