Tao Klerks <tao@xxxxxxxxxx> writes: > I would expect that some sort of merge- or rebase-like "--continue or > --abort" facility would make this much easier to understand... but of > course I have no idea how one would go about doing that. I assume the > closest existing pattern would be "git cherry-pick", but I imagine I'm > missing lots of subtleties. > ... > Is this kind of direction one that's been considered before? Are there > reasons why it's a bad idea? I saw a few exchange on the intended use of "stash" on another thread in the past days, but I think the reason why the current set of defaults and behaviour are appropriate for "stash" is related to it. The intended use of "stash" is to clear the deck as quickly as possible to deal with "emergencies", and its behaviour comes from the need to support that use case effectively. Untracked cruft are often useful even when you do a "quick context switch" (aka "the boss suddenly appears and asks you to do something different real quick"), hence "-u" is not the default, for example. "stash pop" was the primary way to go back to where you were before the interruption, and such going back is expected to be done after the crisis is over when you can be more relaxed, and was expected to be done _after_ you "reset --hard" and/or "git switch" out of the crisis mode. And the natural way to recover from "eh, I moved back to a different commit---I wanted to go to the commit I was when I saved the stash" was "reset --hard" that would not lose anything new (and "stash branch" was later added to make the last one easier to do), for another example. Users are better off doing any large scale "I made a mess in the working tree with mixed changes, and I want to take time to separate them out" on separate (possibly temporary) branches, instead of using "stash save" + "stash pop". Any change that would make it more cumbersome for the primary intended purpose of "quick save" would be very much unwelcome, I would have to say. Thanks.
