Thread (1 message) 1 message, 1 author, 2016-06-15

Re: `git stash pop` UX Problem

From: David Kastrup <hidden>
Date: 2016-06-15 23:00:00

Matthieu Moy [off-list ref] writes:
Junio C Hamano [off-list ref] writes:
quoted
I'd however have to say that even "please resolve the conflicts
manually" is over-assuming.
I understand your point, but in a short hint message, I still find it
reasonable. Fixing conflicts is the natural way to go after a "stash
pop", and the user who do not want to go this way probably knows why.
quoted
"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.
I'm fine with this, but it's even longer than mine which I already found
too long. Perhaps the "leaving conflicts in the working tree" could be
dropped, as the message follows "CONFLICT (content): Merge conflict in
foo.txt".
All that verbosity...

$ git stash pop
Auto-merging foo.txt
CONFLICT (content): Merge conflict in foo.txt
Cowardly refusing to drop stash.
$

-- 
David Kastrup
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help