Backing out merges and closing heads

[Martin Geisler]

Philip Pemberton <philpem at philpem.me.uk> writes:

> On 24/05/10 21:37, Vishakh Harikumar wrote:
>> You can use 'hg clone -r rev [-r rev..]'. This will result in a clone
>> containing all
>> the specified revisions and their ancestors. In this case 'hg clone src
>> dest -r 62 -r 59 -r 52'
>
> I guess I need to RTFM a bit more closely. I was under the impression
> you could only specify a single rev to 'hg clone'...
> If specifying '-r' only clones that rev and its ancestors, that would
> nicely explain why one of the dev branches vanished when I cloned the
> repo (the one that vanished was the last one I merged in).

Yeah, it's actually not that easy to discover rigt now. We've had some
patches floating around that would improve this by annotating each
command line option to say if it can be repeated.

>> If i understand the next part correctly, in the new clone,
>> hg up -r 59
>> hg merge -r 52
>> to keep r59 and discard all changes from r52 hg revert -a -r 59
>> mark everything as resolved 'hg resolve --all -m'
>> and commit
>
> Huh. Again, I need to RTFM... I thought 'hg revert' would back out all
> the changes made in 'hg merge', including the fact that I was doing a
> merge.

Almost -- as you know, a merge is special by having two parent
revisions. You can see the two parent revision right after 'hg merge'
with 'hg parents'. This is how you know that a merge is currently being
done in the working copy.

When you use 'hg revert', you change the file content only, but not the
working copy parent revision. So that means that a 'hg revert --all -r
59' will change everything back to how it looked at revision 59, but
without aborting the merge.

You use 'hg update' to change the file content *and* the working copy
parent revision. So that is also the command you use to abandon a merge
completely. In particular, 'hg update --clean .' will update the working
copy parent revision to the first parent (always called '.') which
brings you back to how things looked before you did 'hg merge X' (the
second parent of the merge was then 'X').

> Is it possible to stop 'hg merge' from firing up Kdiff3 in situations
> like this? In other words, just leave all the merges unresolved and
> let me deal with the fallout? An "I'm doing an unusual merge, leave me
> to deal with it" switch, if you will :)

Yes, we sort of have such a switch:

  hg --config ui.merge=internal:fail merge

That overrides the normal merge tool configuration in Mercurial and you
wont see Kdiff3. All files will be left unresolved after that, so use
revert to give them the right content and resolve to tell Mercurial that
things are okay.

-- 
Martin Geisler

See my Mercurial presentation: http://vimeo.com/11497288
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20100525/8ae9bbe3/attachment.asc>