Why can't I merge when there are uncommitted outstanding changes?

Mads Kiilerich mads at kiilerich.com
Thu Apr 22 10:10:40 CDT 2010

Aardwolf wrote, On 04/22/2010 04:49 PM:
> But again, if I have uncommitted changes to file A, I have committed changes
> to file B, and on the "central" repository there are changes to file C. How
> hard can it be to automatically solve this by the tools? Isn't that what the
> tools are for?
> Why do I have to manually do so many tricks for that situation? I'm here to
> write code, not someone who loves constantly playing with version control
> systems. They're a very good tool to me to look up file histories (what did
> other people do), give my changes to the rest, and get their changes, but
> that's about it.

You are trying to use a workflow that (often) works with CVS or SVN. And 
because these VCSs enforces a linear history you actually have to use a 
workflow like you describe. The disadvantage is that you don't know 
exactly what you are committing, and you can't verify that the merge is 
correct. And sometimes things go terribly wrong.

Mercurial always tracks whole repositories and doesn't encourage 
workflows where you have many different changes in your working 
directory at once. For example, when you merge then Mercurial will use 
the working directory to resolve conflicts,  and after the merge the 
working directory contains exactly how the changeset will look when you 
commit the merge. There can thus not be other changes in the working 

You have to change your work-flow a bit if you want to use Mercurial.

In your case I would probably wait with the merge until I am ready to 
commit my local changes, commit them, and then merge and commit the 
merge. If the merge goes wrong it can be discarded before commit and 
done again.

If I need the other changes in order to continue I would create another 
clone / working directory, pull the changesets that has to be merged 
into it, do the merge and commit, and pull the result into the first 
working directory and update. But note that the update with pending 
changes in the working directory is slightly risky if you end up with 
conflicts and can't resolve them correctly. Merging tracked revisions is 
more reliable.

In the trivial case where distinct files are changed then Mercurials 
work-flow is a bit overkill. But it is 100% reliable and works in all cases.

(And I suggest that you forget about extensions until you are familiar 
with these work-flows.)


More information about the Mercurial mailing list