Question

This is not a question or feature request, but just a chance to document something I've discovered about merges in Mercurial that I think will be valuable to the Kiln audience.

Let's say that you have your code tagged at Version 1. You make a couple changes to two files and commit the changeset. When you go to push your change to the remote repository, you've found out that another developer refactored the code and made changes to 100 different files while you were editing your two files.

If you:

1. pull changesets from remote (but do not update)
2. merge the two heads
3. commit the merge

You will see 100 files in the merge, with only two of them actually having been merged.

If you:

1. pull changesets from remote
2. update to the other new head
3. merge the two heads
4. commit the merge

The merge now contains only the two files you modified, with the merge results.

I assume this is because the merge operation considers changes made to the local state as the changeset to commit.

So the bottom line: update yourself to the head with the most files modified before doing the merge. This will minimize the scope of the merge changeset.

Hope this helps,

-Steve

Answer 1

Steve,

That's a very good observation! In fact, it may be worth writing an extension to do it for you; when you merge, before the merge starts, it does a quick update to the parent with more changes, and then continues as usual.

Answer 2

Actually this should not make too much of a difference, since the only files which make a real difference when working should be the ones which are changed in both revisions. They are the ones with potential conflicts.

Also the number of files changed need not equal the number of lines changed.

More useful might be an extension which records in the merge changeset’s commit message which files had changes in both revisions (automatic merge) and which had to be resolved by hand (conflict).

All other changes are mostly uninteresting, as they can be found by just looking at the previous revisions.