{"thread":{"id":"40045","subject":"Feature: git stash pop --always-drop","startedAt":"2015-08-10T10:42:30Z","lastAt":"2015-08-10T15:16:42Z","messageCount":9,"participants":["Ed Avis","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"267747","messageId":"loom.20150810T124037-407@post.gmane.org","threadId":"40045","inReplyTo":null,"subject":"Feature: git stash pop --always-drop","fromName":"Ed Avis","fromEmail":"eda@waniasset.com","sentAt":"2015-08-10T10:42:30Z","receivedAt":"2015-08-10T10:42:30Z","isPatch":false,"sender":{"key":"eda@waniasset.com","avatar":null},"body":"I would find it useful to ask 'git stash pop' to always drop the stash after\napplying it to the working tree, even if there were conflicts. (Only if there\nwas some hard error, such as an I/O error updating some of the files, should\nthe stash be left on the stack.)\n\nWould a patch for such an --always-drop flag be accepted?\n\n-- \nEd Avis \n"},{"id":"267754","messageId":"20150810124125.GC32371@sigill.intra.peff.net","threadId":"40045","inReplyTo":"loom.20150810T124037-407@post.gmane.org","subject":"Re: Feature: git stash pop --always-drop","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-08-10T12:41:25Z","receivedAt":"2015-08-10T12:41:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 10, 2015 at 10:42:30AM +0000, Ed Avis wrote:\n\n> I would find it useful to ask 'git stash pop' to always drop the stash after\n> applying it to the working tree, even if there were conflicts. (Only if there\n> was some hard error, such as an I/O error updating some of the files, should\n> the stash be left on the stack.)\n\nHmm. That seems rather dangerous, but hey, if it's not the default, I\nguess it is your own foot that you are shooting.\n\n> Would a patch for such an --always-drop flag be accepted?\n\nI doubt you will get a good answer to that question; the attitude here\nis usually \"well, we would have to see the patch\". For instance, I don't\nknow how easy it will be to tell merge conflicts apart from I/O errors.\nFiguring that out will probably be part of a rough draft patch.\n\n-Peff\n"},{"id":"267755","messageId":"loom.20150810T144849-152@post.gmane.org","threadId":"40045","inReplyTo":"20150810124125.GC32371@sigill.intra.peff.net","subject":"Re: Feature: git stash pop --always-drop","fromName":"Ed Avis","fromEmail":"eda@waniasset.com","sentAt":"2015-08-10T12:50:51Z","receivedAt":"2015-08-10T12:50:51Z","isPatch":false,"sender":{"key":"eda@waniasset.com","avatar":null},"body":"An alternative would be for git stash to always print the name of the stash\nit is applying. Then you can drop it afterwards by name and be sure you got\nthe right one. Printing the name of the stash sounds like a reasonable\nbit of chatter to add anyway, do you agree?\n\n-- \nEd Avis \n"},{"id":"267757","messageId":"20150810133220.GA3559@sigill.intra.peff.net","threadId":"40045","inReplyTo":"loom.20150810T144849-152@post.gmane.org","subject":"Re: Feature: git stash pop --always-drop","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-08-10T13:32:21Z","receivedAt":"2015-08-10T13:32:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 10, 2015 at 12:50:51PM +0000, Ed Avis wrote:\n\n> An alternative would be for git stash to always print the name of the stash\n> it is applying. Then you can drop it afterwards by name and be sure you got\n> the right one. Printing the name of the stash sounds like a reasonable\n> bit of chatter to add anyway, do you agree?\n\nYeah, I agree that makes sense. We already show something like:\n\n Dropped refs/stash@{0} (31cb86c3d700d241e315d989f460e3e83f84fa19)\n\nwhen dropping. Perhaps model the message after that:\n\n Applying refs/stash@{0} (31cb86c3d700d241e315d989f460e3e83f84fa19)\n\nOr maybe it would be useful to actually show the stash subject, though\nthe defaults are not very informative (just \"WIP on master\", and then\nsome totally irrelevant commit subject).\n\n-Peff\n"},{"id":"267759","messageId":"loom.20150810T153939-856@post.gmane.org","threadId":"40045","inReplyTo":"20150810133220.GA3559@sigill.intra.peff.net","subject":"Re: Feature: git stash pop --always-drop","fromName":"Ed Avis","fromEmail":"eda@waniasset.com","sentAt":"2015-08-10T13:43:07Z","receivedAt":"2015-08-10T13:43:07Z","isPatch":false,"sender":{"key":"eda@waniasset.com","avatar":null},"body":"Jeff King peff.net> writes:\n\n>>An alternative would be for git stash to always print the name of the stash\n>>it is applying.\n\n> Applying refs/stash@{0} (31cb86c3d700d241e315d989f460e3e83f84fa19)\n\nYes, that's the one.\n\n>Or maybe it would be useful to actually show the stash subject,\n\nThat could be nice to see, but is not a substitute for the SHA.\n\nIf the stash pop failed because of conflicts then it could even print\n\n To drop this stash manually, run 'git stash drop abcde...'\n\nAnother feature I would like to see is a kind of atomic stash apply, where\neither the whole change can be applied to the working tree without conflicts,\nor nothing happens.\n\n-- \nEd Avis \n"},{"id":"267761","messageId":"20150810134957.GC6763@sigill.intra.peff.net","threadId":"40045","inReplyTo":"loom.20150810T153939-856@post.gmane.org","subject":"Re: Feature: git stash pop --always-drop","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-08-10T13:49:58Z","receivedAt":"2015-08-10T13:49:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 10, 2015 at 01:43:07PM +0000, Ed Avis wrote:\n\n> Jeff King peff.net> writes:\n> \n> >>An alternative would be for git stash to always print the name of the stash\n> >>it is applying.\n> \n> > Applying refs/stash@{0} (31cb86c3d700d241e315d989f460e3e83f84fa19)\n> \n> Yes, that's the one.\n> \n> >Or maybe it would be useful to actually show the stash subject,\n> \n> That could be nice to see, but is not a substitute for the SHA.\n\nI think you'd be _technically_ OK without the sha1 in the \"applying\nmessage\", because you can refer to it as stash@{0} until it is dropped,\nand the drop message does mention the sha1. But that seems needlessly\ncomplicated for the user. I agree that including the sha1 is reasonable\n(though we might want to use an abbreviated one if there is other stuff\nto go on the line).\n\n> If the stash pop failed because of conflicts then it could even print\n> \n> To drop this stash manually, run 'git stash drop abcde...'\n\nYup, that makes sense. You might want to make it optional an advice.*\nconfig key, though. I also wondered if the \"dropped\" message is\nsufficiently clear to new users. The point of it, I think, is to allow a\nfinal \"oops, I didn't mean to do that\" moment. But there are no\ninstructions for how one would re-create the same stash.\n\nIt might be that showing instructions on even successful drops would\nquickly get annoying, though. I dunno. I tend to turn off most of our\nadvice config myself.\n\n> Another feature I would like to see is a kind of atomic stash apply, where\n> either the whole change can be applied to the working tree without conflicts,\n> or nothing happens.\n\nI think that may be a bit harder, as the merge machinery would have to\nknow how to be atomic. Still, I agree it's a good goal if you'd like to\nwork on it.\n\n-Peff\n"},{"id":"267762","messageId":"loom.20150810T155117-978@post.gmane.org","threadId":"40045","inReplyTo":"20150810134957.GC6763@sigill.intra.peff.net","subject":"Re: Feature: git stash pop --always-drop","fromName":"Ed Avis","fromEmail":"eda@waniasset.com","sentAt":"2015-08-10T14:01:23Z","receivedAt":"2015-08-10T14:01:23Z","isPatch":false,"sender":{"key":"eda@waniasset.com","avatar":null},"body":">\nYes, my use case is that I get confused about whether the stash has been\ndropped or not and whether I might have stashed something else in the\nmeantime. So for me plain 'git stash drop' feels a bit dangerous.\n\nJeff King peff.net> writes:\n\n>I also wondered if the \"dropped\" message is\n>sufficiently clear to new users. The point of it, I think, is to allow a\n>final \"oops, I didn't mean to do that\" moment. But there are no\n>instructions for how one would re-create the same stash.\n\nRight - myself I didn't even realize that recreating the stash was possible\n(though I was vaguely aware that old stashes float around somewhere until\nthey are garbage collected many months later).\n\ngit stash is a relatively infrequent operation and quite exotic, so it\nwouldn't hurt to add lots of chatter to it.\n\n>>Another feature I would like to see is a kind of atomic stash apply, \n\n>I think that may be a bit harder, as the merge machinery would have to\n>know how to be atomic.\n\nIf git merge-recursive had a --dry-run flag that might take care of it.\n\n-- \nEd Avis \n"},{"id":"267764","messageId":"xmqqzj1zuqod.fsf@gitster.dls.corp.google.com","threadId":"40045","inReplyTo":"loom.20150810T155117-978@post.gmane.org","subject":"Re: Feature: git stash pop --always-drop","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-08-10T15:08:34Z","receivedAt":"2015-08-10T15:08:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ed Avis writes:\n\n> Yes, my use case is that I get confused about whether the stash has been\n> dropped or not and whether I might have stashed something else in the\n> meantime. So for me plain 'git stash drop' feels a bit dangerous.\n\nThen \"git stash apply\" followed by \"git stash drop\" would be a pair\nof good workflow elements for you, no?\n"},{"id":"267765","messageId":"loom.20150810T171010-455@post.gmane.org","threadId":"40045","inReplyTo":"xmqqzj1zuqod.fsf@gitster.dls.corp.google.com","subject":"Re: Feature: git stash pop --always-drop","fromName":"Ed Avis","fromEmail":"eda@waniasset.com","sentAt":"2015-08-10T15:16:42Z","receivedAt":"2015-08-10T15:16:42Z","isPatch":false,"sender":{"key":"eda@waniasset.com","avatar":null},"body":"Junio C Hamano pobox.com> writes:\n \n>>Yes, my use case is that I get confused about whether the stash has been\n>>dropped or not and whether I might have stashed something else in the\n>>meantime. So for me plain 'git stash drop' feels a bit dangerous.\n>\n>Then \"git stash apply\" followed by \"git stash drop\" would be a pair\n>of good workflow elements for you, no?\n\nI like ordinary 'git stash pop' when it applies cleanly. Only in the cases\nwhere it has conflicts and leaves the stash in place does it get a bit\nawkward. I manually resolve the conflicts and then 'git stash drop', but\nthat last step is a bit dangerous because it might drop an unrelated stash\nif I have done some other stashing in the meantime.\n\nIf 'git stash pop' (and 'apply') would always print the name of the stash,\nthen it would be easy to drop that particular stash afterwards. Running\none too many or one too few 'git stash drop' commands would no longer cause\nproblems.\n\nPrinting the name of the stash would, for me, largely remove the need for\nan --always-drop option to git stash, which is what I at first suggested.\n\n-- \nEd Avis \n"}]}