Re: [PATCH v2] stash: expose untracked modes in create

From: 重田一聖 <kazumasa.shigeta@kanamei.com>
Date: Oct 8, 2026, 13:58 UTC
Message-ID: <CANUHOw3N+_yWnh7=2-5fD+XxgYC9-M9fqL8GEjfEC6kN+CD=gg@mail.gmail.com>
In-Reply-To: <xmqq1pa4ksiw.fsf@gitster.g>

Hi Junio,

Show 6 quoted lines

> Perhaps, but I do not think it is too huge a backward-compatibility
> breakage to forbid giving a message lazily (i.e., all strings in
> argv[] after 'git stash create' gets concatenated and becomes a
> single message) that begins with "-", with an escape hatch that a
> leading "-m" will take the next argv[] element as the message, for
> example.

If the compatibility change for messages beginning with `-` is acceptable with an `-m` escape hatch like the one you mentioned, I think a new subcommand is unnecessary.

>> 3. Add something like `--create-only` to `git stash push`.
>
> This also would work and sounds the safest.

I think so too, at least for the immediate change.

But `stash create` is already intended for scripts, and I think we may want to add more script-oriented options to it in the future.

If we put the create-only interface under `push`, each future option for that interface would also need a decision about whether it applies to ordinary `push`, `--create-only`, or both.

That would add another set of option rules inside `push` that future additions would have to account for.

So I currently think extending `stash create` directly is the better long-term approach.

Phillip's comments about which options make sense for scripts also made me reconsider the scope of this patch.

I realized that I had been treating two decisions as one: whether to introduce option parsing in `stash create`, and how much of what `do_create_stash()` already supports to expose now.

I think adding option parsing and `-m/--message` now would be useful, even if we only expose a few options. That is because we should not need to revisit the basic parsing and message compatibility question just to add another script-oriented option later.

That makes me think we don't need to expose everything `do_create_stash()` already supports in this patch. I now think we don't need to settle the public rules for other options and their interactions until there is a concrete need.

In particular, I would prioritize leaving out options for which I haven't found a concrete request and whose interaction rules might make future additions harder if fixed now.

So my conclusion for this patch is to expose `-m/-q/-u/-a`. The untracked modes address the original gap, and I think `-q/--quiet` makes sense for a script-oriented command. It would use the existing creation helper's quiet behavior without suppressing the object name returned on success.

For now, I would leave `--patch` and pathspec support out.

I also checked `-k/--keep-index`. It concerns the cleanup and preservation behavior of `push`, rather than creation of the stash object itself, so I would leave it out.

I still need to think a little more about `--staged`. It does affect what goes into the stash object, but its interactions with other options are less straightforward. For example, `stash push` does not allow it with `-u/-a` or `--pathspec-from-file`, while patch mode takes precedence over it.

So far I haven't found a concrete request specifically for `stash create --staged`, but I'm still checking. Unless I find one, I would like to leave `--staged` out of this patch rather than decide those interaction rules now.

Thanks, Kazumasa Shigeta

On Mon, 05 Oct 2026 09:43:03 -0700, Junio C Hamano <gitster@pobox.com> wrote:

Show 34 quoted lines

> 重田一聖 <kazumasa.shigeta@kanamei.com> writes:
>
> > Your question made me realize that I had focused too narrowly on the
> > untracked modes. The larger issue is not simply that `do_create_stash()`
> > has capabilities that `git stash create` does not expose.
>
> Brilliant. I agree that is the right way to frame the issue.
>
> > Making more of those capabilities available through `create` would
> > therefore mean either changing that contract or designing around it.
> > That is a much larger interface decision than I appreciated when I sent
> > the patch.
>
> Perhaps, but I do not think it is too huge a backward-compatibility
> breakage to forbid giving a message lazily (i.e., all strings in
> argv[] after 'git stash create' gets concatenated and becomes a
> single message) that begins with "-", with an escape hatch that a
> leading "-m" will take the next argv[] element as the message, for
> example.
>
> > 2. Add a new stash subcommand for the creation functionality.
>
> This is essentially how 'git stash save' came about, to give us ways
> to control how a new stash entry is created and how the working tree
> is cleared with command line options. In the beginning, you did not
> even have to say 'save', because 'git stash <message>' was invented
> as a way to say "the boss is here and tells me to work on something
> unrelated. clear the slate with minimum number of keystrokes to
> continue working on what I have been working on later." And that
> later became 'git stash push'.
>
> > 3. Add something like `--create-only` to `git stash push`.
>
> This also would work and sounds the safest.