On Sat, 16 Apr 2005, Petr Baudis wrote:
> But otherwise it is great news to me. Actually, in that case, is it
> worth renaming it to Cogito and using cg to invoke it? Wouldn't be that
> actually more confusing after it gets merged? IOW, should I stick to
> "git" or feel free to rename it to "cg"?
I'm perfectly happy for it to stay as "git", and in general I don't have
any huge preferences either way. You guys can discuss names as much as you
like, it's the "tracking renames" and "how to merge" things that worry me.
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 _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.
- 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.
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".
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