tg-update.sh: suppress "automatic" merges on failed octopus
commit3834295db4d3c2dd6362a9d39b611d6594092d18
authorKyle J. McKay <mackyle@gmail.com>
Thu, 23 Feb 2017 09:51:36 +0000 (23 01:51 -0800)
committerKyle J. McKay <mackyle@gmail.com>
Thu, 23 Feb 2017 09:51:36 +0000 (23 01:51 -0800)
tree50a59fcc838cfc4a8340058f4cd5fe7b3b67cc0c
parent020f70096e3e73660b1914213da93dc541081d5b
tg-update.sh: suppress "automatic" merges on failed octopus

If an attempt to create an octopus merge fails, multiple
individual three-way merges are attempted instead.

It's quite possible that the individual merges will succeed
using the "recursive" strategy where the simple merge strategy
of the octopus merge did not.

However, if that happens, it's important to avoid using any
"simple" (aka git merge-file) operations to perform any "automatic"
merges for any of the other heads that were part of the failed
octopus since it's likely the "recursive" logic will be needed to
guarantee that no unintentional "duplicate" merging happens.

In other words, once we've "upgraded" one of the octopus heads
from "automatic" to "recursive" we must upgrade all the rest
of the "automatic" merges to "recursive" to avoid accidents.

Plain "trivial aggressive" merges are, however, still permitted.

This would seem likely to result in a "tg update" speed penalty.

And, in fact, there is a small speed penalty, but it's mitigated
by the fact that 1) a full checkout would have been required
anyway at some point for at least one of the heads, 2) the rest
of the heads for the failed octopus are done on top of that one
so they will all be relatively fast after that first full checkout
and 3) pure "trivial aggressive" merges are still allowed so there
can still be some in-index merge activity taking place.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
tg-update.sh