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]

 



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