Requesting `git stash --cached` or something similar
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`. Thanks in advance for considering my request. Regards, - Quinn smime.p7s Description: S/MIME cryptographic signature
Re: Requesting `git stash --cached` or something similar
On Mon, Apr 13, 2015 at 02:24:04PM -0700, Quinn Taylor 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.) Ok, so this git stash --cached will save the state of the index in the stash, and reset the index to the state in HEAD. What happens to the working tree? 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. What do you want this new command to do with untracked files? I would expect the answers to be it sets the working directories state to the state in HEAD, and leaves untracked files alone. If that's what you want you can do git commit -m message; git reset --hard; git reset --soft; git stash save to get the effect you want I believe. That said it seems like a kind of odd thing to want to do, what are you actually trying to do? Trev 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`. Thanks in advance for considering my request. Regards, - Quinn -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Requesting `git stash --cached` or something similar
Quinn: On Mon, Apr 13, 2015 at 5:24 PM, Quinn Taylor quinntay...@mac.com 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 bamcc...@gmail.com bamcc...@castopulence.org 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Requesting `git stash --cached` or something similar
Trevor: On Mon, Apr 13, 2015 at 9:44 PM, Trevor Saunders tbsau...@tbsaunde.org wrote: I would expect the answers to be it sets the working directories state to the state in HEAD, and leaves untracked files alone. If that's what you want you can do git commit -m message; git reset --hard; git reset --soft; git stash save to get the effect you want I believe. That said it seems like a kind of odd thing to want to do, what are you actually trying to do? That looks like a bad solution. git reset --hard is going to throw away any remaining changes to the working tree. The previous commit would have committed the staged changes, albeit, you should connect the commands with instead of ; to account for errors. After a `git reset --hard' there's no point in doing a `git reset --soft' because hard does *everything*. --soft would try to reset the HEAD without touching the index or working tree, but both have already been reset with --hard. The motivation is most likely stashing a few changes away so that you can commit others that are ready to be committed while keeping others around to continue working on them. This too is a good observation. It could mean that the OP is inexperienced with a commit-often workflow. You can use git -add -i or -p to commit the good stuff and keep the bad stuff out to work on it more. The great thing about Git is that the history is very malleable. You can also commit the bad and fix it after, rebase the history to clean it up, and end up with perfect history while still keeping your changes safely in history. The OP should experiment with workflows because Git is already very good at this. Stash isn't really needed. That said, I had forgotten that --patch was added to stash some time ago so if that is what you want then it already exists. It's not quite as easy as --cached, but it still gives you some control. It's still not nearly as good as using the full power of Git with a regular commit on a branch though. Regards, -- Brandon McCaig bamcc...@gmail.com bamcc...@castopulence.org 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Requesting `git stash --cached` or something similar
On Mon, Apr 13, 2015 at 10:05:02PM -0400, Brandon McCaig wrote: Trevor: On Mon, Apr 13, 2015 at 9:44 PM, Trevor Saunders tbsau...@tbsaunde.org wrote: I would expect the answers to be it sets the working directories state to the state in HEAD, and leaves untracked files alone. If that's what you want you can do git commit -m message; git reset --hard; git reset --soft; git stash save to get the effect you want I believe. That said it seems like a kind of odd thing to want to do, what are you actually trying to do? That looks like a bad solution. git reset --hard is going to throw away any remaining changes to the working tree. The previous commit git reset --hard is there to do *exactly* that, which I'm assuming is the desired thing for a hypothetical git stash save --cached to do because its consistant with what git stash save does. would have committed the staged changes, albeit, you should connect the commands with instead of ; to account for errors. After a `git it should be clear this is not actual code to run exactly as written. reset --hard' there's no point in doing a `git reset --soft' because hard does *everything*. --soft would try to reset the HEAD without touching the index or working tree, but both have already been reset with --hard. yes, that was supposed to be git reset --soft HEAD~ in which case it does do something, and it is there exactly to just reset HEAD so that git stash can then pick up the changes from the temporary commit. The motivation is most likely stashing a few changes away so that you can commit others that are ready to be committed while keeping others around to continue working on them. This too is a good observation. It yes, it could be they are looking for something like git stash --patch, but maybe not we don't know. could mean that the OP is inexperienced with a commit-often workflow. You can use git -add -i or -p to commit the good stuff and keep the bad stuff out to work on it more. The great thing about Git is that the history is very malleable. You can also commit the bad and fix it after, rebase the history to clean it up, and end up with perfect history while still keeping your changes safely in history. git stash also stores changes in the git database. However if you really like the stack / queue type workflow you might want to consider stgit or stacked git or something (I personally really dislike that work flow so I'm not really familiar with those tools). The OP should experiment with workflows because Git is already very good at this. Stash isn't really needed. That said, I had forgotten that --patch was added to stash some time ago so if that is what you want then it already exists. It's not quite as easy as --cached, but it still gives you some control. It's still not nearly as good as using the full power of Git with a regular commit on a branch though. good is subjective and depends on what you need to do. There are certainly times where the stash is a good way to solve problems, and if people have ideas for things they think it can do better that's great. Trev Regards, -- Brandon McCaig bamcc...@gmail.com bamcc...@castopulence.org 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html