Re: `git stash pop` UX Problem
Well, it's called `git stash` and not `git trash`... :-D That's your own usage of it, but its main usage is different. This is not a solution, but it's better than nothing and I second it. On 25-02-14 13:33, Matthieu Moy wrote: Holger Hellmuth hellm...@ira.uka.de writes: Am 24.02.2014 17:21, schrieb Matthieu Moy: $ git add foo.txt $ git status On branch master Changes to be committed: (use git reset HEAD file... to unstage) modified: foo.txt Maybe status should display a stash count if that count is 0, as this is part of the state of the repo. Maybe it would help some users, but not me for example. My main use of git stash is a safe replacement for git reset --hard: when I want to discard changes, but keep them safe just in case. So, my stash count is almost always 0, and I don't want to hear about it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: `git stash pop` UX Problem
Brandon: Please note that what I am asking for is not always dropping the stash, but doing that *only* when the merge conflict is resolved. This is simply getting the whole command to be consistent. If you do `git stash pop` and it succeeds, the stash reference is dropped. If you do `git stash pop` and it succeeds *after resolving the merge conflict*, the stash reference is *not* dropped. This is *not* consistent and *is* a user experience problem. I'm not asking about dumbing git down by any means. On 24-02-14 17:04, Brandon McCaig wrote: Omar: On Mon, Feb 24, 2014 at 3:32 AM, Omar Othman omar.oth...@booking.com wrote: In general, whenever something a user should do, git always tells. So, for example, when things go wrong with a merge, you have the option to abort. When you are doing a rebase, git tells you to do git commit --amend, and then git rebase --continue... and so on. The point is: Because of this, git is expected to always instruct you on what to do next in a multilevel operation, or instructing you what to do when an operation has gone wrong. Now comes the problem. When you do a git stash pop, and a merge conflict happens, git correctly tells you to fix the problems and then git add to resolve the conflict. But once that happens, and the internal status of git tells you that there are no more problems (I have a prompt that tells me git's internal status), the operation is not culminated by dropping the stash reference, which what normally happens automatically after a git stash pop. This has actually confused me for a lot of time, till I ran into a git committer and asked him, and only then were I 100% confident that I did nothing wrong and it is indeed a UX problem. I wasted a lot of time to know why the operation is not completed as expected (since I trusted that git just does the right thing), and it turned out that it is git's fault. If this is accepted, please reply to this email and tell me to start working on it. I've read the Documenation/SubmittingPatches guidelines, but I'll appreciate also telling me where to base my change. My guess is maint, since it's a bug in the sense of UX. Unlike a merge, when you pop a stash that history is lost. If you screw up the merge and the stash is dropped then there's generally no reliable way to get it back. I think that it's correct behavior for the stash to not be dropped if the merge conflicts. The user is expected to manually drop the stash when they're done with it. It's been a while since I've relied much on the stash (commits and branches are more powerful to work with) so I'm not really familiar with what help the UI gives when a conflict occurs now. Git's UI never really expects the user to be negligent. It does help to hint to you what is needed, but for the most part it still expects you to know what you're doing and does what you say, not what you mean. If there's any change that should be made it should be purely providing more detailed instructions to the user about how to deal with it. Either resolve the merge conflicts and git-add the conflicting files, or use git-reset to either reset the index (unstaging files nad clear) or reset index and working tree back to HEAD. In general, I almost always git-reset after a git-stash pop because I'm probably not ready to commit those changes yet and generally want to still see those changes with git diff (without --staged). Or perhaps just direct them to the appropriate sections of the man pages. I'm not really in favor of dumbing down Git in any way and I think that any step in that direction would be for the worst... Software should do what you say, not what you mean, because it's impossible to reliably guess what you meant. When a git-stash pop operation fails that might make the user rethink popping that stash. That's why it becomes a manual operation to drop it if still desired. And unlike git-reset --continue, which is explicitly the user saying it is fixed and I accept the consequences, let's move on, there is no such option to git-stash to acknowledge that the merge conflicts have been resolved and you no longer need that stash (aside from git-stash drop, of course). It's not a UI problem. It's maybe a documentation problem, but again I'm not familiar with the current state of that. /not a git dev...yet Regards, -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: `git stash pop` UX Problem
Please note that what I am asking for is not always dropping the stash, but doing that *only* when the merge conflict is resolved. This is simply getting the whole command to be consistent. If you do `git stash pop` and it succeeds, the stash reference is dropped. If you do git stash pop` and it succeeds *after resolving the merge conflict*, the stash reference is *not* dropped. This is *not* consistent and *is* a user experience problem. I'm not asking about dumbing git down by any means. Can you describe precisely what you would expect, e.g. what Git's output should look like after such and such command? Sure. This is my current command prompt (which shows git's internal status): [omar_othman main (trunk*)]$ I do a git stash pop, which causes a merge conflict: Auto-merging path/to/file.txt CONFLICT (content): Merge conflict in path/to/file.txt [omar_othman main (trunk|MERGING*)]$ vi path/to/file.txt [omar_othman main (trunk|MERGING*)]$ git add path/to/file.txt [omar_othman main (trunk*)]$ Note how the status message has changed to show that git is now happy. It is at that moment that the stash reference should be dropped (or the user (somehow) is notified to do that herself if desired), because this means that the popping operation has succeeded. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: `git stash pop` UX Problem
[omar_othman main (trunk|MERGING*)]$ git add path/to/file.txt [omar_othman main (trunk*)]$ Note how the status message has changed to show that git is now happy. It is at that moment that the stash reference should be dropped Dropping the stash on a git add operation would be really, really weird... (or the user (somehow) is notified to do that herself if desired), because this means that the popping operation has succeeded. But how would you expect to be notified? Answering the last question, your previous comments are fine with me: If there's any change that should be made it should be purely providing more detailed instructions to the user about how to deal with it. Yes, there may be room for improvement, but that does not seem so easy. Today, we have: $ git stash pop Auto-merging foo.txt CONFLICT (content): Merge conflict in foo.txt $ git status On branch master Unmerged paths: (use git reset HEAD file... to unstage) (use git add file... to mark resolution) both modified: foo.txt = The advices shown here are OK. Then: $ git add foo.txt $ git status On branch master Changes to be committed: (use git reset HEAD file... to unstage) modified: foo.txt = here, git status could have hinted the user you may now run 'git stash drop' if you are satisfied with your merge. Though I don't know why you think this is important: Now, the real question is: when would Git stop showing this advice. I don't see a real way to answer this, and I'd rather avoid doing just a guess. If it is really annoying for the user, we can just have a configuration parameter to switch this message on/off. I don't know whether git has such customizations (in general) currently. This is very useful (maybe we can agree on wording later): One easy thing to do OTOH would be to show a hint at the end of git stash pop's output, like $ git stash pop Auto-merging foo.txt CONFLICT (content): Merge conflict in foo.txt 'stash pop' failed. Please resolve the conflicts manually. The stash was not dropped in case you need to restart the operation. When you are done resolving the merge, you may run the following to drop the stash reference: git stash drop -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: `git stash pop` UX Problem
Am 24.02.2014 17:21, schrieb Matthieu Moy: $ git add foo.txt $ git status On branch master Changes to be committed: (use git reset HEAD file... to unstage) modified: foo.txt Maybe status should display a stash count if that count is 0, as this is part of the state of the repo. $ git status On branch master Stashes: 1 -- Changes to be committed: (use git reset HEAD file... to unstage) modified: foo.txt It would be in Omars example case a clear message that git kept the stash. And generally a reminder that there is still a stash around that might or might not be obsolete. Again, the same comment: If there is a way to customize git's messages by turning them on/off (or, even cooler, the ability to change their wording) then this is also a nice option to have and we can turn it off by default if we find that most people (here at least) don't like it. I don't know whether you guys have discussed this option before (or does it exist? I doubt, but I don't know), because having such an option (the ability to turn messages on/off or change their wording and what internal status information they manifest) will really resolve all kinds of such potential conflicts of preferences. Even cooler, people will be able to change the wording to their native languages for example. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: `git stash pop` UX Problem
Matthieu Moy matthieu@grenoble-inp.fr writes: Holger Hellmuth hellm...@ira.uka.de writes: Am 24.02.2014 17:21, schrieb Matthieu Moy: $ git add foo.txt $ git status On branch master Changes to be committed: (use git reset HEAD file... to unstage) modified: foo.txt Maybe status should display a stash count if that count is 0, as this is part of the state of the repo. Maybe it would help some users, but not me for example. My main use of git stash is a safe replacement for git reset --hard: when I want to discard changes, but keep them safe just in case. So, my stash count is almost always 0, and I don't want to hear about it. status is about reminding the user what changes are already in the index (i.e. what you would commit) and what changes are in the working tree, from which you could further update the index with (i.e. what you could commit). One _could_ argue that stashed changes are what could be reflected to the working tree and form the source of the latter, but my gut feeling is that it is a rather weak argument. At that point you are talking about what you could potentially change in the working tree, and the way to do so is not limited to stash pop (i.e. you can git cherry-pick --no-commit $a_commit, or edit any file in the working tree for that matter, with the same ease). So, I tend to agree with you, while I do understand where I want to know about what is in stash is coming from (and that is why we do have git stash list command). Same comment. Everyone will have his own opinion. As long as the messages are not customizable, we can debate for hours and everybody has a valid point. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
`git stash pop` UX Problem
Hi there, I'm fairly new to git and I wanted to ask about a certain behavior that I want to fix myself (if you agree with me that it is a misbehavior)... since I've never contributed to open source and it'll be an important step for me to start and get something done. In general, whenever something a user should do, git always tells. So, for example, when things go wrong with a merge, you have the option to abort. When you are doing a rebase, git tells you to do git commit --amend, and then git rebase --continue... and so on. The point is: Because of this, git is expected to always instruct you on what to do next in a multilevel operation, or instructing you what to do when an operation has gone wrong. Now comes the problem. When you do a git stash pop, and a merge conflict happens, git correctly tells you to fix the problems and then git add to resolve the conflict. But once that happens, and the internal status of git tells you that there are no more problems (I have a prompt that tells me git's internal status), the operation is not culminated by dropping the stash reference, which what normally happens automatically after a git stash pop. This has actually confused me for a lot of time, till I ran into a git committer and asked him, and only then were I 100% confident that I did nothing wrong and it is indeed a UX problem. I wasted a lot of time to know why the operation is not completed as expected (since I trusted that git just does the right thing), and it turned out that it is git's fault. If this is accepted, please reply to this email and tell me to start working on it. I've read the Documenation/SubmittingPatches guidelines, but I'll appreciate also telling me where to base my change. My guess is maint, since it's a bug in the sense of UX. Thanks and sorry for the long email. -- Best Regards, Omar Othman -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
`git stash pop` UX Problem
Hi there, I'm fairly new to git and I wanted to ask about a certain behavior that I want to fix myself (if you agree with me that it is a misbehavior)... since I've never contributed to open source and it'll be an important step for me to start and get something done. In general, whenever something a user should do, git always tells. So, for example, when things go wrong with a merge, you have the option to abort. When you are doing a rebase, git tells you to do git commit --amend, and then git rebase --continue... and so on. The point is: Because of this, git is expected to always instruct you on what to do next in a multilevel operation, or instructing you what to do when an operation has gone wrong. Now comes the problem. When you do a git stash pop, and a merge conflict happens, git correctly tells you to fix the problems and then git add to resolve the conflict. But once that happens, and the internal status of git tells you that there are no more problems (I have a prompt that tells me git's internal status), the operation is not culminated by dropping the stash reference, which what normally happens automatically after a git stash pop. This has actually confused me for a lot of time, till I ran into a git committer and asked him, and only then were I 100% confident that I did nothing wrong and it is indeed a UX problem. I wasted a lot of time to know why the operation is not completed as expected (since I trusted that git just does the right thing), and it turned out that it is git's fault. If this is accepted, please reply to this email and tell me to start working on it. I've read the Documenation/SubmittingPatches guidelines, but I'll appreciate also telling me where to base my change. My guess is maint, since it's a bug in the sense of UX. Thanks and sorry for the long email. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
