Re: Octopus merge: unique (?) to git, but is it useful?

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 3, 2008, 19:54 UTC
Message-ID: <alpine.LFD.1.10.0806031244290.3473@woody.linux-foundation.org>
In-Reply-To: <200806030932.03051.jnareb@gmail.com>

On Tue, 3 Jun 2008, Jakub Narebski wrote:

Show 7 quoted lines

> On Tue, 3 June 2008, Linus Torvalds wrote:
> > 
> > Once you have 0, 1 or 2 parents, the logical progression is "many". 
> 
> Well, it of course depends on design.  For example Mercurial (from what
> I have read in the documentation) has fixed width (two element) parents
> array in revflog structure.

Sure. And git very much on purpose made all basic data structures be text.

I'm a UNIX weenie, not some VMS hack. Fixed-sized records are evil.

[ Yes, I made the hashes fixed-size binary blobs in the tree object. In 
  retrospect, that was probably a mistake. Not a huge one, but it's one of 
  the few things in the basic data structure that I'm sorry for. It 
  seemed to make sense at the time. ]

I do like how you can have arbitrary parenthood (well, arbitrary on a data structure level - we do restrict it in practice). Maybe it's not a hugely important thing, but it does allow more than just plain merges.

IOW, I could well imagine having an extra parent pointer that is not a "data merge" pointer, but a "concept merge" - you could have branches that have commits that point back to not the data in the tree, but to particular commits in another branch.

One of the things I could imagine using git for is to have "annotation branches" for things like code review etc. They'd be a real branch in their own right and with their own history, but at the same time they could well want to point back to the "code branch" that they annotate by considering that another parent in a "non-data merge" (and yes, you'd obviously have to use a special merge strategy for things like that, but you'd likely integrate it in some "annotation tool chain" rather than anything else).

			Linus