forcing or overriding a merge in mercurial?

Question

When I do "hg heads", I see two heads.

I want to just take the changes from the first and completely ignore the other.

Is that what hg push -f does?

How can I tell mercurial to just ignore the second head?

Answer 1

This tip covers it nicely:

https://www.mercurial-scm.org/wiki/TipsAndTricks#Keep_.22My.22_or_.22Their.22_files_when_doing_a_merge

If you're updated to the one you want then you'd run:

hg --config ui.merge=internal:local merge  #keep my files

You not want hg push -f.

Answer 2

This page gives three different methods for getting rid of branches, but will work for heads as well. A Branch is created when a changeset has more than one child. Named branches can be created with the hg branch command, however unnamed branches can be created (either on accident or on purpose) by committing two changesets to the same parent.

For example, if I make a new repository, add a file to it, and commit, that commit will be changeset 0.

hg init     # create repo
# edit file myfile.txt
hg add myfile.txt 
hg ci -m 'added myfile.txt' # creates changeset 0

Then I make some more changes and commit again, creating changeset 1, who's parent is changeset 0.

# more edits to myfile.txt
hg ci -m 'changed myfile.txt' # creates changest 1, with parent changeset 0

Now, for some unknown reason I go back to changeset 0, make some changes to myfile.txt and commit those.

hg up -C 0    # update to changeset 0
# more edits to myfile.txt
hg ci -m 'edited myfile.txt' # creates changeset 2, who's parent is also changest 0

Now we've done something strange. We've gone back before changeset 1, and made a different change. We've gone back in time in our code and changed something creating an alternate universe like in BttF Part II!

Well ok, not really. We've really just created a branch. However it's an unnamed branch since we didn't create it with the hg branch command (and thus doesn't show up in `hg branches). It has also created a new head. Heads are just changesets with no children, so any branch, named or unnamed, that hasn't been merged or closed will have a head.

This is a contrived example and and probably not what you did. What is more common is if you work from two locations and forget to push when done at one location or pull when starting work again at another location. If you don't push when done at one location, when you start work at the 2nd location you may be working on an older changeset, and thus any commits will create a second head. A similar thing happens when you forget to pull.

As I said earlier, this creates an unnamed branch. However you can treat this branch the same as any other branch. The command hg update branch_name simply updates you to the head of that branch, so for the unnamed branch you can simply update to the head of that unnamed branch with hg update head_revision and hg heads will list the heads for you (or hg heads -v if you want more info about each head).

I would recommend simply closing the head you no longer want (the first option on the first link above). That way it's still there just in case you might need it later, but it won't show up in hg heads. To do this run the following commands:

hg up -C head_to_close
hg commit --close-branch -m 'Closing un-wanted head'
hg up -C head_to_keep

You'll have to figure out which head you want to close though. hg heads -v will give you some extended info about the heads. You can also update to each one hg up head_changeset and examine the code to figure out which one you want to close.