ansaurus

Question

Is constant merging with Mercurial common practice? Something wrong with this workflow?

Answer 1

+3 A:

There's nothing wrong with this. The vast majority of merges should be automatic. You did create two heads when you both made changes stemming from the same revision and going in divergent directions - your changes might or might not conflict.

If you want to eliminate the "merge" changesets (which aren't actually a problem), you can change/pull/rebase/commit/push instead of change/commit/pull/merge/commit. In other words, before committing your changes, rebase them to the new tip.

Borealid 2010-07-29 20:59:42

Boo for suggesting rebase without warning someone that it's a form of rewriting history and has potential dataloss that merge never does. Mercurial workflows involve merges.

Ry4an 2010-07-30 04:58:45

@Ry4an : Rebasing before a commit has ever become public is not rewriting history. It's just taking a diff of your changes and applying them to the new tip instead of the place you originally made the modifications. Nothing wrong with that.

Borealid 2010-07-30 13:34:38

There's no risk of invalidating remote caches, but it does use some on-disk data structures that are usually append-only and does inserts on them. There's a reason it's disabled by default in mercurial -- history modifying commands are. Ask in #mercurial if anyone has ever had rebase fail and leave their repo disconnected. It's worth warning a guy.

Ry4an 2010-07-30 13:38:11

@Ry4an : If the problem is with the Mercurial-internal structures you could do the rebase via `hg export; hg clone; hg import` instead of using the rebase extension. That will never ever fail.

Borealid 2010-07-30 13:39:34

@Borealid, yeah that's a much more traditional Mercurial workflow. I'm not saying no one should ever use rebase, but they should always be warned it's a little closer to playing with fire than the traditional tools are. Mercurial's primary author is very big on the idea that Mercurial is entirely usable without enabling any extensions, and I agree. Personally, I love a merge-y history -- it lets me think back to my CVS days and laugh heartily. :)

Ry4an 2010-07-30 18:42:15

Answer 2

+1 A:

If the merges are being executed without manual merge resolution, then I would say mercurial and your workflow are behaving as designed.

msw 2010-07-29 21:00:32

What do you mean by "with no human intervention?" Do you mean, no manual resolution of conflicts? Or do you mean, no having to go "hg merge; hg commit" to do the merge?

Chad Johnson 2010-07-29 23:01:06

I meant "manual merge resolution" but Borealid's answer is more complete which is why I upvoted it. I've edited my answer to clarify, thanks.

msw 2010-07-29 23:37:26

Answer 3

+1 A:

It is common as you really do need to get your repos in a consistent state. One thing that speeds it up is instead of

hg pull; hg update

use fetch

hg fetch

This will intelligently do a pull and than either an update or a merge. It comes with mercurial so it's basically a matter of editing your .hgrc to add a line like so:

[extensions]
hgext.fetch=

If the merge goes cleanly you won't even notice it happening. That was a big help in my workflow.

Paul Rubel 2010-07-30 00:35:04

ansaurus

tags:

views:

answers:

Is constant merging with Mercurial common practice? Something wrong with this workflow?

related questions