Re: [PATCH v3] stash: infer "push" when push-specific options are given

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 9, 2026, 20:31 UTC
Message-ID: <xmqqa4vbswnq.fsf@gitster.g>
In-Reply-To: <a280c7de-1357-44a9-afdd-bd473fd4e2a4@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

> "create" accepts "-m" as well so that's not unique either. I agree with 
> Junio's suggestion in the link above that we should assume "push" when 
> there is no subcommand given and error out if we see an unsupported 
> option.

Yeah, if -X were unique for "pop" and -Y were unique for "push", it is tempting to DWIM "git stash -X" to "git stash pop -X" while DWIMming "git stash -Y" to "git stash push -Y", but the thing is that the urgency of each "stash" subcommand is different. As the "the boss is here and tells me to work on this completely unrelated thing, clear the desk as quickly as possible to switch context" command, "push" deserves to have more quick access than other commands.

It also makes it resilient if we said "a command line that begins with an option cannot be naming any 'git stash' subcommand, so we will unconditionally insert 'push' before that first option", because 'push' may later acquire "-X" or 'save' may acquire "-Y" and making these options no longer unique to a single subcommand. A version of Git may have treated "git stash -Y" as "git stash push -Y" but if the next version that has "git stash save -Y" stopped accepting "git stash -Y" as "git stash push -Y" because -Y is not unique, the end users will be unhappy.

And of course it is far easier to document and teach.