{"thread":{"id":"30197","subject":"stash refuses to pop","startedAt":"2012-04-10T17:52:16Z","lastAt":"2012-04-16T01:29:49Z","messageCount":12,"participants":["Phillip Susi","Junio C Hamano","Andrew Ardill","Johannes Sixt","Victor Engmark","Andreas Krey","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"188889","messageId":"4F847350.3000409@ubuntu.com","threadId":"30197","inReplyTo":null,"subject":"stash refuses to pop","fromName":"Phillip Susi","fromEmail":"psusi@ubuntu.com","sentAt":"2012-04-10T17:52:16Z","receivedAt":"2012-04-10T17:52:16Z","isPatch":false,"sender":{"key":"psusi@ubuntu.com","avatar":null},"body":"git stash refuses to apply a stash if it touches files that are \nmodified. Using stash -p to selectively stash some hunks of a file and \nthen immediately trying to pop that stash causes this failure every \ntime. This seems incredibly broken, and there does not seem to be a \nforce switch. How can you get the stash applied?\n"},{"id":"188892","messageId":"7vpqbfpim2.fsf@alter.siamese.dyndns.org","threadId":"30197","inReplyTo":"4F847350.3000409@ubuntu.com","subject":"Re: stash refuses to pop","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-10T18:05:57Z","receivedAt":"2012-04-10T18:05:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Susi writes:\n\n> git stash refuses to apply a stash if it touches files that are\n> modified. Using stash -p to selectively stash some hunks of a file\n> and then immediately trying to pop that stash causes this failure\n> every time.\n\nI think that is by design.\n\nI do not use \"stash -p\" and personally, but I think its broken from the UI\npoint of view. The point of \"stash\" is to clear your workspace to a\npristine state, do random things, and after you are done and cleared your\nworkspace again, apply it to come back to the original state or a state as\nif you started your WIP from the updated clean-slate.\n\nSo probably the right way to use \"stash -p\" (if there were such a thing)\nwould be to stash away the remainder in a separate stash with another\n\"stash\" without \"-p\" (which will clear your workspace to a pristine state)\nand then pop the one you created with \"stash -p\", I think.\n"},{"id":"188899","messageId":"4F84827B.80104@ubuntu.com","threadId":"30197","inReplyTo":"7vpqbfpim2.fsf@alter.siamese.dyndns.org","subject":"Re: stash refuses to pop","fromName":"Phillip Susi","fromEmail":"psusi@ubuntu.com","sentAt":"2012-04-10T18:56:59Z","receivedAt":"2012-04-10T18:56:59Z","isPatch":false,"sender":{"key":"psusi@ubuntu.com","avatar":null},"body":"On 4/10/2012 2:05 PM, Junio C Hamano wrote:\n> Phillip Susi writes:\n>\n>> git stash refuses to apply a stash if it touches files that are\n>> modified. Using stash -p to selectively stash some hunks of a file\n>> and then immediately trying to pop that stash causes this failure\n>> every time.\n>\n> I think that is by design.\n\nBeing able to push something that you can not pop seems to be broken \ndesign...\n\n> I do not use \"stash -p\" and personally, but I think its broken from the UI\n> point of view. The point of \"stash\" is to clear your workspace to a\n> pristine state, do random things, and after you are done and cleared your\n> workspace again, apply it to come back to the original state or a state as\n> if you started your WIP from the updated clean-slate.\n\nOr temporarily undo some changes and come back to those changes later?\n\n> So probably the right way to use \"stash -p\" (if there were such a thing)\n> would be to stash away the remainder in a separate stash with another\n> \"stash\" without \"-p\" (which will clear your workspace to a pristine state)\n> and then pop the one you created with \"stash -p\", I think.\n\nThat would not get you back to the state you were in when you first \nstashed, but instead to a state where you have the first set of changes, \nbut not the second ( which you then also can not pop due to the first \nchanges being there ).\n"},{"id":"188922","messageId":"CAH5451=0KvUPB77hKyjFVXRwPfEZ8+45b20SimBPmuF-gq_A3w@mail.gmail.com","threadId":"30197","inReplyTo":"4F84827B.80104@ubuntu.com","subject":"Re: stash refuses to pop","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-04-11T02:47:44Z","receivedAt":"2012-04-11T02:47:44Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 11 April 2012 04:56, Phillip Susi wrote:\n> On 4/10/2012 2:05 PM, Junio C Hamano wrote:\n>>\n>> Phillip Susi  writes:\n>>\n>>> git stash refuses to apply a stash if it touches files that are\n>>> modified.  Using stash -p to selectively stash some hunks of a file\n>>> and then immediately trying to pop that stash causes this failure\n>>> every time.\n>>\n>>\n>> I think that is by design.\n>\n>\n> Being able to push something that you can not pop seems to be broken\n> design...\n>\n>\n>> I do not use \"stash -p\" and personally, but I think its broken from the UI\n>> point of view.  The point of \"stash\" is to clear your workspace to a\n>> pristine state, do random things, and after you are done and cleared your\n>> workspace again, apply it to come back to the original state or a state as\n>> if you started your WIP from the updated clean-slate.\n>\n>\n> Or temporarily undo some changes and come back to those changes later?\n>\n>\n>> So probably the right way to use \"stash -p\" (if there were such a thing)\n>> would be to stash away the remainder in a separate stash with another\n>> \"stash\" without \"-p\" (which will clear your workspace to a pristine state)\n>> and then pop the one you created with \"stash -p\", I think.\n>\n>\n> That would not get you back to the state you were in when you first stashed,\n> but instead to a state where you have the first set of changes, but not the\n> second ( which you then also can not pop due to the first changes being\n> there ).\n\nThe first question, it would seem, is what should git do when there\nare modified files present, and the user tries to pop a stash which\ntouches those files. The current behaviour is to reject the pop,\nreasonable enough, though for what exact reason I am not sure\n(potential merge issues, I assume).\n\nThe method you have described is just one way of coming on this\nsituation. The user could have\n* stashed their work, modified some files and tried to pop\n* partially stashed their work, and tried to pop\n* partially stashed their work, modified some files and then tried to pop.\n\nThe options for dealing with this situation seem to be\n1. Reject the pop outright\n2. put the affected files into a merge conflict state\n3. revert the file to the state they were at at the time of stash\n4. reject those files that do not apply cleanly (but apply all others)\n5. reject those hunks which do not apply cleanly (but apply all others)\n6. provide an interactive pop session for choosing what to apply\n\nI don't know if all of these are possible/feasible/reasonable.\n1. possible by # git reset\n2. default behaviour\n3. is possible using # git stash branch []\n4. 5. seems this might be possible, not sure of best method\n6. this would be something like # git stash pop -p [], which I\nthink does not exist yet\n\nI would like to see 6. implemented, but the behaviour seems very\nreasonable at the moment.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"188923","messageId":"4F84F39B.6070907@ubuntu.com","threadId":"30197","inReplyTo":"CAH5451=0KvUPB77hKyjFVXRwPfEZ8+45b20SimBPmuF-gq_A3w@mail.gmail.com","subject":"Re: stash refuses to pop","fromName":"Phillip Susi","fromEmail":"psusi@ubuntu.com","sentAt":"2012-04-11T02:59:39Z","receivedAt":"2012-04-11T02:59:39Z","isPatch":false,"sender":{"key":"psusi@ubuntu.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nOn 04/10/2012 10:47 PM, Andrew Ardill wrote:\n> The first question, it would seem, is what should git do when there\n> are modified files present, and the user tries to pop a stash which\n> touches those files. The current behaviour is to reject the pop,\n> reasonable enough, though for what exact reason I am not sure\n> (potential merge issues, I assume).\n\nSince pop is the inverse of push, and merge is the inverse of a partial push, I would expect pop to perform a merge.\n\n> The method you have described is just one way of coming on this\n> situation. The user could have\n> * stashed their work, modified some files and tried to pop\n> * partially stashed their work, and tried to pop\n> * partially stashed their work, modified some files and then tried to pop.\n\nYes, there are a number of ways you can get to the situation where you can not pop the stash. How to resolve this is unclear from the results of the failed pop. I finally ended up resolving it by committing the remaining changes, then popping the stash ( which performed the merge successfully ), and finally doing a git reset HEAD~1 to remove the temporary commit, but preserve the merged results. This seemed like a good deal of unnecessary trouble.\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.11 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\n\niQEcBAEBAgAGBQJPhPObAAoJEJrBOlT6nu75qwkH/jlWpu+yRIx9l8qsp4+MWB/I\nFPfKku+LnUpRoegsmKMer1J59kriw8zJF8hujHUUp1RcCdfQBUJwCDZnNGEa/LRn\nPNrceRHc3V92ImBBJHwLsOqr4IQa7O+PDG8Tuht6q6NwIxEu2ZycoxnThx7JoF/G\nwsD5KA9yZmJKb+lptCNVVfgez4k6ESqnekx4Tsl8C5UOUXbra61SC6vG+igRnU2P\n6V+QaYbHEmNNq3pLmebCty/wmzwHJc9oTA+wDawJwV5BhcgsKnUY0RhVMT86t1Qu\nIbwqkFUJV9je1GZKEwklvbLnBx2js80yvEnPWpC3jt9j6gxRGAfaq/5NQnl7vQE=\n=UEM3\n-----END PGP SIGNATURE-----\n"},{"id":"188929","messageId":"4F851D8A.4000501@viscovery.net","threadId":"30197","inReplyTo":"4F84827B.80104@ubuntu.com","subject":"Re: stash refuses to pop","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-04-11T05:58:34Z","receivedAt":"2012-04-11T05:58:34Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 4/10/2012 20:56, schrieb Phillip Susi:\n> On 4/10/2012 2:05 PM, Junio C Hamano wrote:\n>> Phillip Susi writes:\n>>\n>>> git stash refuses to apply a stash if it touches files that are\n>>> modified. Using stash -p to selectively stash some hunks of a file\n>>> and then immediately trying to pop that stash causes this failure\n>>> every time.\n>>\n>> I think that is by design.\n> \n> Being able to push something that you can not pop seems to be broken\n> design...\n\nYou are trying to abuse git-stash, but it does not cooperate because it\nwas not designed to be abused ;-) git-stash is not intended as a generic\npush-and-pop-my-changes work horse.\n\nThe purpose of git-stash is that you can \"move away\"\n\n- all of your changes to have a clean worktree or\n- part of your changes to _create a clean worktree from the remaining\nchanges_.\n\nThat is, before you can think of applying a stash, you are expected to\nhave cleaned out your worktree.\n\n-- Hannes\n"},{"id":"188932","messageId":"CAA5Ydx9CTKdm-3OPM1s424d=PAi18MtpfhNXxdDw=44VQBXtGQ@mail.gmail.com","threadId":"30197","inReplyTo":"CAH5451=0KvUPB77hKyjFVXRwPfEZ8+45b20SimBPmuF-gq_A3w@mail.gmail.com","subject":"Re: stash refuses to pop","fromName":"Victor Engmark","fromEmail":"victor.engmark@gmail.com","sentAt":"2012-04-11T07:15:57Z","receivedAt":"2012-04-11T07:15:57Z","isPatch":false,"sender":{"key":"victor.engmark@gmail.com","avatar":"https://gravatar.com/avatar/5d7b4229a48f2ed011a265c19a1881c4ee58946449215db6627373a244c8aa4c?d=mp&s=160"},"body":"On Wed, Apr 11, 2012 at 4:47 AM, Andrew Ardill wrote:\n>\n> On 11 April 2012 04:56, Phillip Susi wrote:\n> > On 4/10/2012 2:05 PM, Junio C Hamano wrote:\n> >> So probably the right way to use \"stash -p\" (if there were such a thing)\n> >> would be to stash away the remainder in a separate stash with another\n> >> \"stash\" without \"-p\" (which will clear your workspace to a pristine state)\n> >> and then pop the one you created with \"stash -p\", I think.\n> >\n> > That would not get you back to the state you were in when you first stashed,\n> > but instead to a state where you have the first set of changes, but not the\n> > second ( which you then also can not pop due to the first changes being\n> > there ).\n>\n> The first question, it would seem, is what should git do when there\n> are modified files present, and the user tries to pop a stash which\n> touches those files. The current behaviour is to reject the pop,\n> reasonable enough, though for what exact reason I am not sure\n> (potential merge issues, I assume).\n>\n> The method you have described is just one way of coming on this\n> situation. The user could have\n> * stashed their work, modified some files and tried to pop\n> * partially stashed their work, and tried to pop\n> * partially stashed their work, modified some files and then tried to pop.\n>\n> The options for dealing with this situation seem to be\n> 1. Reject the pop outright\n> 2. put the affected files into a merge conflict state\n> 3. revert the file to the state they were at at the time of stash\n> 4. reject those files that do not apply cleanly (but apply all others)\n> 5. reject those hunks which do not apply cleanly (but apply all others)\n> 6. provide an interactive pop session for choosing what to apply\n\n#2 seems like the most natural option, for the reason Phillip Susi\nmentioned. But how about\n7. Apply all hunks iff all of them can be applied cleanly\n? That way pop would be an atomic operation. It might be easier to do\nthan 2, and even if 2 is implemented it would be nice to have a\n--atomic or --dry-run option when you want to make sure not to end up\nin a messy merge.\n\nCheers,\nV\n"},{"id":"188963","messageId":"4F859353.4070700@ubuntu.com","threadId":"30197","inReplyTo":"4F851D8A.4000501@viscovery.net","subject":"Re: stash refuses to pop","fromName":"Phillip Susi","fromEmail":"psusi@ubuntu.com","sentAt":"2012-04-11T14:21:07Z","receivedAt":"2012-04-11T14:21:07Z","isPatch":false,"sender":{"key":"psusi@ubuntu.com","avatar":null},"body":"On 4/11/2012 1:58 AM, Johannes Sixt wrote:\n> You are trying to abuse git-stash, but it does not cooperate because it\n> was not designed to be abused ;-) git-stash is not intended as a generic\n> push-and-pop-my-changes work horse.\n\nIn what way is using the documented -p switch abuse?\n\n> The purpose of git-stash is that you can \"move away\"\n\nYes, and then move back. That is why it is broken that you can not \nimmediately move back after a stash -p.\n\n> - all of your changes to have a clean worktree or\n> - part of your changes to _create a clean worktree from the remaining\n> changes_.\n>\n> That is, before you can think of applying a stash, you are expected to\n> have cleaned out your worktree.\n\nIt is obvious that is the assumption that stash was originally made \nwith, and it might make some sense if it always left the tree in a clean \nstate, but it no longer makes sense given -p and how it can leave the \ntree in a not clean state.\n\nThis is clearly a case of the initial implementation being a bit lazy. \npop already performs a type of merge, just on a whole file basis. In \nother words, the pop leaves you with some files from before the pop, and \nsome files that were modified by the pop. It should do a proper merge \ninstead of a lazy whole file merge.\n"},{"id":"189075","messageId":"4F866D0D.7070904@viscovery.net","threadId":"30197","inReplyTo":"4F859353.4070700@ubuntu.com","subject":"Re: stash refuses to pop","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-04-12T05:50:05Z","receivedAt":"2012-04-12T05:50:05Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 4/11/2012 16:21, schrieb Phillip Susi:\n> On 4/11/2012 1:58 AM, Johannes Sixt wrote:\n>> You are trying to abuse git-stash, but it does not cooperate because it\n>> was not designed to be abused ;-) git-stash is not intended as a generic\n>> push-and-pop-my-changes work horse.\n> \n> In what way is using the documented -p switch abuse?\n\nIt isn't.\n\n>> The purpose of git-stash is that you can \"move away\"\n> \n> Yes, and then move back.\n\nThis is abuse, if you haven't cleaned your worktree.\n\n>> That is, before you can think of applying a stash, you are expected to\n>> have cleaned out your worktree.\n> \n> It is obvious that is the assumption that stash was originally made with,\n> and it might make some sense if it always left the tree in a clean state,\n> but it no longer makes sense given -p and how it can leave the tree in a\n> not clean state.\n\nYou are misunderstanding. The intended workflow is:\n\n stash -p\n # ... test the remaining changes in isolation ...\n commit -a\n # now the worktree is clean\n stash pop\n\n-- Hannes\n"},{"id":"189241","messageId":"20120414042713.GA13889@inner.h.iocl.org","threadId":"30197","inReplyTo":"4F84F39B.6070907@ubuntu.com","subject":"Re: stash refuses to pop","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2012-04-14T04:27:13Z","receivedAt":"2012-04-14T04:27:13Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Tue, 10 Apr 2012 22:59:39 +0000, Phillip Susi wrote:\n...\n> Yes, there are a number of ways you can get to the situation where you can not pop the stash. How to resolve this is unclear from the results of the failed pop. I finally ended up resolving it by committing the remaining changes, then popping the stash ( which performed the merge successfully ), and finally doing a git reset HEAD~1 to remove the temporary commit, but preserve the merged results. This seemed like a good deal of unnecessary trouble.\n\n(Late to the game.) Actually, this is exactly what I would have proposed\nto do. Git is a bit shy on performing a merge into a locally modified\nfile. I assumed so far that is because there is no way of aborting\nsuch a merge (resetting to the state of local modifications before the\nattempt). With the temporary commit you have a way of retrying the pop\nmerge if you lost your way in it.\n\nAnd I think that is a good idea; I never liked the way in which a cvs/svn\nupdate merged into locally modified files without a way to undo, and\nthus forcing you to clean up the potential mess manually. (Ok, they leave\nthe old files lying arond, but that doesn't help rewinding the state.)\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"189255","messageId":"m3pqbaaaga.fsf@localhost.localdomain","threadId":"30197","inReplyTo":"20120414042713.GA13889@inner.h.iocl.org","subject":"Re: stash refuses to pop","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-04-14T10:12:43Z","receivedAt":"2012-04-14T10:12:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Krey writes:\n> On Tue, 10 Apr 2012 22:59:39 +0000, Phillip Susi wrote:\n> ...\n> > Yes, there are a number of ways you can get to the situation where\n> > you can not pop the stash. How to resolve this is unclear from\n> > the results of the failed pop. I finally ended up resolving it by\n> > committing the remaining changes, then popping the stash ( which\n> > performed the merge successfully ), and finally doing a git reset\n> > HEAD~1 to remove the temporary commit, but preserve the merged\n> > results. This seemed like a good deal of unnecessary trouble.\n> \n> (Late to the game.) Actually, this is exactly what I would have proposed\n> to do. Git is a bit shy on performing a merge into a locally modified\n> file. I assumed so far that is because there is no way of aborting\n> such a merge (resetting to the state of local modifications before the\n> attempt). With the temporary commit you have a way of retrying the pop\n> merge if you lost your way in it.\n\nIt would be nice if a.) git gave this advice when unable to \"git stash pop\"\n(or \"git stash apply\") for newbie users, and b.) this solution was put\nin documentation including git-stash(1) manpage.\n \n> And I think that is a good idea; I never liked the way in which a cvs/svn\n> update merged into locally modified files without a way to undo, and\n> thus forcing you to clean up the potential mess manually. (Ok, they leave\n> the old files lying arond, but that doesn't help rewinding the state.)\n\nBTW. I sometimes wonder if Mercurial's transaction-based approach\nisn't a superior solution...\n\n> Andreas\n> \n> -- \n> \"Totally trivial. Famous last words.\"\n> From: Linus Torvalds \n> Date: Fri, 22 Jan 2010 07:29:21 -0800\n\n-- \nJakub Narebski\n"},{"id":"189367","messageId":"4F8B760D.6030207@ubuntu.com","threadId":"30197","inReplyTo":"20120414042713.GA13889@inner.h.iocl.org","subject":"Re: stash refuses to pop","fromName":"Phillip Susi","fromEmail":"psusi@ubuntu.com","sentAt":"2012-04-16T01:29:49Z","receivedAt":"2012-04-16T01:29:49Z","isPatch":false,"sender":{"key":"psusi@ubuntu.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nOn 04/14/2012 12:27 AM, Andreas Krey wrote:\n> (Late to the game.) Actually, this is exactly what I would have proposed\n> to do. Git is a bit shy on performing a merge into a locally modified\n> file. I assumed so far that is because there is no way of aborting\n> such a merge (resetting to the state of local modifications before the\n> attempt). With the temporary commit you have a way of retrying the pop\n> merge if you lost your way in it.\n> \n> And I think that is a good idea; I never liked the way in which a cvs/svn\n> update merged into locally modified files without a way to undo, and\n> thus forcing you to clean up the potential mess manually. (Ok, they leave\n> the old files lying arond, but that doesn't help rewinding the state.)\n\nThat makes sense for the default behavior, but there should be a way to override. Or maybe git could automatically stash the current state to a temporary commit before applying the requested stash and print the sha1 of that commit ( or save it as ORIG_HEAD ) so you could undo the stash pop/apply.\n\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.11 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\n\niQEcBAEBAgAGBQJPi3YKAAoJEJrBOlT6nu75OXAH+gK4pfFomFgblw1sLb9Bpgud\n0O88dtWWOr9/bNR6NIiIWj76x+xMiRMxuq2YP3/6vkuhGAtVxYqoHc/BkWUmzop/\noma30g244H17Oa0r9H0yf6n6v824xv3tVx166cQ0pVeBnnFs1GINxjODuD0QGTnH\nVewepnyaYkPRSjgzrJShOadaxRZFZWUBNlncLbHMLBNJl+n4cMXsg9uasEv3rG73\nMw+zAKcMMf4zCfxE0T2dpbf0hOOde8PWtJY12RAYWvhn7YTVP9Uj+t3a9flb2UyB\nzuo84Xv49meMB9ce4DDtANXeH8uKamBGk94NH6Khv6LewuG5SOS7DukDEJxA+B0=\n=xaNu\n-----END PGP SIGNATURE-----\n"}]}