How do I check for potential merge/rebase conflicts in Mercurial?

Question

Is there a simple way to check if a merge/rebase will yield file conflicts, without actually performing the merge/rebase?

I want to be able to decide whether to:

Answer 1

There is no reason to use hg merge if the changes overlap and hg rebase otherwise since hg rebase make a merge internally and will let you resolve it using the same tools as hg merge.

As for testing if a merge or rebase will cause conflicts, then you can use

$ hg merge --tool internal:merge

in Mercurial 1.7 to override your normal merge tool configuration. (The --tool internal:merge part is new, use --config ui.merge=internal:merge in earlier versions of Mercurial.)

Following the merge,

$ hg resolve --list

will tell you the results and you will get back to where you started with

$ hg update --clean .

Answer 2

You can see if two changesets, REV1 and REV2, affect any of the same files doing something like:

(hg status --change REV1 --no-status ; hg status --change REV2 --no-status) | sort | uniq --repeated

If that has any output then the same file is touched in both revisions.

That could easily be made a shell script like:

#!/bin/sh
(hg status --change $1 --no-status ; hg status --change $2 --no-status) | sort | uniq --repeated

which could be run as any of these:

./find_overlaps c8f7e56536ab d9e2268e20b9
./find_overlaps 1 33

If you really wanted to get fancy you could tweak the script to automatically run merge or rebase depending on whether or not any lines were found.

If you're on windows my god help you. :)

Answer 3

So, with some aid from Martin's answer, I've come up with the rebaseif extension, which does what I want.

Essentially, it tries to rebase using the internal merge tool, if that fails (which it does for any conflict), it aborts and does a merge with the user's preferred tool.

See https://bitbucket.org/marcusl/ml-hgext/src/tip/rebaseif.py for details.

Update

In recent months, I've gone back to just do a merge, since it's inherently safe. A non-conflict rebase might still muck things up since dependent files can affect the change. (i.e. a rebase loses information of how the code looked before merge).

As the rebaseif author, I recommend to use plain old merge instead. :)