Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes:
> +static struct option *add_switch_branch_options(struct checkout_opts *opts,
> + struct option *prevopts)
> +{
> + struct option options[] = {
> OPT_STRING('b', NULL, &opts->new_branch, N_("branch"),
> N_("create and checkout a new branch")),
I think there should be another step to rename the options to more
sensible ones for the context. In the context of overall "checkout"
command, the 'b' option
git checkout -b <new-name> <commit-ish>"
that signals that its parameter has something to do with a 'branch'
makes perfect sense. But when the user uses the new command
git switch-branch -b <new-name> <commit-ish>
does not convey the more important fact in the context. In the
orignal context, "this is about a branch" and "we are not checking
out an existing one, but are creating" are both worthwhile thing to
express, but because a single letter option cannot stand for both,
"-b" is the most reasonable choice (compared to calling it "-c" that
stands for "create" that invites "what exactly are you creating?").
In the new context of "switch-branch", it no longer has to be said
that the optional feature is about "branch". So I would imagine
that users naturally expect this option to be called
git switch-branch --create <new-name> <commit-ish>
(or -c for short).
I'll just stop with this single example, but I think we should make
sure all the options make sense in the context of new command.
Of course, that means it will NOT be sufficient to just split the
option table into two tables and stitch them together for the single
command. This option must stay to be "-b" (giving it a synonym
"--create-branch" is OK) in the context of "checkout".
