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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]