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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jan 8, 2012, 19:37 UTC
Message-ID: <20120108193749.GH1942@burratino>
In-Reply-To: <1326025653-11922-4-git-send-email-artagnon@gmail.com>

Ramkumar Ramachandra wrote:

Show 10 quoted lines

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