Re: [PATCH 0/6] Initial subproject support (RFC?)

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 10 Apr 2007, Alex Riesen wrote:
> 
> It is already "merged somewhere": as soon as the patches left landed
> on vger, it is not possible to loose (and even destroy) them.
> The feature is just too much sought after.

Well, unless it hits something like Junios 'pu' (or 'next') branch, or 
somebody (like you?) ends up maintaining a repo with this, it's just 
unnecessarily hard to have lots of people working together on it..

I'm obviously interested in working on it, but at the same time, I don't 
expect to be a primary *user* of it, so I'm hoping others will come in and 
start looking at it.

It looks promising that you're getting involved, but I suspect you may be 
a bit too optimistic when you say "just too much sought after". We've been 
*talking* about subprojects for a long long time, and we've had other 
patches fail. So...

> > For example, with just two smallish updates:
> >  - teach "git upload-pack" not to try to follow gitlinks
> >  - teach "git read-tree" to check out a git-link as just an empty
> >    subdirectory
> 
> which also should fix switching between the branches with subprojects.

Yes. It would require either git-read-tree or the git-checkout script 
around it knowing to then also check out the subproject branches.

It's actually not *entirely* obvious what you should do when you switch 
branches (or even just do a "git reset --hard") in the superproject. The 
branches in the subprojects are likely to be totally different from the 
superproject, so as far as I can see, you end up having two choices when 
you reset a subproject:

 - either basically create a "disconnected HEAD" in the subproject(s) when 
   you switch them around as a consequence of resetting/switching the 
   branch in the superproject.

 - or you'd stay on the same branch in the subproject, and just reset that 
   branch..

 - or you describe the branch name in the ".gitmodules" file in the
   superproject, and use whatever branch in the submodule that is 
   described in the supermodule that you reset/check-out.

 - or possibly other policies.

So there is bound to be various "policy" issues like this worth sorting 
out. I don't think they matter that deeply.

I would _personally_ tend to like the notion of using ".gitmodules" in the 
supermodule to describe things like this, exactly because it's a policy 
decision - not something that git itself should really decide about, but 
that the supermodule maintainers can just decide to agree on.

But I haven't really even thought about all the things I'd want to have in 
the .gitmodules. We'd obviously need to list the default URL's for the 
submodules some way etc, but I haven't really sat down and thought about 
what all the higher-level porcelain really would need to know.

I suspect that somebody who has used and set up CVS "modules" setups 
should be thinking about that. I've been a "stupid user" for CVS modules 
setups, but I've never actually needed to really know how they *work*.

		Linus