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

--

[ message continues ]

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

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.



	
--

[ message continues ]

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

[ message continues ]

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

--

[ message continues ]

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

--

[ message continues ]

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

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

Yup, that's the spirit.
--

[ message continues ]