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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.