Re: RFC: Subprojects

Junio C Hamano [off-list ref] writes:

Daniel Barkalow [off-list ref] writes:

quoted

quoted

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.

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

Is there a version of git with this to try it ?

Alexander Litvinov wrote:

quoted

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

Is there a version of git with this to try it ?

The pu branch of the official git repo.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231