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

Nikolaj Sjujskij sterkrig at myopera.com
Tue May 21 03:49:39 CDT 2013

Den 2013-05-20 19:20:53 skrev André Felipe Dias <andref.dias at gmail.com>:

> 2013/5/20 Nikolaj Sjujskij <sterkrig at myopera.com>
>> Den 2013-05-18 18:10:35 skrev André Felipe Dias <andref.dias at gmail.com>:
>>>>>  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.
> In Portuguese, there is no direct correspondent to 'deprecated'.  
> Obsolete is used instead and its meaning is slightly different than
> deprecated. It suggests that there is a newer or better option.
>>  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.
> I don't think so either. But it is the first of a two-step sollution to a
> very specific and rare case. The second one would be the back out of the
> previous merge revision backout just before the next merge.
>>  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.
> Now, I see that when a situation that needs a merge revision backout
> arises, it will end up being researched in google and in stackoverflow
> anyway. The help text doesn't need to give a complete answer, but I think
> it could be a little more descriptive:
> Backing out a merge revision should be used as a feature of last resort.
> The backed out changeset won't be included in the next merge and probably
> it will need to be reintroduced again later. Instead, try to back out a
> previous offending revision or correct the problem after the merge.
  Now it's time to send a help patch (for verbose section) and get new  
discussion going :)

More information about the Mercurial-devel mailing list