On Sun, Oct 19, 2008 at 11:40:30AM -0700, Shawn O. Pearce wrote: > Ditto. I never use "git stash". Its command line usage is too > unfriendly for me, so I tend to prefer making WIP commits. If I > need to stash something I'll do: > > git commit -a -m wip > ... some time later .. > git checkout branch > git reset --soft HEAD^ That's what I do, too, except when I want to move changes from one branch to another, or split some changes from their history. So something like: git checkout next ;# which is where I usually am anyway hack hack hack # oops, I have been building this directly on top of next and it # really needs to be a feature-branch on maint git stash git checkout -b jk/maint-fix-whatever origin/maint git stash apply The equivalent non-stash commands would be "commit -m wip" and "cherry-pick". But the stash saves me the trouble later of having to delete the wip cruft on top of next. Side note: obviously this uses the stash only as a push/pop stack. I have never personally had a situation where I wanted a named stash or multiple stashes over a wip commit. > Personally I wish git-stash wasn't invented the way it is. I would > have rather seen it as macros to do a quick: > > git commit -m wip-index-state > git commit -A -m wip-worktree-state > > and unwind it with essentially: > > git reset --mixed HEAD^ > git reset --soft HEAD^ I disagree. I think the strength of stash is that it is divorced from the history. So it is more like a cherry-pick (or diff | apply, which is what it was intended to replace). > time they ran the stash. I think its rare you'd stash something > then switch to another branch to apply it. But that could easily > be done with cherry-pick. I guess we are viewing the tool oppositely. :) -Peff -- 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
