Re: [PATCH 1/2] completion: merge options for cherry-pick and revert

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

 



Denton Liu <liu.denton@xxxxxxxxx> writes:

> Since revert and cherry-pick share the same sequencer code, they should
> both accept the same command-line options. Merge the
> `__git_cherry_pick_inprogress_options` and
> `__git_revert_inprogress_options` variables together into
> `__git_cherry_pick_revert_inprogress_options` so that the options aren't
> unnecessarily duplicated twice.

Hmm, will the claim hold true in the future?  I do agree that they
will share continue, quit and abort (and skip) forever, but I am not
bold enough to declare that they will never have some unique option
in addition to the common one only because they "share the same
sequencer" machinery.  It is trivial to add a "if we are in revert,
do this" to the code, and it already works that way.

__git_sequencer_inprogress_common_options="--continue --quit --abort"
__git_cherry_pick_inprogress_options=$__git_sequencer_inprogress_common_options
__git_revert_inprogress_options=$__git_sequencer_inprogress_common_options

may be a bit more future-proof way, perhaps?  The places that use
the variable(s) already correctly distinguish cherry-pick and
revert, so even though the above and your version equally "unify"
the set of common options and allow adding a new common option
(i.e. skip) with equal ease, yours makes giving unique option to one
but not to the other more difficult.



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

  Powered by Linux