{"thread":{"id":"39066","subject":"Requesting `git stash --cached` or something similar","startedAt":"2015-04-13T21:24:04Z","lastAt":"2015-04-14T03:39:42Z","messageCount":5,"participants":["Quinn Taylor","Brandon McCaig","Trevor Saunders"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"259312","messageId":"37E34942-ACEB-48BC-ABFF-C7248DA6607E@mac.com","threadId":"39066","inReplyTo":null,"subject":"Requesting `git stash --cached` or something similar","fromName":"Quinn Taylor","fromEmail":"quinntaylor@mac.com","sentAt":"2015-04-13T21:24:04Z","receivedAt":"2015-04-13T21:24:04Z","isPatch":false,"sender":{"key":"quinntaylor@mac.com","avatar":null},"body":"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.)\n\nSince `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.)\n\nI 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.\n\nI 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`.\n\nThanks in advance for considering my request.\n\nRegards,\n - Quinn"},{"id":"259316","messageId":"CANUGeEZ7tgVDfh2mnha3dwNDF--aRCMGB3TDQ5pQOUYMaX7tJQ@mail.gmail.com","threadId":"39066","inReplyTo":"37E34942-ACEB-48BC-ABFF-C7248DA6607E@mac.com","subject":"Re: Requesting `git stash --cached` or something similar","fromName":"Brandon McCaig","fromEmail":"bamccaig@gmail.com","sentAt":"2015-04-14T01:42:54Z","receivedAt":"2015-04-14T01:42:54Z","isPatch":false,"sender":{"key":"bamccaig@gmail.com","avatar":"https://gravatar.com/avatar/05b01f2b62a5ddbaa1946579266a8d9e970fed0c0b3c20e8d42aca973c31531c?d=mp&s=160"},"body":"Quinn:\n\nOn Mon, Apr 13, 2015 at 5:24 PM, Quinn Taylor <quinntaylor@mac.com> wrote:\n> 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.)\n>\n> 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.)\n>\n> 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.\n>\n> 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`.\n\nI know that git-stash feels like a suitable solution for this, but it\nreally doesn't seem to have been built for it. Especially when you get\na little bit more experienced with Git and start experimenting with\nbranching more you will find that stashes quickly become difficult to\nmaintain. Branches are easier to manage, and they come with the full\npower of Git for free. It just doesn't make sense to create a separate\nsystem to manage this when it's precisely what Git does so well\nalready. That's my two cents.\n\nNote that you don't have to merge these \"branches\". You can rebase as\nyou please to formulate the history exactly as you want if you want.\nYou'll find that if you try you can more easily keep track of\nbranches. It helps to formulate a workflow for yourself. You can even\nuse \"namespaces\" in your branch names to keep them separate. For\nexample, instead of creating a branch with your \"stash\" changes called\n\"foobar\", you could create one called \"stash/foobar\". It would help\nyou to differentiate between other branches, but you still have the\nfull power of Git. You can rebase the branch onto other history, or\nyou can merge if you so desire. It's easier to keep track of where the\nwork began and where it was first applied. There are just so many\nadvantages. The stash can be useful to quickly tuck a dirty tree away\nwhile you do something else. Even so, often committing it is\nsufficient. You can often just work around that commit and edit it\nlater if necessary.\n\nI'm not a developer so I can't say that your suggestion isn't useful.\nI know that I have had the same desire in the past. For example,\nwanting git stash save --interactive or git stash save --patch (i.e.,\nsee git-add flags). Of course, Git already has stable code to do this\nand it doesn't require introducing parallel APIs for the same exact\nthing. If you give it a shot you may find that branches solve your\nproblem sufficiently.\n\nRegards,\n\n\n-- \nBrandon McCaig <bamccaig@gmail.com> <bamccaig@castopulence.org>\nCastopulence Software <https://www.castopulence.org/>\nBlog <http://www.bambams.ca/>\nperl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.\nq{Vg qbrfa'\\''g nyjnlf fbhaq gung jnl.};\ntr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'\n"},{"id":"259317","messageId":"20150414014435.GC8601@tsaunders-iceball.corp.tor1.mozilla.com","threadId":"39066","inReplyTo":"37E34942-ACEB-48BC-ABFF-C7248DA6607E@mac.com","subject":"Re: Requesting `git stash --cached` or something similar","fromName":"Trevor Saunders","fromEmail":"tbsaunde@tbsaunde.org","sentAt":"2015-04-14T01:44:35Z","receivedAt":"2015-04-14T01:44:35Z","isPatch":false,"sender":{"key":"tbsaunde@tbsaunde.org","avatar":null},"body":"On Mon, Apr 13, 2015 at 02:24:04PM -0700, Quinn Taylor wrote:\n> 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.)\n> \n> 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.)\n\nOk, so this git stash --cached will save the state of the index in the\nstash, and reset the index to the state in HEAD.  What happens to the\nworking tree?\n\n> 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.\n\nWhat do you want this new command to do with untracked files?\n\nI would expect the answers to be it sets the working directories state\nto the state in HEAD, and leaves untracked files alone.  If that's what\nyou want you can do git commit -m <message>; git reset --hard; git reset\n--soft; git stash save to get the effect you want I believe.  That said\nit seems like a kind of odd thing to want to do, what are you actually\ntrying to do?\n\nTrev\n\n> \n> 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`.\n> \n> Thanks in advance for considering my request.\n> \n> Regards,\n>  - Quinn\n"},{"id":"259319","messageId":"CANUGeEbRyG4A2UdTYOBgtjDtqi_A1WnbkOBjH_h2AcEZT741jQ@mail.gmail.com","threadId":"39066","inReplyTo":"20150414014435.GC8601@tsaunders-iceball.corp.tor1.mozilla.com","subject":"Re: Requesting `git stash --cached` or something similar","fromName":"Brandon McCaig","fromEmail":"bamccaig@gmail.com","sentAt":"2015-04-14T02:05:02Z","receivedAt":"2015-04-14T02:05:02Z","isPatch":false,"sender":{"key":"bamccaig@gmail.com","avatar":"https://gravatar.com/avatar/05b01f2b62a5ddbaa1946579266a8d9e970fed0c0b3c20e8d42aca973c31531c?d=mp&s=160"},"body":"Trevor:\n\nOn Mon, Apr 13, 2015 at 9:44 PM, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:\n> I would expect the answers to be it sets the working directories state\n> to the state in HEAD, and leaves untracked files alone.  If that's what\n> you want you can do git commit -m <message>; git reset --hard; git reset\n> --soft; git stash save to get the effect you want I believe. That said\n> it seems like a kind of odd thing to want to do, what are you actually\n> trying to do?\n\nThat looks like a bad solution. git reset --hard is going to throw\naway any remaining changes to the working tree. The previous commit\nwould have committed the staged changes, albeit, you should connect\nthe commands with && instead of ; to account for errors. After a `git\nreset --hard' there's no point in doing a `git reset --soft' because\nhard does *everything*. --soft would try to reset the HEAD without\ntouching the index or working tree, but both have already been reset\nwith --hard.\n\nThe motivation is most likely stashing a few changes away so that you\ncan commit others that are ready to be committed while keeping others\naround to continue working on them. This too is a good observation. It\ncould mean that the OP is inexperienced with a commit-often workflow.\nYou can use git -add -i or -p to commit the good stuff and keep the\nbad stuff out to work on it more. The great thing about Git is that\nthe history is very malleable. You can also commit the bad and fix it\nafter, rebase the history to clean it up, and end up with perfect\nhistory while still keeping your changes safely in history.\n\nThe OP should experiment with workflows because Git is already very\ngood at this. Stash isn't really needed. That said, I had forgotten\nthat --patch was added to stash some time ago so if that is what you\nwant then it already exists. It's not quite as easy as --cached, but\nit still gives you some control. It's still not nearly as good as\nusing the full power of Git with a regular commit on a branch though.\n\nRegards,\n\n-- \nBrandon McCaig <bamccaig@gmail.com> <bamccaig@castopulence.org>\nCastopulence Software <https://www.castopulence.org/>\nBlog <http://www.bambams.ca/>\nperl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.\nq{Vg qbrfa'\\''g nyjnlf fbhaq gung jnl.};\ntr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'\n"},{"id":"259321","messageId":"20150414033942.GD8601@tsaunders-iceball.corp.tor1.mozilla.com","threadId":"39066","inReplyTo":"CANUGeEbRyG4A2UdTYOBgtjDtqi_A1WnbkOBjH_h2AcEZT741jQ@mail.gmail.com","subject":"Re: Requesting `git stash --cached` or something similar","fromName":"Trevor Saunders","fromEmail":"tbsaunde@tbsaunde.org","sentAt":"2015-04-14T03:39:42Z","receivedAt":"2015-04-14T03:39:42Z","isPatch":false,"sender":{"key":"tbsaunde@tbsaunde.org","avatar":null},"body":"On Mon, Apr 13, 2015 at 10:05:02PM -0400, Brandon McCaig wrote:\n> Trevor:\n> \n> On Mon, Apr 13, 2015 at 9:44 PM, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:\n> > I would expect the answers to be it sets the working directories state\n> > to the state in HEAD, and leaves untracked files alone.  If that's what\n> > you want you can do git commit -m <message>; git reset --hard; git reset\n> > --soft; git stash save to get the effect you want I believe. That said\n> > it seems like a kind of odd thing to want to do, what are you actually\n> > trying to do?\n> \n> That looks like a bad solution. git reset --hard is going to throw\n> away any remaining changes to the working tree. The previous commit\n\n git reset --hard is there to do *exactly* that, which I'm assuming is\n the desired thing for a hypothetical git stash save --cached to do\n because its consistant with what git stash save does.\n\n> would have committed the staged changes, albeit, you should connect\n> the commands with && instead of ; to account for errors. After a `git\n\nit should be clear this is not actual code to run exactly as written.\n\n> reset --hard' there's no point in doing a `git reset --soft' because\n> hard does *everything*. --soft would try to reset the HEAD without\n> touching the index or working tree, but both have already been reset\n> with --hard.\n\nyes, that was supposed to be git reset --soft HEAD~ in which case it\ndoes do something, and it is there exactly to just reset HEAD so that\ngit stash can then pick up the changes from the temporary commit.\n\n> The motivation is most likely stashing a few changes away so that you\n> can commit others that are ready to be committed while keeping others\n> around to continue working on them. This too is a good observation. It\n\nyes, it could be they are looking for something like git stash --patch,\nbut maybe not we don't know.\n\n> could mean that the OP is inexperienced with a commit-often workflow.\n> You can use git -add -i or -p to commit the good stuff and keep the\n> bad stuff out to work on it more. The great thing about Git is that\n> the history is very malleable. You can also commit the bad and fix it\n> after, rebase the history to clean it up, and end up with perfect\n> history while still keeping your changes safely in history.\n\ngit stash also stores changes in the git database.  However if you\nreally like the stack / queue type workflow you might want to consider\nstgit or stacked git or something (I personally really dislike that work\nflow so I'm not really familiar with those tools).\n\n> The OP should experiment with workflows because Git is already very\n> good at this. Stash isn't really needed. That said, I had forgotten\n> that --patch was added to stash some time ago so if that is what you\n> want then it already exists. It's not quite as easy as --cached, but\n> it still gives you some control. It's still not nearly as good as\n> using the full power of Git with a regular commit on a branch though.\n\ngood is subjective and depends on what you need to do.  There are\ncertainly times where the stash is a good way to solve problems, and if\npeople have ideas for things they think it can do better that's great.\n\nTrev\n\n> \n> Regards,\n> \n> -- \n> Brandon McCaig <bamccaig@gmail.com> <bamccaig@castopulence.org>\n> Castopulence Software <https://www.castopulence.org/>\n> Blog <http://www.bambams.ca/>\n> perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.\n> q{Vg qbrfa'\\''g nyjnlf fbhaq gung jnl.};\n> tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"}]}