Re: `git stash pop` UX Problem

[Brandon McCaig <bamccaig@gmail.com>]

Omar:

On Mon, Feb 24, 2014 at 3:32 AM, Omar Othman <omar.othman@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 <bamccaig@gmail.com> <bamccaig@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'