On Fri, 15 Apr 2005, Linus Torvalds wrote:
> I think I've explained my name tracking worries. When it comes to "how to
> merge", there's three issues:
>
> - we do commonly have merge clashes where both trees have applied the
> exact same patch. That should merge perfectly well using the 3-way
> merge from a common parent that Junio has, but not your current "bring
> patches forward" kind of strategy.
I think 3-way merge is probably the best starting point, but I think that
there might be value in being able to identify the commits of each side
involved in a conflict. I think this would help with cases where both
sides pick up an identical patch, and then each side makes a further
change to a different part of the changed region (you find out that the
other guy's change was supposed to follow the patch, and don't conflict
with it).
> - I _do_ actually sometimes merge with dirty state in my working
> directory, which is why I want the merge to take place in a separate
> (and temporary) directory, which allows for a failed merge without
> having any major cleanup. If the merge fails, it's not a big deal, and
> I can just blow the merge directory away without losing the work I had
> in my "real" working directory.
Is there some reason you don't commit before merging? All of the current
merge theory seems to want to merge two commits, using the information git
keeps about them. It should be cheap to get a new clean working directory
to merge in, too, particularly if we add a cache of hardlinkable expanded
blobs.
> - reliability. I care much less for "clever" than I care for "guaranteed
> to never do the wrong thing". If I have to fix up some stuff by hand,
> I'll happily do so. But if I can't trust the merge and have to _check_
> things by hand afterwards, that will make me leery of the merges, and
> _that_ is bad.
>
> The third point is why I'm going to the ultra-conservative "three-way
> merge from the common parent". It's not fancy, but it's something I feel
> comfortable with as a merge strategy. For example, arch (and in particular
> darcs) seems to want to try to be "clever" about the merges, and I'd
> always live in fear.
How much do you care about the situation where there is no best common
ancestor (which can happen if you're merging two main lines, each of which
has merged with both of a pair of minor trees)? I think that arch is even
more conservative, in that it doesn't look for a common ancestor, and
reports conflicts whenever changes overlap at all. Of course, reliability
by virtue of never working without help is not a big win over living in
fear; you always have to check over it, not because you're afraid, but
because it needs you to.
> And, finally, there's obviously performance. I _think_ a normal merge with
> nary a conflict and just a few tens of files changed should be possible in
> a second. I realize that sounds crazy to some people, but I think it's
> entirely doable. Half of that is writing the new tree out (that is a
> relative costly op due to the compression). The other half is the "work".
I think that the time spent on I/O will be overwhelmed by the time spent
issuing the command at that rate. It might matter if you start getting
into merging lots of things at once, but that's more like a minute for a
merge group with 600 changes rather than a second per merge; we could
potentially save a lot of time based of having a bunch of information left
over from the previous merge when starting merge number 2. So 15 seconds
plus half a second per merge might be better than a second per merge in
the case that matters.
-Daniel
*This .sig left intentionally blank*
-
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
