Does merging capture both parents?

[Matt Mackall]

On Fri, Jul 01, 2005 at 09:36:04PM -0400, Theodore Ts'o wrote:
> 
> Right now, it looks like "hg update -m <node>" will merge a node into
> the current working directory, and then a "hg commit" will only record
> the parent of the working directory, but not <node> as a second parent.
> Is that correct?

No. See here for some counterexamples:

http://www.selenic.com/hg/?cmd=changelog&rev=merge+tah

There are two scenarios:

Scenario 1: linear merge

  r1           r1                r1             r1
  |   pull ->  | \   update ->   |   commit ->  |
  wd           r2 wd             r2             r2
               |                 |              |
               r3                r3             r3
                                 |              |
                                 wd             r4

Scenario 2: branch merge

  r1            r1               r1               r1
  |   pull ->   | \    update->  | \    commit -> | \
  r2            r3 r2            r3 r2            r3 r2
  |             |   |            |  |             |  |
  wd            r4  wd           r4 |             r4 |
                                  \ |              \ |
                                   wd               r5

The second case requires -m, the first case ignores it.

Why do we bother with the first case, you may wonder. Well:

- branch merges basically force a commit
  - merge3 is only meaningfully definable with two parents and one
    ancestor, so we can't bring in more lines of descent without
    trouble
  - it's basically good practice: a merge is a single unit of work and
    ought to be recorded as such (after you've verified the merge is
    correct!)

- branch merges complicate history

- merge3 can't do anything useful with a parent that's also the
  common ancestor

-- 
Mathematics is the supreme nostalgia of our time.