Re: LCA2006 Git/Cogito tutorial
- From
Junio C Hamano <junkio@cox.net>
- Date
- Oct 24, 2005, 01:48 UTC
- Message-ID
- <7vy84jsn1o.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <Pine.LNX.4.64.0510231804430.10477@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
Show 11 quoted lines
> On Sun, 23 Oct 2005, Junio C Hamano wrote: >> >> Even if we did that, we are still doing 3-way merge; git-merge >> framework may not mesh very well when we want to use something >> like codeville merge which is not based on 3-way. > > Oh, the git merge is about a million times better than any silly weave > merge with extra BonusPoints and MagicCapitalizedNames. > > Why? Because if you want to be slow and careful, you can always just > create the weave after-the-fact and do a weave merge.
Yes, I know that as the one who did the convention between git-merge and merge strategy backends. The convention feeds two (or more) heads and the common ancestors git-merge already figured out to the strategy backends.
The current callers only feed commits for "$heads" parameters, so the merge strategy backends are free to figure out the common ancestor or even generate weave on the fly, but an unwritten rule was that strategy backends are expected to do something sensible even when the "common ancestors" and "heads" fed to them are tree objects, which was my comment about 3-way was about.