Subject: Re: [RFC] Submodules in GIT

From: Andreas Ericsson <[email-masked]>
Date: Thu, 30 Nov 2006 13:16:37 +0100

Andy Parkins wrote:
> On Wednesday 2006, November 29 16:03, Martin Waitz wrote:
> 
  >>  - when updating the supermodule, you have to take care that your
>>    submodules are on the right branch.
>>    You might for example have some testing-throwawy branch in one
>>    submodule and don't want to merge it with other changes yet.
> 
> What is the "right" branch though?  As I said above, if you're tracking one 
> branch in the submodule then you've effectively locked that submodule to that 
> branch for all supermodule uses.  Or you've made yourself a big rod to beat 
> yourself with everytime you want to do some development on an "off" branch on 
> the submodule.
> 

Perhaps I'm just daft, but I fail to see how you can safely track a 
topic-branch that might get rewinded or rebased in the submodule without 
crippling the supermodule. Wasn't the intention that the supermodule has 
a new tree object (called "submodule") that points to a commit in the 
submodule from where it gets its tree and stuff? Is the intention that 
the supermodule pulls all of the submodules history into its own ODB? If 
so, what's the difference between just having one large repository. If 
not, how can you make it not break in case the commit it references in 
the submodule is pruned away?

One possible way would ofcourse be to add something like this to the 
supermodule commit:
submodule directory/commit-sha1
tree submodule-tree-sha1

but then you're in trouble because the supermodule will have the same 
files as all the submodules stored in its own tree. I'm confused. Could 
someone shed some light on how this sub-/super-module connection is 
supposed to work in the supermodule's commit objects?

-- 
Andreas Ericsson                   [email-masked]
OP5 AB                             www.op5.se