From: Omar Othman <omar.othman@booking.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: Brandon McCaig <bamccaig@gmail.com>, git@vger.kernel.org
Subject: Re: `git stash pop` UX Problem
Date: Wed, 26 Feb 2014 08:28:58 +0100 [thread overview]
Message-ID: <530D97BA.1080107@booking.com> (raw)
In-Reply-To: <vpqeh2r43kx.fsf@anie.imag.fr>
>> [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
next prev parent reply other threads:[~2014-02-26 7:29 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
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 [this message]
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=530D97BA.1080107@booking.com \
--to=omar.othman@booking.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=bamccaig@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).