Introduce "git stash --continue" and "git stash --abort"?

[Tao Klerks <tao@klerks.biz>]

Hi folks,

I've spent a little time trying to understand how git stash behaves,
and understanding the differences wrt how a "naive user" (eg me?)
would expect it to.

So far most of the differences are about defaults, eg:
* I would expect "git stash push" (or "git stash") to
"--include-untracked" by default
* I would expect "git stash pop" to include "--index" by default
* I would expect "git checkout" (or at least "git switch") to have an
"--autostash" option like "git rebase" and "git merge" do

There's one "bigger" thing though, that sounds like a whole project:
The behavior of "stash pop" in the case of conflicts is somewhat
traumatizing:

* My worktree is left in a "conflicted" state, and the only way to
"back out" seems to be some sort of "reset" (but good luck figuring
out which one, or how to revert the stash-based changes without
impacting any other uncommitted changes that I had in my worktree)

* If I "forge on", resolve the conflicts, and stage the conflicted
files... my stash stack still contains something that I didn't intend
it to, until/unless I remember to "git stash drop"... which is an
unsafe (non-idempotent / not-easily-reversible) operation...

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.

I understand Brian M. Carlson has been working on big changes around
stash export, and Victoria Dye has been working on Sparse Index
support, but I'm not aware of any other major ongoing work from
skimming the mailing list in the past months.

Is this kind of direction one that's been considered before? Are there
reasons why it's a bad idea?

Thanks,
Tao