All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.