Subject: Stashing just index..working-copy rather than HEAD..working-copy?

From: Tim Chase <[email-masked]>
Date: Wed, 24 Apr 2024 08:44:09 -0500

A while back[1] I'd encountered a situation and sparred my way
around it, but was hoping there was a better solution.

I'd done a

  $ git add -p

to selectively add things that I wanted in the next commit.
So I wanted to stash the changes that appeared in

  $ git diff

and test just the changes I was about to commit so I did a

  $ git stash

However, that reset my index and stashed everything HEAD..working-copy.
Okay, my fault.  There's a --keep-index that isn't default, so I
carefully re-staged my commit with another

  $ git add -p

and did

  $ git stash --keep-index

to keep the index.  Great.  My index was still good.  But when I went to

  $ git stash pop

as described in `git help stash` under the "Testing partial commits"
it generated conflicts because it had still stashed HEAD..working-copy
(as confirmed with a `git stash show -p`) rather than index..working-copy
and some of those popped changes were already in the working-copy/index.

To work around it, I re-staged my index yet again:

  $ git add -p

and then did

  $ git diff > temp.diff
  $ git reset --staged

did my testing, and then re-applied the temp.diff patch to the
working-copy to get back to where I'd been.  Conflict-free as
expected.

As a slight improvement, /u/splettnet suggested actually committing
a dummy-commit:

  $ git add -p
  $ git commit --allow-empty-message
  $ git stash

at which point I could build/run/test and then resetting to uncommit:

  $ git stash pop
  $ git reset --soft HEAD~1

which I've been using since.  However, I was wondering if there was
a better way to instruct git-stash to stash index..working-copy
instead of HEAD..working-copy (and leave the index alone in the
process) in the first place.

Thanks,

-tkc

[1]
https://www.reddit.com/r/git/comments/vchu83/stashing_only_unstaged_changes/