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>