Re: [RFC] Submodules in GIT

[Daniel Barkalow <barkalow@iabervon.org>]

On Tue, 28 Nov 2006, Sven Verdoolaege wrote:

> On Tue, Nov 28, 2006 at 01:37:54PM -0500, Daniel Barkalow wrote:
> > If submodule was the only thing that got changed, it's not dirty; if it 
> > were dirty, some of its contents would also have gotten changed.
> 
> For me, the commit is the only "content" of the subproject that the
> superproject should care about, so the submodule being dirty or not
> is completely irrelevant (for committing), but it seems you see the
> subproject more as a (working) tree than as a commit.

I think we agree on the tree/commit/object database model part.

I think we disagree on how the working *directories* relate. I see the 
checked-out state of a submodule as being relevant to the checked-out 
state of the supermodule, such that dirty state in the submodule directory 
is dirty state in the supermodule directory.

> > Surely:
> > 
> > "git commit submodule/foo bar"
> 
> I wouldn't dream of doing such an operation, because it doesn't make
> sense to me.  (So as far as I'm concerned, you can make it do whatever
> you'd like it to do.)  You can only commit the subproject as a whole.

I'm thinking that users of subprojects will often want to work on the
subprojects rather than exclusively using commits prepared by other 
people, and it's too much trouble to have to do the work in a repository 
for just the subproject and pull it into the superproject's submodule to 
test it. So the submodule working directory needs to function as a working 
directory for the subproject. Then

  "cd submodule; git commit foo"

does the obvious thing, but that should be the same as

  "git commit submodule/foo" (since it normally is)

and then it makes sense to let you do multiple commits with a single 
command when the paths end in different modules, since that's obviously 
what you're requesting, and then -a must do all of them.

	-Daniel