About changing the status of the --parent option of the hg backout command from DEPRECATED to WARNING

Nikolaj Sjujskij sterkrig at myopera.com
Mon May 20 08:30:27 CDT 2013


Den 2013-05-18 18:10:35 skrev André Felipe Dias <andref.dias at gmail.com>:

> 2013/5/18 Nikolaj Sjujskij <sterkrig at myopera.com>
>
>> Den 2013-05-18 03:39:47 skrev André Felipe Dias <andref.dias at gmail.com>:
>>
>>
>>  2013/5/17 Matt Mackall <mpm at selenic.com>
>>>
>>>>
>>>>
>>>>> I don't think the existence of a non-broken use case is essential or
>>>>> even possible. Simply, there is no alternative sometimes! As in a
>>>>> wrong merge between an incomplete feature branch and the default
>>>>> branch. Yes, there will be implications, but they are unavoidable and
>>>>> inherent to DVCS and not a hg's limitation.
>>>>>
>>>>>
>>>>> When a situation like this occurs and a user searches for a solution,
>>>>> the backout command is the best shot but its help says:
>>>>>
>>>>>
>>>>>     "Note: backout cannot be used to fix either an unwanted or
>>>>> incorrect merge."
>>>>>
>>>>
>>>>  This is misinformation! The backout command can fix it through the
>>>>> '--parent' option, but there are implications.
>>>>>
>>>>
>>>> And the "implications" here are that it doesn't actually fix anything
>>>> and leaves you with more problems than you started with.
>>>>
>>>
> Not more problems. Only a different kind of problem to be solved later  
> on.
> It is up to an informed user to weight them all and choose if it is  
> worth.
  Nobody forbids user to use deprecated feature.

  If you referred to
> "Note: backout cannot be used to fix either an unwanted or incorrect  
> merge."
  then I don't think that result of backing out a merge changeset could be  
called a real fix.

>>> Still, this problem eventually happens and thus needs a solution. What  
>>> do you recommend?
>>  I recommend not thinking that `backout --parent` could help in this  
>> case.
>> It's one thing when one devises his own kludgy "solution" (like  
>> creating a
>> patch with `hg diff` then applying it), and quite the other when one  
>> sees
>> some magic option and relies on tool developers (they should know  
>> better,
>> shouldn't they?). Both do essentially the same, both have the same
>> implications, but `backout --parent` smells "official", while homebrewn
>> solution is more... kind of "transparent", thus exposing those  
>> implications better.
> I believe we all agree that the problem is not in the command itself. It
> does exactly what it is supposed to do.
  Yep, and if it is supposed to break things (especially for inexperienced  
user), should it be not DEPRECATED?
> The problem is inherent to DVCS and a complete solution encompasses more  
> than a single command execution.
> I was wondering if there is some way to make this clear to the user  
> without
> bloating the help text. If you guys think it is not worth, its ok to me.
  I think a paragraph in "verbose" help wouldn't hurt. It's quite short.

> But IMHO, the user is helpless in this situation.
  Why? User can use deprecated feature or revert changes by hand.

Changeset evolution concept should bring better way of solving it (I think  
so).

Anyway, I'm just a user (like you), I don't decide anything, just trying  
to explain developers' point of view as I see it.


More information about the Mercurial-devel mailing list