{"thread":{"id":"63952","subject":"[FEATURE] Proposal: git stash --only-unstaged","startedAt":"2025-08-13T08:59:09Z","lastAt":"2025-09-16T17:10:29Z","messageCount":11,"participants":["J. Dettweiler","Junio C Hamano","D. Ben Knoble","Phillip Wood","Ben Knoble"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"524116","messageId":"12fe17735317215aa0de58a20055193a@dettweb.de","threadId":"63952","inReplyTo":null,"subject":"[FEATURE] Proposal: git stash --only-unstaged","fromName":"J. Dettweiler","fromEmail":"git.vger.kernel.org@dettweb.de","sentAt":"2025-08-13T08:51:50Z","receivedAt":"2025-08-13T08:59:09Z","isPatch":false,"sender":{"key":"git.vger.kernel.org@dettweb.de","avatar":null},"body":"Hi all,\n\nI’ve run into a recurring workflow problem when splitting commits during \nan interactive rebase, and I think Git could benefit from an option to \nstash *only* the working tree (unstaged) changes, without saving or \nrestoring the index (staged changes) at all.\n\n---\n\n**Scenario:**\n- I have a commit that needs to be split.\n- I stage the part of the changes that will remain in the earlier commit \n(this becomes the new, fixed commit).\n- The rest of the changes (which belong in a later commit) remain \nunstaged in the working tree.\n- I want to test the staged commit in isolation before actually \ncommitting it, without losing or committing the later changes.\n- After testing, I want to bring back the unstaged changes exactly as \nthey were.\n\n---\n\n**Current limitations:**\n- `git stash --keep-index` still saves the index in the stash object.\n- When I later `git stash pop`, Git tries to restore those staged \nchanges, often causing merge conflicts if I’ve modified them during the \ntest.\n- `git stash -p` and `git diff`+`git apply` can work as workarounds, but \nthey are clunky and error-prone in longer rebases.\n- The goal is essentially:\n   > “stash the working tree only, leave the index untouched and \nunrecorded in the stash.”\n\n---\n\n**Proposed feature:**\nA new option, for example: git stash push --only-unstaged\n\n---\n\nThis would:\n- Save only the unstaged working tree changes to the stash.\n- Leave the index both in the working directory and completely absent \nfrom the stash object.\n- Make `stash pop` safe even if the index has changed in the meantime.\n\n---\n\n**Benefits:**\n- Cleaner workflows for splitting commits during interactive rebases.\n- Safer testing of staged changes in isolation.\n- Avoids unnecessary conflicts on stash pop.\n\n---\n\nI have not found an existing Git command that provides this exact \nbehavior, nor an option to `git stash` that prevents the index from \nbeing stored in the stash object.\n\nHas this been considered before? Would there be interest in adding such \nan option?\n\nThanks for your time and for Git!\n\nJ. Dettweiler\n\n"},{"id":"524131","messageId":"xmqqjz37nss7.fsf@gitster.g","threadId":"63952","inReplyTo":"12fe17735317215aa0de58a20055193a@dettweb.de","subject":"Re: [FEATURE] Proposal: git stash --only-unstaged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-08-13T15:30:16Z","receivedAt":"2025-08-13T15:30:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Dettweiler\" <git.vger.kernel.org@dettweb.de> writes:\n\n> **Proposed feature:**\n> A new option, for example: git stash push --only-unstaged\n>\n> ---\n>\n> This would:\n> - Save only the unstaged working tree changes to the stash.\n> - Leave the index both in the working directory and completely absent\n>   from the stash object.\n> - Make `stash pop` safe even if the index has changed in the meantime.\n>\n> ---\n>\n> **Benefits:**\n> - Cleaner workflows for splitting commits during interactive rebases.\n> - Safer testing of staged changes in isolation.\n> - Avoids unnecessary conflicts on stash pop.\n>\n> ---\n\nWhat is the downside?  If the users of \"git stash --keep\" can keep\nusing the same workflow by switching to this new option, you\nwouldn't be proposing it as a separate option---rather you would be\nproposing an improvement to the \"--keep\" option.  So there must be\nsomething that the users would have to do differently if they switch\nto this new \"feature\", but it is unclear what that is.\n"},{"id":"524136","messageId":"CALnO6CB-vg-t42OD57Dk5OX9S4v+HnH8BHj2gAozJWwmaLhAQw@mail.gmail.com","threadId":"63952","inReplyTo":"12fe17735317215aa0de58a20055193a@dettweb.de","subject":"Re: [FEATURE] Proposal: git stash --only-unstaged","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-08-13T17:02:31Z","receivedAt":"2025-08-13T17:02:45Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Wed, Aug 13, 2025 at 5:00 AM J. Dettweiler\n<git.vger.kernel.org@dettweb.de> wrote:\n>\n> Hi all,\n>\n> I’ve run into a recurring workflow problem when splitting commits during\n> an interactive rebase, and I think Git could benefit from an option to\n> stash *only* the working tree (unstaged) changes, without saving or\n> restoring the index (staged changes) at all.\n>\n> ---\n>\n> **Scenario:**\n> - I have a commit that needs to be split.\n> - I stage the part of the changes that will remain in the earlier commit\n> (this becomes the new, fixed commit).\n> - The rest of the changes (which belong in a later commit) remain\n> unstaged in the working tree.\n> - I want to test the staged commit in isolation before actually\n> committing it, without losing or committing the later changes.\n> - After testing, I want to bring back the unstaged changes exactly as\n> they were.\n>\n> ---\n>\n> **Current limitations:**\n> - `git stash --keep-index` still saves the index in the stash object.\n> - When I later `git stash pop`, Git tries to restore those staged\n> changes, often causing merge conflicts if I’ve modified them during the\n> test.\n> - `git stash -p` and `git diff`+`git apply` can work as workarounds, but\n> they are clunky and error-prone in longer rebases.\n> - The goal is essentially:\n>    > “stash the working tree only, leave the index untouched and\n> unrecorded in the stash.”\n\nI can reproduce (2.50.1):\n\n    git init\n    echo a >a && echo b >b && git add .\n    git commit -m.\n    echo c >>a && echo d >>b && git add b\n    git stash --keep-index\n    echo f >>b && git add . && git commit -m.\n\nHere, “git stash pop” creates conflicts for b, even with “--no-index”.\n“git stash branch foo” is slightly more sensible, but also includes\nthe stashed index changes for b, which I thought were normally dropped\nwhen applying stashes [1,2]. This also seems like exactly the use case\nthat “Testing partial commits” in “git help stash“ is supposed to\ncover.\n\nTaking a closer look, though, the conflicts aren’t from the index? The\nstash tree for the “W” commit (aka stash@{0}^{tree}) has the changes\nin a and has b in the state before more modifications were made (since\nthe version in the index and working tree were the same). Try “git\ndiff @^{tree} stash@{0}^{tree}”. Now, the I commit in the stash has\nthe same changes for b (git diff @^{tree} stash@{0}^2^{tree}), so that\nexplains why it seems like the conflicts are about the index!\n\nI don’t see how to avoid this in general: “git restore -W -s stash@{0}\na” does what I want, but wouldn’t scale to many files easily. If I do\na “git restore -Ws @ b” in the recipe above _before_ stashing, then I\nget no conflicts on “git stash pop” (see tree diffs above for why),\nbut that seems hard to remember to do (and isn’t documented in “git\nhelp stash” as being necessary)?\n\n[1]: https://lore.kernel.org/git/20250510183358.36806-1-ben.knoble+github@gmail.com/\n[2]: https://lore.kernel.org/git/20250510183358.36806-4-ben.knoble+github@gmail.com/\n"},{"id":"524293","messageId":"60f38225-2bcb-4383-be40-36c7b02cf38c@gmail.com","threadId":"63952","inReplyTo":"12fe17735317215aa0de58a20055193a@dettweb.de","subject":"Re: [FEATURE] Proposal: git stash --only-unstaged","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-08-16T16:12:47Z","receivedAt":"2025-08-16T16:12:51Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 13/08/2025 09:51, J. Dettweiler wrote:\n> \n> **Current limitations:**\n> - `git stash --keep-index` still saves the index in the stash object.\n> - When I later `git stash pop`, Git tries to restore those staged \n> changes, often causing merge conflicts if I’ve modified them during the \n> test.\n\nAs the index and the worktree are saved in the stash we can restore the\nunstaged changes with a three-way merge between the stashed index, HEAD\nand the stashed worktree. The (lightly tested) script below does that\nand updates the worktree without changing the index unless there are\nconflicts. There will only be conflicts when a staged line that is\nadjacent to an unstaged line is changed. Changes to staged lines that\nare not next to unstaged lines should not create conflicts as they are\nonly modified on one side of the merge.\n\nTo use it create your stash with \"git stash push --keep-index\" and then\nuse the script to pop the unstaged changes rather than using \"git stash\npop\". If the script proves to be useful then perhaps we could add an\n\"--unstaged\" option to \"git stash pop\"\n\nThanks\n\nPhillip\n\n---- 8< ----\n#!/bin/sh\n\nUSAGE=\"${0##*/} [<stash>]\"\nSUBDIRECTORY_OK=1\n. \"$(git --exec-path)/git-sh-setup\"\ncd_to_toplevel\nrequire_clean_work_tree stash-pop-unstaged\n\nLF='\n'\nstash=\"${1:-stash@{0}}\"\nif ! stash_oid=\"$(git rev-parse --verify --quiet \"$stash\")\" ||\n    ! oid1=\"$(git rev-parse --verify --quiet $stash_oid^1)\" ||\n    ! oid2=\"$(git rev-parse $stash_oid^2^@ 2>/dev/null)\" ||\n    test \"$oid1\" != \"$oid2\"\nthen\n     die \"error: '$stash' does not look like a stash commit\"\nfi\nmerge_output=\"$(git merge-tree --merge-base=$stash_oid^2: HEAD: $stash_oid:)\"\nstatus=$?\nif test $status = 0\nthen\n     tree=$merge_output\n     conflict_info=\n     messages=\nelif test $status = 1\nthen\n     merge_output=\"$merge_output$LF\"\n     tree=\"${merge_output%%$LF*}\"\n     conflict_info=\"${merge_output%%$LF$LF*}\"\n     conflict_info=\"${conflict_info#*$LF}\"\n     messages=\"${merge_output#*$LF$LF}\"\nelse\n     exit 128\nfi\ngit read-tree --index-output=\"$GIT_DIR/stash-pop-index\" -m -u HEAD $tree &&\nrm \"$GIT_DIR/stash-pop-index\" &&\nif test -n \"$conflict_info\"\nthen\n     printf '%s' \"$messages\" >&2\n     printf '%s\\n' \"$conflict_info\" | git update-index --index-info\nelse\n     git stash drop \"$stash\"\nfi\n\n"},{"id":"524321","messageId":"xmqqfrdqkk1l.fsf@gitster.g","threadId":"63952","inReplyTo":"60f38225-2bcb-4383-be40-36c7b02cf38c@gmail.com","subject":"Re: [FEATURE] Proposal: git stash --only-unstaged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-08-17T16:08:38Z","receivedAt":"2025-08-17T16:08:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood <phillip.wood123@gmail.com> writes:\n\n> To use it create your stash with \"git stash push --keep-index\" and then\n> use the script to pop the unstaged changes rather than using \"git stash\n> pop\". If the script proves to be useful then perhaps we could add an\n> \"--unstaged\" option to \"git stash pop\"\n\nHmph, would the behaviour useful enough that it should be always\nenabled, without any new option?  I strongly suspect that those who\nworked on adding \"--keep-index\" option did not expect the user to be\nmucking with the working tree files while \"testing the staged stuff\nby updating the working tree files to match it and nothing else\",\nand as long as the end-user stays within that originally designed\nuse case, nothing changes for them, no?\n\nThanks.\n\n(the script left for reference without comments below).\n\n> ---- 8< ----\n> #!/bin/sh\n>\n> USAGE=\"${0##*/} [<stash>]\"\n> SUBDIRECTORY_OK=1\n> . \"$(git --exec-path)/git-sh-setup\"\n> cd_to_toplevel\n> require_clean_work_tree stash-pop-unstaged\n>\n> LF='\n> '\n> stash=\"${1:-stash@{0}}\"\n> if ! stash_oid=\"$(git rev-parse --verify --quiet \"$stash\")\" ||\n>    ! oid1=\"$(git rev-parse --verify --quiet $stash_oid^1)\" ||\n>    ! oid2=\"$(git rev-parse $stash_oid^2^@ 2>/dev/null)\" ||\n>    test \"$oid1\" != \"$oid2\"\n> then\n>     die \"error: '$stash' does not look like a stash commit\"\n> fi\n> merge_output=\"$(git merge-tree --merge-base=$stash_oid^2: HEAD: $stash_oid:)\"\n> status=$?\n> if test $status = 0\n> then\n>     tree=$merge_output\n>     conflict_info=\n>     messages=\n> elif test $status = 1\n> then\n>     merge_output=\"$merge_output$LF\"\n>     tree=\"${merge_output%%$LF*}\"\n>     conflict_info=\"${merge_output%%$LF$LF*}\"\n>     conflict_info=\"${conflict_info#*$LF}\"\n>     messages=\"${merge_output#*$LF$LF}\"\n> else\n>     exit 128\n> fi\n> git read-tree --index-output=\"$GIT_DIR/stash-pop-index\" -m -u HEAD $tree &&\n> rm \"$GIT_DIR/stash-pop-index\" &&\n> if test -n \"$conflict_info\"\n> then\n>     printf '%s' \"$messages\" >&2\n>     printf '%s\\n' \"$conflict_info\" | git update-index --index-info\n> else\n>     git stash drop \"$stash\"\n> fi\n"},{"id":"524348","messageId":"89394e50-9077-4a7b-b30e-afd1be1a40e8@gmail.com","threadId":"63952","inReplyTo":"xmqqfrdqkk1l.fsf@gitster.g","subject":"Re: [FEATURE] Proposal: git stash --only-unstaged","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-08-18T15:14:13Z","receivedAt":"2025-08-18T15:14:16Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 17/08/2025 17:08, Junio C Hamano wrote:\n> Phillip Wood <phillip.wood123@gmail.com> writes:\n> \n>> To use it create your stash with \"git stash push --keep-index\" and then\n>> use the script to pop the unstaged changes rather than using \"git stash\n>> pop\". If the script proves to be useful then perhaps we could add an\n>> \"--unstaged\" option to \"git stash pop\"\n> \n> Hmph, would the behaviour useful enough that it should be always\n> enabled, without any new option?  I strongly suspect that those who\n> worked on adding \"--keep-index\" option did not expect the user to be\n> mucking with the working tree files while \"testing the staged stuff\n> by updating the working tree files to match it and nothing else\",\n> and as long as the end-user stays within that originally designed\n> use case, nothing changes for them, no?\n\nYes it probably would make sense if we knew that the stash had been \ncreated with \"--keep-index\". At the moment I don't think there is \nanywhere to tell from looking at the stash if that's the case but we \ncould add a trailer to the commit message when we create the stash to \nrecord that it was created with \"--keep-index\" and apply only the \nunstaged changes when we see that trailer.\n\nThanks\n\nPhillip\n\n> Thanks.\n> \n> (the script left for reference without comments below).\n> \n>> ---- 8< ----\n>> #!/bin/sh\n>>\n>> USAGE=\"${0##*/} [<stash>]\"\n>> SUBDIRECTORY_OK=1\n>> . \"$(git --exec-path)/git-sh-setup\"\n>> cd_to_toplevel\n>> require_clean_work_tree stash-pop-unstaged\n>>\n>> LF='\n>> '\n>> stash=\"${1:-stash@{0}}\"\n>> if ! stash_oid=\"$(git rev-parse --verify --quiet \"$stash\")\" ||\n>>     ! oid1=\"$(git rev-parse --verify --quiet $stash_oid^1)\" ||\n>>     ! oid2=\"$(git rev-parse $stash_oid^2^@ 2>/dev/null)\" ||\n>>     test \"$oid1\" != \"$oid2\"\n>> then\n>>      die \"error: '$stash' does not look like a stash commit\"\n>> fi\n>> merge_output=\"$(git merge-tree --merge-base=$stash_oid^2: HEAD: $stash_oid:)\"\n>> status=$?\n>> if test $status = 0\n>> then\n>>      tree=$merge_output\n>>      conflict_info=\n>>      messages=\n>> elif test $status = 1\n>> then\n>>      merge_output=\"$merge_output$LF\"\n>>      tree=\"${merge_output%%$LF*}\"\n>>      conflict_info=\"${merge_output%%$LF$LF*}\"\n>>      conflict_info=\"${conflict_info#*$LF}\"\n>>      messages=\"${merge_output#*$LF$LF}\"\n>> else\n>>      exit 128\n>> fi\n>> git read-tree --index-output=\"$GIT_DIR/stash-pop-index\" -m -u HEAD $tree &&\n>> rm \"$GIT_DIR/stash-pop-index\" &&\n>> if test -n \"$conflict_info\"\n>> then\n>>      printf '%s' \"$messages\" >&2\n>>      printf '%s\\n' \"$conflict_info\" | git update-index --index-info\n>> else\n>>      git stash drop \"$stash\"\n>> fi\n\n"},{"id":"524377","messageId":"18A45EC6-2D2C-45A2-8802-0E5060539398@gmail.com","threadId":"63952","inReplyTo":"89394e50-9077-4a7b-b30e-afd1be1a40e8@gmail.com","subject":"Re: [FEATURE] Proposal: git stash --only-unstaged","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-08-18T23:41:30Z","receivedAt":"2025-08-18T23:41:42Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"\n> Le 18 août 2025 à 11:14, Phillip Wood <phillip.wood123@gmail.com> a écrit :\n> \n> On 17/08/2025 17:08, Junio C Hamano wrote:\n>> Phillip Wood <phillip.wood123@gmail.com> writes:\n>>> To use it create your stash with \"git stash push --keep-index\" and then\n>>> use the script to pop the unstaged changes rather than using \"git stash\n>>> pop\". If the script proves to be useful then perhaps we could add an\n>>> \"--unstaged\" option to \"git stash pop\"\n>> Hmph, would the behaviour useful enough that it should be always\n>> enabled, without any new option?  I strongly suspect that those who\n>> worked on adding \"--keep-index\" option did not expect the user to be\n>> mucking with the working tree files while \"testing the staged stuff\n>> by updating the working tree files to match it and nothing else\",\n>> and as long as the end-user stays within that originally designed\n>> use case, nothing changes for them, no?\n\nI can’t particularly comment on the script, but I do think the example in the docs should either just work or be adjusted to work.\n\n> Yes it probably would make sense if we knew that the stash had been created with \"--keep-index\". At the moment I don't think there is anywhere to tell from looking at the stash if that's the case but we could add a trailer to the commit message when we create the stash to record that it was created with \"--keep-index\" and apply only the unstaged changes when we see that trailer.\n> \n> Thanks\n> \n> Phillip\n\nThis seems reasonable; I wonder if there would be any interaction with the stash import/export features? But perhaps those omitted the index anyway, I cannot recall."},{"id":"525200","messageId":"9f9e49c5-5612-4e6d-89af-839b353506f1@gmail.com","threadId":"63952","inReplyTo":"18A45EC6-2D2C-45A2-8802-0E5060539398@gmail.com","subject":"Re: [FEATURE] Proposal: git stash --only-unstaged","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-08-29T13:06:07Z","receivedAt":"2025-08-29T13:06:09Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Ben\n\nOn 19/08/2025 00:41, Ben Knoble wrote:\n> \n>> Le 18 août 2025 à 11:14, Phillip Wood <phillip.wood123@gmail.com> a écrit :\n>>\n>> On 17/08/2025 17:08, Junio C Hamano wrote:\n>>> Phillip Wood <phillip.wood123@gmail.com> writes:\n>>>> To use it create your stash with \"git stash push --keep-index\" and then\n>>>> use the script to pop the unstaged changes rather than using \"git stash\n>>>> pop\". If the script proves to be useful then perhaps we could add an\n>>>> \"--unstaged\" option to \"git stash pop\"\n>>> Hmph, would the behaviour useful enough that it should be always\n>>> enabled, without any new option?  I strongly suspect that those who\n>>> worked on adding \"--keep-index\" option did not expect the user to be\n>>> mucking with the working tree files while \"testing the staged stuff\n>>> by updating the working tree files to match it and nothing else\",\n>>> and as long as the end-user stays within that originally designed\n>>> use case, nothing changes for them, no?\n> \n> I can’t particularly comment on the script, but I do think the example\n > in the docs should either just work or be adjusted to work.\n\nI think the example works but may generate conflicts when the stash is \npopped. One can argue that the conflicts are unnecessary because they \ncould be avoided by popping the unstaged changes but I don't think the \nexample is broken as such.\n\n>> Yes it probably would make sense if we knew that the stash had been\n>> created with \"--keep-index\". At the moment I don't think there is\n >> anywhere to tell from looking at the stash if that's the case but we\n >> could add a trailer to the commit message when we create the stash to\n >> record that it was created with \"--keep-index\" and apply only the\n >> unstaged changes when we see that trailer.>\n> This seems reasonable; I wonder if there would be any interaction \n > with the stash import/export features? But perhaps those omitted the\n > index anyway, I cannot recall.\n\nIt exports the stash commits as-is so it should be fine I think\n\nThanks\n\nPhillip\n\n"},{"id":"525203","messageId":"CALnO6CCsFuYqo-q8D1g=vR9q22+Cy1MAgk1Ld0cD1wFNjr-eSw@mail.gmail.com","threadId":"63952","inReplyTo":"9f9e49c5-5612-4e6d-89af-839b353506f1@gmail.com","subject":"Re: [FEATURE] Proposal: git stash --only-unstaged","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-08-29T13:30:11Z","receivedAt":"2025-08-29T13:30:24Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Fri, Aug 29, 2025 at 9:06 AM Phillip Wood <phillip.wood123@gmail.com> wrote:\n>\n> Hi Ben\n>\n> On 19/08/2025 00:41, Ben Knoble wrote:\n> >\n> >> Le 18 août 2025 à 11:14, Phillip Wood <phillip.wood123@gmail.com> a écrit :\n> >>\n> >> On 17/08/2025 17:08, Junio C Hamano wrote:\n> >>> Phillip Wood <phillip.wood123@gmail.com> writes:\n> >>>> To use it create your stash with \"git stash push --keep-index\" and then\n> >>>> use the script to pop the unstaged changes rather than using \"git stash\n> >>>> pop\". If the script proves to be useful then perhaps we could add an\n> >>>> \"--unstaged\" option to \"git stash pop\"\n> >>> Hmph, would the behaviour useful enough that it should be always\n> >>> enabled, without any new option?  I strongly suspect that those who\n> >>> worked on adding \"--keep-index\" option did not expect the user to be\n> >>> mucking with the working tree files while \"testing the staged stuff\n> >>> by updating the working tree files to match it and nothing else\",\n> >>> and as long as the end-user stays within that originally designed\n> >>> use case, nothing changes for them, no?\n> >\n> > I can’t particularly comment on the script, but I do think the example\n>  > in the docs should either just work or be adjusted to work.\n>\n> I think the example works but may generate conflicts when the stash is\n> popped. One can argue that the conflicts are unnecessary because they\n> could be avoided by popping the unstaged changes but I don't think the\n> example is broken as such.\n\nThanks, let me try to rephrase: the example makes no mention of\nconflicts appearing or having to adjust them. It seems to heavily\nimply to me that no such conflicts are expected, though as we\ndiscussed upthread it seems unlikely you _won't_ get conflicts if you\ndo\n\n               # ... hack hack hack ...\n               $ git add --patch foo            # add just first part\nto the index\n               $ git stash push --keep-index    # save all other\nchanges to the stash\n               $ edit/build/test first part\n               $ git commit -m 'First part'     # commit fully tested change\n               $ git stash pop                  # prepare to work on\nall other changes\n               # ... repeat above five steps until one commit remains ...\n               $ edit/build/test remaining parts\n               $ git commit foo -m 'Remaining parts'\n\nsince we explicitly say \"edit[…] first part,\" since it seems natural\nto me for that to include editing \"foo.\" Perhaps this is where Junio's\nsuspicion (reproduced below) falls afoul of the language used in the\nexample?\n\n> I strongly suspect that those who\n> worked on adding \"--keep-index\" option did not expect the user to be\n> mucking with the working tree files while \"testing the staged stuff\n> by updating the working tree files to match it and nothing else\",\n> and as long as the end-user stays within that originally designed\n> use case, nothing changes for them, no?\n\nI suppose my main complaint is nothing about the example makes it\nclear that's the intended use case to me? Hence\n- we could change the example to mention conflicts and/or use case\n(smaller patch, punts on the problem)\n- we could change the code to accommodate the example as written\n(using ideas from your script; harder but bigger win IMO?)\n\n> >> Yes it probably would make sense if we knew that the stash had been\n> >> created with \"--keep-index\". At the moment I don't think there is\n>  >> anywhere to tell from looking at the stash if that's the case but we\n>  >> could add a trailer to the commit message when we create the stash to\n>  >> record that it was created with \"--keep-index\" and apply only the\n>  >> unstaged changes when we see that trailer.>\n> > This seems reasonable; I wonder if there would be any interaction\n>  > with the stash import/export features? But perhaps those omitted the\n>  > index anyway, I cannot recall.\n>\n> It exports the stash commits as-is so it should be fine I think\n\nGreat!\n\n> Thanks\n>\n> Phillip\n\nThank _you_ for taking a look and providing something to work from :)\n\n-- \nD. Ben Knoble\n"},{"id":"526441","messageId":"4b689f92-5277-4e57-b4b7-8cc241ddd664@gmail.com","threadId":"63952","inReplyTo":"CALnO6CCsFuYqo-q8D1g=vR9q22+Cy1MAgk1Ld0cD1wFNjr-eSw@mail.gmail.com","subject":"Re: [FEATURE] Proposal: git stash --only-unstaged","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-09-16T11:03:11Z","receivedAt":"2025-09-16T11:03:15Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Ben\n\nOn 29/08/2025 14:30, D. Ben Knoble wrote:\n> On Fri, Aug 29, 2025 at 9:06 AM Phillip Wood <phillip.wood123@gmail.com> wrote:\n>>\n>> I think the example works but may generate conflicts when the stash is\n>> popped. One can argue that the conflicts are unnecessary because they\n>> could be avoided by popping the unstaged changes but I don't think the\n>> example is broken as such.\n> \n> Thanks, let me try to rephrase: the example makes no mention of\n> conflicts appearing or having to adjust them. It seems to heavily\n> imply to me that no such conflicts are expected, though as we\n> discussed upthread it seems unlikely you _won't_ get conflicts if you\n> do\n\nYes, I think if you edit any staged changes (that is the lines that \ndiffered between the index and HEAD when \"git stash\" was run) you'll end \nup with conflicts. If you edit a line where the index, HEAD and the \nworktree matched when the stash was created then I don't think you will \nsee a conflict. Overall conflicts seem pretty likely, so maybe we should \nmention them in the documentation.\n\n> [...]\n> I suppose my main complaint is nothing about the example makes it\n> clear that's the intended use case to me? Hence\n> - we could change the example to mention conflicts and/or use case\n> (smaller patch, punts on the problem)\n> - we could change the code to accommodate the example as written\n> (using ideas from your script; harder but bigger win IMO?)\n\nI was hoping that we'd hear back from J. Dettweiler as to whether the \nideas in the script were useful. It would certainly be better to update \nthe command to avoid conflicts if we can.\n\nThanks\n\nPhillip\n\n"},{"id":"526461","messageId":"CALnO6CBprG+TSa3vtVjDOX5sF3MorvPv4Do7gA8mXXz26+3hUA@mail.gmail.com","threadId":"63952","inReplyTo":"4b689f92-5277-4e57-b4b7-8cc241ddd664@gmail.com","subject":"Re: [FEATURE] Proposal: git stash --only-unstaged","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-09-16T17:10:16Z","receivedAt":"2025-09-16T17:10:29Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Tue, Sep 16, 2025 at 7:03 AM Phillip Wood <phillip.wood123@gmail.com> wrote:\n>\n> Hi Ben\n>\n> On 29/08/2025 14:30, D. Ben Knoble wrote:\n> > On Fri, Aug 29, 2025 at 9:06 AM Phillip Wood <phillip.wood123@gmail.com> wrote:\n> >>\n> >> I think the example works but may generate conflicts when the stash is\n> >> popped. One can argue that the conflicts are unnecessary because they\n> >> could be avoided by popping the unstaged changes but I don't think the\n> >> example is broken as such.\n> >\n> > Thanks, let me try to rephrase: the example makes no mention of\n> > conflicts appearing or having to adjust them. It seems to heavily\n> > imply to me that no such conflicts are expected, though as we\n> > discussed upthread it seems unlikely you _won't_ get conflicts if you\n> > do\n>\n> Yes, I think if you edit any staged changes (that is the lines that\n> differed between the index and HEAD when \"git stash\" was run) you'll end\n> up with conflicts. If you edit a line where the index, HEAD and the\n> worktree matched when the stash was created then I don't think you will\n> see a conflict. Overall conflicts seem pretty likely, so maybe we should\n> mention them in the documentation.\n\nThanks—I realize we were talking across each other, so I'm glad we\nwere able to get on the same page.\n\n> > [...]\n> > I suppose my main complaint is nothing about the example makes it\n> > clear that's the intended use case to me? Hence\n> > - we could change the example to mention conflicts and/or use case\n> > (smaller patch, punts on the problem)\n> > - we could change the code to accommodate the example as written\n> > (using ideas from your script; harder but bigger win IMO?)\n>\n> I was hoping that we'd hear back from J. Dettweiler as to whether the\n> ideas in the script were useful. It would certainly be better to update\n> the command to avoid conflicts if we can.\n\nSounds like a good idea.\n\n-- \nD. Ben Knoble\n"}]}