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

[sf <sf@b-i-t.de>]

Yann Dirson wrote:
...
> 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.

I would go even further: The resulting tree does not depend on anything. 
A tree is a tree is a tree.

A commit is really just the statement: "I changed the tree from state A 
to state B". After all, the commit message does not describe the new 
state (neither the old state) but does describe the changes.

> 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.

Exactly, the tree "linux-2.6.11" is the tree "linux-2.6.11". How it came 
about is totally irrelevant if you are only interested in this 
particular version (does anyone download all linux-*.tar.bz2 just to get 
  linux-2.6.11.tar.bz2?).

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

You can traverse tree -> commit -> tree -> commit -> tree ... to get the 
history. No functionality lost.

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

In your model you have a mapping from commits to sets of trees (by way 
of commit objects). Now you create the "inverse" mapping from trees to 
sets of commits. Both mappings together enable you to walk the history.

Why is git's model different?

1. You have to watch out for circles in history (Git's model ensures 
that history is always a DAG).

2. Your model is harder to implement in the typical case (But deleting 
from repositiories, partial repositories, augmenting or cutting history 
etc. are hard to implement as it is now, if not outright impossible).

3. It is the way repositories have been organized ever since CVS (Git 
throws out some concepts of the CVS model, but not all).


Regards
	Stephan