Phillip Wood <phillip.wood@xxxxxxxxxxxx> writes:
> On 02/08/17 23:29, Junio C Hamano wrote:
> ...
>> The
>> latter makes it more in line with how "am -3" followed by "am --no-3
>> --continue" behaves.
>
> I'm a bit confused about what am does when you pass extra options to
> --continue. It looks like they do not persist if there's another
> conflict and may only apply to the first patch that is applied when
> resuming - I'd need to spend more time looking at the code or run a test
> to be sure.
I think you got what "am" wants to do.
The idea is that the user would say she does not trust the three-way
fallback when she starts to apply many patches in an mbox, i.e.
$ git am mbox
Upon seeing a message that does not apply, she would examine the
patch that caused _this_ stoppage, and then decide that it is safe
to apply _this_ patch (but not necessarily later ones) with
three-way fallback and move on:
$ git am -3 --continue
I have not thought too deeply if the parallel applies to
multi-commit pick, though.
"am" (rather, its underlying machinery "apply") is designed to be
all-or-none, so a failed --no-3way application would leave the index
and the working tree intact. "-3 --continue" can retry the failed
step, with "--3way" processing turned on for only one message, from
that state.
But a multi-commit cherry-pick/revert would stop _after_ it munges
the conflicted paths in the index into an unmerged state and writes
the conflicted state into the working tree files. For "--continue
--rerere-autoupdate" to work more like "am --continue -3", it would
have to learn to reset to the state before the failed cherry-pick
first, before re-attempting the failed cherry-pick with the auto
update enabled only for the single commit and keep going. So it may
not as trivial as "am --continue", even though it sounds doable.
