From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: "SZEDER Gábor" <szeder.dev@gmail.com>,
"Pratyush Yadav" <me@yadavpratyush.com>,
"Git List" <git@vger.kernel.org>
Subject: Re: [PATCH] worktree: add shorthand '-d' for detach
Date: Mon, 27 Jan 2020 12:31:38 -0800 [thread overview]
Message-ID: <xmqq36c0bpzp.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <CAPig+cS_H+FTcZkBz4dA94bAcxv0CZ8UG=P8jOGvD=HXzf8ODQ@mail.gmail.com> (Eric Sunshine's message of "Mon, 27 Jan 2020 11:05:20 -0500")
Eric Sunshine <sunshine@sunshineco.com> 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.
next prev parent reply other threads:[~2020-01-27 20:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-25 17:37 [PATCH] worktree: add shorthand '-d' for detach Pratyush Yadav
2020-01-27 12:26 ` SZEDER Gábor
2020-01-27 16:05 ` Eric Sunshine
2020-01-27 20:31 ` Junio C Hamano [this message]
2020-01-27 16:28 ` Eric Sunshine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq36c0bpzp.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=me@yadavpratyush.com \
--cc=sunshine@sunshineco.com \
--cc=szeder.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox