git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: `git stash pop` UX Problem

From
OOOmar Othman <omar.othman@booking.com>
Date
Feb 25, 2014, 14:12 UTC
Message-ID
<530CA4C9.60601@booking.com>
In-Reply-To
<vpqlhwz5o58.fsf@anie.imag.fr>
Show 10 quoted lines
>> Please note that what I am asking for is not always dropping the
>> stash, but doing that *only* when the merge conflict is resolved. This
>> is simply getting the whole command to be consistent. If you do `git
>> stash pop` and it succeeds, the stash reference is dropped. If you do
>> git stash pop` and it succeeds *after resolving the merge conflict*,
>> the stash reference is *not* dropped. This is *not* consistent and
>> *is* a user experience problem. I'm not asking about dumbing git down
>> by any means.
> Can you describe precisely what you would expect, e.g. what Git's output
> should look like after such and such command?
Sure. This is my current command prompt (which shows git's internal status):
[omar_othman main (trunk*)]$
I do a git stash pop, which causes a merge conflict:

Auto-merging path/to/file.txt CONFLICT (content): Merge conflict in path/to/file.txt

[omar_othman main (trunk|MERGING*)]$ vi path/to/file.txt [omar_othman main (trunk|MERGING*)]$ git add path/to/file.txt [omar_othman main (trunk*)]$

Note how the status message has changed to show that git is now happy. It is at that moment that the stash reference should be dropped (or the user (somehow) is notified to do that herself if desired), because this means that the popping operation has succeeded.

Previous: Matthieu MoyNext: Matthieu Moy
Message 19 of 46 in “`git stash pop` UX Problem”
  1. Omar OthmanFeb 24, 2014
  2. Brandon McCaigFeb 24, 2014
  3. Matthieu MoyFeb 24, 2014
  4. Holger HellmuthFeb 25, 2014
  5. Matthieu MoyFeb 25, 2014
  6. Omar OthmanFeb 25, 2014
  7. Junio C HamanoFeb 25, 2014
  8. Stephen LeakeFeb 25, 2014
  9. Junio C HamanoFeb 25, 2014
  10. Stephen LeakeFeb 27, 2014
  11. Omar OthmanFeb 26, 2014
  12. Theodore Ts'oFeb 26, 2014
  13. brian m. carlsonFeb 25, 2014
  14. Omar OthmanFeb 26, 2014
  15. Simon RuderichFeb 26, 2014
  16. Stephen LeakeFeb 27, 2014
  17. Omar OthmanFeb 25, 2014
  18. Matthieu MoyFeb 25, 2014
  19. Omar OthmanFeb 25, 2014
  20. Matthieu MoyFeb 25, 2014
  21. Stephen LeakeFeb 25, 2014
  22. Junio C HamanoFeb 25, 2014
  23. Stefan HallerFeb 26, 2014
  24. Matthieu MoyFeb 26, 2014
  25. Stephen LeakeFeb 28, 2014
  26. Brandon McCaigFeb 28, 2014
  27. Stephen LeakeFeb 28, 2014
  28. Matthieu MoyFeb 28, 2014
  29. Stephen LeakeFeb 28, 2014
  30. Matthieu MoyFeb 28, 2014
  31. Stephen LeakeMar 1, 2014
  32. David KastrupFeb 28, 2014
  33. Stephen LeakeFeb 28, 2014
  34. Matthieu MoyFeb 28, 2014
  35. Junio C HamanoFeb 28, 2014
  36. Stephen LeakeMar 1, 2014
  37. Omar OthmanFeb 26, 2014
  38. Matthieu MoyFeb 26, 2014
  39. Junio C HamanoFeb 26, 2014
  40. Matthieu MoyFeb 26, 2014
  41. Junio C HamanoFeb 26, 2014
  42. David KastrupFeb 26, 2014
  43. Junio C HamanoFeb 26, 2014
  44. David KastrupFeb 27, 2014
  45. Stephen LeakeFeb 28, 2014
  46. Stephen LeakeFeb 27, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.