How to use Mercurial?
Michael Ekstrand
michael at elehack.net
Fri Apr 9 10:02:06 CDT 2010
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
More information about the Mercurial
mailing list