Question

I have a repository with two branches, A and B.

They are meant to be the same code, but aimed at different versions of the libraries they depend on.

So A/file1.js might have a snippet in it like so:

this.actor.bar();

whilst B/file1.js might have:

// `bar` had its name changed to `foo` in version X.Y of library Z
this.actor.foo();

Then I go along into A say and make a whole bunch of changes that are compatible with both versions of library Z and want to merge them into B.

Is there any way I can tell mercurial, “do a merge but ignore the lines where *.bar() becomes *.foo()“?

Basically there are a few blocks of code that differ between branches A and B because of the version of library they depend upon, but I’ve written the code such that asides from those lines, the rest of the code is identical.

I just don’t want to have to deal with these blocks of code every time I merge, because otherwise I’m more prone to fudge up the merge and switch some of these blocks around.

The only thing I can conceive is somehow making a different diff preset for each file that calls diff --ignore-matching-lines [impressively_long_argument] that is custom to each file – this seems like the wrong way to do it!

(Can I do this in git? This is a feature I’d switch versioning systems for, although I have no idea how one would implement it. Or perhaps the solution lies in finding a sophisticated diff tool).

Answer 1

Git and Mercurial both handle this more easily that you’re imagining (and easier than, say, svn or CVS do). That’s because git and Mercurial merge changes not differences.

If you have two branches, A and B, and you’ve changed bar to foo in branch A when you do this:

hg update B
hg merge A

it will merge in all the changesets currently in A that haven’t yet been merged into B. That will include your bar to foo change and you’ll have to manually exclude that specific change but only that one time.

The next time you do:

hg update B
hg merge A

it will again merge in all the changesets currently in A that haven’t been merged to A, but since the changeset that does bar to foo has already been merged in it doesn’t matter at all that A has foos and and B has barss because that difference wasn’t created in the changesets now being merged, that change won’t be applied to B and you don’t have to manually reject it again.

This is one of the key advantages that a CVS with a full graph history brings. You’re not merging two snapshots, you’re applying the differences that are new in branch A to branch B, so if a difference isn’t new you don’t have to re-reject it — the system remembers, “oh, I remember, you didn’t want that”.