From: 重田一聖 Date: Thu, 08 Oct 2026 13:58:26 GMT Subject: Re: [PATCH v2] stash: expose untracked modes in create Message-ID: In-Reply-To: Hi Junio, > 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 wrote: > 重田一聖 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 ' 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.