Re: What's cooking in git.git (topics)

Brandon Casey <casey@nrlssc.navy.mil> writes:

That's what I thought initially. But after thinking about it a bit, I do not think so anymore.

It feels limiting not to be able to stash here and unstash there. You cannot stash on one branch and apply on another as easily (you should still be able to, by naming the stash explicitly, if you really wanted to).

But why would one even want to? "What I've been hacking on is getting into a good shape but now I noticed I was on a wrong branch", is probably the only reason. But that is what branch switching "git checkout" (and its -m variant) does. If your changes are something that would make "checkout -m" conflict, stashing and unstashing will result in the same conflict anyway, so nothing is lost.

And there are obvious advantages to per-branch stash. "stash list" would contain only changes related to the current branch by default for one thing. "stash apply" without parameter would be context sensitive as well.

By the way, I also thought that "pop instead of delete" was too limiting. I tried to like "pop" and wanted to justify it, but I suspect it would invite user grief in this sequence:

        hack hack, gets interrupted
        git stash
        switch to another branch, service interrupt, and come back
        git stash pop
        hack hack, oops, I made a mess.

And earlier stash point was in a much better shape, but it has already been lost.

While the workflow with the current stash would be:
        
        hack hack, gets interrupted
        git stash
        switch to another branch, service interrupt, and come back
        git stash apply
        hack hack, oops, I made a mess.
        git reset --hard
        git stash apply
        git commit
        git stash clear