Question

I have two machines, A and B that both access an external hg repository.

I did some development on A, wasn’t ready to push changesets to the external, and needed to switch machines, so I pushed the changesets to B using hg serve. Changesets continued on B, were committed and then pushed to external repo.

I then pulled on A and updated to default/tip. This left the local changesets that had previously been pushed to B as a branch, but because of how I pushed things around, the changes in the local changesets are already in default/tip.

I’ve now continued to make changes and commit locally on A, but when I try to push hg asks me to merge or do push -f instead. I know push -f is almost never recommended.
This situation is close to one where I should use rebase, however the changesets that would be “rebased” I don’t really need locally or in the external repository since they are already effectively in default/tip via the push to B.

Now, I know I could merge with the latest local changeset and just discard the changes, but then I would still have to commit the merge which gets me back into rebase territory.

Is this a case where I could do hg push -f?

Also, why would pushing from A create remote heads if I’ve updated to default/tip before I continued to commit changesets?

Answer 1

I would back up my A & B repositories and then try this:

rem Machine A
rem ---------
hg merge
hg commit -m"merge"
hg push

rem Machine B
rem ---------
hg pull

The merge should ensure that you have one instance of each changeset visible from the tip, plus an additional merge changeset with no file changes. It should be safe to push the committed merge – although I would check this before doing it.

One of the features of Mercurial is that it is good at merging, so you could try to take advantage of this. If you are nervous about the effect of a merge you could try:

hg merge --preview

to get a better idea of what it is about to do.

If you really want an unbranched history, then you could create a clean clone of the external repository [if it isn’t too big] and apply your changes from A as patches.