git-status for submodules

git-status for submodules

[Chris Frey]

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

Re: git-status for submodules

[Junio C Hamano]

Chris Frey <cdfrey@foursquare.net> writes:

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

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:

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

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.



	

Re: git-status for submodules

[Johan Herland]

On Friday 21 November 2008, Junio C Hamano wrote:
> Chris Frey <cdfrey@foursquare.net> writes:
> > 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.
>
> 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:
> > 	cd super
> > 	vi newsuper
> > 	vi existing_file
> > 	cd sub
> > 	vi newsub
> > 	cd ..
> > 	git status
>
> 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.

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

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: git-status for submodules

[Chris Frey]

On Fri, Nov 21, 2008 at 04:27:10PM +0100, Johan Herland 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

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

Re: git-status for submodules

[Chris Frey]

On Fri, Nov 21, 2008 at 06:56:15AM -0800, Junio C Hamano wrote:
> My understanding is that this is exactly by design.  The supermodule
> tracks which commit in the subproject is bound to the tree location.


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

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

Re: git-status for submodules

[Junio C Hamano]

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.