Re: Re: Re: [ANNOUNCE] git-pasky-0.1

Linus Torvalds
2005-04-10T23:09:20Z

On Mon, 11 Apr 2005, Petr Baudis wrote:
>
> I currently already do a merge when you track someone's source - it will
> throw away your previous HEAD record though

Not only that, it doesn't do what I consider a "merge".

A real merge should have two or more parents. The "commit-tree" command
already allows that: just add any arbitrary number of "-p xxxxxxxxx"
switches (well, I think I limited it to 16 parents, but that's just a
totally random number, there's nothing in the file format or anything
else that limits it).

So while you've merged my "data", but you've not actually merged my
revision history in your tree.

And the reason a real merge _has_ to show both parents properly is that
unless you do that, you can never merge sanely another time without
getting lots of clashes from the previous merge. So it's important that a
merge really shows both trees it got data from.

This is, btw, also the reason I haven't merged with your tree - I want to
get to the point where I really _can_ merge without throwing away the
information. In fact, at this point I'd rather not merge with your tree at
all, because I consider your tree to be "corrupt" thanks to lacking the
merge history.

So you've done the data merge, but not the history merge.

And because you didn't do the history merge, there's no way to
automatically find out what point of my tree you merged _with_. See?

And since I have no way to see what point in time you merged with me, now
I can't generate a nice 3-way diff against the last common ancestor of
both of our trees.

So now I can't do a three-way merge with you based on any sane ancestor,
unless I start guessing which ancestor of mine you merged with. Now, that
"guess" is easy enough to do with a project like "git" which currently has
just a few tens of commits and effectively only two parallell development
trees, but the whole point is to get to a system where that isn't true..

Linus