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

[Yann Dirson <ydirson@altern.org>]

Ryan wrote:
> 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/>