Re: [RFC] Applying a graft to a tree and "rippling" the changes through

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Nov 18, 2005, 15:54 UTC
Message-ID: <200511181654.21052.Josef.Weidendorfer@gmx.de>
In-Reply-To: <20051117230723.GD26122@nowhere.earth>

On Friday 18 November 2005 00:07, Yann Dirson wrote:

Show 5 quoted lines

> Current commit objects refer to a child tree, but to parent _commits_.
> Whereas it seems necessary to walk through the history line, and
> easily get a changelog, it is semantically quite not right: the
> changes we record with a commit indeed come from modification of
> trees, not of commits.

Yes. The change to a tree (which is equalent to 2 trees - new old and the new one; or for merges multiple old ones and the new one) does not depend on any history. Unfortunately, we have no separate object to specify the "the change to a tree". We include this information into the commit object, and thus, bind it to the history.

This could be changed in git, i.e. put the tree relationship into a separate object; even comments could be split up in change related and history related. The question is: is this useful, is there any important usage scenario that rectifies such a change? I do not really think so.

> That is, the resulting tree does not depend on 
> the history of the parent trees, but on the parent trees themselves.

No, the resulting tree is an independent object, it is the tree ;-) Do not confuse this with the commit pointing to the tree.

> And similarly, tags usually denote a particular state of the tree,
> "somewhat" independantly of its history: linux-2.6.11 is the same
> beast, whereas the repository holds full history since 0.1 or not.

I agree that tags for tree objects are useful, but what is the problem? You can do this already.

But tags for commit objects are equally useful, especially signed ones: they include a fixed history which can not be changed. Eg. they include all the people which attributed code to the project, and this is important for license questions. This is the reason that "grafting" should stay a local workaround.

That the concrete tag "linux-2.6.11" points to a commit, and not to the tree object, probably was done on purpose; i.e. the creator of the tag wanted to include the history. If not, he could have made the tag for the tree object directly.

> Indeed that emphasizes that the history lines are on living on a
> higher level of abstraction that commits.

Hmm.. If you only have tree changes, there is no history. The history specifies an order of the changes. The changes themselve do not include any such order.

> Now what if we used 
> trees->tree commits, instead of the current commits->tree ones ?

It would be better to not talk about "commits" for tree changes (perhaps with comments about the change). As said above, tree change objects could be introduced. The question is why?

> The
> main problem would be to be able to reconstruct those history lines,
> so that we can still extract the log

No problem: You still have the chain of commits, and one commit points to the parent commit(s) and the corresponding new introduced tree change objects.

> - what's a better model if we 
> loose functionnality ? ;)

There is nothing lost. If you regard the comments entered at "git commit" time as purely change related, this comments can be put together with the tree change object. So if you "apply a graft to a tree", (signed) tags for tree changes would include the comment, and stay valid after "regrafting". But why would anyone want to sign a change?

> However, I must admit that at this point, I have not found a
> reasonable solution to this problem.
> 
> Any genius with a solution out there ? :)

What is the difficult problem here?

Josef