Why can't I merge when there are uncommitted outstanding changes?
Mads Kiilerich
mads at kiilerich.com
Thu Apr 22 15:10:40 UTC 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
directory.
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.)
/Mads
More information about the Mercurial
mailing list