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

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

Am 14.09.2010 01:14, schrieb Junio C Hamano:
> What makes untracked paths in the superproject different from the ones in
> a submodule?

That you can have a different state for each path inside the superproject
(modified, untracked etc.) while you can't have that for the paths in the
submodule (when looked at from the superproject): There is only a single
state available for the whole submodule, it's either modified or it isn't.
So IMO a modified submodule should tell the user: "There is a change in
this submodule so that when you commit/push your superproject now, others
might run into problems when fetching it; you want to be sure this is not
the case before doing that". And this is just the same thing you could
say about a file in the superproject when it shows up as modified, no?
And for submodules this definition must also include new yet untracked
files, as they are very likely to be missing in every but your work tree.


> "git diff" cannot be it as it does not show untracked paths
> in the superproject, so you are talking about "the user cannot tell from
> the 'git status' output", right?

Nope, it's "git diff" too. The thing that got me started working on this
topic was that "git gui" and "gitk" were quiet about submodules which
had modified tracked files and/or new untracked files, which lead to
real world problems where I work. And both use diff-index and diff-files
to get the paths they should display *and* to display the actual changes.
(And as "git diff" uses the same machinery under the hood as "git status"
does, everything fell into place pretty easily)

And I argue that this is sane behavior, as I'm sure other tools rely on
"git diff" or "git status" too to check if there are modifications to the
work tree (or they call run_diff_files() or run_diff_index() directly to
do that). So all of these should agree on what they are saying about the
state of a submodule, or things will get interesting. (Same goes for
describe, it should append the "-dirty" when "git status" or "git diff"
say a submodule is modified)

And this approach works really well at my dayjob. Since we are using it,
me and my colleagues are really happy with it, because we can't forget to
commit changes inside a submodule anymore. So judging from this real life
experience "ignore=none" is a very sane default.

But I admit that this change in behavior can be strange for long time
submodule users when they first encounter it. And if they still don't
like the new behavior after some consideration, they can disable it
easily using the new configuration options. But one of the advantages I
really liked when I started using git was that is was not able to forget
to commit new files anymore. So I suspect ignore=none is especially
useful for new users of submodules, because it is on the safe side, and
therefore should be the default setting. You can later turn the 'noise'
down if you want (just like some users do when using the "-uno" option
to "git status" if they don't want to be told about untracked files in
the superproject or its submodules).