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, -- Brandon McCaig <bamcc...@gmail.com> <bamcc...@castopulence.org> Castopulence Software <https://www.castopulence.org/> Blog <http://www.bamccaig.com/> perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }. q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.}; tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say' -- 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
