<div dir="ltr"><font face="courier new, monospace"><br><br><br>2013/5/17 Matt Mackall <<a href="mailto:mpm@selenic.com">mpm@selenic.com</a>><br>><br>> ><br>> > I don't think the existence of a non-broken use case is essential or<br>
> > even possible. Simply, there is no alternative sometimes! As in a<br>> > wrong merge between an incomplete feature branch and the default<br>> > branch. Yes, there will be implications, but they are unavoidable and<br>
> > inherent to DVCS and not a hg's limitation.<br>> ><br>> ><br>> > When a situation like this occurs and a user searches for a solution,<br>> > the backout command is the best shot but its help says:<br>
> ><br>> ><br>> >     "Note: backout cannot be used to fix either an unwanted or<br>> > incorrect merge."<br>><br>> > This is misinformation! The backout command can fix it through the<br>
> > '--parent' option, but there are implications.<br>><br>> And the "implications" here are that it doesn't actually fix anything<br>> and leaves you with more problems than you started with.</font><div>
<font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">Still, this problem eventually happens and thus needs a solution. What do you recommend?</font></div><div><font face="courier new, monospace"><br>
</font></div><div><div><font face="courier new, monospace">><br>><br>> In other words, I stand by the original statement. That's further backed<br>> by most of a decade of experience of fielding reports from numerous<br>
> people who've gone down that road.<br>><br>> >  I think the help text should point this out instead of hide this<br>> > information.<br>><br>> In my judgment, a (perforce) complicated explanation in the help will<br>
> simply result in more people shooting themselves in the foot. Indeed,</font></div><div><font face="courier new, monospace"><br></font></div><div style><font face="courier new, monospace">Agreed. It is an advanced topic to a very specific situation. </font><font face="courier new, monospace">Nevertheless, some orientation is needed</font><span style="font-family:'courier new',monospace">.</span></div>
<div><font face="courier new, monospace"><br></font><div><font face="courier new, monospace">> the fact that you think this feature is somehow still useful for fixing<br>> merges after having researched it is good evidence of the theory that<br>
> more information is not necessarily better for usability.</font><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">If this feature isn't useful for fixing merges, what is it then?</font></div>
<div><div><font face="courier new, monospace">For example, suppose the following situation where a feature-x branch was prematurely merged into default by mistake. It is not possible to back out just one revision of feature-x branch nor immediatly finish feature-x directly in default. How to revert the default branch to a consistent state after the fact?</font></div>
<div><font face="courier new, monospace"><br> ---o---o---o---M   } default<br>               /<br>   ---o---o---o     } feature-x</font></div><div><font face="courier new, monospace"><br></font></div><div style><font face="courier new, monospace">André</font></div>
<div style><font face="courier new, monospace"><br> </font></div></div></div></div></div></div>