Really undo bad merge

[Laurens Blankers]

Hi,

 

I have a situation in which two branches were merged to soon. So I would like to undo the merge in such as way that I am able to redo the merge at a later stage.

 

Basically the Wiki describes my situation exactly:

http://mercurial.selenic.com/wiki/Backout?action=recall&rev=21#Backout_of_a_Merge_Changeset

 

However in the final step (the black box to the far right) I would like the result to be "a b c X Y Z".

 

The wiki on named branches states no solution exists yet:

http://mercurial.selenic.com/wiki/NamedBranches?action=recall&rev=20#Undoing_a_Bad_Merge

 

Does this issue still exist in 1.9? Is there an issues to track progress on this?

 

Thanks,

 

Laurens

[Matt Mackall]

On Tue, 2011-09-27 at 11:38 +0200, Laurens Blankers wrote:
> Hi,
>
>
>
> I have a situation in which two branches were merged to soon. So I would
> like to undo the merge in such as way that I am able to redo the merge
> at a later stage.
>
>
>
> Basically the Wiki describes my situation exactly:
>
> http://mercurial.selenic.com/wiki/Backout?action=recall&rev=21#Backout_o
> f_a_Merge_Changeset

> <http://mercurial.selenic.com/wiki/Backout?action=recall&rev=21%23Backou
> t_of_a_Merge_Changeset>

>
>
>
> However in the final step (the black box to the far right) I would like
> the result to be "a b c X Y Z".
>
>
>
> The wiki on named branches states no solution exists yet:
>
> http://mercurial.selenic.com/wiki/NamedBranches?action=recall&rev=20#Und
> oing_a_Bad_Merge

> <http://mercurial.selenic.com/wiki/NamedBranches?action=recall&rev=20%23
> Undoing_a_Bad_Merge>

>
>
>
> Does this issue still exist in 1.9? Is there an issues to track progress
> on this?

There are two important points to understand:

a) All merge algorithms that I'm aware of have a fundamental weakness:
they assume all changes going forward in time are GOOD.

b) Mercurial's existing data structures contain no way of countering
that assumption.

..which means it's impossible for backout to ever fix the problem
without designing a whole new, much more complicated SCM with its own
newly-invented merge algorithm. In short, it's a hard problem.

Thus, the only way to fix up a catastrophic merge is to:

1) manually fix the merge
2) force ALL users to update past the merge point so that the bad merge
is never the common ancestor again and is thus never consulted again

Having a good write-up of how to do this on the wiki would be nice.

--
Mathematics is the supreme nostalgia of our time.

_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial

[Tim Schmielau]

Laurens Blankers <Blankers <at> riscure.com> writes:

> I have a situation in which two branches were merged to soon. So
> I would like to undo the merge in such as way that I am able to
> redo the merge at a later stage.
>  
> Basically the Wiki describes my situation exactly:
> http://mercurial.selenic.com/wiki/Backout
>  

> However in the final step (the black box to the far right) I would
> like the result to be "a b c X Y Z".

I'm not sure I fully understand your situation, but here
is how I would handle a bad merge:

Suppose I had merged two branches and developed further on
top of that:

a -> ab -> abxy -> abxyz
/
x -> xy

Now I discover the merge was bad, so I redo it:

a -> ab -> abxy -> abxyz
/\
x -> xy -> abXY

To instruct mercurial that this merge is better than the
previous one, I pro forma merge it again with the old,
bad merge, always choosing the version from the good merge:

a -> ab -> abxy -> abxyz
/\ \
x -> xy -> abXY -> abXY

Now I can merge with everything developed on top of the
bad merge without risking to reintroduce the bad changes:

a -> ab -> abxy -> abxyz
/\ \ \
x -> xy -> abXY -> abXY -> ab XYZ

Would this method apply to your problem?
Tim