Re: RFC: Subprojects

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 17, 2006, 05:46 UTC
Message-ID: <Pine.LNX.4.64.0601170001130.25300@iabervon.org>
In-Reply-To: <7vek37rj83.fsf@assigned-by-dhcp.cox.net>

On Mon, 16 Jan 2006, Junio C Hamano wrote:

Show 11 quoted lines

>    We could introduce "bind the rest" to make write-tree write
>    out a tree that contains only the containing project part and
>    not any of the subproject part (e.g. Makefile, README and
>    src/ but not linux-2.6/ nor gcc-4.0/ in the earlier example).
>    Essentially the contents of such a tree object would be the
>    same as what "gitlink" approach would have had for the
>    containing project in the index file, minus "gitlink" entries
>    themselves).  This is not so surprising, because the missing
>    information "gitlink" approach recorded in the tree object
>    itself is expressed on "bind" lines in the commit object with
>    this approach.

So why not use the "bind" approach for the "index vs working tree" part, but write out "gitlink"-style tree objects? I think putting the info in the tree objects in the location the subproject would appear is nicer than having tree objects that tell only part of the story, and you don't have to worry about commits that stick a subproject on top of something in the tree.

In any case, I think it would be good to track where the subprojects are in some core state, and probably the right solution is to have special index entries for them, in addition to having their contents in the index. I'm not seeing a clear way to get from commit objects with "bind" lines to an index with the appropriate things read and back otherwise.

One idea I toyed with a while ago for the index/working tree implementation is having an index file per bound project, such that each project has a completely ordinary index file, and you just need to tell checkout-index where to write. This is especially cute because the index file for the superproject doesn't need to know about the subprojects at all; they're not in that index, and the working tree is just directories of untracked files. Not sure if this is a useful idea at this point or not.

	-Daniel
*This .sig left intentionally blank*