Brandon Casey <casey@xxxxxxxxxxxxxxx> writes:
> Junio C Hamano wrote:
>
>> Also we may want to introduce a stash per branch if we do this.
>
> This isn't necessary for how I use stash.
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
