How to use Mercurial?

[Michael Ekstrand]

On 04/08/2010 10:07 AM, Jon Ribbens wrote:
> On Thu, Apr 08, 2010 at 04:54:03PM +0200, Dirkjan Ochtman wrote:
>> On Thu, Apr 8, 2010 at 16:51, Jon Ribbens
>> <jon-mercurial at unequivocal.co.uk> wrote:
>>> If we want to make sure a project repository has all the latest
>>> changes from the central repository, we do 'hg pull -u', which
>>> then requires a 'hg merge' and 'hg ci -m merge'. However, if
>>> the working directory is dirty this involves all sorts of nastiness
>>> with 'hg merge -f' and manually keeping track of which changed files
>>> are changed due to the "pull -u" and which were already changed
>>> locally.
>>
>> Yeah, you're not supposed to have a dirty working dir while merging.
>> You should probably wait with merging until you have the local changes
>> committed.
> 
> Yes, that was the impression I was getting. What I don't understand is
> how this is an acceptable restriction? What working practices to
> people use that make this limitation one they can live with?

For me, it isn't a different working practice so much as a mindset
change.  If you follow the rule that you never have a dirty working dir
while merging, then a copy your work is always saved before you merge.
If the merge somehow fails (weird conflicts or something) and you need
to re-try it, you have that option - you can just 'hg up -C <mychange>'
and re-merge.  With rebase, you can do this and have linear
history/fewer merge commits.  If you try to merge into a dirty working
copy, and the merge gets ugly, recovering with your changes intact is a
lot harder.

The safety net provided by commit-before-merge changes this from a
restriction to a huge benefit.

- Michael