From: Junio C Hamano <gitster@pobox.com>
To: Deveshi Dwivedi <deveshigurgaon@gmail.com>
Cc: git@vger.kernel.org, ben.knoble@gmail.com, mroik@delayed.space,
quentin.bernet@bluewin.ch
Subject: Re: [PATCH v4] stash: infer "push" when command line starts with an option
Date: Mon, 13 Apr 2026 08:09:16 -0700 [thread overview]
Message-ID: <xmqqeckilwwz.fsf@gitster.g> (raw)
In-Reply-To: <20260412195204.4636-1-deveshigurgaon@gmail.com> (Deveshi Dwivedi's message of "Sun, 12 Apr 2026 19:52:04 +0000")
Deveshi Dwivedi <deveshigurgaon@gmail.com> writes:
> When "git stash" is run without the "push" subcommand, the command
> tries to assume "push" but rejects any non-option arguments (i.e.,
> pathspecs without "--") to avoid treating a misspelled subcommand
> name as a pathspec.
I think "run without the 'push' subcommand" above should be "run
without any subcommand (on the command line)". "git stash pop
-- paths" is run without the "push" subcommand, and obviously we do
not want it to assume "push".
> A command line that begins with an option cannot be naming a "git
> stash" subcommand, so unconditionally assume "push" in that case and
> allow pathspec arguments to follow without requiring "--". This is
> simpler and more robust than checking a specific list of options,
> and remains correct even if push or other subcommands gain new
> options in the future.
Good.
> Note that this does not check for negated options, so "git stash
> --no-staged [<pathspec>]" is still rejected. Handling negated
> options would require teaching the inference logic about them
> explicitly.
That is unexpected, and unfortunate. I would have expected, since
we are now sending any thing that is not unrecognised to "push", it
would largely be the matter of removing special casing code about
push_assumed from push_stash() and adding some to its caller, which
is cmd_stash(). It would first look at its table of subcommands and
if it finds a hit, calls the handler. If not, and if there is no
argument or if the first argument begins with a dash "if (argv[1] &&
argv[1][0] == '-')", then unshift "push" into the argv[] array, and
call push_stash(), which would complain if the command line (with
"push" prepended) does not make sense to it. If the above two
conditions were not met, cmd_stash() would not call push_stash() but
complain that it did not get a valid command. Or something like that.
That way, there is nothing that makes "--no-something" any more
special than "--something", no?
next prev parent reply other threads:[~2026-04-13 15:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-04 14:36 [PATCH] stash: infer "push" when push-specific options are given Deveshi Dwivedi
2026-04-04 15:19 ` Mirko Faina
2026-04-04 16:03 ` [PATCH v2] " Deveshi Dwivedi
2026-04-04 23:40 ` Mirko Faina
2026-04-05 7:02 ` Deveshi Dwivedi
2026-04-05 11:09 ` [PATCH v3] " Deveshi Dwivedi
2026-04-06 18:15 ` Mirko Faina
2026-04-07 9:36 ` Phillip Wood
2026-04-09 19:22 ` Deveshi Dwivedi
2026-04-09 19:37 ` Mirko Faina
2026-04-09 20:31 ` Junio C Hamano
2026-04-09 20:22 ` Junio C Hamano
2026-04-12 19:52 ` [PATCH v4] stash: infer "push" when command line starts with an option Deveshi Dwivedi
2026-04-13 9:08 ` Phillip Wood
2026-04-13 15:09 ` Junio C Hamano [this message]
2026-04-19 16:54 ` [PATCH v5] stash: assume " Deveshi Dwivedi
2026-04-21 15:28 ` Phillip Wood
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=xmqqeckilwwz.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ben.knoble@gmail.com \
--cc=deveshigurgaon@gmail.com \
--cc=git@vger.kernel.org \
--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