From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Sun, 08 Jan 2012 20:03:41 GMT
Subject: Re: [PATCH 3/6] revert: don't let revert continue a cherry-pick
Message-ID: <CALkWK0=-AWy7HnVASB1rt8njavTYOhV7Zxsdq4TE+VShVZmEzQ@mail.gmail.com>
In-Reply-To: <20120108193749.GH1942@burratino>

Hi,

Jonathan Nieder wrote:
> 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"?

Yes.  Clarified wording.

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