Re: New SCM and commit list

Linus Torvalds
2005-04-11T06:13:36Z

On Mon, 11 Apr 2005, Jeff Garzik wrote:
>
> > But I hope that I can get non-conflicting merges done fairly soon, and
> > maybe I can con James or Jeff or somebody to try out GIT then...
>
> I don't mind being a guinea pig as long as someone else does the hard
> work of finding a new way to merge :)

So I can tell you what merges are going to be like, just to prepare you.

First, the good news: I think we can make the workflow look like bk, ie
pretty much like "git pull" and "git push". And for well-behaved stuff
(ie minimal changes to the same files on both sides) it will even be fast.
I think.

Then the bad news: the merge algorithm is going to suck. It's going to be
just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
understanding of renames etc. I'll try to find the best parent to base the
merge off of, although early testers may have to tell the piece of crud
what the most recent common parent was.

So anything that got modified in just one tree obviously merges to that
version. Any file that got modified in two trees will end up just being
passed to the "merge" program. See "man merge" and "man diff3". The merger
gets to fix up any conflicts by hand.

Quite frankly, that means that we really want to avoid any "exciting"
merges with GIT. Maybe somebody can come up with something smarter.
Eventually. Don't count on it, at least not in the near future.

The good news is that it's not like a three-way file merge is any worse
than many people are used to. The bad news is that BK is just a hell of a
lot better. So anybody who has been depending heavily on BK merges (and
hey, the beauty of them is that you often don't even _know_ that you are
depending on them) will be a bit bummed by the "Welcome back to the
1980's" message from a three-way merge.

Linus