From: "J. Dettweiler" <git.vger.kernel.org@dettweb.de>
To: git@vger.kernel.org
Subject: [FEATURE] Proposal: git stash --only-unstaged
Date: Wed, 13 Aug 2025 10:51:50 +0200 [thread overview]
Message-ID: <12fe17735317215aa0de58a20055193a@dettweb.de> (raw)
Hi all,
I’ve run into a recurring workflow problem when splitting commits during
an interactive rebase, and I think Git could benefit from an option to
stash *only* the working tree (unstaged) changes, without saving or
restoring the index (staged changes) at all.
---
**Scenario:**
- I have a commit that needs to be split.
- I stage the part of the changes that will remain in the earlier commit
(this becomes the new, fixed commit).
- The rest of the changes (which belong in a later commit) remain
unstaged in the working tree.
- I want to test the staged commit in isolation before actually
committing it, without losing or committing the later changes.
- After testing, I want to bring back the unstaged changes exactly as
they were.
---
**Current limitations:**
- `git stash --keep-index` still saves the index in the stash object.
- When I later `git stash pop`, Git tries to restore those staged
changes, often causing merge conflicts if I’ve modified them during the
test.
- `git stash -p` and `git diff`+`git apply` can work as workarounds, but
they are clunky and error-prone in longer rebases.
- The goal is essentially:
> “stash the working tree only, leave the index untouched and
unrecorded in the stash.”
---
**Proposed feature:**
A new option, for example: git stash push --only-unstaged
---
This would:
- Save only the unstaged working tree changes to the stash.
- Leave the index both in the working directory and completely absent
from the stash object.
- Make `stash pop` safe even if the index has changed in the meantime.
---
**Benefits:**
- Cleaner workflows for splitting commits during interactive rebases.
- Safer testing of staged changes in isolation.
- Avoids unnecessary conflicts on stash pop.
---
I have not found an existing Git command that provides this exact
behavior, nor an option to `git stash` that prevents the index from
being stored in the stash object.
Has this been considered before? Would there be interest in adding such
an option?
Thanks for your time and for Git!
J. Dettweiler
next reply other threads:[~2025-08-13 8:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-13 8:51 J. Dettweiler [this message]
2025-08-13 15:30 ` [FEATURE] Proposal: git stash --only-unstaged Junio C Hamano
2025-08-13 17:02 ` D. Ben Knoble
2025-08-16 16:12 ` Phillip Wood
2025-08-17 16:08 ` Junio C Hamano
2025-08-18 15:14 ` Phillip Wood
2025-08-18 23:41 ` Ben Knoble
2025-08-29 13:06 ` Phillip Wood
2025-08-29 13:30 ` D. Ben Knoble
2025-09-16 11:03 ` Phillip Wood
2025-09-16 17:10 ` D. Ben Knoble
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=12fe17735317215aa0de58a20055193a@dettweb.de \
--to=git.vger.kernel.org@dettweb.de \
--cc=git@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).