{"thread":{"id":"15920","subject":"Usability of git stash","startedAt":"2008-10-15T19:24:52Z","lastAt":"2008-10-20T16:33:14Z","messageCount":15,"participants":["Anders Melchiorsen","Brandon Casey","David Kastrup","Stephan Beyer","Shawn O. Pearce","Leo Razoumov","Jeff King","Miles Bader","Junio C Hamano","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"93121","messageId":"87wsg9acfv.fsf@cup.kalibalik.dk","threadId":"15920","inReplyTo":null,"subject":"Usability of git stash","fromName":"Anders Melchiorsen","fromEmail":"mail@cup.kalibalik.dk","sentAt":"2008-10-15T19:24:52Z","receivedAt":"2008-10-15T19:24:52Z","isPatch":false,"sender":{"key":"mail@cup.kalibalik.dk","avatar":null},"body":"I find the UI of git stash quite unfortunate.\n\nFirst, I would prefer list to be the default action, so that typing\n\"git stash\" in the hope of getting some help would not make me lose my\nlocal changes.\n\nWhen trying to recover from that scenario, I do \"git stash apply\" as\nrecommended by the \"git stash\" output. Now I still lost my index\nstate, all changes are unstaged.\n\nThe \"git command subcommand\" syntax seems different from other git\ncommands. For example, you do not delete a branch with \"git branch\ndelete\".\n\nThe default naming of stashes makes it hard to remember what I was\nactually working on. Forcing me to give it a description (like branch\nand commit do) would probably have saved me some time overall.\n\nAnd finally, a \"git stash clear\" has quite far-reaching consequences.\nMost other mistakes are easy to recover from, but not this one.\n\n\nI offer these observations just for discussion. It has not been\npossible for me to think of any backwards compatible improvements,\nother than staying away from \"git stash\".\n\n\nCheers,\nAnders.\n"},{"id":"93124","messageId":"nKimSsYZj6xfGNCQS3i5cRwnWQfbHrtUrwdGB2zGWVfMOcfZMwJDKg@cipher.nrlssc.navy.mil","threadId":"15920","inReplyTo":"87wsg9acfv.fsf@cup.kalibalik.dk","subject":"Re: Usability of git stash","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-10-15T19:31:05Z","receivedAt":"2008-10-15T19:31:05Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Anders Melchiorsen wrote:\n\n> When trying to recover from that scenario, I do \"git stash apply\" as\n> recommended by the \"git stash\" output. Now I still lost my index\n> state, all changes are unstaged.\n\nSee the documentation, apply has a '--index' option.\n\n-brandon\n"},{"id":"93186","messageId":"86vdvsg4up.fsf@lola.quinscape.zz","threadId":"15920","inReplyTo":"nKimSsYZj6xfGNCQS3i5cRwnWQfbHrtUrwdGB2zGWVfMOcfZMwJDKg@cipher.nrlssc.navy.mil","subject":"Re: Usability of git stash","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2008-10-16T11:24:30Z","receivedAt":"2008-10-16T11:24:30Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Brandon Casey writes:\n\n> Anders Melchiorsen wrote:\n>\n>> When trying to recover from that scenario, I do \"git stash apply\" as\n>> recommended by the \"git stash\" output. Now I still lost my index\n>> state, all changes are unstaged.\n>\n> See the documentation, apply has a '--index' option.\n\nStill, the shoot-yourself-in-the-foot potential is quite larger than\nappropriate for what is mostly workflow porcelaine. It is even larger\nthan appropriate for plumbing IMHO.\n\nI mean, even misspellings like\ngit stash lisp\n\ncause action that is not easily reversible, and the given help output is\nmisleading with regard to index state.\n\n-- \nDavid Kastrup\n"},{"id":"93210","messageId":"vCcONcOJu3QKQyRgPdT5Dws3F2P25RNAFOgM5GX6FWWKJe40papCRw@cipher.nrlssc.navy.mil","threadId":"15920","inReplyTo":"86vdvsg4up.fsf@lola.quinscape.zz","subject":"Re: Usability of git stash","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-10-16T15:22:44Z","receivedAt":"2008-10-16T15:22:44Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"David Kastrup wrote:\n> Brandon Casey writes:\n> \n>> Anders Melchiorsen wrote:\n>>\n>>> When trying to recover from that scenario, I do \"git stash apply\" as\n>>> recommended by the \"git stash\" output. Now I still lost my index\n>>> state, all changes are unstaged.\n>> See the documentation, apply has a '--index' option.\n> \n> Still, the shoot-yourself-in-the-foot potential is quite larger than\n> appropriate for what is mostly workflow porcelaine. It is even larger\n> than appropriate for plumbing IMHO.\n\nI think it is excessive to call the action taken by 'git stash', when it\nis unwanted, \"shoot[ing]-yourself-in-the-foot\". More like stub-your-toe.\n\nIn exchange for allowing new users to stub their toe on new commands, the\nwork flow of more experienced users is made a little easier.\n\n> I mean, even misspellings like\n> git stash lisp\n>\n> cause action that is not easily reversible, and the given help output is\n> misleading with regard to index state.\n\n$ git stash lisp\nUsage: git stash list []\n or: git stash (show | drop | pop ) []\n or: git stash apply [--index] []\n or: git stash branch []\n or: git stash [save [--keep-index] []]\n or: git stash clear\n\n\nMaybe you are referring to the long since changed behavior where\n'git stash' == 'git stash save' and so \"lisp\" in your example\nwould have been taken as a stash description. This behavior existed\nfor less than 6 months, and has been changed now for over 10 months.\n\n-brandon\n"},{"id":"93350","messageId":"87prly5k5r.fsf@cup.kalibalik.dk","threadId":"15920","inReplyTo":"vCcONcOJu3QKQyRgPdT5Dws3F2P25RNAFOgM5GX6FWWKJe40papCRw@cipher.nrlssc.navy.mil","subject":"Re: Usability of git stash","fromName":"Anders Melchiorsen","fromEmail":"mail@cup.kalibalik.dk","sentAt":"2008-10-18T09:26:08Z","receivedAt":"2008-10-18T09:26:08Z","isPatch":false,"sender":{"key":"mail@cup.kalibalik.dk","avatar":null},"body":"Brandon Casey writes:\n\n> In exchange for allowing new users to stub their toe on new commands, the\n> work flow of more experienced users is made a little easier.\n\nI wonder whether experienced users even use stash a lot. Personally,\nafter getting my head around the DAG, and thus getting more\ncomfortable with git reset, I tend to make \"WIP\" commits instead.\n\nAfter having used \"git stash clear\" at a bad time once, I am wary of\nstashing work that I actually want to keep. I prefer workflows where\nmy mistakes can be (easily) corrected.\n\n\nThe primary thing that stash does for me is preserve the index state.\nUnfortunately, --index is not default for stash apply, so I often\nforget it.\n\nSometimes, I also want stash to store away changes to untracked files\n(to get a clean working directory), but that is not possible.\n\n\nMaybe I just don't quite understand what git stash is about ...\n\n\nAnders.\n"},{"id":"93467","messageId":"20081019184029.GF14786@spearce.org","threadId":"15920","inReplyTo":"87prly5k5r.fsf@cup.kalibalik.dk","subject":"Re: Usability of git stash","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-10-19T18:40:30Z","receivedAt":"2008-10-19T18:40:30Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Anders Melchiorsen wrote:\n> Brandon Casey writes:\n> \n> > In exchange for allowing new users to stub their toe on new commands, the\n> > work flow of more experienced users is made a little easier.\n> \n> I wonder whether experienced users even use stash a lot. Personally,\n> after getting my head around the DAG, and thus getting more\n> comfortable with git reset, I tend to make \"WIP\" commits instead.\n\nDitto. I never use \"git stash\". Its command line usage is too\nunfriendly for me, so I tend to prefer making WIP commits. If I\nneed to stash something I'll do:\n\n git commit -a -m wip\n ... some time later ..\n git checkout branch\n git reset --soft HEAD^\n\n> The primary thing that stash does for me is preserve the index state.\n> Unfortunately, --index is not default for stash apply, so I often\n> forget it.\n\nI never find the index saving useful. My commits are frequent\nenough that losing the index state usually only costs me a few\nminutes when I go back to the branch and pop the wip commit.\n \n> Sometimes, I also want stash to store away changes to untracked files\n> (to get a clean working directory), but that is not possible.\n\nIndeed, that's an advantage of the wip commit approach, you can shove\nthe untracked files quickly into the wip commit, especially with 1.6:\n\n\tgit commit -A -m wip\n\n\nPersonally I wish git-stash wasn't invented the way it is. I would\nhave rather seen it as macros to do a quick:\n\n\tgit commit -m wip-index-state\n\tgit commit -A -m wip-worktree-state\n\nand unwind it with essentially:\n\n\tgit reset --mixed HEAD^\n\tgit reset --soft HEAD^\n\nthen its a lot less black magic to users, as they can see it in the\nDAG, and its more explicitly tied to the branch they were on at the\ntime they ran the stash. I think its rare you'd stash something\nthen switch to another branch to apply it. But that could easily\nbe done with cherry-pick.\n\n-- \nShawn.\n"},{"id":"93474","messageId":"ee2a733e0810191408m2cbe1ba5n540ad0fb99b49708@mail.gmail.com","threadId":"15920","inReplyTo":"20081019184029.GF14786@spearce.org","subject":"Re: Usability of git stash","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2008-10-19T21:08:19Z","receivedAt":"2008-10-19T21:08:19Z","isPatch":false,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On 10/19/08, Shawn O. Pearce wrote:\n> [..snip..]\n> Indeed, that's an advantage of the wip commit approach, you can shove\n> the untracked files quickly into the wip commit, especially with 1.6:\n>\n> git commit -A -m wip\n>\n> [..snip..]\n\nWhat version of git are you using?\nI am using git-1.6.0.2 on Linux and \"-A\" is illegal option for \"git commit\"\n\n--Leo--\n"},{"id":"93450","messageId":"20081019214953.GI14786@spearce.org","threadId":"15920","inReplyTo":"ee2a733e0810191408m2cbe1ba5n540ad0fb99b49708@mail.gmail.com","subject":"Re: Usability of git stash","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-10-19T21:49:53Z","receivedAt":"2008-10-19T21:49:53Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Leo Razoumov wrote:\n> On 10/19/08, Shawn O. Pearce wrote:\n> > [..snip..]\n> > Indeed, that's an advantage of the wip commit approach, you can shove\n> > the untracked files quickly into the wip commit, especially with 1.6:\n> >\n> > git commit -A -m wip\n> >\n> > [..snip..]\n> \n> What version of git are you using?\n> I am using git-1.6.0.2 on Linux and \"-A\" is illegal option for \"git commit\"\n\nOh. Sorry. I thought I saw a patch for that go by. I guess I mean:\n\n\tgit add -A && git commit\n\n-- \nShawn.\n"},{"id":"93445","messageId":"20081019231239.GA23692@leksak.fem-net","threadId":"15920","inReplyTo":"20081019184029.GF14786@spearce.org","subject":"Re: Usability of git stash","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-10-19T23:12:39Z","receivedAt":"2008-10-19T23:12:39Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nShawn O. Pearce wrote:\n> Personally I wish git-stash wasn't invented the way it is. I would\n> have rather seen it as macros to do a quick:\n> \n> \tgit commit -m wip-index-state\n> \tgit commit -A -m wip-worktree-state\n> \n> and unwind it with essentially:\n> \n> \tgit reset --mixed HEAD^\n> \tgit reset --soft HEAD^\n> \n> then its a lot less black magic to users, as they can see it in the\n> DAG, and its more explicitly tied to the branch they were on at the\n> time they ran the stash. I think its rare you'd stash something\n> then switch to another branch to apply it. But that could easily\n> be done with cherry-pick.\n\nJust a side note:\nI, for example, have a stash in which some \"valgrind ...\" string is\nprepended to some lines in some test scripts. I apply the stash on\ndifferent branches and after testing I reset the file (or checkout -f\nanother branch). I never really want to commit these changes.\n\nSo, the alternative for this use case (if there was no git-stash) is\nto have a \"valgrind\" branch somewhere and do some \"cherry-pick -n\" of\nthose commits, right?\n\nHmm, it seems that this is the better way in the long run. But\n\"git-stash\" seemed to be the natural way at first.\n\nRegards,\n Stephan\n\n-- \nStephan Beyer , PGP 0x6EDDD207FCC5040F\n"},{"id":"93477","messageId":"20081020003644.GA10412@coredump.intra.peff.net","threadId":"15920","inReplyTo":"20081019184029.GF14786@spearce.org","subject":"Re: Usability of git stash","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-20T00:36:44Z","receivedAt":"2008-10-20T00:36:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Oct 19, 2008 at 11:40:30AM -0700, Shawn O. Pearce wrote:\n\n> Ditto. I never use \"git stash\". Its command line usage is too\n> unfriendly for me, so I tend to prefer making WIP commits. If I\n> need to stash something I'll do:\n> \n> git commit -a -m wip\n> ... some time later ..\n> git checkout branch\n> git reset --soft HEAD^\n\nThat's what I do, too, except when I want to move changes from one\nbranch to another, or split some changes from their history. So\nsomething like:\n\n git checkout next ;# which is where I usually am anyway\n hack hack hack\n # oops, I have been building this directly on top of next and it\n # really needs to be a feature-branch on maint\n git stash\n git checkout -b jk/maint-fix-whatever origin/maint\n git stash apply\n\nThe equivalent non-stash commands would be \"commit -m wip\" and\n\"cherry-pick\". But the stash saves me the trouble later of having to\ndelete the wip cruft on top of next.\n\nSide note: obviously this uses the stash only as a push/pop stack. I\nhave never personally had a situation where I wanted a named stash or\nmultiple stashes over a wip commit.\n\n> Personally I wish git-stash wasn't invented the way it is. I would\n> have rather seen it as macros to do a quick:\n> \n> \tgit commit -m wip-index-state\n> \tgit commit -A -m wip-worktree-state\n> \n> and unwind it with essentially:\n> \n> \tgit reset --mixed HEAD^\n> \tgit reset --soft HEAD^\n\nI disagree. I think the strength of stash is that it is divorced from\nthe history. So it is more like a cherry-pick (or diff | apply, which is\nwhat it was intended to replace).\n\n> time they ran the stash. I think its rare you'd stash something\n> then switch to another branch to apply it. But that could easily\n> be done with cherry-pick.\n\nI guess we are viewing the tool oppositely. :)\n\n-Peff\n"},{"id":"93479","messageId":"buowsg3delb.fsf@dhapc248.dev.necel.com","threadId":"15920","inReplyTo":"87prly5k5r.fsf@cup.kalibalik.dk","subject":"Re: Usability of git stash","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2008-10-20T05:23:44Z","receivedAt":"2008-10-20T05:23:44Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Anders Melchiorsen writes:\n> I wonder whether experienced users even use stash a lot. Personally,\n> after getting my head around the DAG, and thus getting more\n> comfortable with git reset, I tend to make \"WIP\" commits instead.\n\nI certainly do, and my impression is that some of the biggest boosters\nof stash have always been the git heavy hitters (it's certainly not one\nof these \"implemented due to nagging by newbies\" features)...\n\n-Miles\n\n-- \nLiberty, n. One of imagination's most precious possessions.\n"},{"id":"93480","messageId":"7vmygz4yws.fsf@gitster.siamese.dyndns.org","threadId":"15920","inReplyTo":"20081020003644.GA10412@coredump.intra.peff.net","subject":"Re: Usability of git stash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-20T05:29:39Z","receivedAt":"2008-10-20T05:29:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> git checkout next ;# which is where I usually am anyway\n> hack hack hack\n> # oops, I have been building this directly on top of next and it\n> # really needs to be a feature-branch on maint\n> git stash\n> git checkout -b jk/maint-fix-whatever origin/maint\n> git stash apply\n>\n> The equivalent non-stash commands would be \"commit -m wip\" and\n> \"cherry-pick\". But the stash saves me the trouble later of having to\n> delete the wip cruft on top of next.\n\nThe equivalent would be:\n\n\tgit checkout -m -b jk/maint-fix-whatever origin/maint\n\nno need for stash, wip-commit, nor cherry-pick.\n\nThe advantage of using \"stash then stash apply\" (not \"stash pop\") or\n\"wip-commit with cherry-pick\" is that you can reset, take a deep breath,\nand redo it, when the resulting merge conflict gets too hairy.\n\n> I disagree. I think the strength of stash is that it is divorced from\n> the history. So it is more like a cherry-pick (or diff | apply, which is\n> what it was intended to replace).\n\nI agree with you; it really is the \"diff saved somewhere, later applied\".\n"},{"id":"93492","messageId":"buor66bd2wq.fsf@dhapc248.dev.necel.com","threadId":"15920","inReplyTo":"20081019231239.GA23692@leksak.fem-net","subject":"Re: Usability of git stash","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2008-10-20T09:36:05Z","receivedAt":"2008-10-20T09:36:05Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Stephan Beyer writes:\n> I, for example, have a stash in which some \"valgrind ...\" string is\n> prepended to some lines in some test scripts. I apply the stash on\n> different branches and after testing I reset the file (or checkout -f\n> another branch). I never really want to commit these changes.\n\nI'd just use an appropriate patch file kept around in a parent dir or\nsomething... :-)\n\n-Miles\n\n-- \nPeople who are more than casually interested in computers should have at\nleast some idea of what the underlying hardware is like. Otherwise the\nprograms they write will be pretty weird. -- Donald Knuth\n"},{"id":"93483","messageId":"48FC542F.9010200@op5.se","threadId":"15920","inReplyTo":"87prly5k5r.fsf@cup.kalibalik.dk","subject":"Re: Usability of git stash","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-20T09:49:35Z","receivedAt":"2008-10-20T09:49:35Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Anders Melchiorsen wrote:\n> Brandon Casey writes:\n> \n>> In exchange for allowing new users to stub their toe on new commands, the\n>> work flow of more experienced users is made a little easier.\n> \n> I wonder whether experienced users even use stash a lot. Personally,\n> after getting my head around the DAG, and thus getting more\n> comfortable with git reset, I tend to make \"WIP\" commits instead.\n> \n\nI use stash quite a lot. It's useful for me because my co-workers\nsometimes pull from me so I cannot use 'wip' commits (without annoying\nmy co-workers anyway).\n\n> After having used \"git stash clear\" at a bad time once, I am wary of\n> stashing work that I actually want to keep. I prefer workflows where\n> my mistakes can be (easily) corrected.\n> \n\nI never use \"stash clear\", but always do \"stash pop\", so my stash-stack\nis hardly ever deeper than one. It would be a lot worse for us to get a\n\"wip\" commit accidentally propagated and built on further. It's happened\nand it's no fun what so ever as it requires team coordination and rewrite\nof published history to get it back to a good state.\n\n> \n> The primary thing that stash does for me is preserve the index state.\n> Unfortunately, --index is not default for stash apply, so I often\n> forget it.\n> \n\nI commit regularly enough that it doesn't take me long at all to re-do\nthe index changes.\n\n> Sometimes, I also want stash to store away changes to untracked files\n> (to get a clean working directory), but that is not possible.\n> \n\ngit add .\ngit stash --index\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"93526","messageId":"iLaWuW8h9LOhSqXlSRIQTWkC7QR2AL4JEb3gIbblWjY2dzOepLLfdg@cipher.nrlssc.navy.mil","threadId":"15920","inReplyTo":"87prly5k5r.fsf@cup.kalibalik.dk","subject":"Re: Usability of git stash","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-10-20T16:33:14Z","receivedAt":"2008-10-20T16:33:14Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Anders Melchiorsen wrote:\n> Brandon Casey writes:\n> \n>> In exchange for allowing new users to stub their toe on new commands, the\n>> work flow of more experienced users is made a little easier.\n> \n> I wonder whether experienced users even use stash a lot. Personally,\n> after getting my head around the DAG, and thus getting more\n> comfortable with git reset, I tend to make \"WIP\" commits instead.\n\nThere is another use for stash, as has previously been described by someone\nelse on this list. That is for incrementally splitting up changes made to\nthe working directory into a series of commits, _and_ testing each commit.\n\nThis is what the 'git stash save --keep-index' functionality was invented for,\nbut I do not consider this single option to completely satisfy the\nrequirements. The idea is to be able to 'git add -i' commits to the index and\nthen stash away all of the remaining commits so that the commits in the index\ncan be tested alone. After testing, you may decide that you want to move\ncommits from the index into the stash set or vice versa as appropriate before\ncommitting.\n\nEasily performing the operations in the previous sentence is what is missing.\nAdditional hunks can be added easily, but they can not be un-staged easily.\nMaybe the interactive mode of git-add needs a '-p' sub-command which will\nallow selecting from the set of staged hunks, and un-staging individually in\nthe same way that the 'p' sub-command allows staging hunks.\n\nThere is an example of this workflow in the stash man page, but I think it\nneeds to be changed. It is suggested:\n\n # ... hack hack hack ...\n $ git add --patch foo # add just first part to the index\n $ git stash save --keep-index # save all other changes to the stash\n $ edit/build/test first part\n $ git commit -m 'First part' # commit fully tested change\n $ git stash pop # prepare to work on all other changes\n # ... repeat above five steps until ...\n\nThe commit and pop currently need to be changed to something like:\n\n # git reset --hard\n # git stash pop --index\n # git commit -m 'First part'\n\nOtherwise you are prone to merge conflicts in the working directory which\nare not straight-forward to reconcile. When there are merge conflicts,\nthe changes from the stash are staged for committing, and the files with\nconflicts are 'Changed but not updated'. The user must reconcile the\nconflicts and then 'git reset'.\n\nI'm sure the user's reaction (as mine was) will be WTF!?. I initially\nconcluded that this work-flow was just broken. It is still usable, but far\nfrom perfect.\n\n> After having used \"git stash clear\" at a bad time once, I am wary of\n> stashing work that I actually want to keep. I prefer workflows where\n> my mistakes can be (easily) corrected.\n\nThere is now a 'git stash drop' which can be used to drop individual stashes,\nand a 'git stash pop' to apply and then drop an individual stash.\n\n> The primary thing that stash does for me is preserve the index state.\n> Unfortunately, --index is not default for stash apply, so I often\n> forget it.\n\nThe apply can always be redone.\n\n git reset --hard && git stash apply --index\n\nBut, I wouldn't be against making --index the default.\n\n-brandon\n"}]}