Re: RFC: Subprojects

From: Junio C Hamano <junkio@cox.net>
Date: Jan 18, 2006, 03:49 UTC
Message-ID: <7vy81eyz47.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vpsmq2tyb.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 17 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>>> Reading such a commit is easy:
>>> 
>>> 	$ git-read-tree $tree ;# ;-)
>>> 
>>> But that is cheating.  
>>
>> This is for backwards compatibility, I assume?
>
> This is done more for not having to touch *anything* that does
> "index vs working file", "tree vs index" and "tree vs working
> file via index".  It also is the easiest way to keep the "a
> commit object name can be used in place of the tree object name
> of the tree it contains" invariant.  Also I suspect this
> organization might help recursive subprojects, but if it is the
> case, that is just a byproduct, not a design goal.

I started this "bind" design as a thought experiment, but I started to like it more and more.

One interesting outcome of keeping the whole tree in the index and the tree object recorded in the commit object of the toplevel project is that a merge in the toplevel project "just works".

To preserve our sanity, let's say we refuse to merge two commits that have different sets of subprojects. That is, they must have the "bind" lines for the same set of subdirectories. The commits bound at these subdirectories do not need to match.

Before starting a merge, we require that the index is in sync with the tree object recorded in the top commit, just like we do for a normal merge[*1*]. Then we use the current merge machinery that does not know anything about "bind" to perform the merge, using the merge base of the toplevel project and usual three-way merge. From the mechanism point of view, there is no need to look at commits on "bind" line of either side to come up with the resulting tree.

We could notice that the commit bound at linux-2.6/ subdirectory of one side is v2.6.15 and the other side is v2.6.16-rc1, and because one is a fast-forward of the other, choose to pick the tree associated with v2.6.16-rc1 commit without actually doing the 3-way resolve of linux-2.6/ subtree part, but that is purely a performance optimization [*2*].

When writing out the merge result as a commit, we would create (this is the fun part) a commit for linux-2.6/ part that has two parents: the commits bound to linux-2.6/ tree from the two toplevel commits being merged are the parents of such a subproject commit. And the resulting toplevel merge commit would have that commit object name on its "bind" line. Obviously, when the bound subproject head of one side is a fast-forwad of the other, we do not create such a merge commit for the subproject; instead, we just record the one that is ahead on the "bind" line of the resulting toplevel merge commit.

[Footnote]

*1* As a side effect, this also ensures the index is in sync with the bound commits of the subprojects. As an additional requirement, we may want to enforce that the bound commits must match the branch heads that keep track of subprojects.

*2* Of course, from the usability, safety and confusion avoidance point of view, it _might_ make sense to require that bound commits are in such fast-forward relationship. But that is a policy issue; at the mechanism level, there is no need to impose such a requirement.