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
