merged two branches, and pushed, how to backout/strip?
Becker, Mischa J
mischa.becker at kroger.com
Tue Jan 10 18:54:02 UTC 2017
> From: Uwe Brauer
>
> > Uwe Brauer <oub at mat.ucm.es> writes:
>
> > The merge and revert are necessary, because if you only revert the
> > default branch, this branch then contains a commit which undoes all the
> > work in vs-11.89. If you were to do some changes and then merge it into
> > the vs-11.89 branch to get that branch up to date, it would undo all the
> > work done in the vs-11.89 branch up until you first merged it into
> > default.
>
> > Reason: Default contains a change which undoes the changes in vs-11.89.
>
> > To fix that, vs-11.89 needs a change which undoes the undoing of its
> > changes.
>
> This drives me crazy I understand your argument, but why isn't it sufficient
> to revert the merge in both branches. Like this
>
> Bad merge repo (now with 2 files)
>
>
> hg init
> echo Main1 > main.txt
> hg add main.txt
> hg commit -m "Main1"
> echo Main2 >> main.txt
> hg commit -m "Main1"
> hg branch vs-11.89
> echo branch1 > branch.txt
> hg add branch.txt
> hg commit -m "Good Commit1"
> echo branch2 >> branch.txt
> hg commit -m "Good Commit2"
> echo badvariable >> branch.txt
> hg commit -m "Bad Commit"
> hg up default
> hg merge vs-11.89
> hg commit -m "Bad merge"
>
>
> Your recipe
>
> # revert to last good commit in default
> hg revert --all -r 1
> hg commit -m "backout bad merge"
> # go to branch
> hg up vs-11.89
> hg merge default
> hg ci -m "merge default with the backout"
> hg log -G
> # revert the last bad commit to branch vs-11.89
> hg revert --all -r 4
> hg ci -m "backout the backout"
>
> But mine
>
> hg revert --all -r 1
> hg commit -m "backout bad merge from default"
> hg revert --all -r 4
> hg ci -m "backout bad merge from vs-11.89"
>
>
> Seems to result in the same files, but not the same graph.
>
> What do I miss?
Assuming you didn't leave out steps between your two reverts you are now worse off because that last commit isn't backing out a bad merge from vs-11.89, it's replacing everything on default with your last revision from vs-11.89.
If the bad merge is only bad because it was committed to the wrong branch, then instead of reverting to the last good commit in vs-11.89, I'd revert to that original merge itself. In the above example that would mean reverting to -r 5 instead of 4. This has the benefit of keeping any changes in default that aren't already in branch vs-11.89. (This use case doesn't exist in your example repo.)
I sometimes combine the last merge and revert into one commit. It's slightly more succinct but less obvious what actually happened.
# revert to last good commit in default
hg revert --all -r 1
hg commit -m "backout bad merge"
# go to branch
hg up vs-11.89
# tell vs-11.89 to ignore the backout of the merge
hg merge default
hg revert --all -r 5
hg ci -m "backout the backout from default"
hg log -G
Mischa
________________________________
This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
More information about the Mercurial
mailing list