Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Mirko Faina <mroik@delayed.space>,
	 Deveshi Dwivedi <deveshigurgaon@gmail.com>,
	 git@vger.kernel.org,  ben.knoble@gmail.com,
	quentin.bernet@bluewin.ch
Subject: Re: [PATCH v3] stash: infer "push" when push-specific options are given
Date: Thu, 09 Apr 2026 13:31:37 -0700	[thread overview]
Message-ID: <xmqqa4vbswnq.fsf@gitster.g> (raw)
In-Reply-To: <a280c7de-1357-44a9-afdd-bd473fd4e2a4@gmail.com> (Phillip Wood's message of "Tue, 7 Apr 2026 10:36:13 +0100")

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.


  parent reply	other threads:[~2026-04-09 20:31 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 [this message]
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
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=xmqqa4vbswnq.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=phillip.wood123@gmail.com \
    --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