git-status for submodules

Hi,

I'm using git 1.6.0.4 and trying to make submodules work for me. The init/add/update steps are a bit tedious, but workable. The problem I have is when I make a change in a submodule, then git-status does not show the change.

For example, assuming a directory structure like:  super and super/sub

	cd super
	vi newsuper
	vi existing_file
	cd sub
	vi newsub
	cd ..
	git status

This will show newsuper as needing to be added, and existing_file as changed, but newsub will not appear.

Is there a way to accomplish this?

Thanks,
- Chris

Chris Frey <cdfrey@foursquare.net> writes:

My understanding is that this is exactly by design. The supermodule tracks which commit in the subproject is bound to the tree location.

A mere act of changing something in the subproject directory is just a single, incomplete step to create a new commit in the subproject and will not be seen by the superproject's status. Instead of this workflow:

the submodule support is geared toward supporting this layout:

	- "super" has a subproject X at "sub"

        - When you do a real work on the subproject X, you do so as if
          there is no supermodule.  IOW, subproject X has to be able to
          stand on its own.

One extreme case is you have a(nother) clone of subproject X that is independent from "super", do the real work there and create new commit, and update the subproject X inside "super". In such a workflow, "super" will never see an intermediate state between commits in the subproject directory.

On Friday 21 November 2008, Junio C Hamano wrote:

Chris' workflow is farily easily supported by running git-status within each submodule, like this:

git submodule foreach "git status; true"

If the above is too cumbersome to type, one can easily wrap an alias around it:

git config alias.substatus 'submodule foreach "git status; true"' git substatus

Have fun! :)

...Johan

On Fri, Nov 21, 2008 at 04:27:10PM +0100, Johan Herland wrote:

Fascinating. :-)  This is not yet released, I see, but thanks very much.

Looking at the git sources, submodule foreach doesn't seem to recurse, for the nested submodule case Junio mentioned. It's still a good start.

- Chris

On Fri, Nov 21, 2008 at 06:56:15AM -0800, Junio C Hamano wrote:

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. 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.

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.

- Chris

Chris Frey <cdfrey@foursquare.net> writes:

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.

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.

Yup, that's the spirit.