Merge woes

[Steve Borho]

On Wed, 2007-10-17 at 00:31 -0700, mercurial.9.pauldf at spamgourmet.com
wrote:
> On 10/10/07, Steve Borho - steve at borho.org
> <+mercurial+pauldf+2a1d96d2da.steve#borho.org at spamgourmet.com> wrote:
> >
> > On Wed, 2007-10-10 at 09:06 -0700, mercurial.9.pauldf at spamgourmet.com
> > wrote:
> > > I ran into a situation that's somewhat similar to the FAQ "My merge
> > > program failed, and now I don't know what to do".
> > >
> > > I installed Mercurial for Windows, and was developing a small piece of
> > > code together with someone who was using Mercurial on his Linux box.
> > > However, it wasn't until I pulled some new code from his repository to
> > > merge it that I realized I didn't have a tool to set up a merge tool.
> >
> > This is the primary reason I've started providing "Batteries Included"
> > Mercurial installers for Windows.  There's a functional merge setup out
> > of the box, along with a history browser and commit tool.
> 
> I think I did that.  However, I did the install as admin, but was
> running it as a regular user; did I miss out on some of the setup that
> way?  Hmm.  Actually, based on the exact message, it looks like it was
> a quoting issue.  (see the output below)
> 
> Output of "hg version":
> 
> Mercurial Distributed SCM (version bbdcdc7f170e+win32extras)

That's embarrassing.

> Copyright (C) 2005-2007 Matt Mackall <mpm at selenic.com> and others
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> > > At this point, he & I decided that the simplest thing was to do the
> > > merge on his side instead of my side.  The merge on his side went
> > > smoothly.
> > >
> > > However, I was left with an unfinished merge in my tree, and I
> > > couldn't figure out how to back out of it.  I tried reverting.  I also
> > > tried pulling from his tree again to pick up the results of his merge.
> > >  In the end, I abandoned that tree, creating a new one (moving any
> > > local changes over if I had any).
> >
> > All that should have been required was:
> > hg update -C REV
> >
> > The merge failure message should have included this, though I haven't
> > run the case where no merge tool was found in some time.
> 
> It vaguely hinted at this:
> 
> merging pivot.c
> 'C:\Program' is not recognized as an internal or external command,
> operable program or batch file.

I'll be releasing a new package based on 0.9.5, hopefully this weekend.
This will be fixed.

> merging pivot.c failed!
> 0 files updated, 0 files merged, 0 files removed, 1 files unresolved
> There are unresolved merges, you can redo the full merge using:
>   hg update -C 4
>   hg merge 5
> 
> Reading the docs for "hg update -C", it sounded like just running that
> command wouldn't only back out the merge; rather, I got the impression
> that it would also destroy any local changes.  So I assumed it must
> not be what I was looking for.

When you run 'hg merge', it adds the 'other' head as a second parent to
your working directory.  Unless you intend to commit the contents of
your working directory as a merge, you have to use 'hg update -C' to
remove the second parent.

The update -C will destroy _uncommitted_ local changes.  Since you had
checked in your changes before attempting the merge (always a good thing
to do), it is perfectly safe to use 'hg merge update -C 4' to get back
to your pre-merge starting point.

> After that, almost everything I did just bailed out with "abort:
> uncommitted merge".

Yes, the second parent will prevent many normal operations from working.

Section 3.1.2 in the hgbook covers this nicely:
http://hgbook.red-bean.com/hgbookch3.html#x7-530003

My apologies for the broken merge configuration.

-- 
Steve Borho (steve at borho.org)
http://www.borho.org/~steve/steve.asc
Key fingerprint = 2D08 E7CF B624 624C DE1F  E2E4 B0C2 5292 F2C6 2C8C