André Felipe Dias wrote, On 07/29/2011 12:16 AM: > On 28-07-2011 17:46, Mads Kiilerich wrote: >>> 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 hope your merge tool can handle trivial merges too - and let you decide how much you will automate and review. > 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? Merging can not be automated flawlessly, so whether you dare to automate it or not should IMHO be a conscious decision. The best place to control the decision is IMHO in the merge tool where there usually is a GUI with the purpose of controlling how merges should be resolved. I think it is fine if thg has the "safest" and conceptually simplest choice as default. /Mads ------------------------------------------------------------------------------ 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
