Handling if's with parenthesis
Mads Kiilerich
mads at kiilerich.com
Fri Dec 5 18:22:38 UTC 2008
I think we know where we disagree, so this could end up being a
pointless discussion. But for completeness I would like to add a couple
of comments to this thread:
Matt Mackall wrote:
> The trade-off is that the average person's error rate when faced with a
> large number of 'trivial' merges will likely be higher than the
> automated tool's error rate.
>
Yes, a good file merge algorithm has lower error rate than I have. So
the merge tool should definitely use a good file merge algorithm to do
as much of the hard work as possible.
If I don't have any other merge tool than what Mercurials provides (and
if I'm lucky also an editor) then Mercurial is my merge tool, and in
that case the internal simplemerge is good - much better than nothing.
(But because it isn't perfect it shouldn't be silent ...)
> For instance, I suspect my error rate when fiddling with kdiff3 on the
> rare occassions it pops up for me is something like 10% or more.
> Meanwhile, I don't think I've yet seen a merge error while managing the
> main Mercurial repo, so I think that error rate is < 1%. If I were
> reviewing all those merges by hand, I'm pretty sure it would be worse
> rather than better.
>
That is not a fair comparison and no conclusion can be made from that.
As it is now kdiff3 pops up only when there are real hard conflicts.
Kdiff3 is just the messenger and asks you to provide a resolution. It
doesn't create the problem.
If kdiff3 also popped up and requested a _review_ in the simpler cases
then that wouldn't increase the error rate of these. It (or Mercurial
simplemerge) could do the merge as good as it can anyway. That is what
would have helped E.L.K. in this case.
> Merging is hard. Errors will happen occasionally regardless of what tool
> or process you're using.
>
Yes. I can review a merge - no tool can do that. That is why I think
silent premerge is a bad default and we should encourage users to always
review merges with a suitable tool.
> Lastly, I wrote a quick test and discovered that the internal merge
> properly flags this error.. but kdiff3 (which is slightly more
> optimistic) silently merges it.
>
The example had a blank line after somefunc. That makes internal merge
make the "wrong" merge like reported.
/Mads
More information about the Mercurial
mailing list