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

On Fri, Nov 18, 2005 at 12:28:56AM +0100, Johannes Schindelin wrote:

Hm, I'm not sure I get your point here.

Trees have an existence outside any consideration of what changes led to them, as shown by the fact that git trees do not reference anything outside them. And it is right that, at that level, noone tells you how you got there - not less nor more than when you fetch a linux-x.y.z.tar.gz2 from kernel.org.

Then at a bit higher level, you can consider changes from a tree to a tree. What you usually do when you commit a change is explaining what you change to the tree. Then changes themselves are just derived from the trees (iow, "abstracted from" the trees), and you augment this information with a message explaining what you did.

Then at a still higher level, you can derive history lines from the individual trees and changes, and augment this information, eg. by signing them.

The fact is, currently git does not distinguish much between those 2nd and 3rd levels. It is my understanding that one of the most basic design decisions of git was precisely to make the tool "aware" of the 1st level, and that it played an important part of why git works so well: it maps to the reality closer than any other tool.

I was not convinced at all by the ideas when git appeared, but that was probably because I was too much influenced by previous tools, all focussing either on the history line (most of them), or on the changes (darcs).

I think that if we can formalize into git the disctinction between those two higher levels (and possibly other levels in the future), we could get to an even more powerful and usable tool, even if, like git, the basic ideas may look weird and possibly even counter-productive at first sight.

As an example, here is an idea I had while formalizing the above 3rd level: we also work at this level when rolling back a previous change, since we take the history line into account. We could add, at that History level, the possiblity to record this information, by linking to that previous commit.

Now maybe I was mistaken in thinking the objects at the History level should be only "cached" and temporary objects - that, and loop prevention, and signed history lines, make too many reasons for them to be permanent already :).

But their existence as such should not prevent to work at a lower level. I'll have to reconsider the way I intended to design my ArcheoloGIT toolkit, but I'm afraid it would need a new generation of GIT ;)

Best regards,