# stash refuses to pop 12 messages from 2012-04-10 to 2012-04-16. Participants: Phillip Susi, Junio C Hamano, Andrew Ardill, Johannes Sixt, Victor Engmark, Andreas Krey, Jakub Narebski. Thread: https://gitlist.dev/t/30197 ## Phillip Susi, 2012-04-10 17:52 Subject: stash refuses to pop Message-ID: <4F847350.3000409@ubuntu.com> URL: https://gitlist.dev/e/4F847350.3000409%40ubuntu.com ``` git stash refuses to apply a stash if it touches files that are modified. Using stash -p to selectively stash some hunks of a file and then immediately trying to pop that stash causes this failure every time. This seems incredibly broken, and there does not seem to be a force switch. How can you get the stash applied? ``` ## Junio C Hamano, 2012-04-10 18:05 Subject: Re: stash refuses to pop Message-ID: <7vpqbfpim2.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vpqbfpim2.fsf%40alter.siamese.dyndns.org In-Reply-To: <4F847350.3000409@ubuntu.com> ``` Phillip Susi writes: > git stash refuses to apply a stash if it touches files that are > modified. Using stash -p to selectively stash some hunks of a file > and then immediately trying to pop that stash causes this failure > every time. I think that is by design. I do not use "stash -p" and personally, but I think its broken from the UI point of view. The point of "stash" is to clear your workspace to a pristine state, do random things, and after you are done and cleared your workspace again, apply it to come back to the original state or a state as if you started your WIP from the updated clean-slate. So probably the right way to use "stash -p" (if there were such a thing) would be to stash away the remainder in a separate stash with another "stash" without "-p" (which will clear your workspace to a pristine state) and then pop the one you created with "stash -p", I think. ``` ## Phillip Susi, 2012-04-10 18:56 Subject: Re: stash refuses to pop Message-ID: <4F84827B.80104@ubuntu.com> URL: https://gitlist.dev/e/4F84827B.80104%40ubuntu.com In-Reply-To: <7vpqbfpim2.fsf@alter.siamese.dyndns.org> ``` On 4/10/2012 2:05 PM, Junio C Hamano wrote: > Phillip Susi writes: > >> git stash refuses to apply a stash if it touches files that are >> modified. Using stash -p to selectively stash some hunks of a file >> and then immediately trying to pop that stash causes this failure >> every time. > > I think that is by design. Being able to push something that you can not pop seems to be broken design... > I do not use "stash -p" and personally, but I think its broken from the UI > point of view. The point of "stash" is to clear your workspace to a > pristine state, do random things, and after you are done and cleared your > workspace again, apply it to come back to the original state or a state as > if you started your WIP from the updated clean-slate. Or temporarily undo some changes and come back to those changes later? > So probably the right way to use "stash -p" (if there were such a thing) > would be to stash away the remainder in a separate stash with another > "stash" without "-p" (which will clear your workspace to a pristine state) > and then pop the one you created with "stash -p", I think. That would not get you back to the state you were in when you first stashed, but instead to a state where you have the first set of changes, but not the second ( which you then also can not pop due to the first changes being there ). ``` ## Andrew Ardill, 2012-04-11 02:47 Subject: Re: stash refuses to pop Message-ID: URL: https://gitlist.dev/e/CAH5451%3D0KvUPB77hKyjFVXRwPfEZ8%2B45b20SimBPmuF-gq_A3w%40mail.gmail.com In-Reply-To: <4F84827B.80104@ubuntu.com> ``` On 11 April 2012 04:56, Phillip Susi wrote: > On 4/10/2012 2:05 PM, Junio C Hamano wrote: >> >> Phillip Susi  writes: >> >>> git stash refuses to apply a stash if it touches files that are >>> modified.  Using stash -p to selectively stash some hunks of a file >>> and then immediately trying to pop that stash causes this failure >>> every time. >> >> >> I think that is by design. > > > Being able to push something that you can not pop seems to be broken > design... > > >> I do not use "stash -p" and personally, but I think its broken from the UI >> point of view.  The point of "stash" is to clear your workspace to a >> pristine state, do random things, and after you are done and cleared your >> workspace again, apply it to come back to the original state or a state as >> if you started your WIP from the updated clean-slate. > > > Or temporarily undo some changes and come back to those changes later? > > >> So probably the right way to use "stash -p" (if there were such a thing) >> would be to stash away the remainder in a separate stash with another >> "stash" without "-p" (which will clear your workspace to a pristine state) >> and then pop the one you created with "stash -p", I think. > > > That would not get you back to the state you were in when you first stashed, > but instead to a state where you have the first set of changes, but not the > second ( which you then also can not pop due to the first changes being > there ). The first question, it would seem, is what should git do when there are modified files present, and the user tries to pop a stash which touches those files. The current behaviour is to reject the pop, reasonable enough, though for what exact reason I am not sure (potential merge issues, I assume). The method you have described is just one way of coming on this situation. The user could have * stashed their work, modified some files and tried to pop * partially stashed their work, and tried to pop * partially stashed their work, modified some files and then tried to pop. The options for dealing with this situation seem to be 1. Reject the pop outright 2. put the affected files into a merge conflict state 3. revert the file to the state they were at at the time of stash 4. reject those files that do not apply cleanly (but apply all others) 5. reject those hunks which do not apply cleanly (but apply all others) 6. provide an interactive pop session for choosing what to apply I don't know if all of these are possible/feasible/reasonable. 1. possible by # git reset 2. default behaviour 3. is possible using # git stash branch [] 4. 5. seems this might be possible, not sure of best method 6. this would be something like # git stash pop -p [], which I think does not exist yet I would like to see 6. implemented, but the behaviour seems very reasonable at the moment. Regards, Andrew Ardill ``` ## Phillip Susi, 2012-04-11 02:59 Subject: Re: stash refuses to pop Message-ID: <4F84F39B.6070907@ubuntu.com> URL: https://gitlist.dev/e/4F84F39B.6070907%40ubuntu.com In-Reply-To: ``` -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/10/2012 10:47 PM, Andrew Ardill wrote: > The first question, it would seem, is what should git do when there > are modified files present, and the user tries to pop a stash which > touches those files. The current behaviour is to reject the pop, > reasonable enough, though for what exact reason I am not sure > (potential merge issues, I assume). Since pop is the inverse of push, and merge is the inverse of a partial push, I would expect pop to perform a merge. > The method you have described is just one way of coming on this > situation. The user could have > * stashed their work, modified some files and tried to pop > * partially stashed their work, and tried to pop > * partially stashed their work, modified some files and then tried to pop. 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhPObAAoJEJrBOlT6nu75qwkH/jlWpu+yRIx9l8qsp4+MWB/I FPfKku+LnUpRoegsmKMer1J59kriw8zJF8hujHUUp1RcCdfQBUJwCDZnNGEa/LRn PNrceRHc3V92ImBBJHwLsOqr4IQa7O+PDG8Tuht6q6NwIxEu2ZycoxnThx7JoF/G wsD5KA9yZmJKb+lptCNVVfgez4k6ESqnekx4Tsl8C5UOUXbra61SC6vG+igRnU2P 6V+QaYbHEmNNq3pLmebCty/wmzwHJc9oTA+wDawJwV5BhcgsKnUY0RhVMT86t1Qu IbwqkFUJV9je1GZKEwklvbLnBx2js80yvEnPWpC3jt9j6gxRGAfaq/5NQnl7vQE= =UEM3 -----END PGP SIGNATURE----- ``` ## Johannes Sixt, 2012-04-11 05:58 Subject: Re: stash refuses to pop Message-ID: <4F851D8A.4000501@viscovery.net> URL: https://gitlist.dev/e/4F851D8A.4000501%40viscovery.net In-Reply-To: <4F84827B.80104@ubuntu.com> ``` Am 4/10/2012 20:56, schrieb Phillip Susi: > On 4/10/2012 2:05 PM, Junio C Hamano wrote: >> Phillip Susi writes: >> >>> git stash refuses to apply a stash if it touches files that are >>> modified. Using stash -p to selectively stash some hunks of a file >>> and then immediately trying to pop that stash causes this failure >>> every time. >> >> I think that is by design. > > Being able to push something that you can not pop seems to be broken > design... You are trying to abuse git-stash, but it does not cooperate because it was not designed to be abused ;-) git-stash is not intended as a generic push-and-pop-my-changes work horse. The purpose of git-stash is that you can "move away" - all of your changes to have a clean worktree or - part of your changes to _create a clean worktree from the remaining changes_. That is, before you can think of applying a stash, you are expected to have cleaned out your worktree. -- Hannes ``` ## Victor Engmark, 2012-04-11 07:15 Subject: Re: stash refuses to pop Message-ID: URL: https://gitlist.dev/e/CAA5Ydx9CTKdm-3OPM1s424d%3DPAi18MtpfhNXxdDw%3D44VQBXtGQ%40mail.gmail.com In-Reply-To: ``` On Wed, Apr 11, 2012 at 4:47 AM, Andrew Ardill wrote: > > On 11 April 2012 04:56, Phillip Susi wrote: > > On 4/10/2012 2:05 PM, Junio C Hamano wrote: > >> So probably the right way to use "stash -p" (if there were such a thing) > >> would be to stash away the remainder in a separate stash with another > >> "stash" without "-p" (which will clear your workspace to a pristine state) > >> and then pop the one you created with "stash -p", I think. > > > > That would not get you back to the state you were in when you first stashed, > > but instead to a state where you have the first set of changes, but not the > > second ( which you then also can not pop due to the first changes being > > there ). > > The first question, it would seem, is what should git do when there > are modified files present, and the user tries to pop a stash which > touches those files. The current behaviour is to reject the pop, > reasonable enough, though for what exact reason I am not sure > (potential merge issues, I assume). > > The method you have described is just one way of coming on this > situation. The user could have > * stashed their work, modified some files and tried to pop > * partially stashed their work, and tried to pop > * partially stashed their work, modified some files and then tried to pop. > > The options for dealing with this situation seem to be > 1. Reject the pop outright > 2. put the affected files into a merge conflict state > 3. revert the file to the state they were at at the time of stash > 4. reject those files that do not apply cleanly (but apply all others) > 5. reject those hunks which do not apply cleanly (but apply all others) > 6. provide an interactive pop session for choosing what to apply #2 seems like the most natural option, for the reason Phillip Susi mentioned. But how about 7. Apply all hunks iff all of them can be applied cleanly ? That way pop would be an atomic operation. It might be easier to do than 2, and even if 2 is implemented it would be nice to have a --atomic or --dry-run option when you want to make sure not to end up in a messy merge. Cheers, V ``` ## Phillip Susi, 2012-04-11 14:21 Subject: Re: stash refuses to pop Message-ID: <4F859353.4070700@ubuntu.com> URL: https://gitlist.dev/e/4F859353.4070700%40ubuntu.com In-Reply-To: <4F851D8A.4000501@viscovery.net> ``` On 4/11/2012 1:58 AM, Johannes Sixt wrote: > You are trying to abuse git-stash, but it does not cooperate because it > was not designed to be abused ;-) git-stash is not intended as a generic > push-and-pop-my-changes work horse. In what way is using the documented -p switch abuse? > The purpose of git-stash is that you can "move away" Yes, and then move back. That is why it is broken that you can not immediately move back after a stash -p. > - all of your changes to have a clean worktree or > - part of your changes to _create a clean worktree from the remaining > changes_. > > That is, before you can think of applying a stash, you are expected to > have cleaned out your worktree. It is obvious that is the assumption that stash was originally made with, and it might make some sense if it always left the tree in a clean state, but it no longer makes sense given -p and how it can leave the tree in a not clean state. This is clearly a case of the initial implementation being a bit lazy. pop already performs a type of merge, just on a whole file basis. In other words, the pop leaves you with some files from before the pop, and some files that were modified by the pop. It should do a proper merge instead of a lazy whole file merge. ``` ## Johannes Sixt, 2012-04-12 05:50 Subject: Re: stash refuses to pop Message-ID: <4F866D0D.7070904@viscovery.net> URL: https://gitlist.dev/e/4F866D0D.7070904%40viscovery.net In-Reply-To: <4F859353.4070700@ubuntu.com> ``` Am 4/11/2012 16:21, schrieb Phillip Susi: > On 4/11/2012 1:58 AM, Johannes Sixt wrote: >> You are trying to abuse git-stash, but it does not cooperate because it >> was not designed to be abused ;-) git-stash is not intended as a generic >> push-and-pop-my-changes work horse. > > In what way is using the documented -p switch abuse? It isn't. >> The purpose of git-stash is that you can "move away" > > Yes, and then move back. This is abuse, if you haven't cleaned your worktree. >> That is, before you can think of applying a stash, you are expected to >> have cleaned out your worktree. > > It is obvious that is the assumption that stash was originally made with, > and it might make some sense if it always left the tree in a clean state, > but it no longer makes sense given -p and how it can leave the tree in a > not clean state. You are misunderstanding. The intended workflow is: stash -p # ... test the remaining changes in isolation ... commit -a # now the worktree is clean stash pop -- Hannes ``` ## Andreas Krey, 2012-04-14 04:27 Subject: Re: stash refuses to pop Message-ID: <20120414042713.GA13889@inner.h.iocl.org> URL: https://gitlist.dev/e/20120414042713.GA13889%40inner.h.iocl.org In-Reply-To: <4F84F39B.6070907@ubuntu.com> ``` On Tue, 10 Apr 2012 22:59:39 +0000, Phillip Susi wrote: ... > 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. (Late to the game.) Actually, this is exactly what I would have proposed to do. Git is a bit shy on performing a merge into a locally modified file. I assumed so far that is because there is no way of aborting such a merge (resetting to the state of local modifications before the attempt). With the temporary commit you have a way of retrying the pop merge if you lost your way in it. And I think that is a good idea; I never liked the way in which a cvs/svn update merged into locally modified files without a way to undo, and thus forcing you to clean up the potential mess manually. (Ok, they leave the old files lying arond, but that doesn't help rewinding the state.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 ``` ## Jakub Narebski, 2012-04-14 10:12 Subject: Re: stash refuses to pop Message-ID: URL: https://gitlist.dev/e/m3pqbaaaga.fsf%40localhost.localdomain In-Reply-To: <20120414042713.GA13889@inner.h.iocl.org> ``` Andreas Krey writes: > On Tue, 10 Apr 2012 22:59:39 +0000, Phillip Susi wrote: > ... > > 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. > > (Late to the game.) Actually, this is exactly what I would have proposed > to do. Git is a bit shy on performing a merge into a locally modified > file. I assumed so far that is because there is no way of aborting > such a merge (resetting to the state of local modifications before the > attempt). With the temporary commit you have a way of retrying the pop > merge if you lost your way in it. It would be nice if a.) git gave this advice when unable to "git stash pop" (or "git stash apply") for newbie users, and b.) this solution was put in documentation including git-stash(1) manpage. > And I think that is a good idea; I never liked the way in which a cvs/svn > update merged into locally modified files without a way to undo, and > thus forcing you to clean up the potential mess manually. (Ok, they leave > the old files lying arond, but that doesn't help rewinding the state.) BTW. I sometimes wonder if Mercurial's transaction-based approach isn't a superior solution... > Andreas > > -- > "Totally trivial. Famous last words." > From: Linus Torvalds > Date: Fri, 22 Jan 2010 07:29:21 -0800 -- Jakub Narebski ``` ## Phillip Susi, 2012-04-16 01:29 Subject: Re: stash refuses to pop Message-ID: <4F8B760D.6030207@ubuntu.com> URL: https://gitlist.dev/e/4F8B760D.6030207%40ubuntu.com In-Reply-To: <20120414042713.GA13889@inner.h.iocl.org> ``` -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/14/2012 12:27 AM, Andreas Krey wrote: > (Late to the game.) Actually, this is exactly what I would have proposed > to do. Git is a bit shy on performing a merge into a locally modified > file. I assumed so far that is because there is no way of aborting > such a merge (resetting to the state of local modifications before the > attempt). With the temporary commit you have a way of retrying the pop > merge if you lost your way in it. > > And I think that is a good idea; I never liked the way in which a cvs/svn > update merged into locally modified files without a way to undo, and > thus forcing you to clean up the potential mess manually. (Ok, they leave > the old files lying arond, but that doesn't help rewinding the state.) That 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPi3YKAAoJEJrBOlT6nu75OXAH+gK4pfFomFgblw1sLb9Bpgud 0O88dtWWOr9/bNR6NIiIWj76x+xMiRMxuq2YP3/6vkuhGAtVxYqoHc/BkWUmzop/ oma30g244H17Oa0r9H0yf6n6v824xv3tVx166cQ0pVeBnnFs1GINxjODuD0QGTnH VewepnyaYkPRSjgzrJShOadaxRZFZWUBNlncLbHMLBNJl+n4cMXsg9uasEv3rG73 Mw+zAKcMMf4zCfxE0T2dpbf0hOOde8PWtJY12RAYWvhn7YTVP9Uj+t3a9flb2UyB zuo84Xv49meMB9ce4DDtANXeH8uKamBGk94NH6Khv6LewuG5SOS7DukDEJxA+B0= =xaNu -----END PGP SIGNATURE----- ```