Re: git-status for submodules

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

Chris Frey <cdfrey@foursquare.net> writes:

> It's true that subproject X has to be able to stand on its own.  That
> is important from git's perspective as well as for managing subprojects
> in general.
>
> But I don't see the advantage in hiding submodule information from the
> supermodule, and if that hiding is by design, I think the design is wrong.

There is no "wrong" design in git.  There are ones that do not cover 360
degrees of the field, because nobody designed out let alone coded to cover
such use cases.

> In order to manage the various modules effectively (actually, in order to
> manage any git repo effectively), you need to know what's changed,
> and git-status is the way to do that.  I don't see why submodules should
> break that.

Changes to parts of submodules are fundamentally different from changes to
parts of your main project.  A change to what commit the superproject
wants for a submodule is at the same level as a change to what content the
superprojects wants for a blob.

It is not unreasonable to want to have both modes of operation, one that
shows the uncommitted details in the submodule even when you are viewing
from the superproject (which does not exist), and one that does not (which
does exist, because somebody felt need for it and coded so).

In order to see the status of your working tree, you may want to take into
account what untracked files are in there, but some people do not want to,
so there is an option to pick which behaviour you want.  We would need a
similar switch.

> With the new submodule foreach command, though, it should be possible
> to add that as a config option, similar to the way submodule summary
> is handled now.  Maybe I can cook up a patch for that.

Yup, that's the spirit.