On 28-07-2011 17:46, Mads Kiilerich wrote: > André Felipe Dias wrote, On 07/28/2011 09:37 PM: >> >> >> On 28-07-2011 11:15, Mads Kiilerich wrote: >>> On 07/28/2011 04:05 AM, André Felipe Dias wrote: >>>> Hi, >>>> >>>> TortoiseHg installation fills the configuration with lots of merge >>>> tools >>>> settings and this is good. The problem is that each tool has its >>>> premerge value set to False and it is not the expected default >>>> behavior >>>> according to Mercurial specification >>>> (http://www.selenic.com/mercurial/hgrc.5.html#merge-tools). I'd >>>> like to >>>> suggest that the TortoiseHg installation does not set premerge at >>>> all in >>>> next releases. >>> >>> Why? What problem do you see? A default is just a default, and it is >>> not a bug to have configuration that set it to something else. I am >>> sure someone put the values there for a reason - in what were they >>> wrong? >>> >>> premerge set to True (which is the default in Mercurial if nothing >>> else is set) means that Mercurial automatically and silently will >>> combine edits in different parts of the file without using the merge >>> tool. That is convenient if you have a not-so-powerful merge tool >>> (such as a plain text editor), but it will in some (pathological) >>> cases silently make an incorrect merge without starting the merge >>> tool where the user could review and acknowledge the merge. (In my >>> opinion the default value in Mercurial should be 100% safe and have >>> premerge off, but that's a different and old story.) >>> >>> However, with a good merge tool there is no reason why you shouldn't >>> leave all file merges to the merge tool where they can reviewed, >>> rather than letting some of them be resolved silently. Especially >>> for kdiff3 there are some cases where it could be argued that it do >>> a better job than Mercurial - especially because it can interact >>> with the user. >>> >>> /Mads >>> >> >> I had a classroom full of students who didn't expect this behavior. >> If a merge launches an external tool, it seems that there is a >> problem to be solved. > > Do we agree that Mercurial only launches the tool if the file really > has been edited in two different branches and the merge should create > a new file version that combines these two; that there always will be > a problem to solve - even though it might be trivial? >
Agreed >> Common and simple merge cases are expected to be resolved by Mercurial. > > Ok, that is where we disagree. I think this expectation is reasonable, > but it is not necessarily a universal truth. Where do that expectation > come from? > > In my opinion it would be simpler and more intuitive if Mercurial > always left it to the merge tool to resolve conflicts. The distinction > between what premerge can handle and what it can't is kind of > arbitrary and depends on the algorithms used by Mercurial. The merge > tool can use the same algorithm as Mercurial or come up with something > better, and it also has the advantage of having a GUI and being able > to ask the user what he would prefer if there is a tie or ambiguity or > uncertainty. If the problem is trivial to solve, so it's better to Mercurial handle it. There are other issues to solve during development to do more important than the trivial ones. I'd rather to check everything is ok by building and running automated tests. >> I've ran into a case where kdiff3 results were slightly different >> from others tools. I can't recall exactly what situation was that >> now, but it didn't worth the trouble. I'd appreciate if you present >> one pathological case. After all, Mercurial's internal merge is >> reliable to deal with plain text or not? > > Mercurials merge is fine and usually does the right thing. It could > use a different algorithm and handle some corner cases differently, > but I doubt it could be "better" in absolute terms. > > Here are some examples of merges where "all" algorithms could end up > doing something which turns out to not be correct: > > * C code where the same function (or different functions with the same > name) are defined in two different places > > * HTML with for example a list of entries like '<li>\n<div>\n<pre > id="x117">\nHello\n</pre>\n</div>\n</li>' where both branches append a > x118 item to the list but the amount of boilerplate lines do that they > are merged 'cleanly' and you end up with two x118 elements. > > * Whenever an issue has been fixed in two different ways that doesn't > collide; each of them might work but the combination might be bloat or > introduce other problems. > > * Whenever development in the two branches just isn't compatible. > > /Mads Since one algorithm is not really better then other, why bother? The less trivial work I have to handle, the better. That's the reason we automate tasks, right? André ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
