Dear diary, on Sat, Apr 16, 2005 at 02:22:45AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
>
>
> 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.
My current "bring patches forward" strategy is only very interim, to
have something working well enough for me to merge with you. I will
gladly change it to use merge-tree*, when it is done. (Or read-tree -m -
I will yet have to have a look, but it looks extremely promising.)
> - 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.
Ok. But still, especially when you do some nontrivial conflicts
resolving, how do you check if it even compiles after the merge? Or do
you just commit it and possibly fix the compilation in another commit?
> - 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.
I agree and I would like to achieve the same. I too think the three-way
merge from the common parent is the best way to go for now.
> 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".
Being written in shell, there is plenty of space for optimization - from
using bash internals instead of textutils to rewriting parts of it in C.
My priority now is to get it right first, though. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
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
