Quinn: On Mon, Apr 13, 2015 at 5:24 PM, Quinn Taylor <quinntaylor@xxxxxxx> wrote: > I'm still fairly new to git (coming from svn) and have found `git stash` to be really useful for storing in-progress work to resume later, as one might otherwise do with diff/patch files. (With the git tools I use, I find `git stash pop` to be more convenient and reliable than creating and applying diffs, partially because the changes remained tied to my repository and easily accessible.) > > Since `git stash` defaults to stashing ALL local modifications, I'd like to request there be an easy way to stash *only* the changes I've already staged in the index. (The reason I suggested --cached is due to the similarity with `git diff --cached`, but I don't doubt there would be a better name for this option.) > > I tried staging everything *except* what I want to stash and using `git stash save --keep-index <message>`, but it isn't intended to support this case, and doesn't work when I have new untracked files. Instead, it stashes *all* local (tracked) changes — both staged and unstaged — but leaves the staged changes intact in the index. > > I understand that git's branching model is powerful and flexible, and that an experienced git user would generally create a private branch and commit to that, then merge the changes to mainline sometime later. However, for those like me for whom having many branches is generally more confusing than helpful, it would be fantastic to have more flexibility with `git stash`. I know that git-stash feels like a suitable solution for this, but it really doesn't seem to have been built for it. Especially when you get a little bit more experienced with Git and start experimenting with branching more you will find that stashes quickly become difficult to maintain. Branches are easier to manage, and they come with the full power of Git for free. It just doesn't make sense to create a separate system to manage this when it's precisely what Git does so well already. That's my two cents. Note that you don't have to merge these "branches". You can rebase as you please to formulate the history exactly as you want if you want. You'll find that if you try you can more easily keep track of branches. It helps to formulate a workflow for yourself. You can even use "namespaces" in your branch names to keep them separate. For example, instead of creating a branch with your "stash" changes called "foobar", you could create one called "stash/foobar". It would help you to differentiate between other branches, but you still have the full power of Git. You can rebase the branch onto other history, or you can merge if you so desire. It's easier to keep track of where the work began and where it was first applied. There are just so many advantages. The stash can be useful to quickly tuck a dirty tree away while you do something else. Even so, often committing it is sufficient. You can often just work around that commit and edit it later if necessary. I'm not a developer so I can't say that your suggestion isn't useful. I know that I have had the same desire in the past. For example, wanting git stash save --interactive or git stash save --patch (i.e., see git-add flags). Of course, Git already has stable code to do this and it doesn't require introducing parallel APIs for the same exact thing. If you give it a shot you may find that branches solve your problem sufficiently. Regards, -- Brandon McCaig <bamccaig@xxxxxxxxx> <bamccaig@xxxxxxxxxxxxxxxx> Castopulence Software <https://www.castopulence.org/> Blog <http://www.bambams.ca/> perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }. q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.}; tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say' -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html