On Sat, 16 Apr 2005, Sanjoy Mahajan wrote:
>
> I like this elegant approach, but clever pattern matching can help even
> at commit time. Suppose hello.c is simply:
Here, what you're talking about is not "commit", but "merge".
The git model very much separates the two events. You first generate a
merged tree, an dyou commit that merge as a separate and largely totally
independent phase.
And yes, I agree that with merging, you do end up potentially wanting to
try different things. When I've done my "git" merges, all I've really done
is to make sure that the trivial parts basically merge in zero time, so
that you can afford to perhaps spend some effort on handling the _real_
merge conflicts.
Many systems seem to be designed around a "clever merge" algorithm, with
darcs perhaps being the most extreme example. The problem with that design
is that 99.9% of all the work is not at all about being clever, and if you
try to base your design around the clever things, your performance will
definitely suck.
So I think that with git, you can actually really try to be clever,
because when you get a merge conflict, you're now only worrying about one
file out of 17,000, and then you can go wild on that one and try different
merge algorithms (token merge, character-merge, line-based merge, you name
it).
Of course, I might not actually personally want to depend on any clever
merges, but the git infrastructure really doesn't care. My plumbing
doesn't merge the conflicts that arise within one single object, or the
filename differences - you can do anything you want on that.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
