Subject: Re: [PATCH] cherry-pick: refuse cherry-pick sequence if index is dirty

From: Junio C Hamano <[email-masked]>
Date: Wed, 24 May 2023 09:06:26 +0900

Tao Klerks <[email-masked]> writes:

> The current implementation of this patch is far too restrictive. It
> doesn't break any tests (and maybe I should add one now that I know),
> but it's doing the wrong thing.

I am ambivalent.  What do we want to see in a multi-pick sequence
that is different from rebase?  A single-step cherry-pick can fail
safely before it touches the index or the working tree files, but if
two-step cherry-pick, whose first step succeeds, finds that it
cannot safely carry out its second step without clobbering the local
changes made to the working tree files, what should happen?  Are we
OK if we stopped in the state just after the first step has already
been done?

My (tentative) answer to that question is "yes", but the recovery
options of "cherry-pick" may want to work differently from what we
have seen them traditionally do.  Namely, the user accepts that the
first step is already done, and stopping "cherry-pick", be it called
"--abort" or something else, should just remove the sequencer state
and behave as if the single-pick cherry-pick on the first step only
has just finished and leave such a state in the index and the
working tree.  If that is what we are going to do, then it would
make sense to adopt the same safety semantics we use for "git merge"
and "git checkout" to ensure only that the index is clean, relying
on the unpack-trees machinery that stops before clobbering a locally
modified working tree files.  But if we are to aim for "all-or-none"
semantics people expect from aborting "git rebase", I suspect that
it would be way too complicated to allow random changes in the
working tree files that we may only discover to be problems after
starting the sequence of replaying commits one-by-one, and "too
restrictive" check may be justified.  To put it differently, if it
is too restrictive for multi-pick, then we would want to loosen it
for "git rebase" as well, as the issues are likely to be the same.

Thanks.