Re: Usability of git stash

["Shawn O. Pearce" <spearce@spearce.org>]

Anders Melchiorsen <mail@cup.kalibalik.dk> wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
> 
> > In exchange for allowing new users to stub their toe on new commands, the
> > work flow of more experienced users is made a little easier.
> 
> I wonder whether experienced users even use stash a lot. Personally,
> after getting my head around the DAG, and thus getting more
> comfortable with git reset, I tend to make "WIP" commits instead.

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^

> The primary thing that stash does for me is preserve the index state.
> Unfortunately, --index is not default for stash apply, so I often
> forget it.

I never find the index saving useful.  My commits are frequent
enough that losing the index state usually only costs me a few
minutes when I go back to the branch and pop the wip commit.
 
> Sometimes, I also want stash to store away changes to untracked files
> (to get a clean working directory), but that is not possible.

Indeed, that's an advantage of the wip commit approach, you can shove
the untracked files quickly into the wip commit, especially with 1.6:

	git commit -A -m wip


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^

then its a lot less black magic to users, as they can see it in the
DAG, and its more explicitly tied to the branch they were on at the
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.

-- 
Shawn.