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

> Phillip Wood <phillip.wood@talktalk.net> 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.
>