Question

I’ve been using Mercurial for a few weeks now and don’t understand why when Mercurial comes to merge committed changes from two repositories it does it in the working copy?

Surely the merge could happen without the use of the working copy removing the need to shelf changes etc.

It just doesn’t seem necessary to involve the working copy. Am I missing something?

Answer 1

There is only one working copy per repository, by definition:

The working directory is the top-level directory in a repository, in which
the plain versions of files are available to read, edit and build.

Unless your file system descends from Schrödinger’s cat, you cannot have two versions of the same file at the same time, thus you cannot have two working copies.

Nevertheless, it’s indeed theoretically possible to use something like a ephemeral clone (per @Ry4an) to act as the working copy of a merge, resolve conflicts there, commit, then make it disappear. You’d get a beautiful merge changeset and your intact working copy.

I can think of several ways to achieve this:

1. Petition hg team to do it in core
2. Write an extension to implement the ephemeral clone or some other way
3. Shelve with a temporary changeset
4. Shelve with MQ

I would strongly recommend #4, as I would for almost all workflow scenarios. It took me a few good days to grok MQ, but once I did I’ve never had to turn back.

In an MQ workflow, your working copy is always the current patch. So for the merge situation you would do:

1. hg qrefresh
2. hg qpop -a
3. hg update -r<merge first parent>
4. hg merge [-r<merge second parent>]
5. hg commit
6. hg update qparent
7. hg qgo <working copy patch>

You don’t have to pop all patches in #2. I always do that whenever I need to deal with real changesets to avoid mixing them up with patches.

Solution #3 is really the same as #4, since a patch is a temporary changeset by definition (this is really the only thing you need for understanding MQ). It’s just different commands:

1. hg commit -A
2. hg update -r<merge first parent>
3. hg merge [-r<merge second parent>]
4. hg commit
5. hg update -r<working copy changeset parent>
6. hg revert -a -r<working copy changeset>
7. hg strip <working copy changeset>

If you want to keep the working copy changeset and continue to commit, simply update to it in #5.

From your question it seems like you already know #4 but don’t like shelving. I think shelving is good because merging is a fundamentally different task than coding (changing working copy), and shelving makes the context switch explicit and safe.