I am surprised not having found a response to this question but basically say I have a stash with several files in it (I can explore it through git extension for instance). Looking at its content, I'd like to drop some files before applying it, is it possible ?
The only workaround I can think of is:
- checkout the stash to a new branch
- checkout the targeted files
- stash again
- delete the branch
Is there something better ?
thanks
You can directly use
stash@{0}
as a commit reference.If your working tree is clean (no modified files), you can checkout the files you want :
and then inspect the diff manually to keep what you want.
If you want something closer to the behaviour of
git stash apply
, you can create a patch and apply it :[EDIT] To list the files modified in
stash@{0}
:If you want to get all files except one :
It seems like the tricky part of this question revolves around what you want the stash to look like when you're done. Since
git stash {pop|apply}
only affects the working tree (and sometimes index), it's easy enough to selectively take changes from a stash (enough so that I initially thought you were over-thinking the problem):But those commands remove the stash entirely; and by contrast if I'd said
git stash apply
instead ofpop
, that leaves the stash unchanged. It sounds like you want the stash to remain with the changes you've selected (in case you should need to apply them again).(I suppose alternately there could be times you'd want exactly the opposite - to leave in the stash those changes that you didn't apply, so they can be applied later.)
So taking a step back: what is involved in modifying a stash?
A stash, really, comprises two or three temporary commits. The special ref
stash
points to these commits, and a "stack" of multiple stashes is maintained using the reflog (which may be a bit of a hack, but generally is effective).So to modify the stash is to create new commits (because commits are immutable) and rearrange the
stash
ref and reflog accordingly.This is why the notations LeGEC mentions will work and may give you extra flexibility in reading a stash. But because the reflog usage is not the same as for non-stash refs, leveraging this fact to contrive a way to write to a stash could have unexpected results. I'm not saying the results would be horrible, or impossible to predict/control; but I think in the end you'd create more complexity than you'd avoid.
So if we confine ourselves to actual documented
git-stash
subcommands, then a stash is more or less atomic. When you create a stash there's apatch
mode that lets you select working changes to put in the stack, but I'm aware of no corresponding functionality for pop/apply. Still, that's something:If you have a clean work tree and a stash you want to split, you could try things like:
Apply some changes, and keep those same changes in the stash
Apply some changes, and keep the remaining changes in the stash
Split the stash into two parts, decide what to do with them later
Yes there is a better way to do it.
First of all, You can check the stash list as
Then you can do below for checking contents of the stashed commits.
Then you can apply using