Re: [PATCH 6/6] cherry-pick/revert: reject --rerere-autoupdate when continuing

Phillip Wood [off-list ref] writes:

On 02/08/17 23:29, Junio C Hamano wrote:
...

quoted

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.