Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
> or against the change:
>
> - synonym bloat; balloons documentation
> - steals command verbs from potential future features
> - ...
I tend to agree with these two (and if I were to replace the "..."
with something concrete, this change is not desirable because it
will force us to add all these three when we introduce "remove"
elsewhere in the system).
Having said that, this remids me of an age-old topic we discussed in
a distant past but stalled due to lack of strong drive, which is:
Some git subcommands take command verb (e.g. "git notes 'remove'")
while others take command mode flags (e.g. "git branch --delete"),
and the users need to remember them, which is not ideal.
I think the consensus back then, if we were to aim for consistency
by uniformly using only one of the two, is to use the command mode
flags, simply because existing commands that have the primary mode
and take an optional command mode flag [*1*] cannot be migrated to
the command verb UI safely and sanely.
And then, if we are not careful when we standardize all subcommands
to take command mode flags, we might end up with a situation where
some subcommand say "--remove" while other say "--delete", and some
users will wish to rectify that situation by adding an alias defined
for these flags---I view this patch as a part of that possible
future topic ;-).
[Footnote]
*1* For example, "git branch" by default is in the branch creation
mode, but it can be told to work in its branch deletion mode
with "--delete".
If we were to standardize on command verbs, is "git branch
delete" a deprecated relic from the old world that wants to
create a branch whose name is 'delete', or is it done by a
script in the new world that collected names of branches to
delete and asked "git branch delete $to_delete" to delete all of
them, where the $to_delete variable happened to end up empty?
With command mode flags, we do not have to worry about such an
ambiguity during and after transition.
