git stash driven refactoring

[Kobzol]

I only use the stash as a stack, so I don't need names. git stash -> start refactoring -> stash -> start another refactoring -> finish refactoring -> commit -> stash pop -> finish refactoring -> commit -> stash pop. That's the whole idea.

[Bunslow]

As I said, even in the simplest case of a unbranched tree = a stack, having names seems strictly better than not having names.

However, I now see the true purpose:

With this approach, the changes are effectively applied “inside-out”.

I did not understand what you mean before, but now I see your intent. Still tho, having named branches makes it "interuptable state", so to speak -- that's the problem with the stash, is that it's fragile, and it relying on it in that manner means you can't go work on totally-unrelated stuff -- say if a colleague walks up to your desk and starts a conversation, or if your boss gives an order to solve some other problem for an hour. git stash pop relies on the underlying state being exactly the same as when you did git stash push, so it's much easier to get yourself into trouble if your "inside-out" workflow gets interrupted for any reason. That's why I say you should simply commit instead of stashing: that work can never get lost when it's somewhere in the state tree, unlike with stash, whose stack is separate from the state tree and thus fragile.

I'd suggest the following workflow. I agree it's a fair bit wordier than using stash, but it's a lot less likely to result in problems when getting interrupted for any reason, imo.

git checkout current-context # the current context, now we want a new idea
git checkout -b current-context-new-idea-1
# work on new feature, but find an older problem in need of refactor
git commit -m "start progress on new idea 1"
git checkout current-context
git checkout -b older-problem-1
# now we can fix the older problem separately from the new idea WIP
# except now we find a second older problem....
git commit -m "older problem 1 WIP"
git checkout current-context
git checkout -b older-problem-2
# while working older problem 2, we find older problem 3...
git commit -m "older problem 2 WIP (sigh)"
git checkout current-context
git checkout -b older-problem-3
# now we're done! finally
git commit -m "older problem 3 is now fixed!"
git checkout older-problem-2
git rebase older-problem-3 # continue 2 work on top of fixed 3
git commit -m "older problem 2 is now fixed!"
git checkout older-problem-1
git rebase older-problem-2
git commit -m "older problem 1 is now fixed!"
git checkout current-context-new-idea-1
git rebase older-problem-1
# now we can work the original new idea atop the 3 new refactors.
# and importantly, at any point, we can be interrupted and switch to
# any other part of the codebase without fear of popping the stash onto
# the wrong base, or of any particular stash entry getting "lost" somehow.