Question

I have just been asked by a fellow developer whether they need to do anything when that merge window appears. Apparently their default course of action has been to simply close the window immediately.

Anyway, we're now in a situation where they have made minor changes to a number of files where another developer made a large number of changes. They then 'merged' them, essentially backing out all remote changes to the files, committed the code, and pushed to the central repository.

So we're in the situation that there is revision x with changes we want, revision y with changes we want, and revision z that is a merge of x+y, but actually just contains the code from y.

Is there a way now to retrospectively get back into the merge tool?

I'd like to run a command and get a meld window up to let me merge back in the changes from y into the current revision.

Was it helpful?

Solution

First, clone your repository somewhere, and test these instructions in there. I tested them on a very small repository made for the purpose, so I may have overlooked something.

hg clone yourrepo testrepo
cd testrepo

You can check out the code as of revision x, and repeat the merge. That will give you a new head. Then, if you have not made changes since, you can use hg strip to get rid of the bad one. If you don't want to risk the strip, then merge the two heads, telling hg to keep the version of the code in the good version. If you have it checked out, as you will immediately after making it, then give the argument -t internal:local to throw away the changes from the other, bad, head. It's a lot simpler to do than to explain:

hg update x
hg merge -r y
hg commit -m 'Redo the merge.'

Then either:

hg strip z

or:

hg merge -t internal:local -r z
hg commit -m 'Get rid of the bad merge.'

You can look at the state of the graph with the very useful hg view extension.

Once again, I tested this on a toy repository. Back it up first!

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top