stash refuses to pop
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?
Quoted 4 lines · Phillip Susi
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.
Quoted 8 lines · Junio C Hamano
Quoted 4 lines · Phillip Susi
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...
Quoted 5 lines
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?
Quoted 4 lines
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 ).
Am 4/10/2012 20:56, schrieb Phillip Susi:
Quoted 8 lines · Junio C Hamano
Quoted 7 lines
Quoted 4 lines · Phillip Susi
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.
Quoted 4 lines
Quoted 1 line
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
Quoted 3 lines · Johannes Sixt
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?
Quoted 1 line
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.
Quoted 6 lines
- all of your changes to have a clean worktree or
- part of your changes to_createa clean worktree from the remainingchanges_.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.
Am 4/11/2012 16:21, schrieb Phillip Susi:
Quoted 6 lines · Johannes Sixt
Quoted 3 lines
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.
Quoted 3 lines
Quoted 1 line
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.
Quoted 7 lines
Quoted 2 lines
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
Quoted 33 lines · Phillip Susi
Quoted 10 lines · Junio C Hamano
Quoted 4 lines · Phillip Susi
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...
Quoted 5 lines
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?
Quoted 4 lines
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.
Quoted 4 lines
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 <branchname> [<stash>]
4. 5. seems this might be possible, not sure of best method
6. this would be something like # git stash pop -p [<stash>], 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 5 lines · Andrew Ardill
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.
Quoted 5 lines
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-----
On Tue, 10 Apr 2012 22:59:39 +0000, Phillip Susi wrote:
...
Quoted 1 line
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
Signature · 3 lines
"Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
Quoted 10 lines · Andreas Krey
On Tue, 10 Apr 2012 22:59:39 +0000, Phillip Susi wrote:
...Quoted 7 lines
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.
Quoted 6 lines
(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.
Quoted 4 lines
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...
Quoted 6 lines
Andreas
Signature · 3 lines
"Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
Signature · 1 line
Jakub Narebski
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 11 lines · Andreas Krey
(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-----
Quoted 25 lines · Andrew Ardill
Quoted 10 lines · Phillip Susi
Quoted 4 lines · Junio C Hamano
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.
Quoted 7 lines
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