Re: [PATCH 3/6] revert: don't let revert continue a cherry-pick

[Jonathan Nieder <jrnieder@gmail.com>]

Ramkumar Ramachandra wrote:

> When we allow mixing "revert" and "pick" instructions in the same
> sheet in the next patch, the following workflow would be perfectly
> valid:
>
>   $ git cherry-pick base..latercommit
>   [conflict occurs]
>   $ edit problematicfile
>   $ git add problematicfile
>   $ git revert --continue
>   [finishes successfully]

Does "workflow" mean "sequence of commands"?

> This is confusing to the operator, because the sequencer is an
> implementation detail hidden behind the 'git cherry-pick' and 'git
> revert' builtins.

I don't know --- it's not confusing to me.  Could you explain further
what harm the current behavior does?  E.g., could it cause me to
misunderstand some basic concepts, or could it lead me to run commands
that cause me to scratch my head or lose data?

>  builtin/revert.c                |   57 +++++++++++++++++++++++++++++++++++++++
>  sequencer.h                     |    1 +
>  t/t3510-cherry-pick-sequence.sh |   11 +++++++
>  3 files changed, 69 insertions(+), 0 deletions(-)

I haven't read the patch, but based on the above rationale and this
diffstat, it doesn't look good.