From: Omar Othman <omar.othman@booking•com>
To: Brandon McCaig <bamccaig@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: `git stash pop` UX Problem
Date: Tue, 25 Feb 2014 14:06:07 +0100 [thread overview]
Message-ID: <530C953F.9050805@booking.com> (raw)
In-Reply-To: <CANUGeEbPrPp8Sa-KEKSxNDWJShdkDBTkQyXv7tDJ6ReH6MXrHw@mail.gmail.com>
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@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,
>
>
next prev parent reply other threads:[~2014-02-25 13:06 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-24 8:32 `git stash pop` UX Problem Omar Othman
2014-02-24 16:04 ` Brandon McCaig
2014-02-24 16:21 ` Matthieu Moy
2014-02-25 12:14 ` Holger Hellmuth
2014-02-25 12:33 ` Matthieu Moy
2014-02-25 13:02 ` Omar Othman
2014-02-25 19:12 ` Junio C Hamano
2014-02-25 20:48 ` Stephen Leake
2014-02-25 22:20 ` Junio C Hamano
2014-02-27 13:18 ` Stephen Leake
2014-02-26 7:37 ` Omar Othman
2014-02-26 15:17 ` Theodore Ts'o
2014-02-25 23:50 ` brian m. carlson
2014-02-26 7:34 ` Omar Othman
2014-02-26 0:39 ` Simon Ruderich
2014-02-27 13:22 ` Stephen Leake
2014-02-25 13:06 ` Omar Othman [this message]
2014-02-25 13:15 ` Matthieu Moy
2014-02-25 14:12 ` Omar Othman
2014-02-25 15:25 ` Matthieu Moy
2014-02-25 20:52 ` Stephen Leake
2014-02-25 22:23 ` Junio C Hamano
2014-02-26 10:24 ` Stefan Haller
2014-02-26 10:45 ` Matthieu Moy
2014-02-28 2:57 ` Stephen Leake
2014-02-28 4:50 ` Brandon McCaig
2014-02-28 15:12 ` Stephen Leake
2014-02-28 15:42 ` Matthieu Moy
2014-02-28 17:27 ` Stephen Leake
2014-02-28 19:45 ` Matthieu Moy
2014-03-01 8:41 ` Stephen Leake
2014-02-28 16:02 ` David Kastrup
2014-02-28 17:45 ` Stephen Leake
2014-02-28 19:39 ` Matthieu Moy
2014-02-28 17:45 ` Junio C Hamano
2014-03-01 8:47 ` Stephen Leake
2014-02-26 7:28 ` Omar Othman
2014-02-26 8:27 ` Matthieu Moy
2014-02-26 19:36 ` Junio C Hamano
2014-02-26 19:46 ` Matthieu Moy
2014-02-26 20:20 ` Junio C Hamano
2014-02-26 20:33 ` David Kastrup
2014-02-26 22:17 ` Junio C Hamano
2014-02-27 0:19 ` David Kastrup
2014-02-28 3:00 ` Stephen Leake
2014-02-27 13:25 ` Stephen Leake
-- strict thread matches above, loose matches on Subject: below --
2014-02-24 8:33 Omar Othman
2014-02-27 11:23 Damien Robert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=530C953F.9050805@booking.com \
--to=omar.othman@booking$(echo .)com \
--cc=bamccaig@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox