Thread (8 messages) flat view 8 messages, 7 authors, 2016-06-15

Re: Usability of git stash

From: Jeff King <hidden>
Date: 2016-06-15 22:45:30

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help