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

[Phillip Wood <phillip.wood@talktalk.net>]

On 03/08/17 18:19, Junio C Hamano wrote:
> 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.
> 
Thanks for explaining that, as you say having cherry-pick take
'--rerere-autoupadate' with '--continue' sounds more complicated than
the am case. Also I'm not sure it would be as helpful to toggle
'--rerere-autoupdate' with cherry-pick as it is to toggle '--3way' with
am as it's not that hard for the user to stage the merged files
themselves. If you're happy with the way it is currently implemented I'm
not inclined to change it.

Thanks

Phillip