Re: New SCM and commit list

[Daniel Barkalow <barkalow@iabervon.org>]

On Sun, 10 Apr 2005, Linus Torvalds wrote:

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

If merge took trees instead of single files, and had some way of detecting
renames (or it got additional information about the differences between
files), would that give BK-quality performance? Or does BK also support
cases like:

orig ---> first ---> first-merge -
 |                /               \
 |------> second -                 -> final
 |                \               /
 |------> third ---> third-merge -

where the final merge requires, for complete cleanliness, a comparison of
more than 3 states (since some changes will have orig as the common
ancestor and some will have second).

Does this happen in real life? It seems like sane development processes
wouldn't have multiple mainline-candidate patch sets including the same
patches, if for no other reason than that, should the merge fail, nobody
with any clue about the original patches would be anywhere nearby. It
seems better to throw something back to someone to rebase their diffs.

Otherwise, the problem seems to boil down to finding the common ancestor
well, getting trees instead of files to merge, and improving merge until
it handles all of the tractible cases.

	-Daniel
*This .sig left intentionally blank*

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/