Re: `git stash pop` UX Problem

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 26, 2014, 19:36 UTC
Message-ID: <xmqqd2i94qfq.fsf@gitster.dls.corp.google.com>
In-Reply-To: <vpqzjlez3c4.fsf@anie.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Show 15 quoted lines

> 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:

Show 13 quoted lines

>> 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.