Hi Dscho
On 17/04/2019 13:26, Johannes Schindelin wrote:
Hi,
On Wed, 17 Apr 2019, Junio C Hamano wrote:
Phillip Wood <phillip.wood123@xxxxxxxxx> writes:
Avoid this potential problem by removing the sequencer state if we're
committing or resetting the final pick in a sequence.
The use-case story before this conclusion only mentioned "commit"
that concluded the multi-step cherry-pick/revert, and never talked
about "reset", which made my eyebrows to rise.
As a part of "reset", we have already been removing CHERRY_PICK_HEAD
and REVERT_HEAD, so "git reset" during a conflicted "cherry-pick"
for example is already destructive and the user can no longer get
back to continuing the cherry-pick anyway after running it, even
without this patch. So from that point of view, it does make sense
to remove the other sequencer states at the same time.
Do you mean to say that a `git reset` during `git cherry-pick <range>`
aborts it?
No I mean it removes CHERRY_PICK_HEAD/REVERT_HEAD and so cancels the
conflicting pick/revert, it does not abort the operation as a whole. If
the conflicting pick/revert was the last in a range then we want it to
remove .git/sequencer as well as the ..._HEAD file as it is easy to
forget to run --continue in that case.
Best Wishes
Phillip
In my experience, this is not the case. The advice printed out after a
conflict even recommends to run `git reset` (followed by `git cherry-pick
--continue`, in lieu of the `git cherry-pick --skip` we have yet to
implement).
So I don't think it is correct to say that `git reset` does not let the
user get back to continuing a cherry-pick...
Ciao,
Dscho
