Re: `git stash pop` UX Problem

Brandon McCaig [off-list ref] writes:

Unlike a merge, when you pop a stash that history is lost. If you
screw up the merge and the stash is dropped then there's generally no
reliable way to get it back. I think that it's correct behavior for
the stash to not be dropped if the merge conflicts.

Agreed.

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

An obvious issue is that at this point Git has no way to know that you
just did a "git stash pop". But that could be solved by leaving a file
around like .git/stash-pop-ongoing.

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.

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

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Am 24.02.2014 17:21, schrieb Matthieu Moy:

$ git add foo.txt
$ git status
On branch master
Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)

         modified:   foo.txt

Maybe status should display a stash count if that count is > 0, as this is part of the state of the repo.

$ git status
On branch master
Stashes: 1                         <----------
Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)

          modified:   foo.txt

It would be in Omars example case a clear message that git kept the stash. And generally a reminder that there is still a stash around that might or might not be obsolete.

On Mon, Feb 24, 2014 at 05:21:40PM +0100, Matthieu Moy wrote:

One easy thing to do OTOH would be to show a hint at the end of "git
stash pop"'s output, like

I think that's a good idea. It makes it obvious that Git has kept
the stash and that the user should drop it when he's done - if he
wants to.

$ 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

Maybe just the following to keep the output on a single line:

    Use 'git stash drop' to remove the stash after resolving the conflicts.

But maybe that's too short as it doesn't mention explicitly, that
the stash was kept.

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

Am 24.02.2014 17:21, schrieb Matthieu Moy:

quoted

$ git add foo.txt
$ git status
On branch master
Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)

         modified:   foo.txt

Maybe status should display a stash count if that count is > 0, as this is part of the state of the repo.

$ git status
On branch master
Stashes: 1                         <----------
Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)

          modified:   foo.txt

It would be in Omars example case a clear message that git kept the stash. And generally a reminder that there is still a stash around that might or might not be obsolete.

Again, the same comment: If there is a way to customize git's messages by turning them on/off (or, even cooler, the ability to change their wording) then this is also a nice option to have and we can turn it off by default if we find that most people (here at least) don't like it. I don't know whether you guys have discussed this option before (or does it exist? I doubt, but I don't know), because having such an option (the ability to turn messages on/off or change their wording and what internal status information they manifest) will really resolve all kinds of such potential conflicts of preferences. Even cooler, people will be able to change the wording to their native languages for example.