Re: RFC: Subprojects

From: Petr Baudis <pasky@suse.cz>
Date: Jan 23, 2006, 01:22 UTC
Message-ID: <20060123012227.GW28365@pasky.or.cz>
In-Reply-To: <Pine.LNX.4.64.0601181214150.25300@iabervon.org>

Dear diary, on Wed, Jan 18, 2006 at 07:21:59PM CET, I got a letter where Daniel Barkalow <barkalow@iabervon.org> said that...

Show 8 quoted lines

> Okay, so you're using additional branch heads in the superproject to track 
> the current state of the subprojects. That makes sense, although I think 
> it would confuse people less if they were held separately. IIRC, 
> refs/subprojects/kernel/heads/master is a perfectly good ref name these 
> days, so that might be a good idea. That would also mean that 
> refs/tags/v2.6.14 and refs/tags/v2.7.2.3 wouldn't get confused (being 
> linux and gcc tags, respectively), because they'd be under the appropriate 
> subprojects.

I passionately agree - this is the only thing I do not like on the current Junio's proposal (besides that top-level subproject confusion). The way it is proposed, you are mixing different projects in a single refs namespace and I think that's *really* confusing.

Besides, you are going to get a lot of complications since to do merging properly you need two heads per subproject (its 'master' and 'origin' heads; and it's useful to have e.g. all the upstream heads called 'origin' since then you can say cg-fetch -r origin in the superproject and have all the subproject origins fetched as well) and you might want to have other subproject heads as well. Now, for different superproject heads, you want separate set of subproject heads. You can see the downward spiral from here, I guess... And multiply all that by two since you also have tags.

It actually took me a short while to realize that keeping separate subproject/.git/refs makes no sense precisely because for different superproject heads, you want a different set of subproject refs. So in line with Daniel's proposal, I'd propose:

	refs/subprojects/<superhead>/<subid>/heads/master

<superhead> is the name of the current HEAD (${#refs/heads/}). <subid> is a little more tricky - this should be the part after the equal sign in .git/mtab (or .git/binds or .git/subprojects or whichever is the name of the day). Obviously, you can just figure out something, but I'd like to assign this automagically.

OTOH, in Cogito I might as well just default to sha1 of something random (e.g. the path+commitid+time()) since I do not expect this to be normally referenced by a human; I just intend to switch from refs/ to refs/subprojects/<superhead>/<subid>/ when dealing with the subproject exclusively. ($GIT_REF_DIR (by default $GIT_DIR/refs) would come useful; I'll probably whip up a patch when I get to finally need it.)

Show 6 quoted lines

> I hope people will want to prepare their commits to the kernel subproject 
> as would be suitable for pushing to Linus, which would suggest that they'd 
> tend to do a commit in the kernel subproject embedded in their 
> superproject separately from doing the commit in the superproject, and 
> so the branch head would match the index but not the bind line when they 
> got to committing the superproject.

FWIW, my idea is that it should be "a seamless experience for the user" (tm) to do development in a subproject of another project, and I can see no reason why should that be hard to do in any way.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams