Subject: Re: [RFC] Submodules in GIT

From: Andy Parkins <[email-masked]>
Date: Fri, 1 Dec 2006 10:29:26 +0000

On Friday 2006 December 01 09:57, Martin Waitz wrote:

> So why do you need the url hint committed to the supermodule?
> We don't store remote information in the object database, too.

That's why it was a hint, probably configured when you first create the 
submodule connection.

> Remember: this is still a distributed project, there is no one URL to
> any submodule.

That point applies equally to your "tracking a submodule branch" point, except 
mine is only a URL hint, to help when first cloning that supermodule.  In 
truth, the clone will be perfectly able to get the submodule objects from the 
upstream supermodule, maintaining the distributed nature easily.

> > I say:
> >  submodulecommithash points at a commit /in the submodule/
>
> But unluckily, this does not work.

Eh?  "Not work", we're talking about code that doesn't even exist, of course 
it doesn't "work".   Do you mean "doesn't work if we're using my 
implementation of submodules"?  Well that hardly seems like a fair attack.

> You really have to be able to traverse the entire commit chain
> from the supermodule into all submodules.

You can: when you hit a submodule tree object you set GIT_DIR to that 
submodule and continue.  If you don't do it like that then you have stored 
submodule trees in the supermodule and it's no longer a separate repository.  
Why you'd want to - I have no idea.  What purpose would you have for 
traversing the commit chain into the submodules?  The commit in the submodule 
is just a note of where that submodule was during the supermodule commit in 
question.

I notice though that you avoided my question: what does YOUR submodule object 
contain?  I really do want to know, as there is obviously a fundamental 
difference in what I think a submodule does and what you (and maybe everybody 
else) thinks a submodule does.  I'm perfectly willing to accept I'm wrong, 
but not without understanding how your method is going to work.

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE