{"thread":{"id":"35945","subject":"`git stash pop` UX Problem","startedAt":"2014-02-24T08:32:21Z","lastAt":"2014-03-01T08:47:44Z","messageCount":46,"participants":["Omar Othman","Brandon McCaig","Matthieu Moy","Holger Hellmuth","Junio C Hamano","Stephen Leake","brian m. carlson","Simon Ruderich","Stefan Haller","Theodore Ts'o","David Kastrup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"235232","messageId":"530B0395.5030407@booking.com","threadId":"35945","inReplyTo":null,"subject":"`git stash pop` UX Problem","fromName":"Omar Othman","fromEmail":"omar.othman@booking.com","sentAt":"2014-02-24T08:32:21Z","receivedAt":"2014-02-24T08:32:21Z","isPatch":false,"sender":{"key":"omar.othman@booking.com","avatar":null},"body":"Hi there,\n\nI'm fairly new to git and I wanted to ask about a certain behavior that \nI want to fix myself (if you agree with me that it is a misbehavior)... \nsince I've never contributed to open source and it'll be an important \nstep for me to start and get something done.\n\nIn general, whenever something a user \"should\" do, git always tells. So, \nfor example, when things go wrong with a merge, you have the option to \nabort. When you are doing a rebase, git tells you to do git commit \n--amend, and then git rebase --continue... and so on.\n\nThe point is: Because of this, git is expected to always instruct you on \nwhat to do next in a multilevel operation, or instructing you what to do \nwhen an operation has gone wrong.\n\nNow comes the problem. When you do a git stash pop, and a merge conflict \nhappens, git correctly tells you to fix the problems and then git add to \nresolve the conflict. But once that happens, and the internal status of \ngit tells you that there are no more problems (I have a prompt that \ntells me git's internal status), the operation is not culminated by \ndropping the stash reference, which what normally happens automatically \nafter a git stash pop. This has actually confused me for a lot of time, \ntill I ran into a git committer and asked him, and only then were I 100% \nconfident that I did nothing wrong and it is indeed a UX problem. I \nwasted a lot of time to know why the operation is not completed as \nexpected (since I trusted that git just does the right thing), and it \nturned out that it is git's fault.\n\nIf this is accepted, please reply to this email and tell me to start \nworking on it. I've read the Documenation/SubmittingPatches guidelines, \nbut I'll appreciate also telling me where to base my change. My guess is \nmaint, since it's a \"bug\" in the sense of UX.\n\nThanks and sorry for the long email.\n"},{"id":"235240","messageId":"CANUGeEbPrPp8Sa-KEKSxNDWJShdkDBTkQyXv7tDJ6ReH6MXrHw@mail.gmail.com","threadId":"35945","inReplyTo":"530B0395.5030407@booking.com","subject":"Re: `git stash pop` UX Problem","fromName":"Brandon McCaig","fromEmail":"bamccaig@gmail.com","sentAt":"2014-02-24T16:04:25Z","receivedAt":"2014-02-24T16:04:25Z","isPatch":false,"sender":{"key":"bamccaig@gmail.com","avatar":"https://gravatar.com/avatar/05b01f2b62a5ddbaa1946579266a8d9e970fed0c0b3c20e8d42aca973c31531c?d=mp&s=160"},"body":"Omar:\n\nOn Mon, Feb 24, 2014 at 3:32 AM, Omar Othman wrote:\n> In general, whenever something a user \"should\" do, git always tells. So, for\n> example, when things go wrong with a merge, you have the option to abort.\n> When you are doing a rebase, git tells you to do git commit --amend, and\n> then git rebase --continue... and so on.\n>\n> The point is: Because of this, git is expected to always instruct you on\n> what to do next in a multilevel operation, or instructing you what to do\n> when an operation has gone wrong.\n>\n> Now comes the problem. When you do a git stash pop, and a merge conflict\n> happens, git correctly tells you to fix the problems and then git add to\n> resolve the conflict. But once that happens, and the internal status of git\n> tells you that there are no more problems (I have a prompt that tells me\n> git's internal status), the operation is not culminated by dropping the\n> stash reference, which what normally happens automatically after a git stash\n> pop. This has actually confused me for a lot of time, till I ran into a git\n> committer and asked him, and only then were I 100% confident that I did\n> nothing wrong and it is indeed a UX problem. I wasted a lot of time to know\n> why the operation is not completed as expected (since I trusted that git\n> just does the right thing), and it turned out that it is git's fault.\n>\n> If this is accepted, please reply to this email and tell me to start working\n> on it. I've read the Documenation/SubmittingPatches guidelines, but I'll\n> appreciate also telling me where to base my change. My guess is maint, since\n> it's a \"bug\" in the sense of UX.\n\nUnlike a merge, when you pop a stash that history is lost. If you\nscrew up the merge and the stash is dropped then there's generally no\nreliable way to get it back. I think that it's correct behavior for\nthe stash to not be dropped if the merge conflicts. The user is\nexpected to manually drop the stash when they're done with it. It's\nbeen a while since I've relied much on the stash (commits and branches\nare more powerful to work with) so I'm not really familiar with what\nhelp the UI gives when a conflict occurs now. Git's UI never really\nexpects the user to be negligent. It does help to hint to you what is\nneeded, but for the most part it still expects you to know what you're\ndoing and does what you say, not what you mean.\n\nIf there's any change that should be made it should be purely\nproviding more detailed instructions to the user about how to deal\nwith it. Either resolve the merge conflicts and git-add the\nconflicting files, or use git-reset to either reset the index\n(unstaging files nad clear) or reset index and working tree back to\nHEAD. In general, I almost always git-reset after a git-stash pop\nbecause I'm probably not ready to commit those changes yet and\ngenerally want to still see those changes with git diff (without\n--staged). Or perhaps just direct them to the appropriate sections of\nthe man pages.\n\nI'm not really in favor of \"dumbing down\" Git in any way and I think\nthat any step in that direction would be for the worst... Software\nshould do what you say, not what you mean, because it's impossible to\nreliably guess what you meant. When a git-stash pop operation fails\nthat might make the user rethink popping that stash. That's why it\nbecomes a manual operation to drop it if still desired. And unlike\ngit-reset --continue, which is explicitly the user saying \"it is fixed\nand I accept the consequences, let's move on\", there is no such option\nto git-stash to acknowledge that the merge conflicts have been\nresolved and you no longer need that stash (aside from git-stash drop,\nof course). It's not a UI problem. It's maybe a documentation problem,\nbut again I'm not familiar with the current state of that.\n\n/not a git dev...yet\n\nRegards,\n\n\n-- \nBrandon McCaig \nCastopulence Software \nBlog \nperl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.\nq{Vg qbrfa'\\''g nyjnlf fbhaq gung jnl.};\ntr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'\n"},{"id":"235260","messageId":"vpqlhx0a3cb.fsf@anie.imag.fr","threadId":"35945","inReplyTo":"CANUGeEbPrPp8Sa-KEKSxNDWJShdkDBTkQyXv7tDJ6ReH6MXrHw@mail.gmail.com","subject":"Re: `git stash pop` UX Problem","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-02-24T16:21:40Z","receivedAt":"2014-02-24T16:21:40Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Brandon McCaig writes:\n\n> Unlike a merge, when you pop a stash that history is lost. If you\n> screw up the merge and the stash is dropped then there's generally no\n> reliable way to get it back. I think that it's correct behavior for\n> the stash to not be dropped if the merge conflicts.\n\nAgreed.\n\n> If there's any change that should be made it should be purely\n> providing more detailed instructions to the user about how to deal\n> with it.\n\nYes, there may be room for improvement, but that does not seem so easy.\nToday, we have:\n\n$ git stash pop\nAuto-merging foo.txt\nCONFLICT (content): Merge conflict in foo.txt\n\n$ git status\nOn branch master\nUnmerged paths:\n (use \"git reset HEAD ...\" to unstage)\n (use \"git add ...\" to mark resolution)\n\n both modified: foo.txt\n\n=> The advices shown here are OK. Then:\n\n$ git add foo.txt \n$ git status\nOn branch master\nChanges to be committed:\n (use \"git reset HEAD ...\" to unstage)\n\n modified: foo.txt\n\n=> here, \"git status\" could have hinted the user \"you may now run 'git\nstash drop' if you are satisfied with your merge\".\n\nAn obvious issue is that at this point Git has no way to know that you\njust did a \"git stash pop\". But that could be solved by leaving a file\naround like .git/stash-pop-ongoing.\n\nNow, the real question is: when would Git stop showing this advice. I\ndon't see a real way to answer this, and I'd rather avoid doing just a\nguess.\n\nOne easy thing to do OTOH would be to show a hint at the end of \"git\nstash pop\"'s output, like\n\n$ git stash pop\nAuto-merging foo.txt\nCONFLICT (content): Merge conflict in foo.txt\n'stash pop' failed. Please, resolve the conflicts manually. The stash\nwas not dropped in case you need to restart the operation. When you are\ndone resolving the merge, you may run the following to drop the stash:\n\n git stash drop\n\n\nor so (I couldn't find a concise yet accurate wording).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235315","messageId":"530C893D.7000108@ira.uka.de","threadId":"35945","inReplyTo":"vpqlhx0a3cb.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2014-02-25T12:14:53Z","receivedAt":"2014-02-25T12:14:53Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 24.02.2014 17:21, schrieb Matthieu Moy:\n> $ git add foo.txt\n> $ git status\n> On branch master\n> Changes to be committed:\n> (use \"git reset HEAD ...\" to unstage)\n>\n> modified: foo.txt\n\nMaybe status should display a stash count if that count is > 0, as this \nis part of the state of the repo.\n\n$ git status\nOn branch master\nStashes: 1 <----------\nChanges to be committed:\n (use \"git reset HEAD ...\" to unstage)\n\n modified: foo.txt\n\nIt would be in Omars example case a clear message that git kept the \nstash. And generally a reminder that there is still a stash around that \nmight or might not be obsolete.\n"},{"id":"235316","messageId":"vpqzjlf5q2z.fsf@anie.imag.fr","threadId":"35945","inReplyTo":"530C893D.7000108@ira.uka.de","subject":"Re: `git stash pop` UX Problem","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-02-25T12:33:56Z","receivedAt":"2014-02-25T12:33:56Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Holger Hellmuth writes:\n\n> Am 24.02.2014 17:21, schrieb Matthieu Moy:\n>> $ git add foo.txt\n>> $ git status\n>> On branch master\n>> Changes to be committed:\n>> (use \"git reset HEAD ...\" to unstage)\n>>\n>> modified: foo.txt\n>\n> Maybe status should display a stash count if that count is > 0, as\n> this is part of the state of the repo.\n\nMaybe it would help some users, but not me for example. My main use of\n\"git stash\" is a safe replacement for \"git reset --hard\": when I want to\ndiscard changes, but keep them safe just in case.\n\nSo, my stash count is almost always >0, and I don't want to hear about\nit.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235317","messageId":"530C9465.3020201@booking.com","threadId":"35945","inReplyTo":"vpqzjlf5q2z.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"Omar Othman","fromEmail":"omar.othman@booking.com","sentAt":"2014-02-25T13:02:29Z","receivedAt":"2014-02-25T13:02:29Z","isPatch":false,"sender":{"key":"omar.othman@booking.com","avatar":null},"body":"Well, it's called `git stash` and not `git trash`... :-D\n\nThat's your own usage of it, but its main usage is different.\n\nThis is not a solution, but it's better than nothing and I second it.\n\nOn 25-02-14 13:33, Matthieu Moy wrote:\n> Holger Hellmuth writes:\n>\n>> Am 24.02.2014 17:21, schrieb Matthieu Moy:\n>>> $ git add foo.txt\n>>> $ git status\n>>> On branch master\n>>> Changes to be committed:\n>>> (use \"git reset HEAD ...\" to unstage)\n>>>\n>>> modified: foo.txt\n>> Maybe status should display a stash count if that count is > 0, as\n>> this is part of the state of the repo.\n> Maybe it would help some users, but not me for example. My main use of\n> \"git stash\" is a safe replacement for \"git reset --hard\": when I want to\n> discard changes, but keep them safe just in case.\n>\n> So, my stash count is almost always >0, and I don't want to hear about\n> it.\n"},{"id":"235318","messageId":"530C953F.9050805@booking.com","threadId":"35945","inReplyTo":"CANUGeEbPrPp8Sa-KEKSxNDWJShdkDBTkQyXv7tDJ6ReH6MXrHw@mail.gmail.com","subject":"Re: `git stash pop` UX Problem","fromName":"Omar Othman","fromEmail":"omar.othman@booking.com","sentAt":"2014-02-25T13:06:07Z","receivedAt":"2014-02-25T13:06:07Z","isPatch":false,"sender":{"key":"omar.othman@booking.com","avatar":null},"body":"Brandon:\n\nPlease note that what I am asking for is not always dropping the stash, \nbut doing that *only* when the merge conflict is resolved. This is \nsimply getting the whole command to be consistent. If you do `git stash \npop` and it succeeds, the stash reference is dropped. If you do `git \nstash pop` and it succeeds *after resolving the merge conflict*, the \nstash reference is *not* dropped. This is *not* consistent and *is* a \nuser experience problem. I'm not asking about dumbing git down by any means.\n\nOn 24-02-14 17:04, Brandon McCaig wrote:\n> Omar:\n>\n> On Mon, Feb 24, 2014 at 3:32 AM, Omar Othman wrote:\n>> In general, whenever something a user \"should\" do, git always tells. So, for\n>> example, when things go wrong with a merge, you have the option to abort.\n>> When you are doing a rebase, git tells you to do git commit --amend, and\n>> then git rebase --continue... and so on.\n>>\n>> The point is: Because of this, git is expected to always instruct you on\n>> what to do next in a multilevel operation, or instructing you what to do\n>> when an operation has gone wrong.\n>>\n>> Now comes the problem. When you do a git stash pop, and a merge conflict\n>> happens, git correctly tells you to fix the problems and then git add to\n>> resolve the conflict. But once that happens, and the internal status of git\n>> tells you that there are no more problems (I have a prompt that tells me\n>> git's internal status), the operation is not culminated by dropping the\n>> stash reference, which what normally happens automatically after a git stash\n>> pop. This has actually confused me for a lot of time, till I ran into a git\n>> committer and asked him, and only then were I 100% confident that I did\n>> nothing wrong and it is indeed a UX problem. I wasted a lot of time to know\n>> why the operation is not completed as expected (since I trusted that git\n>> just does the right thing), and it turned out that it is git's fault.\n>>\n>> If this is accepted, please reply to this email and tell me to start working\n>> on it. I've read the Documenation/SubmittingPatches guidelines, but I'll\n>> appreciate also telling me where to base my change. My guess is maint, since\n>> it's a \"bug\" in the sense of UX.\n> Unlike a merge, when you pop a stash that history is lost. If you\n> screw up the merge and the stash is dropped then there's generally no\n> reliable way to get it back. I think that it's correct behavior for\n> the stash to not be dropped if the merge conflicts. The user is\n> expected to manually drop the stash when they're done with it. It's\n> been a while since I've relied much on the stash (commits and branches\n> are more powerful to work with) so I'm not really familiar with what\n> help the UI gives when a conflict occurs now. Git's UI never really\n> expects the user to be negligent. It does help to hint to you what is\n> needed, but for the most part it still expects you to know what you're\n> doing and does what you say, not what you mean.\n>\n> If there's any change that should be made it should be purely\n> providing more detailed instructions to the user about how to deal\n> with it. Either resolve the merge conflicts and git-add the\n> conflicting files, or use git-reset to either reset the index\n> (unstaging files nad clear) or reset index and working tree back to\n> HEAD. In general, I almost always git-reset after a git-stash pop\n> because I'm probably not ready to commit those changes yet and\n> generally want to still see those changes with git diff (without\n> --staged). Or perhaps just direct them to the appropriate sections of\n> the man pages.\n>\n> I'm not really in favor of \"dumbing down\" Git in any way and I think\n> that any step in that direction would be for the worst... Software\n> should do what you say, not what you mean, because it's impossible to\n> reliably guess what you meant. When a git-stash pop operation fails\n> that might make the user rethink popping that stash. That's why it\n> becomes a manual operation to drop it if still desired. And unlike\n> git-reset --continue, which is explicitly the user saying \"it is fixed\n> and I accept the consequences, let's move on\", there is no such option\n> to git-stash to acknowledge that the merge conflicts have been\n> resolved and you no longer need that stash (aside from git-stash drop,\n> of course). It's not a UI problem. It's maybe a documentation problem,\n> but again I'm not familiar with the current state of that.\n>\n> /not a git dev...yet\n>\n> Regards,\n>\n>\n"},{"id":"235319","messageId":"vpqlhwz5o58.fsf@anie.imag.fr","threadId":"35945","inReplyTo":"530C953F.9050805@booking.com","subject":"Re: `git stash pop` UX Problem","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-02-25T13:15:47Z","receivedAt":"2014-02-25T13:15:47Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Omar Othman writes:\n\n> Brandon:\n\nPlease, don't top-post on this list. Look how other people answer to\neach other and follow the use.\n\n> Please note that what I am asking for is not always dropping the\n> stash, but doing that *only* when the merge conflict is resolved. This\n> is simply getting the whole command to be consistent. If you do `git\n> stash pop` and it succeeds, the stash reference is dropped. If you do\n> git stash pop` and it succeeds *after resolving the merge conflict*,\n> the stash reference is *not* dropped. This is *not* consistent and\n> *is* a user experience problem. I'm not asking about dumbing git down\n> by any means.\n\nCan you describe precisely what you would expect, e.g. what Git's output\nshould look like after such and such command?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235320","messageId":"530CA4C9.60601@booking.com","threadId":"35945","inReplyTo":"vpqlhwz5o58.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"Omar Othman","fromEmail":"omar.othman@booking.com","sentAt":"2014-02-25T14:12:25Z","receivedAt":"2014-02-25T14:12:25Z","isPatch":false,"sender":{"key":"omar.othman@booking.com","avatar":null},"body":"\n>> Please note that what I am asking for is not always dropping the\n>> stash, but doing that *only* when the merge conflict is resolved. This\n>> is simply getting the whole command to be consistent. If you do `git\n>> stash pop` and it succeeds, the stash reference is dropped. If you do\n>> git stash pop` and it succeeds *after resolving the merge conflict*,\n>> the stash reference is *not* dropped. This is *not* consistent and\n>> *is* a user experience problem. I'm not asking about dumbing git down\n>> by any means.\n> Can you describe precisely what you would expect, e.g. what Git's output\n> should look like after such and such command?\nSure. This is my current command prompt (which shows git's internal status):\n\n[omar_othman main (trunk*)]$\n\nI do a git stash pop, which causes a merge conflict:\n\nAuto-merging path/to/file.txt\nCONFLICT (content): Merge conflict in path/to/file.txt\n\n[omar_othman main (trunk|MERGING*)]$ vi path/to/file.txt\n[omar_othman main (trunk|MERGING*)]$ git add path/to/file.txt\n[omar_othman main (trunk*)]$\n\nNote how the status message has changed to show that git is now happy. \nIt is at that moment that the stash reference should be dropped (or the \nuser (somehow) is notified to do that herself if desired), because this \nmeans that the popping operation has succeeded.\n"},{"id":"235323","messageId":"vpqeh2r43kx.fsf@anie.imag.fr","threadId":"35945","inReplyTo":"530CA4C9.60601@booking.com","subject":"Re: `git stash pop` UX Problem","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-02-25T15:25:18Z","receivedAt":"2014-02-25T15:25:18Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Omar Othman writes:\n\n> [omar_othman main (trunk|MERGING*)]$ git add path/to/file.txt\n> [omar_othman main (trunk*)]$\n>\n> Note how the status message has changed to show that git is now happy.\n> It is at that moment that the stash reference should be dropped\n\nDropping the stash on a \"git add\" operation would be really, really\nweird...\n\n> (or the user (somehow) is notified to do that herself if desired),\n> because this means that the popping operation has succeeded.\n\nBut how would you expect to \"be notified\"?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235331","messageId":"xmqqwqgj57n9.fsf@gitster.dls.corp.google.com","threadId":"35945","inReplyTo":"vpqzjlf5q2z.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-25T19:12:10Z","receivedAt":"2014-02-25T19:12:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Holger Hellmuth writes:\n>\n>> Am 24.02.2014 17:21, schrieb Matthieu Moy:\n>>> $ git add foo.txt\n>>> $ git status\n>>> On branch master\n>>> Changes to be committed:\n>>> (use \"git reset HEAD ...\" to unstage)\n>>>\n>>> modified: foo.txt\n>>\n>> Maybe status should display a stash count if that count is > 0, as\n>> this is part of the state of the repo.\n>\n> Maybe it would help some users, but not me for example. My main use of\n> \"git stash\" is a safe replacement for \"git reset --hard\": when I want to\n> discard changes, but keep them safe just in case.\n>\n> So, my stash count is almost always >0, and I don't want to hear about\n> it.\n\n\"status\" is about reminding the user what changes are already in the\nindex (i.e. what you would commit) and what changes are in the\nworking tree, from which you could further update the index with\n(i.e. what you could commit).\n\nOne _could_ argue that stashed changes are what could be reflected\nto the working tree and form the source of the latter, but my gut\nfeeling is that it is a rather weak argument. At that point you are\ntalking about what you could potentially change in the working tree,\nand the way to do so is not limited to \"stash pop\" (i.e. you can\n\"git cherry-pick --no-commit $a_commit\", or \"edit\" any file in the\nworking tree for that matter, with the same ease).\n\nSo, I tend to agree with you, while I do understand where \"I want to\nknow about what is in stash\" is coming from (and that is why we do\nhave \"git stash list\" command).\n"},{"id":"235335","messageId":"85r46q537a.fsf@stephe-leake.org","threadId":"35945","inReplyTo":"xmqqwqgj57n9.fsf@gitster.dls.corp.google.com","subject":"Re: `git stash pop` UX Problem","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-02-25T20:48:09Z","receivedAt":"2014-02-25T20:48:09Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Junio C Hamano writes:\n\n> \"status\" is about reminding the user what changes are already in the\n> index (i.e. what you would commit) and what changes are in the\n> working tree, from which you could further update the index with\n> (i.e. what you could commit).\n\nI believe \"status\" should tell me everything git knows about the current\nworkspace in a resonably concise way. That includes the stash.\n\n> One _could_ argue that stashed changes are what could be reflected\n> to the working tree and form the source of the latter, but my gut\n> feeling is that it is a rather weak argument. At that point you are\n> talking about what you could potentially change in the working tree,\n\nNo, I saved things in the stash on purpose. For example, I had changes\nthat were not ready to commit, but I wanted to do a merge from upstream.\n\nThere are workflows where the stash is not important; provide an option\nto 'git status' that means \"ignore stash\". \n\n> So, I tend to agree with you, while I do understand where \"I want to\n> know about what is in stash\" is coming from (and that is why we do\n> have \"git stash list\" command).\n\nMy Emacs front end currently checks both 'git status' and 'git stash\nlist' to build \"the status of the current workspace\".\n\n-- \n-- Stephe\n"},{"id":"235334","messageId":"85mwhe52zp.fsf@stephe-leake.org","threadId":"35945","inReplyTo":"vpqeh2r43kx.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-02-25T20:52:42Z","receivedAt":"2014-02-25T20:52:42Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Matthieu Moy writes:\n\n> Omar Othman writes:\n>\n>> [omar_othman main (trunk|MERGING*)]$ git add path/to/file.txt\n>> [omar_othman main (trunk*)]$\n>>\n>> Note how the status message has changed to show that git is now happy.\n>> It is at that moment that the stash reference should be dropped\n>\n> Dropping the stash on a \"git add\" operation would be really, really\n> weird...\n\nWhy? That is when the merge conflicts are resolved, which is what\nlogically indicates that the stash is no longer needed, _if_ the merge\nconflicts are related to the stash, which is true in this use case.\n\nThere are other uses for 'git add' that don't indicate that; we'd have\nto be very careful to not throw away the stash at the wrong time.\n\n>> (or the user (somehow) is notified to do that herself if desired),\n>> because this means that the popping operation has succeeded.\n>\n> But how would you expect to \"be notified\"?\n\nWhen 'git add' checks to see if all merge conflicts are now resolved,\nand those merge conflicts were related to the stash, it can either pop\nthe stash, or issue a message telling the user it is now safe to do so.\nWe would need a config setting to indicate which to do.\n\nMaybe that check is hard to do in general?\n\n-- \n-- Stephe\n"},{"id":"235340","messageId":"xmqq4n3m6dic.fsf@gitster.dls.corp.google.com","threadId":"35945","inReplyTo":"85r46q537a.fsf@stephe-leake.org","subject":"Re: `git stash pop` UX Problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-25T22:20:11Z","receivedAt":"2014-02-25T22:20:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephen Leake writes:\n\n>> One _could_ argue that stashed changes are what could be reflected\n>> to the working tree and form the source of the latter, but my gut\n>> feeling is that it is a rather weak argument. At that point you are\n>> talking about what you could potentially change in the working tree,\n>\n> No, I saved things in the stash on purpose. For example, I had changes\n> that were not ready to commit, but I wanted to do a merge from upstream.\n\nI often save things by running \"git diff >P.diff\" on purpose.\nShould \"git status\" read these patches and tell me what paths I\ncould change in the working tree by applying it? Where does it end?\n\n> There are workflows where the stash is not important; provide an option\n> to 'git status' that means \"ignore stash\". \n\nHow is that different to tell those who want to know what are in the\nstash to type \"git stash list\" when they want to learn that\ninformation?\n"},{"id":"235341","messageId":"xmqqvbw24yt3.fsf@gitster.dls.corp.google.com","threadId":"35945","inReplyTo":"85mwhe52zp.fsf@stephe-leake.org","subject":"Re: `git stash pop` UX Problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-25T22:23:04Z","receivedAt":"2014-02-25T22:23:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephen Leake writes:\n\n>> Dropping the stash on a \"git add\" operation would be really, really\n>> weird...\n>\n> Why? That is when the merge conflicts are resolved, which is what\n> logically indicates that the stash is no longer needed,...\n\nNot necessarily. Imagine a case where you used stash to quickly\nsave away a tangled mess that was not ready for a logically single\ncommit and now you are in the process of creating the first commit\nby applying it piece-by-piece to create multiple resulting ones.\nAfter you commit the result, you would still want to keep the parts\nof that stashed change you did not include in the first commit so\nthat you can go back, no?\n\nYou may run \"git add\", but that does not say anything about what you\nare going to use the rest of the stash for. Not even \"git commit\"\nmay be a good enough sign.\n"},{"id":"235347","messageId":"20140225235015.GE250380@vauxhall.crustytoothpaste.net","threadId":"35945","inReplyTo":"vpqzjlf5q2z.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2014-02-25T23:50:15Z","receivedAt":"2014-02-25T23:50:15Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Tue, Feb 25, 2014 at 01:33:56PM +0100, Matthieu Moy wrote:\n> Holger Hellmuth writes:\n> > Maybe status should display a stash count if that count is > 0, as\n> > this is part of the state of the repo.\n> \n> Maybe it would help some users, but not me for example. My main use of\n> \"git stash\" is a safe replacement for \"git reset --hard\": when I want to\n> discard changes, but keep them safe just in case.\n> \n> So, my stash count is almost always >0, and I don't want to hear about\n> it.\n\nI concur with this. Sometimes the stashed changes are remnants of a\nsmall hack or a very brief start to an aborted project that I stashed\nwhen I needed to change branches. I figure that they might be useful in\nthe future, but I don't care about them right now. I may pick them up,\nI may not, but I certainly don't want to be reminded of them constantly.\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"235348","messageId":"20140226003938.GA6809@ruderich.org","threadId":"35945","inReplyTo":"vpqlhx0a3cb.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"Simon Ruderich","fromEmail":"simon@ruderich.org","sentAt":"2014-02-26T00:39:39Z","receivedAt":"2014-02-26T00:39:39Z","isPatch":false,"sender":{"key":"simon@ruderich.org","avatar":"https://avatars.githubusercontent.com/u/390994?v=4"},"body":"On Mon, Feb 24, 2014 at 05:21:40PM +0100, Matthieu Moy wrote:\n> One easy thing to do OTOH would be to show a hint at the end of \"git\n> stash pop\"'s output, like\n\nI think that's a good idea. It makes it obvious that Git has kept\nthe stash and that the user should drop it when he's done - if he\nwants to.\n\n> $ git stash pop\n> Auto-merging foo.txt\n> CONFLICT (content): Merge conflict in foo.txt\n> 'stash pop' failed. Please, resolve the conflicts manually. The stash\n> was not dropped in case you need to restart the operation. When you are\n> done resolving the merge, you may run the following to drop the stash:\n>\n> git stash drop\n\nMaybe just the following to keep the output on a single line:\n\n Use 'git stash drop' to remove the stash after resolving the conflicts.\n\nBut maybe that's too short as it doesn't mention explicitly, that\nthe stash was kept.\n\nRegards\nSimon\n-- \n+ privacy is necessary\n+ using gnupg http://gnupg.org\n+ public key id: 0x92FEFDB7E44C32F9\n"},{"id":"235350","messageId":"530D97BA.1080107@booking.com","threadId":"35945","inReplyTo":"vpqeh2r43kx.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"Omar Othman","fromEmail":"omar.othman@booking.com","sentAt":"2014-02-26T07:28:58Z","receivedAt":"2014-02-26T07:28:58Z","isPatch":false,"sender":{"key":"omar.othman@booking.com","avatar":null},"body":"\n>> [omar_othman main (trunk|MERGING*)]$ git add path/to/file.txt\n>> [omar_othman main (trunk*)]$\n>>\n>> Note how the status message has changed to show that git is now happy.\n>> It is at that moment that the stash reference should be dropped\n> Dropping the stash on a \"git add\" operation would be really, really\n> weird...\n>\n>> (or the user (somehow) is notified to do that herself if desired),\n>> because this means that the popping operation has succeeded.\n> But how would you expect to \"be notified\"?\nAnswering the last question, your previous comments are fine with me:\n>> If there's any change that should be made it should be purely\n>> providing more detailed instructions to the user about how to deal\n>> with it.\n> Yes, there may be room for improvement, but that does not seem so easy.\n> Today, we have:\n>\n> $ git stash pop\n> Auto-merging foo.txt\n> CONFLICT (content): Merge conflict in foo.txt\n>\n> $ git status\n> On branch master\n> Unmerged paths:\n> (use \"git reset HEAD ...\" to unstage)\n> (use \"git add ...\" to mark resolution)\n>\n> both modified: foo.txt\n>\n> => The advices shown here are OK. Then:\n>\n> $ git add foo.txt\n> $ git status\n> On branch master\n> Changes to be committed:\n> (use \"git reset HEAD ...\" to unstage)\n>\n> modified: foo.txt\n>\n> => here, \"git status\" could have hinted the user \"you may now run 'git\n> stash drop' if you are satisfied with your merge\".\nThough I don't know why you think this is important:\n> Now, the real question is: when would Git stop showing this advice. I\n> don't see a real way to answer this, and I'd rather avoid doing just a\n> guess.\nIf it is really annoying for the user, we can just have a configuration \nparameter to switch this message on/off. I don't know whether git has \nsuch customizations (in general) currently.\n\nThis is very useful (maybe we can agree on wording later):\n> One easy thing to do OTOH would be to show a hint at the end of \"git\n> stash pop\"'s output, like\n>\n> $ git stash pop\n> Auto-merging foo.txt\n> CONFLICT (content): Merge conflict in foo.txt\n> 'stash pop' failed. Please resolve the conflicts manually. The stash\n> was not dropped in case you need to restart the operation. When you are\n> done resolving the merge, you may run the following to drop the stash reference:\n>\n> git stash drop\n"},{"id":"235351","messageId":"530D98FC.1020601@booking.com","threadId":"35945","inReplyTo":"530C893D.7000108@ira.uka.de","subject":"Re: `git stash pop` UX Problem","fromName":"Omar Othman","fromEmail":"omar.othman@booking.com","sentAt":"2014-02-26T07:34:20Z","receivedAt":"2014-02-26T07:34:20Z","isPatch":false,"sender":{"key":"omar.othman@booking.com","avatar":null},"body":"\n> Am 24.02.2014 17:21, schrieb Matthieu Moy:\n>> $ git add foo.txt\n>> $ git status\n>> On branch master\n>> Changes to be committed:\n>> (use \"git reset HEAD ...\" to unstage)\n>>\n>> modified: foo.txt\n>\n> Maybe status should display a stash count if that count is > 0, as \n> this is part of the state of the repo.\n>\n> $ git status\n> On branch master\n> Stashes: 1 <----------\n> Changes to be committed:\n> (use \"git reset HEAD ...\" to unstage)\n>\n> modified: foo.txt\n>\n> It would be in Omars example case a clear message that git kept the \n> stash. And generally a reminder that there is still a stash around \n> that might or might not be obsolete.\nAgain, the same comment: If there is a way to customize git's messages \nby turning them on/off (or, even cooler, the ability to change their \nwording) then this is also a nice option to have and we can turn it off \nby default if we find that most people (here at least) don't like it. I \ndon't know whether you guys have discussed this option before (or does \nit exist? I doubt, but I don't know), because having such an option (the \nability to turn messages on/off or change their wording and what \ninternal status information they manifest) will really resolve all kinds \nof such potential conflicts of preferences. Even cooler, people will be \nable to change the wording to their native languages for example.\n"},{"id":"235352","messageId":"530D99D5.5060308@booking.com","threadId":"35945","inReplyTo":"xmqqwqgj57n9.fsf@gitster.dls.corp.google.com","subject":"Re: `git stash pop` UX Problem","fromName":"Omar Othman","fromEmail":"omar.othman@booking.com","sentAt":"2014-02-26T07:37:57Z","receivedAt":"2014-02-26T07:37:57Z","isPatch":false,"sender":{"key":"omar.othman@booking.com","avatar":null},"body":"\n> Matthieu Moy writes:\n>\n>> Holger Hellmuth writes:\n>>\n>>> Am 24.02.2014 17:21, schrieb Matthieu Moy:\n>>>> $ git add foo.txt\n>>>> $ git status\n>>>> On branch master\n>>>> Changes to be committed:\n>>>> (use \"git reset HEAD ...\" to unstage)\n>>>>\n>>>> modified: foo.txt\n>>> Maybe status should display a stash count if that count is > 0, as\n>>> this is part of the state of the repo.\n>> Maybe it would help some users, but not me for example. My main use of\n>> \"git stash\" is a safe replacement for \"git reset --hard\": when I want to\n>> discard changes, but keep them safe just in case.\n>>\n>> So, my stash count is almost always >0, and I don't want to hear about\n>> it.\n> \"status\" is about reminding the user what changes are already in the\n> index (i.e. what you would commit) and what changes are in the\n> working tree, from which you could further update the index with\n> (i.e. what you could commit).\n>\n> One _could_ argue that stashed changes are what could be reflected\n> to the working tree and form the source of the latter, but my gut\n> feeling is that it is a rather weak argument. At that point you are\n> talking about what you could potentially change in the working tree,\n> and the way to do so is not limited to \"stash pop\" (i.e. you can\n> \"git cherry-pick --no-commit $a_commit\", or \"edit\" any file in the\n> working tree for that matter, with the same ease).\n>\n> So, I tend to agree with you, while I do understand where \"I want to\n> know about what is in stash\" is coming from (and that is why we do\n> have \"git stash list\" command).\nSame comment. Everyone will have his own opinion. As long as the \nmessages are not customizable, we can debate for hours and everybody has \na valid point.\n"},{"id":"235354","messageId":"vpqzjlez3c4.fsf@anie.imag.fr","threadId":"35945","inReplyTo":"530D97BA.1080107@booking.com","subject":"Re: `git stash pop` UX Problem","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-02-26T08:27:07Z","receivedAt":"2014-02-26T08:27:07Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Omar Othman writes:\n\n> Though I don't know why you think this is important:\n>> Now, the real question is: when would Git stop showing this advice. I\n>> don't see a real way to answer this, and I'd rather avoid doing just a\n>> guess.\n> If it is really annoying for the user, we can just have a\n> configuration parameter to switch this message on/off.\n\nJust saying \"You have X stash\" is OK to me as long as there is an option\nto deactivate it.\n\nHinting \"You should now run \"git stash drop\".\" OTOH is far more dangerous\nif guessed wrong. Keeping a stash active when you don't need it does no\nreal harm, but droping one you actually needed is data loss.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235361","messageId":"1lho9x8.1qh70zkp477M%lists@haller-berlin.de","threadId":"35945","inReplyTo":"xmqqvbw24yt3.fsf@gitster.dls.corp.google.com","subject":"Re: `git stash pop` UX Problem","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2014-02-26T10:24:00Z","receivedAt":"2014-02-26T10:24:00Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"Junio C Hamano wrote:\n\n> Stephen Leake writes:\n> \n> >> Dropping the stash on a \"git add\" operation would be really, really\n> >> weird...\n> >\n> > Why? That is when the merge conflicts are resolved, which is what\n> > logically indicates that the stash is no longer needed,...\n> \n> Not necessarily. Imagine a case where you used stash to quickly\n> save away a tangled mess that was not ready for a logically single\n> commit and now you are in the process of creating the first commit\n> by applying it piece-by-piece to create multiple resulting ones.\n> After you commit the result, you would still want to keep the parts\n> of that stashed change you did not include in the first commit so\n> that you can go back, no?\n> \n> You may run \"git add\", but that does not say anything about what you\n> are going to use the rest of the stash for. Not even \"git commit\"\n> may be a good enough sign.\n\nBut we are only talking about the situation where you typed \"git stash\npop\", and this resulted in a merge conflict. Your intention was clearly\nto drop the stash, it just wasn't dropped because of the conflict.\nDropping it automatically once the conflict is resolved would be nice.\n\nI know it happened to me too that I forgot to drop a stash after\nresolving conflicts, so I'd appreciate a feature that somehow does this\nautomatically for me.\n\n\n-- \nStefan Haller\nBerlin, Germany\nhttp://www.haller-berlin.de/\n"},{"id":"235364","messageId":"vpqmwhexidi.fsf@anie.imag.fr","threadId":"35945","inReplyTo":"1lho9x8.1qh70zkp477M%lists@haller-berlin.de","subject":"Re: `git stash pop` UX Problem","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-02-26T10:45:13Z","receivedAt":"2014-02-26T10:45:13Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"lists@haller-berlin.de (Stefan Haller) writes:\n\n> Your intention was clearly to drop the stash, it just wasn't dropped\n> because of the conflict. Dropping it automatically once the conflict\n> is resolved would be nice.\n\nYour intention when you ran \"git stash pop\", yes. Your intention when\nyou ran \"git add\", I call that guessing.\n\nThe condition for dropping the stash should be more \"conflits\nresolutions are done AND the user is happy with it\". Otherwise, if you\nmess up your conflict resolution, and notice it after running \"git add\",\nthen you're screwed because Git just happily discarded your important\ndata. The point of keeping the stash is to leave it up to the user to\ndecide between \"I'm happy, I can drop\" or \"I'm not, I should re-apply\",\nand Git cannot tell which is which.\n\nHinting the user to run \"stash pop\" would be more acceptable, but\ntalking about \"git stash\" in \"git add\"'s code is somehow a dependency\norder violation (stash is normally implemented on top of Git's basic\nfeatures, not the other way around). Does not seem serious from at first\nfrom the user point of view, but this pushes the codebase one step in\nthe direction of an unmaintainable mess.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235383","messageId":"20140226151746.GA7422@thunk.org","threadId":"35945","inReplyTo":"xmqqwqgj57n9.fsf@gitster.dls.corp.google.com","subject":"Re: `git stash pop` UX Problem","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2014-02-26T15:17:46Z","receivedAt":"2014-02-26T15:17:46Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Feb 25, 2014 at 11:12:10AM -0800, Junio C Hamano wrote:\n> So, I tend to agree with you, while I do understand where \"I want to\n> know about what is in stash\" is coming from (and that is why we do\n> have \"git stash list\" command).\n\nOne thing that would be nice is if there was built-in \"git stash list\"\noption which only shows the stash items which match the current\nbranch. The discussion on this thread inspired me to create the\nfollowing:\n\n#!/bin/sh\n\nb=$(git symbolic-ref HEAD | sed -e 's;refs/heads/;;')\ngit stash list --pretty=\"%gd %cr on: %s\" | grep \"WIP on $b\" | \\\n sed -e \"s/ WIP on $b: [0-9a-f]*//\"\n\nThis results in:\n\nstash@{0} 4 weeks ago on: mke2fs: add make_hugefile feature\nstash@{1} 5 weeks ago on: e2fsck, mke2fs: enable octal integers in the profile/config file\nstash@{2} 5 weeks ago on: e2fsck, mke2fs: enable octal integers in the profile/config file\nstash@{3} 5 weeks ago on: mke2fs: optimize fix_cluster_bg_counts()\nstash@{4} 8 weeks ago on: e4defrag: choose the best available posix_fadvise variant\nstash@{5} 9 weeks ago on: e2image: add -c option to optimize file system copying for flash devices\nstash@{6} 9 weeks ago on: e2image: clean up gcc -Wall and sparse nits\nstash@{7} 9 weeks ago on: e2fsck: fix printf conversion specs in ea_refcount.c\n\n(Yes, I have a lot of junk on my git stash; showing the relative time\nis going to help my GC what I have left on my git stash list.)\n\nCheers,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"235400","messageId":"xmqqd2i94qfq.fsf@gitster.dls.corp.google.com","threadId":"35945","inReplyTo":"vpqzjlez3c4.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-26T19:36:09Z","receivedAt":"2014-02-26T19:36:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Omar Othman writes:\n>\n>> Though I don't know why you think this is important:\n>>> Now, the real question is: when would Git stop showing this advice. I\n>>> don't see a real way to answer this, and I'd rather avoid doing just a\n>>> guess.\n>> If it is really annoying for the user, we can just have a\n>> configuration parameter to switch this message on/off.\n>\n> Just saying \"You have X stash\" is OK to me as long as there is an option\n> to deactivate it.\n>\n> Hinting \"You should now run \"git stash drop\".\" OTOH is far more dangerous\n> if guessed wrong. Keeping a stash active when you don't need it does no\n> real harm, but droping one you actually needed is data loss.\n\nYes, definitely.\n\nI'm inclined to say that we should go in the direction you suggested\nearlier in Message-ID: , that is:\n\n>> One easy thing to do OTOH would be to show a hint at the end of \"git\n>> stash pop\"'s output, like\n>> \n>> $ git stash pop\n>> Auto-merging foo.txt\n>> CONFLICT (content): Merge conflict in foo.txt\n>> 'stash pop' failed. Please, resolve the conflicts manually. The stash\n>> was not dropped in case you need to restart the operation. When you are\n>> done resolving the merge, you may run the following to drop the stash:\n>> \n>> git stash drop\n>> \n>> or so (I couldn't find a concise yet accurate wording).\n\nI'd however have to say that even \"please resolve the conflicts\nmanually\" is over-assuming.\n\nI often start some WIP of a fix, realize that the fix should apply\nto a lot older maintenance branch than where I happened to have\nstarted the WIP (which typically is at the tip of somebody else's\nbranch where I received the series from the list---and then noticed\nsome existing breakage that needs to be fixed), stash the WIP, and\nthen repeat:\n\n (1) checkout an old maintenance track;\n (2) try to pop;\n (3) if it succeeds, stop the iteration;\n (4) otherwise, reset and go back to (1) to checkout a bit newer\n maintenance track.\n\nto decide. So \"resolve the conflicts\" is assuming the intention of\nthe user who issued \"pop\" too much (let alone \"manually\"---it does\nnot matter how the user resolves conflicts---the only thing we want\nto say is Git did all it would and no further automated help in\nresolving is availble, but \"manually\" is not quite the word).\n\n\"The stash was not dropped\" is the most important thing in your\nadditional text. How about rephrasing like this?\n\n $ git stash pop\n Auto-merging foo.txt\n CONFLICT (content): Merge conflict in foo.txt\n\n The stashed change could not be replayed cleanly, leaving\n conflicts in the working tree. The stash was not dropped in case\n you need it again.\n\n After you are done with the stash, you may want to \"git stash\n drop\" to discard it.\n"},{"id":"235407","messageId":"vpqy50xd5cr.fsf@anie.imag.fr","threadId":"35945","inReplyTo":"xmqqd2i94qfq.fsf@gitster.dls.corp.google.com","subject":"Re: `git stash pop` UX Problem","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-02-26T19:46:44Z","receivedAt":"2014-02-26T19:46:44Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> I'd however have to say that even \"please resolve the conflicts\n> manually\" is over-assuming.\n\nI understand your point, but in a short hint message, I still find it\nreasonable. Fixing conflicts is the natural way to go after a \"stash\npop\", and the user who do not want to go this way probably knows why.\n\n> \"The stash was not dropped\" is the most important thing in your\n> additional text. How about rephrasing like this?\n>\n> $ git stash pop\n> Auto-merging foo.txt\n> CONFLICT (content): Merge conflict in foo.txt\n>\n> The stashed change could not be replayed cleanly, leaving\n> conflicts in the working tree. The stash was not dropped in case\n> you need it again.\n>\n> After you are done with the stash, you may want to \"git stash\n> drop\" to discard it.\n\nI'm fine with this, but it's even longer than mine which I already found\ntoo long. Perhaps the \"leaving conflicts in the working tree\" could be\ndropped, as the message follows \"CONFLICT (content): Merge conflict in\nfoo.txt\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235409","messageId":"xmqqvbw139sy.fsf@gitster.dls.corp.google.com","threadId":"35945","inReplyTo":"vpqy50xd5cr.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-26T20:20:45Z","receivedAt":"2014-02-26T20:20:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> I'd however have to say that even \"please resolve the conflicts\n>> manually\" is over-assuming.\n>\n> I understand your point, but in a short hint message, I still find it\n> reasonable. Fixing conflicts is the natural way to go after a \"stash\n> pop\", and the user who do not want to go this way probably knows why.\n>\n>> \"The stash was not dropped\" is the most important thing in your\n>> additional text. How about rephrasing like this?\n>>\n>> $ git stash pop\n>> Auto-merging foo.txt\n>> CONFLICT (content): Merge conflict in foo.txt\n>>\n>> The stashed change could not be replayed cleanly, leaving\n>> conflicts in the working tree. The stash was not dropped in case\n>> you need it again.\n>>\n>> After you are done with the stash, you may want to \"git stash\n>> drop\" to discard it.\n>\n> I'm fine with this, but it's even longer than mine which I already found\n> too long. Perhaps the \"leaving conflicts in the working tree\" could be\n> dropped, as the message follows \"CONFLICT (content): Merge conflict in\n> foo.txt\".\n\nSurely. s/was not dropped/is kept/ would make the result even\nshorter.\n\nWe can also remove the last three lines, for that matter.\n"},{"id":"235413","messageId":"87ha7l62d6.fsf@fencepost.gnu.org","threadId":"35945","inReplyTo":"vpqy50xd5cr.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-26T20:33:09Z","receivedAt":"2014-02-26T20:33:09Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> I'd however have to say that even \"please resolve the conflicts\n>> manually\" is over-assuming.\n>\n> I understand your point, but in a short hint message, I still find it\n> reasonable. Fixing conflicts is the natural way to go after a \"stash\n> pop\", and the user who do not want to go this way probably knows why.\n>\n>> \"The stash was not dropped\" is the most important thing in your\n>> additional text. How about rephrasing like this?\n>>\n>> $ git stash pop\n>> Auto-merging foo.txt\n>> CONFLICT (content): Merge conflict in foo.txt\n>>\n>> The stashed change could not be replayed cleanly, leaving\n>> conflicts in the working tree. The stash was not dropped in case\n>> you need it again.\n>>\n>> After you are done with the stash, you may want to \"git stash\n>> drop\" to discard it.\n>\n> I'm fine with this, but it's even longer than mine which I already found\n> too long. Perhaps the \"leaving conflicts in the working tree\" could be\n> dropped, as the message follows \"CONFLICT (content): Merge conflict in\n> foo.txt\".\n\nAll that verbosity...\n\n$ git stash pop\nAuto-merging foo.txt\nCONFLICT (content): Merge conflict in foo.txt\nCowardly refusing to drop stash.\n$\n\n-- \nDavid Kastrup\n"},{"id":"235421","messageId":"xmqq4n3l34ex.fsf@gitster.dls.corp.google.com","threadId":"35945","inReplyTo":"87ha7l62d6.fsf@fencepost.gnu.org","subject":"Re: `git stash pop` UX Problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-26T22:17:10Z","receivedAt":"2014-02-26T22:17:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kastrup writes:\n\n> All that verbosity...\n>\n> $ git stash pop\n> Auto-merging foo.txt\n> CONFLICT (content): Merge conflict in foo.txt\n> Cowardly refusing to drop stash.\n> $\n\nActually, modulo \"Cowardly\", that may be the most harmless phrasing,\nas apply_stash may try to signal an error for reasons not related to\nan inability to apply the change cleanly (e.g. we may have failed to\nrefresh the index).\n\nWhatever phrasing we may end up choosing, the change itself should\nbe trivial in any case.\n\n git-stash.sh | 10 ++++++++--\n 1 file changed, 8 insertions(+), 2 deletions(-)\n\ndiff --git a/git-stash.sh b/git-stash.sh\nindex f0a94ab..4798bcf 100755\n--- a/git-stash.sh\n+++ b/git-stash.sh\n@@ -512,8 +512,14 @@ apply_stash () {\n pop_stash() {\n \tassert_stash_ref \"$@\"\n \n-\tapply_stash \"$@\" &&\n-\tdrop_stash \"$@\"\n+\tif apply_stash \"$@\"\n+\tthen\n+\t\tdrop_stash \"$@\"\n+\telse\n+\t\tstatus=$?\n+\t\tsay \"The stash is kept in case you need it again.\"\n+\t\texit $status\n+\tfi\n }\n \n drop_stash () {\n"},{"id":"235431","messageId":"878usx5rwd.fsf@fencepost.gnu.org","threadId":"35945","inReplyTo":"xmqq4n3l34ex.fsf@gitster.dls.corp.google.com","subject":"Re: `git stash pop` UX Problem","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-27T00:19:14Z","receivedAt":"2014-02-27T00:19:14Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> David Kastrup writes:\n>\n>> All that verbosity...\n>>\n>> $ git stash pop\n>> Auto-merging foo.txt\n>> CONFLICT (content): Merge conflict in foo.txt\n>> Cowardly refusing to drop stash\n>> $\n>\n> Actually, modulo \"Cowardly\", that may be the most harmless phrasing,\n> as apply_stash may try to signal an error for reasons not related to\n> an inability to apply the change cleanly (e.g. we may have failed to\n> refresh the index).\n\nWithout \"Cowardly\", the capriciosity of \"refusing\" does not make much\nsense. The error message is a tribute to GNU tar:\ndak@lola:/tmp$ mkdir x\ndak@lola:/tmp$ tar cfz x\ntar: Cowardly refusing to create an empty archive\nTry `tar --help' or `tar --usage' for more information.\ndak@lola:/tmp$ \n\nThe boring variant would be\n\n$ git stash pop\nAuto-merging foo.txt\nCONFLICT (content): Merge conflict in foo.txt\nNot dropping stash\n$\n\n-- \nDavid Kastrup\n"},{"id":"235472","messageId":"85r46o3d9x.fsf@stephe-leake.org","threadId":"35945","inReplyTo":"xmqq4n3m6dic.fsf@gitster.dls.corp.google.com","subject":"Re: `git stash pop` UX Problem","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-02-27T13:18:02Z","receivedAt":"2014-02-27T13:18:02Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Junio C Hamano writes:\n\n> Stephen Leake writes:\n>\n>>> One _could_ argue that stashed changes are what could be reflected\n>>> to the working tree and form the source of the latter, but my gut\n>>> feeling is that it is a rather weak argument. At that point you are\n>>> talking about what you could potentially change in the working tree,\n>>\n>> No, I saved things in the stash on purpose. For example, I had changes\n>> that were not ready to commit, but I wanted to do a merge from upstream.\n>\n> I often save things by running \"git diff >P.diff\" on purpose.\n\nOk. How is that better than 'git stash save'?\n\n> Should \"git status\" read these patches and tell me what paths I\n> could change in the working tree by applying it? \n\nNo, 'git stash save' appears to be the method git provides to do this,\nso it is the only one that git needs to support.\n\n(The content of 'P.diff' already tells you what paths are modified, as\ndoes 'git stash show')\n\nBut I am new to git, so I could just be missing the point.\n\n>Where does it end?\n\nWhere we agree it ends :).\n\n>> There are workflows where the stash is not important; provide an option\n>> to 'git status' that means \"ignore stash\". \n>\n> How is that different to tell those who want to know what are in the\n> stash to type \"git stash list\" when they want to learn that\n> information?\n\nYou are correct, this is a question of style. The question is:\n\nWhich style is best for git, considering the needs of newbies and\nseasoned users?\n\nAs a newbie, I find these things confusing:\n\n- the stash status is not displayed by 'git status'\n\n- 'git add' does not report that all pending merge conflicts are now\nresolved.\n\nI'm sure I will discover other confusing things in the future :).\n\n\nI am a seasoned user of CM systems in general; in all cases, I have\ncustomized an Emacs front-end to do _exactly_ what I want, rather than\nrelying on the command line tools directly. So I have a rather extreme\nperspective on this :). I do rely on the command line tools while\nlearning a new CM system.\n\nIn general, I expect seasoned users to be more accepting of the need to\nprovide additional options to customize the tools to their workflow.\n\n-- \n-- Stephe\n"},{"id":"235473","messageId":"85mwhc3d2z.fsf@stephe-leake.org","threadId":"35945","inReplyTo":"20140226003938.GA6809@ruderich.org","subject":"Re: `git stash pop` UX Problem","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-02-27T13:22:12Z","receivedAt":"2014-02-27T13:22:12Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Simon Ruderich writes:\n\n> On Mon, Feb 24, 2014 at 05:21:40PM +0100, Matthieu Moy wrote:\n>> One easy thing to do OTOH would be to show a hint at the end of \"git\n>> stash pop\"'s output, like\n>\n> I think that's a good idea. It makes it obvious that Git has kept\n> the stash and that the user should drop it when he's done - if he\n> wants to.\n\n+1\n\nThis does not mean I don't _also_ think 'git add' dropping the stash\nwhen the last conflict is resolved is a good idea. If that is\nimplemented, 'stash pop' might have to mention that effect as well; that\ndoes make things more complicated.\n\n-- \n-- Stephe\n"},{"id":"235475","messageId":"85ios03cy1.fsf@stephe-leake.org","threadId":"35945","inReplyTo":"vpqzjlez3c4.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-02-27T13:25:10Z","receivedAt":"2014-02-27T13:25:10Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Matthieu Moy writes:\n\n> Omar Othman writes:\n>\n>> Though I don't know why you think this is important:\n>>> Now, the real question is: when would Git stop showing this advice. I\n>>> don't see a real way to answer this, and I'd rather avoid doing just a\n>>> guess.\n>> If it is really annoying for the user, we can just have a\n>> configuration parameter to switch this message on/off.\n>\n> Just saying \"You have X stash\" is OK to me as long as there is an option\n> to deactivate it.\n\n+1\n\n> Hinting \"You should now run \"git stash drop\".\" OTOH is far more dangerous\n> if guessed wrong. Keeping a stash active when you don't need it does no\n> real harm, but droping one you actually needed is data loss.\n\nI agree giving possibly incorrect advice is bad.\n\nCan you construct a use case where git will give incorrect advice? \n\nI don't know git well enough to do that, nor to assert that it will never\nhappen. \n\nI think we need a more concrete proposal to move this forward.\n\n-- \n-- Stephe\n"},{"id":"235531","messageId":"85fvn40ws9.fsf@stephe-leake.org","threadId":"35945","inReplyTo":"vpqmwhexidi.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-02-28T02:57:10Z","receivedAt":"2014-02-28T02:57:10Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Matthieu Moy writes:\n\n> lists@haller-berlin.de (Stefan Haller) writes:\n>\n>> Your intention was clearly to drop the stash, it just wasn't dropped\n>> because of the conflict. Dropping it automatically once the conflict\n>> is resolved would be nice.\n>\n> Your intention when you ran \"git stash pop\", yes. Your intention when\n> you ran \"git add\", I call that guessing.\n\nYou might be adding other files for other reasons. But if you add a file\nthat does resolve a conflict caused by 'git stash pop', it is not\nguessing.\n\n> The condition for dropping the stash should be more \"conflits\n> resolutions are done AND the user is happy with it\". Otherwise, if you\n> mess up your conflict resolution, and notice it after running \"git add\",\n> then you're screwed because Git just happily discarded your important\n> data. The point of keeping the stash is to leave it up to the user to\n> decide between \"I'm happy, I can drop\" or \"I'm not, I should re-apply\",\n> and Git cannot tell which is which.\n\nYes, that makes sense.\n\n> Hinting the user to run \"stash pop\" would be more acceptable, but\n> talking about \"git stash\" in \"git add\"'s code is somehow a dependency\n> order violation (stash is normally implemented on top of Git's basic\n> features, not the other way around). Does not seem serious from at first\n> from the user point of view, but this pushes the codebase one step in\n> the direction of an unmaintainable mess.\n\nAlso makes sense.\n\nSo \"git add\" and \"git stash *\" are lower level tools; to get the effect\nwe are asking for, we should use a front-end (which is why I'm writing\none for Emacs :).\n\n-- \n-- Stephe\n"},{"id":"235532","messageId":"85bnxs0wmh.fsf@stephe-leake.org","threadId":"35945","inReplyTo":"xmqqd2i94qfq.fsf@gitster.dls.corp.google.com","subject":"Re: `git stash pop` UX Problem","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-02-28T03:00:38Z","receivedAt":"2014-02-28T03:00:38Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Junio C Hamano writes:\n\n> ... So \"resolve the conflicts\" is assuming the intention of\n> the user who issued \"pop\" too much (let alone \"manually\"---it does\n> not matter how the user resolves conflicts---the only thing we want\n> to say is Git did all it would and no further automated help in\n> resolving is availble, but \"manually\" is not quite the word).\n\n+1\n\n> \"The stash was not dropped\" is the most important thing in your\n> additional text. How about rephrasing like this?\n>\n> $ git stash pop\n> Auto-merging foo.txt\n> CONFLICT (content): Merge conflict in foo.txt\n>\n> The stashed change could not be replayed cleanly, leaving\n> conflicts in the working tree. The stash was not dropped in case\n> you need it again.\n>\n> After you are done with the stash, you may want to \"git stash\n> drop\" to discard it.\n\n+1\n\n-- \n-- Stephe\n"},{"id":"235535","messageId":"CANUGeEZTeqBpf0VP4gCG9iN=v20U4axxoSjX9JbLPp_ppX3QiA@mail.gmail.com","threadId":"35945","inReplyTo":"85fvn40ws9.fsf@stephe-leake.org","subject":"Re: `git stash pop` UX Problem","fromName":"Brandon McCaig","fromEmail":"bamccaig@gmail.com","sentAt":"2014-02-28T04:50:41Z","receivedAt":"2014-02-28T04:50:41Z","isPatch":false,"sender":{"key":"bamccaig@gmail.com","avatar":"https://gravatar.com/avatar/05b01f2b62a5ddbaa1946579266a8d9e970fed0c0b3c20e8d42aca973c31531c?d=mp&s=160"},"body":"Stephan:\n\nOn Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake\n wrote:\n> You might be adding other files for other reasons. But if you add a file\n> that does resolve a conflict caused by 'git stash pop', it is not\n> guessing.\n\nStaging a file doesn't tell git that you resolved a conflict. Git will\nhappily accept a blob full of conflict markers. Git doesn't know the\ndifference. Git expects the user to know what is right. The user has\nthe freedom to manipulate the index as they see fit, which means both\nadding and removing from it anytime they wish.\n\n> So \"git add\" and \"git stash *\" are lower level tools; to get the effect\n> we are asking for, we should use a front-end (which is why I'm writing\n> one for Emacs :).\n\nYou *can* use a front end, but I would argue that you shouldn't\nnecessarily. Most third-party front ends only serve to confuse users.\nIn general, they only cause problems and encourage ignorance.\n\nGit is a very pure system. It doesn't impose too may rules on you. It\nbasically just gives you the tools that you need to work within the\nsystem and gets out of your way. It is up to the user to learn how to\nassemble those tools for good (and many front ends exist to help;\nsometimes arguably too many as it is, such as git-pull(1) for\nexample).\n\n This isn't a case of the API being wrong. This is a case of PEBKAC,\nIMO. Maybe the API can be a little bit more verbose in assisting the\nuser to understand what has happened and what sensible options there\nare, but we should avoid catering to newbies too much. You should only\nbe a newbie for a short time. After that you should begin to learn the\nAPI. Hand holding at that point would be noise (as it would for most\nof us here, I imagine). The worst kind of \"hand holding\" is the kind\nthat imposes rules on you that aren't universal. Dropping the stash\nafter adding all changes to the index after a failed pop is not\nuniversal. At most, git stash pop should give the user a bit more\nguidance to understand what the situation is. At least, the user\nshould RTFM and learn to use the tools. And that might involve some\nmistakes, but you learn from mistakes. At least Git does a good job of\nmaking it easy to recover from most of your mistakes. The proposed\nchange to git-add takes away one of those safety nets.\n\nGit isn't always the easiest thing to wrap your head around, but I\nhave found that once you have wrapped your head around it Git is the\neasiest thing to get the job done the way you want. I consider the\nlearning curve a strength of Git. Which isn't to say that there isn't\nroom for improvement, but when proposing improvements we should try to\nmake sure that they actually make things universally better.\n\nRegards,\n\n\n-- \nBrandon McCaig \nCastopulence Software \nBlog \nperl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.\nq{Vg qbrfa'\\''g nyjnlf fbhaq gung jnl.};\ntr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'\n"},{"id":"235624","messageId":"851tynz2yg.fsf@stephe-leake.org","threadId":"35945","inReplyTo":"CANUGeEZTeqBpf0VP4gCG9iN=v20U4axxoSjX9JbLPp_ppX3QiA@mail.gmail.com","subject":"Re: `git stash pop` UX Problem","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-02-28T15:12:07Z","receivedAt":"2014-02-28T15:12:07Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Brandon McCaig writes:\n\n> On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake\n> wrote:\n>> You might be adding other files for other reasons. But if you add a file\n>> that does resolve a conflict caused by 'git stash pop', it is not\n>> guessing.\n>\n> Staging a file doesn't tell git that you resolved a conflict. Git will\n> happily accept a blob full of conflict markers. Git doesn't know the\n> difference. Git expects the user to know what is right. The user has\n> the freedom to manipulate the index as they see fit, which means both\n> adding and removing from it anytime they wish.\n\nBut git has a notion of \"unresolved conflict\". For example, when I have\nconflicts from a 'git stash pop', 'git status' shows:\n\nstephe@takver$ git status\n# On branch master\n# Unmerged paths:\n# (use \"git reset HEAD ...\" to unstage)\n# (use \"git add/rm ...\" as appropriate to mark resolution)\n#\n#\tboth modified: CommandBasedAutonomous.java\n#\tboth modified: DriveByInches.java\n#\n# ...\n\nHow does it know those files are \"unmerged\"? I'm guessing it has\nrecorded the fact that they had conflicts. Where does it record that?\n\nIn fact, at this point, I have edited CommandBasedAutonomous.java to\nresolve the conflicts. But git apparently doesn't know that.\n\nSo I do 'git add CommandBasedAutonomous.java', then 'git status':\n\nstephe@takver$ git status\n# On branch master\n# Changes to be committed:\n# (use \"git reset HEAD ...\" to unstage)\n#\n#\tmodified: AerialAssist2014/src/org/usfirst/frc1939/AerialAssist2014/commands/CommandBasedAutonomous.java\n#\n# Unmerged paths:\n# (use \"git reset HEAD ...\" to unstage)\n# (use \"git add/rm ...\" as appropriate to mark resolution)\n#\n#\tboth modified: AerialAssist2014/src/org/usfirst/frc1939/AerialAssist2014/commands/DriveByInches.java\n\nAnd git thinks that file is now \"merged\".\n\nSo it appears that adding a file _does_ tell git that the conflict is\nresolved.\n\nOr am I still missing something?\n\n\n>> So \"git add\" and \"git stash *\" are lower level tools; to get the effect\n>> we are asking for, we should use a front-end (which is why I'm writing\n>> one for Emacs :).\n>\n> You *can* use a front end, but I would argue that you shouldn't\n> necessarily. Most third-party front ends only serve to confuse users.\n> In general, they only cause problems and encourage ignorance.\n\nWon't happen here; I'm writing it. It may confuse other people, but\nnot me :).\n\n> Git is a very pure system.\n\nHmm. We'll have to disagree on that. git gives the impression of having\ngrown organically for quite a while, and therefore suffers from changing\nand competing design paradigms and conflicting requirements due to\npreserving backward compatiblity.\n\nmonotone is much cleaner, since it has had very few design paradigm\nchanges, and they were implemented cleanly, without preserving backward\ncompatibility. monotone is not as flexible as git, but what I've seen so\nfar could be added to monotone (I don't think it ever will be; monotone\nis dying as a project).\n\nWe are probably using different definitions of \"pure\" here.\n\n> It is up to the user to learn how to assemble those tools for\n> good (and many front ends exist to help; sometimes arguably too many\n> as it is, such as git-pull(1) for example).\n\nYes. Which is why we are discussing how much help git should be while\nstill learning the rules.\n\n> This isn't a case of the API being wrong. This is a case of PEBKAC,\n> IMO.\n\n(wikipedia to the rescue; PEBKAC = \"operator error\")\n\nYes, I'm not using it correctly, because I don't understand it yet.\nThat's the definition of \"newbie\".\n\n> Dropping the stash after adding all changes to the index after a\n> failed pop is not universal.\n\nNot universal, but it appears to be very common; it is certainly what I\nexpect, as a newbie. So it could be the default as long as there is a\nconfiguration option to have it not do that.\n\nI _did_ \"RTFM\" (specifically the man page on 'git stash', and before\nthat the git book at http://git-scm.com/documentation (which did not\nmention stash)); it did not explain the full cycle of how to resolve\nconflicts after stash pop.\n\nPerhaps there is a different manual that I could read instead?\n\nIn particular, one that explains what \"unmerged paths\" means in the 'git\nstatus' output? The 'git-status' man page does not do that.\n\n--\n-- Stephe\n"},{"id":"235628","messageId":"vpq38j3z1jj.fsf@anie.imag.fr","threadId":"35945","inReplyTo":"851tynz2yg.fsf@stephe-leake.org","subject":"Re: `git stash pop` UX Problem","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-02-28T15:42:40Z","receivedAt":"2014-02-28T15:42:40Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Stephen Leake writes:\n\n> So it appears that adding a file _does_ tell git that the conflict is\n> resolved.\n\nYes it does. Git _knows_ that you consider the conflict to be resolved.\nIt cannot know how happy you are with the result.\n\nSimilarly, in a conflicted merge, the last \"git add\" does not trigger a\ncommit silently. And a silent commit would be much less serious than a\nsilent data drop.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235631","messageId":"87mwhb1azp.fsf@fencepost.gnu.org","threadId":"35945","inReplyTo":"851tynz2yg.fsf@stephe-leake.org","subject":"Re: `git stash pop` UX Problem","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-28T16:02:34Z","receivedAt":"2014-02-28T16:02:34Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Stephen Leake writes:\n\n> Brandon McCaig writes:\n>\n>> On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake\n>> wrote:\n>>> You might be adding other files for other reasons. But if you add a file\n>>> that does resolve a conflict caused by 'git stash pop', it is not\n>>> guessing.\n>>\n>> Staging a file doesn't tell git that you resolved a conflict. Git will\n>> happily accept a blob full of conflict markers. Git doesn't know the\n>> difference. Git expects the user to know what is right. The user has\n>> the freedom to manipulate the index as they see fit, which means both\n>> adding and removing from it anytime they wish.\n>\n> But git has a notion of \"unresolved conflict\".\n\nNot really. It has a notion of \"unmerged path\".\n\n> For example, when I have conflicts from a 'git stash pop', 'git\n> status' shows:\n>\n> stephe@takver$ git status\n> # On branch master\n> # Unmerged paths:\n> # (use \"git reset HEAD ...\" to unstage)\n> # (use \"git add/rm ...\" as appropriate to mark resolution)\n> #\n> #\tboth modified: CommandBasedAutonomous.java\n> #\tboth modified: DriveByInches.java\n> #\n> # ...\n>\n> How does it know those files are \"unmerged\"? I'm guessing it has\n> recorded the fact that they had conflicts. Where does it record that?\n\nThe index contains the unmerged versions of the file. Possibly also the\nversion with conflict markers, but it's been too long since I last\nchecked.\n\nAfter \"git add\", there is only one version in the index.\n\nIf you apply a stash with unmerged paths to a worktree/index, possibly\ncontaining unmerged paths of its own, possibly getting new unmerged\npaths by failing to apply the stash, you get unmerged paths from several\ndifferent unresolved conflicts.\n\nGit has no idea about the history of unmerged paths. So having \"git\nadd\" modify the operation of \"git reset\" whenever \"git add\" overwrites\nan unmerged path in the index could lead to quite funny results.\n\n-- \nDavid Kastrup\n"},{"id":"235643","messageId":"85vbvz171p.fsf@stephe-leake.org","threadId":"35945","inReplyTo":"vpq38j3z1jj.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-02-28T17:27:46Z","receivedAt":"2014-02-28T17:27:46Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Matthieu Moy writes:\n\n> Stephen Leake writes:\n>\n>> So it appears that adding a file _does_ tell git that the conflict is\n>> resolved.\n>\n> Yes it does. Git _knows_ that you consider the conflict to be resolved.\n> It cannot know how happy you are with the result.\n>\n> Similarly, in a conflicted merge, the last \"git add\" does not trigger a\n> commit silently. And a silent commit would be much less serious than a\n> silent data drop.\n\nOk, I see your point now.\n\nSo a message \"merge complete; you can drop the stash\" would be the most\ngit should do.\n\n-- \n-- Stephe\n"},{"id":"235644","messageId":"85r46n168a.fsf@stephe-leake.org","threadId":"35945","inReplyTo":"87mwhb1azp.fsf@fencepost.gnu.org","subject":"Re: `git stash pop` UX Problem","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-02-28T17:45:25Z","receivedAt":"2014-02-28T17:45:25Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"David Kastrup writes:\n\n> Stephen Leake writes:\n>\n>> Brandon McCaig writes:\n>>\n>>> On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake\n>>> wrote:\n>>>> You might be adding other files for other reasons. But if you add a file\n>>>> that does resolve a conflict caused by 'git stash pop', it is not\n>>>> guessing.\n>>>\n>>> Staging a file doesn't tell git that you resolved a conflict. Git will\n>>> happily accept a blob full of conflict markers. Git doesn't know the\n>>> difference. Git expects the user to know what is right. The user has\n>>> the freedom to manipulate the index as they see fit, which means both\n>>> adding and removing from it anytime they wish.\n>>\n>> But git has a notion of \"unresolved conflict\".\n>\n> Not really. It has a notion of \"unmerged path\".\n>\n> \n\n> The index contains the unmerged versions of the file. Possibly also the\n> version with conflict markers, but it's been too long since I last\n> checked.\n\nParaphrasing, is this correct? \n\n \"the index contains both versions of the unmerged file; any file\n with more than one version in the index is unmerged\".\n\nSo what 'git add' does in this case is replace both versions of the file\nin the index with a new version.\n\nI was not aware that the git system could support more than one version\nof a file in one branch. That makes it more like monotone :).\n\n> If you apply a stash with unmerged paths to a worktree/index, possibly\n> containing unmerged paths of its own, possibly getting new unmerged\n> paths by failing to apply the stash, you get unmerged paths from several\n> different unresolved conflicts.\n\nYes; doing too many things at once is a bad idea. But that should never\ncause git to lose data or do something wrong.\n\nAt the same time, it seems all unmerged paths result from unresolved\nmerge conflicts, so the two notions are equivalent for git?\n\n> Git has no idea about the history of unmerged paths. So having \"git\n> add\" modify the operation of \"git reset\" whenever \"git add\" overwrites\n> an unmerged path in the index could lead to quite funny results.\n\nOk; I'll take that as describing a large class of \"bad thing\" use cases.\n\n-- \n-- Stephe\n"},{"id":"235645","messageId":"xmqqeh2nw2p4.fsf@gitster.dls.corp.google.com","threadId":"35945","inReplyTo":"85fvn40ws9.fsf@stephe-leake.org","subject":"Re: `git stash pop` UX Problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-28T17:45:59Z","receivedAt":"2014-02-28T17:45:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephen Leake writes:\n\n> Matthieu Moy writes:\n>\n>> lists@haller-berlin.de (Stefan Haller) writes:\n>>\n>>> Your intention was clearly to drop the stash, it just wasn't dropped\n>>> because of the conflict. Dropping it automatically once the conflict\n>>> is resolved would be nice.\n>>\n>> Your intention when you ran \"git stash pop\", yes. Your intention when\n>> you ran \"git add\", I call that guessing.\n>\n> You might be adding other files for other reasons. But if you add a file\n> that does resolve a conflict caused by 'git stash pop', it is not\n> guessing.\n\nThe only thing you know for sure is that the user has consumed _one_\npart of the stashed change, no? What if the stash had changes for\nmore than one path?\n\nAt the time of \"git add $path\", can you reliably tell if the\nconflict to the $path the user is resolving came from a previous\n\"git stash pop\", not from any other mergy operations, e.g. \"git\nstash apply\" or \"git apply -3\"?\n"},{"id":"235659","messageId":"vpqy50vt4az.fsf@anie.imag.fr","threadId":"35945","inReplyTo":"85r46n168a.fsf@stephe-leake.org","subject":"Re: `git stash pop` UX Problem","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-02-28T19:39:32Z","receivedAt":"2014-02-28T19:39:32Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Stephen Leake writes:\n\n> I was not aware that the git system could support more than one version\n> of a file in one branch. \n\nThe index only. The history itself does not.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235661","messageId":"vpqppm7t41g.fsf@anie.imag.fr","threadId":"35945","inReplyTo":"85vbvz171p.fsf@stephe-leake.org","subject":"Re: `git stash pop` UX Problem","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-02-28T19:45:15Z","receivedAt":"2014-02-28T19:45:15Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Stephen Leake writes:\n\n> So a message \"merge complete; you can drop the stash\" would be the most\n> git should do.\n\n>From the user experience point of view, that would be good. It could\nbother some users, but we have advice.* to silent this kind of warnings.\n\n>From the implementation point of view, it's much harder than it seems\nbecause as other pointed out, Git does not know that the merge conflicts\ncomes from, so as it is, the best it could say is \"merge complete; you\ncan now proceed\". Thas is a solvable problem (git stash could leave a\nfile like .git/conflicted-stash, and git add could look for this file\nand remove it), but I can't think of an implementation that would not be\nreally awful. For example, \"git reset\" should also remove the file, and in\ngeneral a substancial subset of Git's command would need to be aware of\nthe status of git stash.\n\nSo, I wouldn't object, but I don't think the implementation cost is\nworth the benefit.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235704","messageId":"85fvn21fbd.fsf@stephe-leake.org","threadId":"35945","inReplyTo":"vpqppm7t41g.fsf@anie.imag.fr","subject":"Re: `git stash pop` UX Problem","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-03-01T08:41:26Z","receivedAt":"2014-03-01T08:41:26Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Matthieu Moy writes:\n\n> Stephen Leake writes:\n>\n>> So a message \"merge complete; you can drop the stash\" would be the most\n>> git should do.\n>\n> From the user experience point of view, that would be good. It could\n> bother some users, but we have advice.* to silent this kind of warnings.\n>\n> \n>\n> So, I wouldn't object, but I don't think the implementation cost is\n> worth the benefit.\n\nOk, that makes sense.\n\n-- \n-- Stephe\n"},{"id":"235705","messageId":"85bnxq1f0v.fsf@stephe-leake.org","threadId":"35945","inReplyTo":"xmqqeh2nw2p4.fsf@gitster.dls.corp.google.com","subject":"Re: `git stash pop` UX Problem","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-03-01T08:47:44Z","receivedAt":"2014-03-01T08:47:44Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Junio C Hamano writes:\n\n> Stephen Leake writes:\n>\n>> Matthieu Moy writes:\n>>\n>>> lists@haller-berlin.de (Stefan Haller) writes:\n>>>\n>>>> Your intention was clearly to drop the stash, it just wasn't dropped\n>>>> because of the conflict. Dropping it automatically once the conflict\n>>>> is resolved would be nice.\n>>>\n>>> Your intention when you ran \"git stash pop\", yes. Your intention when\n>>> you ran \"git add\", I call that guessing.\n>>\n>> You might be adding other files for other reasons. But if you add a file\n>> that does resolve a conflict caused by 'git stash pop', it is not\n>> guessing.\n>\n> The only thing you know for sure is that the user has consumed _one_\n> part of the stashed change, no? What if the stash had changes for\n> more than one path?\n\nCount the unmerged paths in the index; when the count is zero, all\nconflicts are resolved.\n\npaths in the stash that had no conflicts are already in the index.\n\nSo _if_ there is nothing going on except finishing the stash pop, an\nunmerged path count of zero means you are done with the stash, and it\ncan be dropped.\n\n> At the time of \"git add $path\", can you reliably tell if the\n> conflict to the $path the user is resolving came from a previous\n> \"git stash pop\", not from any other mergy operations, e.g. \"git\n> stash apply\" or \"git apply -3\"?\n\nThis is the real problem. I can impose a rule on my team of \"don't do\nmore than one merge at a time\" by implementing that in the front-end,\nbut git can't assume that.\n\n-- \n-- Stephe\n"}]}