From: Junio C Hamano <gitster@pobox.com>
To: Mirko Faina <mroik@delayed.space>
Cc: "D. Ben Knoble" <ben.knoble@gmail.com>,
Quentin Bernet via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Quentin Bernet <quentin.bernet@bluewin.ch>
Subject: Re: [PATCH] docs: fix git stash grammar
Date: Fri, 27 Mar 2026 08:58:30 -0700 [thread overview]
Message-ID: <xmqqqzp5mfh5.fsf@gitster.g> (raw)
In-Reply-To: <acXIl2cuBv0ifiK6@exploit> (Mirko Faina's message of "Fri, 27 Mar 2026 01:04:51 +0100")
Mirko Faina <mroik@delayed.space> writes:
> On Thu, Mar 26, 2026 at 12:17:46PM -0400, D. Ben Knoble wrote:
>> Now, _is_ the grammar bracketed wrong? "git help stash" says
>>
>> For quickly making a snapshot, you can omit "push". In this mode,
>> non-option arguments are not allowed to prevent a misspelled
>> subcommand from making an unwanted stash entry. The two exceptions
>> to this are stash -p which acts as alias for stash push -p and
>> pathspec elements, which are allowed after a double hyphen -- for
>> disambiguation.
>>
>> So _if_ you want to provide options (other than "-p"), the "push" is
>> required. I think the existing brackets indicate that.
>
> When it says "In this mode, non-option arguments are not allowed"
> wouldn't -m be allowed as it is an option and not a non-option? In fact
> if we do try to run "git stash -m something" it does correctly stash
> while if we do something like "git stash pathspec" it does give back
> "fatal: subcommand wasn't specified; 'push' can't be assumed due to
> unexpected token 'pathspec'".
>
> If that is the case then there is an issue with the way the usage
> tooltip shows the optionality of "push".
Yup, you're right. The current SYNOPSIS suggests that you can omit
and say "git stash" and it does the "push" thing, but when you want
to give any "push" related options, the command name "push" becomes
mandatory before them.
If the log message said something like
The "[optionality]" bracket is misplaced on the command line for
"git stash push" in the synopsis section. It is not like you
can omit "push" only when you do not give any options and
arguments.
we wouldn't be having this long thread, I suspect.
next prev parent reply other threads:[~2026-03-27 15:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 12:45 [PATCH] docs: fix git stash grammar Quentin Bernet via GitGitGadget
2026-03-26 16:17 ` D. Ben Knoble
2026-03-27 0:04 ` Mirko Faina
2026-03-27 15:58 ` Junio C Hamano [this message]
2026-03-27 16:28 ` Quentin Bernet
2026-03-27 16:53 ` Junio C Hamano
2026-03-27 16:58 ` Quentin Bernet
2026-03-27 17:16 ` Junio C Hamano
2026-03-27 17:36 ` Quentin Bernet
2026-03-27 17:45 ` Junio C Hamano
2026-03-27 16:47 ` Ben Knoble
2026-03-27 8:25 ` Quentin Bernet
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=xmqqqzp5mfh5.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ben.knoble@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=mroik@delayed.space \
--cc=quentin.bernet@bluewin.ch \
/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