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.othman@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html