8

We just changed over to mercurial from subversion and there is one thing that is taking up more time than expected; merging heads.

We love the fact that it keeps merges independent from the 2 commits (compared to subversion) but we end up on a regular basis merging 2 heads for unrelated changes.

Simple scenario. Both me and Bob are up to date. We both have ou repo up to date on default (aka main) branch and do improvement in different files.

We commit and only one will be able to push to the central server, the other one will create 2 heads. Then, pull, select 2 heads, merge (it will go easily since changes are on different files). Commit, then push.

Therefore, is there an extension that does these steps Attempt merge If no conflicts Commit else Cancel merge

We are looking to have this run on an automated server, so +1 it this is command line and another +1 if it can do the merge without touching the working copy.

Thanks!

Update:
We ended up doing a few python scripts to manage the most common tasks (merge up & build; merge 2 heads).

Thanks for the help!

Babouchk
  • 83
  • 1
  • 5

2 Answers2

3

It sounds like you should be able to use hg fetch for this. It'll pull the changes from the server, merge, and then automatically commit the merge. It does prompt for merge conflicts as well. It's included with Mercurial, so just add 

fetch =

to your hgrc, and you should be all set. It doesn't automatically push, but that's usually a bad idea anyway. You would typically want to run tests and resolve any merge problems before pushing your code out to everyone else.

derekerdmann
  • 17,696
  • 11
  • 76
  • 110
  • 2
    FWIW Mercurial's author, Matt, thinks fetch is a really bad idea: http://www.selenic.com/pipermail/mercurial/2009-June/026320.html – Ry4an Brase Mar 07 '11 at 04:44
  • @Ry4an - Possibly, but you could automatically switch parents through your hgrc (http://www.selenic.com/pipermail/mercurial/2009-June/026324.html). Fetch saves a lot of keystrokes, and works very well for simple repositories where team members are working closely with each other. – derekerdmann Mar 07 '11 at 05:21
  • 1
    what does --switch-parent have to do with anything? Matt isn't recommended against fetch because he didn't know about switch-parent (he probably wrote it). He's recommending against it because he think it's a mis-feature in general. He's talked about deprecating/removing it entirely, but fears it's too late. It's a bad idea. – Ry4an Brase Mar 07 '11 at 05:43
  • 1
    @Ry4an - I took Matt's "that's just weird" comment to be about fetch's default behavior, which --switch-parent changes. Other than that, I'm not sure what his other objections are. I see fetch as a way to simplify pulling down changesets from repos, but wouldn't recommend it when there's any really complicated merging or branching. – derekerdmann Mar 07 '11 at 13:22
  • I was referring to Matt's saying *"Your mistake is in step 9, using the fetch extension. It is misguided and unloved."* Fetch leaves a useless comment, when a human could provide a meaningful one, it's hard to undo, and it leads to a lot of people showing up in #mercurial saying "I always use `fetch` but now it requires me to merge and I'm lost!". Merging is a primary activity in software development and DVCS usage, it shouldn't be hidden away -- it's not possible to identify "trivial" automatically or quickly using `hg incoming` and one should err on the side of caution. – Ry4an Brase Mar 07 '11 at 16:03
3

Are the merges really taking that much time? If they're "unrelated changes" doesn't it just take a blink?

Someone already suggested fetch and someone else will probably suggest rebase, but personally I consider merging to be coding, and want it to be manual. It takes almost no time and it's an opportunity to give a good message like "Pulling in Jane's work half-way through my FooBar work" (instead of the useless commit messages fetch provides).

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • 1
    We are trying to automate many of the common tasks, and while that script is running, 2 heads will be common. We could have the system halt and wait for the merge of the 2 heads, but we'd rather not. – Babouchk Mar 21 '11 at 19:52
  • 1
    Merging **is** coding, and neither should be automatically committed without a human intervening. – Ry4an Brase Mar 22 '11 at 02:53