6

Given repository A and repository B (created off a clone of changeset A2):

A1 - A2 - A3 - A4 - A5
        \
          B3 - B4

Say we wanted to merge these two repositories together. Is there any difference if we merged repo B into repo A versus merging repo A into repo B?

The only diff I can think of is the merge tool local/base arguments would be reversed depending on which option you chose. Are there any other differences to be aware of?

Marcus Leon
  • 55,199
  • 118
  • 297
  • 429
  • 2
    Terminology note: you merge *heads* and not *repositories* (which may have multiple heads). – Oben Sonne Apr 08 '11 at 12:25
  • I updated the question to use normal Mercurial terminology. – Martin Geisler Apr 08 '11 at 13:44
  • possible duplicate of [Does merge direction matter in Mercurial?](http://stackoverflow.com/questions/4946930/does-merge-direction-matter-in-mercurial) – Wim Coenen Apr 08 '11 at 14:31
  • @Martin, I reverted the edit. Our situation is we have two repositories - A and B. We can either go to A and do `hg pull B` & `hg merge`. Or go to B and do `hg pull A` & `hg merge`. That is a different question/scenario from having a single repository with two heads already in existence. – Marcus Leon Apr 08 '11 at 17:57
  • @Wim, see my prior comment. Yes it's similar but not identical. – Marcus Leon Apr 08 '11 at 17:58
  • 3
    @Marcus - once the pull is done there's no distinction, you can update to either A5 or B4 before merging. – Kirk Kelsey Apr 08 '11 at 18:31

3 Answers3

8

Generally merges are symmetric, with a few exceptions:

  • If the merged heads are from different named branches, the order is important. The merge revision will be on the first parent's branch.
  • Starting with Mercurial 1.8.4 the same applies to bookmarks, i.e. only the bookmark
    of the first parent will move forward to the merge revision.
  • The order of the merge revision's parents in log and diff views is different, but that doest not have any noteworthy practical implications (from my experience).
Oben Sonne
  • 9,893
  • 2
  • 40
  • 61
  • Perhaps you know. I've always worked on the assumption that I should merge in the branch with the fewest changes (ie. update to h1, and merge in h2, where h2 has fewer changes since common point than h1), is that really necessary then, to do the "best thing"? Perhaps less work for the merge algorithm or whatnot? I don't remember why I made that assumption but judging by your answer, and the more I think about it, it sounds like my assumption is wrong. This is not in relation to multiple named branches though, just two heads in the same named branch, like, say, in the default branch. – Lasse V. Karlsen Apr 10 '11 at 21:31
  • Interesting point. If I think about it, I also tend to merge the branch with less changes into the one having more. But, technically I cannot think of a good reason either. Maybe this assumption is a misconception based on how one would do the merge if it had to be done completely manually. – Oben Sonne Apr 13 '11 at 17:23
  • I think I'll go ask on the Mercurial mailing list, I'll come back with a comment if I get something definitive one way or another. – Lasse V. Karlsen Apr 13 '11 at 17:27
  • 2
    According to [@Martin Geisler](http://stackoverflow.com/users/110204/martin-geisler) and Kevin Bullock on the mailing list (http://www.selenic.com/pipermail/mercurial/2011-April/037990.html), the answer is no, it does not matter for the merging of the file contents. However, the bookmark of the first parent will be moved forward, the other will not (assuming the parents have bookmarks), and if you merge between named branches, the new commit will end up on the named branch of the first parent (unless manually overridden before you commit.) Read the responses, good information to be sure! – Lasse V. Karlsen Apr 13 '11 at 21:11
  • Thanks for investigating this -- it perfectly backs my answer :) Concerning bookmarks, the 'probably' in my answer does not refer to the fact but to the version which introduces this behavior, it's committed but not yet released I think. I'll update the answer later accordingly. – Oben Sonne Apr 14 '11 at 19:14
  • 1
    Updated (since Mercurial *1.8.4* only the first parent's bookmark moves on a merge). – Oben Sonne Jun 10 '11 at 19:45
  • @Oben Thanks for pointing that out, I did not consider which version that particular feature was introduced in. – Lasse V. Karlsen Jun 10 '11 at 20:10
4

The order of the parents for the merge will be different, but that will only affect which diff you see first when you're looking at the merge changeset. Otherwise, there isn't really any difference if you update to B4 and merge to A5 or vice versa.

tghw
  • 25,208
  • 13
  • 70
  • 96
0

I'm no mercurial expert, but after reading this question&resolution I get the feeling that the merge direction can make a huge difference: Backing Out a backwards merge on Mercurial

Community
  • 1
  • 1
Leven
  • 530
  • 3
  • 10