From: Junio C Hamano <gitster@pobox.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: Omar Othman <omar.othman@booking.com>,
Brandon McCaig <bamccaig@gmail.com>,
git@vger.kernel.org
Subject: Re: `git stash pop` UX Problem
Date: Wed, 26 Feb 2014 11:36:09 -0800 [thread overview]
Message-ID: <xmqqd2i94qfq.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <vpqzjlez3c4.fsf@anie.imag.fr> (Matthieu Moy's message of "Wed, 26 Feb 2014 09:27:07 +0100")
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Omar Othman <omar.othman@booking.com> writes:
>
>> 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.
>
> Just saying "You have X stash" is OK to me as long as there is an option
> to deactivate it.
>
> Hinting "You should now run "git stash drop"." OTOH is far more dangerous
> if guessed wrong. Keeping a stash active when you don't need it does no
> real harm, but droping one you actually needed is data loss.
Yes, definitely.
I'm inclined to say that we should go in the direction you suggested
earlier in Message-ID: <vpqlhx0a3cb.fsf@anie.imag.fr>, that is:
>> 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:
>>
>> git stash drop
>>
>> or so (I couldn't find a concise yet accurate wording).
I'd however have to say that even "please resolve the conflicts
manually" is over-assuming.
I often start some WIP of a fix, realize that the fix should apply
to a lot older maintenance branch than where I happened to have
started the WIP (which typically is at the tip of somebody else's
branch where I received the series from the list---and then noticed
some existing breakage that needs to be fixed), stash the WIP, and
then repeat:
(1) checkout an old maintenance track;
(2) try to pop;
(3) if it succeeds, stop the iteration;
(4) otherwise, reset and go back to (1) to checkout a bit newer
maintenance track.
to decide. So "resolve the conflicts" is assuming the intention of
the user who issued "pop" too much (let alone "manually"---it does
not matter how the user resolves conflicts---the only thing we want
to say is Git did all it would and no further automated help in
resolving is availble, but "manually" is not quite the word).
"The stash was not dropped" is the most important thing in your
additional text. How about rephrasing like this?
$ git stash pop
Auto-merging foo.txt
CONFLICT (content): Merge conflict in foo.txt
The stashed change could not be replayed cleanly, leaving
conflicts in the working tree. The stash was not dropped in case
you need it again.
After you are done with the stash, you may want to "git stash
drop" to discard it.
next prev parent reply other threads:[~2014-02-26 19:36 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
2014-02-26 8:27 ` Matthieu Moy
2014-02-26 19:36 ` Junio C Hamano [this message]
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=xmqqd2i94qfq.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=bamccaig@gmail.com \
--cc=git@vger.kernel.org \
--cc=omar.othman@booking.com \
/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.