Thanks, Linus, for taking your time to answer me. I truly appreciate
it.

also sprach Linus Torvalds <torvalds@linux-foundation.org> [2007.10.09.0221=
 +0100]:
quoted text
> So when the octopus merge starts merging in "master" into the
> "merger" branch, it will *not* just fast-forward the branch to
> "master". Instead, if will generate a new tree that is basically
> the merged state: but that new tree is *not* the same as the
> master commit, it's literally a merge of the two branches - which
> in practice means that it has the same *content* as master, but
> it's not at that commit.

Okay, this makes perfect sense.

quoted text
> And so now we have a half-way done octopus merge, with the first
> branch added. Now it merges in the second branch ("second"), and
> it *still* has the merge base being the original merge base,
> namely "merger".
>=20
> And from that standpoint, it really *is* a conflict.=20

I would have to agree with you: this is pretty exactly what's going
on.

Now, I think Git could do better though. Fast-forwarding
octopus merges, as you suggest, is one possible enhancement, but is
that the solution to my problem? Yes, but could we do better?

Couldn't Git just ignore any commit it has already seen in this
octopus merge? I think this is perfectly okay in terms of the
resulting ancestry, it's really all about applying a commit to the
worktree or not.

Recall the original tree:

  x -- master: d2
  | x -- second: b
  |/
  x  d1
  |
  x -- merger: a

Now after merging master, the tree is at the same state as it is at
the tip of master. The asterisk denotes that the commit is half-way
done:

  x  c* (a+d1+d2)
  |\
  | x -- master: d2
  | | x -- second: b
  | |/
  | x  d1
  |/
  x  a

Next, we merge second to create c2

  x_ c2*  ((a+d1+d2)+(d1+b))
  |\ \
  | | |
  | x-|- master: d2
  | | |
  | | x -- second: b
  | |/
  | x  d1
  |/
  x  a

(yay ASCII art!)

At this point, the conflict happens, when Git tries to re-apply d1
to the work tree. But since d1 is already in the ancestry of the
node into which we are merging, couldn't it just skip applying the
commit to the worktree?

  x_ c  (a+d1+d2+b)
  |\ \
  | | |
  | x-|- master: d2
  | | |
  | | x -- second: b
  | |/
  | x  d1
  |/
  x  a

If it does, then I think ordering of merges for an octopus becomes
relevant, but I'd say that's already the case.

And I guess this is identical to fast-forwarding the branches...
just seems like approaching it from another angle to me.

quoted text
> If you think of octopus merges as a really stupid thing where git
> will mindlessly do a three-way merge based on the *current* state
> with all the branches you name, then you get the current octopus
> merge. You just expected it to be smarter than it is, probably
> because you compare it to the *real* merge.

No, Git just raised the bar for expectations half-way up to the
moon In other words: you spoiled me so far; now I won't settle for
less than perfection. :)

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
"however jewel-like the good will may be in its own right, there is
 a morally significant difference between rescuing someone from
 a burning building and dropping him from a twelfth-storey window
 while trying to rescue him."
                                                       -- thomas nagel
=20
spamtraps: madduck.bogus@madduck.net