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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 3, 2017, 17:19 UTC
Message-ID: <xmqqy3r0po0i.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <6a7c9661-9f12-99c9-1fc1-4a4abd3d0660@talktalk.net>

Phillip Wood <phillip.wood@talktalk.net> writes:

Show 11 quoted lines

> 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.