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

[Phillip Wood <phillip.wood123@gmail.com>]

On 06/04/2026 19:15, Mirko Faina wrote:
> On Sun, Apr 05, 2026 at 11:09:53AM +0000, Deveshi Dwivedi wrote:
>> 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.  The only exception is "-p", which sets
>> force_assume and allows pathspecs to follow.
>>
>> This means "git stash -m foo file" is rejected even though "-m" is
>> unambiguously a "push" option, and the user's intent is clear.  The
>> same applies to other push-specific options like "--staged",
>> "--keep-index", "--include-untracked", and "--pathspec-from-file".
>>
>> Expand the set of options that force the "push" assumption to
>> include all push-specific options, so that pathspec arguments are
>> accepted without requiring "--" or the explicit "push" subcommand
>> when the command line already contains a push-only option.
>>
>> This was marked as #leftoverbits in [1].
>>
>> [1] https://lore.kernel.org/git/xmqqtsu1jipp.fsf@gitster.g/
>>
>> Signed-off-by: Deveshi Dwivedi <deveshigurgaon@gmail.com>
> 
> Just realized, "--include-untracked" is not specific only to 'push' as
> 'show' accepts it too as an argument.

"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. That does not require the arguments to be unique to "push". A 
complete implementation would also support negated options like "git 
stash --no-stage [<pathspec>]". What is implemented in this patch maybe 
sufficient in practice but it would be good to mention the limitations 
in the commit message.

Thanks

Phillip

> "--keep-index" as well, but since
> 'save' is deprecated I don't think anyone would mind and should be fine
> to leave it as is (though this is my opinion, should wait for others to
> see what they think).
>