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

From: Yann Dirson <ydirson@altern.org>
Date: Nov 17, 2005, 23:07 UTC
Message-ID: <20051117230723.GD26122@nowhere.earth>

Ryan wrote:

Show 12 quoted lines

> Junio wrote:
> > Also another rhetorical, tongue-in-cheek question.  What is your
> > plan to ripple the graft through to update signed tags?  ;-)
> 
> :) Well, since I can't resist answering your rhetorical question:
> 
> They signed a specific DAG.  I'm providing a richer, more complete DAG
> that is a pure-superset of the one they signed.  It is not, however,
> equivalent, so their signature is not related to the superset DAG I have
> created.  In practice, however, I don't expect that any tag-signers
> would state that there is a meaningful difference between the two DAGs,
> from the perspective of their signature.

Well, that seems the perfect place to mention an idea that's running in my head since a couple of days, related to the grafing problem. I'll write it here in case the idea would look interesting to others, who may then find a solution to the problem stated by Junio.

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. That is, the resulting tree does not depend on the history of the parent trees, but on the parent trees themselves. 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.

Indeed that emphasizes that the history lines are on living on a higher level of abstraction that commits. Now what if we used trees->tree commits, instead of the current commits->tree ones ? The main problem would be to be able to reconstruct those history lines, so that we can still extract the log - what's a better model if we loose functionnality ? ;)

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 ? :)

-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>