merge awkwardness

Matt Mackall mpm at
Tue Aug 23 15:16:10 CDT 2005

On Tue, Aug 23, 2005 at 01:14:39PM -0500, Hollis Blanchard wrote:
> On Monday 22 August 2005 18:19, Matt Mackall wrote:
> > On Mon, Aug 22, 2005 at 05:08:20PM -0500, Hollis Blanchard wrote:
> > > I've got a problem I don't understand, so maybe I'm just doing something
> > > wrong...
> > >
> > > I've got a Xen branch that I'm trying to merge up to the latest Xen
> > > upstream.
> > >
> > > 	# get branch
> > > 	hg clone
> > > 	cd xenppc-unstable.hg
> > > 	# pull in latest upstream changes
> > > 	hg pull
> > >
> > > At this point I have two options, "hg update -m" or "hg update -C". -m
> > > drops me into vi for a whole ton of files I haven't changed in my branch,
> > > so that seems wrong. See for yourself:
> > > 	hg update -m
> >
> > Seems you've not got any of the normal 3-way merge tools available.
> > $EDITOR is the last fallback of the hgmerge script. You'll probably
> > want one of merge (from RCS), tkdiff, or kdiff3 (recommended).
> Actually, the vi part wasn't my question... I'm worried about needing to merge 
> files that I haven't touched.
> Turns out I had, somehow, and I think this is my problem. At some point I was 
> forced to merge tools/ (as an example). I had no local changes to it, 
> but a changeset was generated for it anyways (see changeset 5856 at 
> So now I really have local changesets to tools/, so all future 
> upstream changes will require me to merge?

Ok, I think we've figured out the 'didn't change any files' problem.
There was a bug related to rename that was comparing working directory
against file contents + rename metadata, rather than just file
contents. Fixed in tip.

If you have a private branch, you will indeed need to merge every time
you try to bring in changes from the upstream branch.

> Also confusing: the changeset IDs listed at that URL do not match those listed 
> by 'hg log tools/':
> 	changeset 5856:  	9315bd0d698d
> 	parent 5797:	47ca1724b31c
> 	parent 5855:	48aed1403fe3
> vs
> 	changeset:   5856:9315bd0d698d9ca77878a38aa82928a74c9218ca
> 	parent:      5:f168352f92328c20bb5419fbac8fb4723e26fc9d
> 	parent:      6:4d2ce12aad39909ae221671c11b37bf48dfff266

This is unnecessarily confusing but probably correct.

There are actually _3_ sets of revision numbers and hashes, at the
level of changesets, manifests, and individual files. The last two
lines above are file level revision numbers and hashes, and have no
relation to the changeset ones.

The plan is to eventually only show the changeset ones to reduce this

But you should also be aware that the revision _numbers_ are not
expected to be the same in different machines. They will change
depending on the relative orders that changesets get pulled into

Mathematics is the supreme nostalgia of our time.

More information about the Mercurial mailing list