Patchwork backout: add example of backing out a merge changeset

login
register
mail settings
Submitter Mathias De Maré
Date Sept. 30, 2015, 5:35 a.m.
Message ID <5a00a9ab705848b7de45.1443591321@waste.org>
Download mbox | patch
Permalink /patch/10699/
State Rejected
Headers show

Comments

Mathias De Maré - Sept. 30, 2015, 5:35 a.m.
# HG changeset patch
# User Mathias De Maré <mathias.demare@gmail.com>
# Date 1443590812 -7200
#      Wed Sep 30 07:26:52 2015 +0200
# Node ID 5a00a9ab705848b7de45b4263ed0bbab29494e29
# Parent  46af0adb5c375cc51ce0d29cbdcd8ba843a33425
backout: add example of backing out a merge changeset
Mathias De Maré - Sept. 30, 2015, 5:43 a.m.
On Wed, Sep 30, 2015 at 7:35 AM, Mathias De Maré <mathias.demare@gmail.com>
wrote:

> # HG changeset patch
> # User Mathias De Maré <mathias.demare@gmail.com>
> # Date 1443590812 -7200
> #      Wed Sep 30 07:26:52 2015 +0200
> # Node ID 5a00a9ab705848b7de45b4263ed0bbab29494e29
> # Parent  46af0adb5c375cc51ce0d29cbdcd8ba843a33425
> backout: add example of backing out a merge changeset
>
Besides adding this example, I'd also like to undeprecate the '--parent'
flag.
The flag was deprecated in 1209de02034e with the following description:

> backout: deprecate/hide support for backing out merges
>
> This has never worked usefully:
>
> - it can't undo a completely unwanted merge, as it leaves the merge in the
> DAG
>
> - it can't undo a faulty merge as that means doing a merge correctly,
>   not simply reverting to one or the other parent
>
> Both of these kinds of merge also require coordinated action among
> developers to avoid the bad merge continuing to affect future merges,
> so we should stop pretending that backout is of any help here.
>
> As backing out a merge now requires a hidden option, it can't be done
> by accident, but will continue to 'work' for anyone who's already
> dependent on --parent for some unknown reason.
>
>
I think the below use case is can be solved using 'backout --parent', and I
don't see any alternatives that handle this in a simple way.

>
> diff --git a/mercurial/commands.py b/mercurial/commands.py
> --- a/mercurial/commands.py
> +++ b/mercurial/commands.py
> @@ -495,6 +495,19 @@
>        cancel the merge and leave the child of REV as a head to be
>        merged separately.
>
> +      Examples:
> +
> +      - do a backout of a merge changeset 33 that was created from
> +        a good changeset 22 and a bad changeset 11::
> +
> +          hg backout -r 33 --parent 22
> +          hg commit -m "Backout of merge 33 to parent 22"
> +
> +        After the backout, all of the changes on
> +        the good side of the merge (the side of changeset 22 and
> ancestors)
> +        are kept, while the changes on the bad side of the merge
> +        (the side of changeset 11 and ancestors) are backed out.
> +
>      See :hg:`help dates` for a list of formats valid for -d/--date.
>
>      Returns 0 on success, 1 if nothing to backout or there are unresolved
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel
>
Pierre-Yves David - Sept. 30, 2015, 6:29 a.m.
On 09/29/2015 10:35 PM, Mathias De Maré wrote:
> # HG changeset patch
> # User Mathias De Maré <mathias.demare@gmail.com>
> # Date 1443590812 -7200
> #      Wed Sep 30 07:26:52 2015 +0200
> # Node ID 5a00a9ab705848b7de45b4263ed0bbab29494e29
> # Parent  46af0adb5c375cc51ce0d29cbdcd8ba843a33425
> backout: add example of backing out a merge changeset

How does this cope with:

     Note:
       backout cannot be used to fix either an unwanted or incorrect merge.

Did you read previous discussion on the topic?


>
> diff --git a/mercurial/commands.py b/mercurial/commands.py
> --- a/mercurial/commands.py
> +++ b/mercurial/commands.py
> @@ -495,6 +495,19 @@
>         cancel the merge and leave the child of REV as a head to be
>         merged separately.
>
> +      Examples:
> +
> +      - do a backout of a merge changeset 33 that was created from
> +        a good changeset 22 and a bad changeset 11::
> +
> +          hg backout -r 33 --parent 22
> +          hg commit -m "Backout of merge 33 to parent 22"
> +
> +        After the backout, all of the changes on
> +        the good side of the merge (the side of changeset 22 and ancestors)
> +        are kept, while the changes on the bad side of the merge
> +        (the side of changeset 11 and ancestors) are backed out.
> +
>       See :hg:`help dates` for a list of formats valid for -d/--date.
>
>       Returns 0 on success, 1 if nothing to backout or there are unresolved
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel
>
Mathias De Maré - Sept. 30, 2015, 6:51 a.m.
On Wed, Sep 30, 2015 at 8:29 AM, Pierre-Yves David <
pierre-yves.david@ens-lyon.org> wrote:

>
>
> On 09/29/2015 10:35 PM, Mathias De Maré wrote:
>
>> # HG changeset patch
>> # User Mathias De Maré <mathias.demare@gmail.com>
>> # Date 1443590812 -7200
>> #      Wed Sep 30 07:26:52 2015 +0200
>> # Node ID 5a00a9ab705848b7de45b4263ed0bbab29494e29
>> # Parent  46af0adb5c375cc51ce0d29cbdcd8ba843a33425
>> backout: add example of backing out a merge changeset
>>
>
> How does this cope with:
>
>     Note:
>       backout cannot be used to fix either an unwanted or incorrect merge.
>
> Did you read previous discussion on the topic?

I found the following about the topic:
https://selenic.com/pipermail/mercurial-devel/2011-October/034559.html
The issues described are when you have 2 valid branches and the merge
between them goes wrong.
But what I describe here is when one of the branches is bad (and all the
changes on it are bad), while the other branch is good.
In that case, I would like to apply the inverse of the branch, and it seems
to be like that would indeed solve my issue.

Matt describes here (see the last example) the issue of backing out an
entire merge:
https://selenic.com/pipermail/mercurial-devel/2011-October/034569.html

> In other words, you just turned a broken real merge into a dummy merge,
> which is probably not what you wanted.
>
> In fact, that is what I wanted. I agree that a backout of a merge is a
broken concept in some of the cases, but I believe it is a valid concept
for the case I'm describing.
Perhaps I'm missing something here?

>
>
>
>
>> diff --git a/mercurial/commands.py b/mercurial/commands.py
>> --- a/mercurial/commands.py
>> +++ b/mercurial/commands.py
>> @@ -495,6 +495,19 @@
>>         cancel the merge and leave the child of REV as a head to be
>>         merged separately.
>>
>> +      Examples:
>> +
>> +      - do a backout of a merge changeset 33 that was created from
>> +        a good changeset 22 and a bad changeset 11::
>> +
>> +          hg backout -r 33 --parent 22
>> +          hg commit -m "Backout of merge 33 to parent 22"
>> +
>> +        After the backout, all of the changes on
>> +        the good side of the merge (the side of changeset 22 and
>> ancestors)
>> +        are kept, while the changes on the bad side of the merge
>> +        (the side of changeset 11 and ancestors) are backed out.
>> +
>>       See :hg:`help dates` for a list of formats valid for -d/--date.
>>
>>       Returns 0 on success, 1 if nothing to backout or there are
>> unresolved
>> _______________________________________________
>> Mercurial-devel mailing list
>> Mercurial-devel@selenic.com
>> https://selenic.com/mailman/listinfo/mercurial-devel
>>
>>
> --
> Pierre-Yves David
>
Matt Mackall - Sept. 30, 2015, 4:57 p.m.
On Wed, 2015-09-30 at 08:51 +0200, Mathias De Maré wrote:
> On Wed, Sep 30, 2015 at 8:29 AM, Pierre-Yves David <
> pierre-yves.david@ens-lyon.org> wrote:
> 
> >
> >
> > On 09/29/2015 10:35 PM, Mathias De Maré wrote:
> >
> >> # HG changeset patch
> >> # User Mathias De Maré <mathias.demare@gmail.com>
> >> # Date 1443590812 -7200
> >> #      Wed Sep 30 07:26:52 2015 +0200
> >> # Node ID 5a00a9ab705848b7de45b4263ed0bbab29494e29
> >> # Parent  46af0adb5c375cc51ce0d29cbdcd8ba843a33425
> >> backout: add example of backing out a merge changeset
> >>
> >
> > How does this cope with:
> >
> >     Note:
> >       backout cannot be used to fix either an unwanted or incorrect merge.
> >
> > Did you read previous discussion on the topic?
> 
> I found the following about the topic:
> https://selenic.com/pipermail/mercurial-devel/2011-October/034559.html
> The issues described are when you have 2 valid branches and the merge
> between them goes wrong.
> But what I describe here is when one of the branches is bad (and all the
> changes on it are bad), while the other branch is good.
> In that case, I would like to apply the inverse of the branch, and it seems
> to be like that would indeed solve my issue.
> 
> Matt describes here (see the last example) the issue of backing out an
> entire merge:
> https://selenic.com/pipermail/mercurial-devel/2011-October/034569.html
> 
> > In other words, you just turned a broken real merge into a dummy merge,
> > which is probably not what you wanted.
> >
> > In fact, that is what I wanted. I agree that a backout of a merge is a
> broken concept in some of the cases, but I believe it is a valid concept
> for the case I'm describing.
> Perhaps I'm missing something here?

We don't want to even mention merge in the backout docs because people
will try to do something it can't really do and compound the damage on
their DAG.

It's pretty easy to just use revert to make a dummy merge, no?
Mathias De Maré - Oct. 1, 2015, 5:26 a.m.
On Wed, Sep 30, 2015 at 6:57 PM, Matt Mackall <mpm@selenic.com> wrote:

> On Wed, 2015-09-30 at 08:51 +0200, Mathias De Maré wrote:
> > On Wed, Sep 30, 2015 at 8:29 AM, Pierre-Yves David <
> > pierre-yves.david@ens-lyon.org> wrote:
> >
> > >
> > >
> > > On 09/29/2015 10:35 PM, Mathias De Maré wrote:
> > >
> > >> # HG changeset patch
> > >> # User Mathias De Maré <mathias.demare@gmail.com>
> > >> # Date 1443590812 -7200
> > >> #      Wed Sep 30 07:26:52 2015 +0200
> > >> # Node ID 5a00a9ab705848b7de45b4263ed0bbab29494e29
> > >> # Parent  46af0adb5c375cc51ce0d29cbdcd8ba843a33425
> > >> backout: add example of backing out a merge changeset
> > >>
> > >
> > > How does this cope with:
> > >
> > >     Note:
> > >       backout cannot be used to fix either an unwanted or incorrect
> merge.
> > >
> > > Did you read previous discussion on the topic?
> >
> > I found the following about the topic:
> > https://selenic.com/pipermail/mercurial-devel/2011-October/034559.html
> > The issues described are when you have 2 valid branches and the merge
> > between them goes wrong.
> > But what I describe here is when one of the branches is bad (and all the
> > changes on it are bad), while the other branch is good.
> > In that case, I would like to apply the inverse of the branch, and it
> seems
> > to be like that would indeed solve my issue.
> >
> > Matt describes here (see the last example) the issue of backing out an
> > entire merge:
> > https://selenic.com/pipermail/mercurial-devel/2011-October/034569.html
> >
> > > In other words, you just turned a broken real merge into a dummy merge,
> > > which is probably not what you wanted.
> > >
> > > In fact, that is what I wanted. I agree that a backout of a merge is a
> > broken concept in some of the cases, but I believe it is a valid concept
> > for the case I'm describing.
> > Perhaps I'm missing something here?
>
> We don't want to even mention merge in the backout docs because people
> will try to do something it can't really do and compound the damage on
> their DAG.
>
That does make sense.
I was trying to think of a way to make it possible to clarify my use case
without risking people incorrectly using backout, but it seems like a
difficult exercise.
One possibility would be to change the note (not sure if the above is a
good choice).
Currently:
    Note:
      backout cannot be used to fix either an unwanted or incorrect merge.

Alternative:
    Note:
      Backout cannot be used to fix either an unwanted or incorrect merge.
It
      can be used in the case where the changes on one side of a merge are
      wrong and need to be removed.


>
> It's pretty easy to just use revert to make a dummy merge, no?
>
Yes, that's true, but it's not quite as obvious as doing a backout.

Greetings,
Mathias
Matt Mackall - Oct. 1, 2015, 5:32 a.m.
On Thu, 2015-10-01 at 07:26 +0200, Mathias De Maré wrote:
> > We don't want to even mention merge in the backout docs because people
> > will try to do something it can't really do and compound the damage on
> > their DAG.
> >
> That does make sense.
> I was trying to think of a way to make it possible to clarify my use case
> without risking people incorrectly using backout, but it seems like a
> difficult exercise.
> One possibility would be to change the note (not sure if the above is a
> good choice).
> Currently:
>     Note:
>       backout cannot be used to fix either an unwanted or incorrect merge.
>
> Alternative:
>     Note:
>       Backout cannot be used to fix either an unwanted or incorrect merge.
> It
>       can be used in the case where the changes on one side of a merge are
>       wrong and need to be removed.

I think you're being too optimistic about the distribution of user
competence.

> > It's pretty easy to just use revert to make a dummy merge, no?
> >
> Yes, that's true, but it's not quite as obvious as doing a backout.

Neither backout nor revert have any help examples and could really use a
few. And should probably "see also" each other.
Pierre-Yves David - Oct. 1, 2015, 5:37 a.m.
Can we make sure a simple and clear statement about this issue is 
written somewhere so that we can just point it out next time the topic 
appears?

On 09/30/2015 10:32 PM, Matt Mackall wrote:
> On Thu, 2015-10-01 at 07:26 +0200, Mathias De Maré wrote:
>>> We don't want to even mention merge in the backout docs because people
>>> will try to do something it can't really do and compound the damage on
>>> their DAG.
>>>
>> That does make sense.
>> I was trying to think of a way to make it possible to clarify my use case
>> without risking people incorrectly using backout, but it seems like a
>> difficult exercise.
>> One possibility would be to change the note (not sure if the above is a
>> good choice).
>> Currently:
>>      Note:
>>        backout cannot be used to fix either an unwanted or incorrect merge.
>>
>> Alternative:
>>      Note:
>>        Backout cannot be used to fix either an unwanted or incorrect merge.
>> It
>>        can be used in the case where the changes on one side of a merge are
>>        wrong and need to be removed.
>
> I think you're being too optimistic about the distribution of user
> competence.
>
>>> It's pretty easy to just use revert to make a dummy merge, no?
>>>
>> Yes, that's true, but it's not quite as obvious as doing a backout.
>
> Neither backout nor revert have any help examples and could really use a
> few. And should probably "see also" each other.
>

Patch

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -495,6 +495,19 @@ 
       cancel the merge and leave the child of REV as a head to be
       merged separately.
 
+      Examples:
+
+      - do a backout of a merge changeset 33 that was created from
+        a good changeset 22 and a bad changeset 11::
+
+          hg backout -r 33 --parent 22
+          hg commit -m "Backout of merge 33 to parent 22"
+
+        After the backout, all of the changes on
+        the good side of the merge (the side of changeset 22 and ancestors)
+        are kept, while the changes on the bad side of the merge
+        (the side of changeset 11 and ancestors) are backed out.
+
     See :hg:`help dates` for a list of formats valid for -d/--date.
 
     Returns 0 on success, 1 if nothing to backout or there are unresolved