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

Hi,

Jonathan Nieder wrote:

Ramkumar Ramachandra wrote:

quoted

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"?

Yes.  Clarified wording.

quoted

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?

Junio explained this to me in [1].  It's very unnatural for a user to
want to execute "git cherry-pick --continue" when the previous command
was a "git revert": it probably means that she forgot about the
in-progress "git revert".  The problem becomes more serious when the
sequencer grows more capabilities: a "git merge --continue" to
continue a "git am" sounds much more absurd.  Ofcourse, we will
provide a way to continue any sequencer operation in the future: "git
continue" seems to be a good candidate.

[1]: http://thread.gmane.org/gmane.comp.version-control.git/185355

Thanks.

-- Ram