Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
>> Here I would prefer to keep '--detach', because "detach" is a real
>> word with proper meaning, while 'd' is just an abbreviation.
>
> I fully agree with this assessment and was going to say the same.
> '-b' and '-B' are special in that they don't have corresponding long
> option names, thus they must be shown in short form, but long name
> '--detach' is much more informative in this context (and the reader
> can discover short '-d' easily enough without mentioning it here).
> So, I'd drop this change (and the other similar one).
Yup.
Even though I do not mind a short-hand '-d', because "worktree add"
would be quite a rare event compared to the use of other Git
subcommands, those who do not remember '--detach' after learning it
would not have any better chance to remember to use the option, even
if a shorter variant '-d' was available.
In other words, if "worktree add --detach" is underused and it is a
problem that needs to be fixed, I do not think the reason why it is
underused is *not* because "--detach" is too long to type or does
not get completed when "git worktree add <TAB>" is typed. Isn't the
real problem because people do not even *know* that the choice of
starting a worktree without being on a particular branch exists?
A better documentation would help, but I do not think
"git worktree add -d foo" is about as easy to type and remember as
"git worktree add foo"
is addressing the right problem. s/-d/--detach/ may make it more
clear what the option is about, in which case it would be a better
way to promote the feature.
