Usability of git stash

I find the UI of git stash quite unfortunate.

First, I would prefer list to be the default action, so that typing "git stash" in the hope of getting some help would not make me lose my local changes.

When trying to recover from that scenario, I do "git stash apply" as recommended by the "git stash" output. Now I still lost my index state, all changes are unstaged.

The "git command subcommand" syntax seems different from other git commands. For example, you do not delete a branch with "git branch delete".

The default naming of stashes makes it hard to remember what I was actually working on. Forcing me to give it a description (like branch and commit do) would probably have saved me some time overall.

And finally, a "git stash clear" has quite far-reaching consequences. Most other mistakes are easy to recover from, but not this one.

I offer these observations just for discussion. It has not been possible for me to think of any backwards compatible improvements, other than staying away from "git stash".

Cheers, Anders.

Anders Melchiorsen wrote:

See the documentation, apply has a '--index' option.

-brandon

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

Still, the shoot-yourself-in-the-foot potential is quite larger than appropriate for what is mostly workflow porcelaine. It is even larger than appropriate for plumbing IMHO.

I mean, even misspellings like git stash lisp

cause action that is not easily reversible, and the given help output is misleading with regard to index state.

David Kastrup wrote:

I think it is excessive to call the action taken by 'git stash', when it is unwanted, "shoot[ing]-yourself-in-the-foot". More like stub-your-toe.

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.

$ git stash lisp
Usage: git stash list [<options>]
   or: git stash (show | drop | pop ) [<stash>]
   or: git stash apply [--index] [<stash>]
   or: git stash branch <branchname> [<stash>]
   or: git stash [save [--keep-index] [<message>]]
   or: git stash clear

Maybe you are referring to the long since changed behavior where 'git stash' == 'git stash save' and so "lisp" in your example would have been taken as a stash description. This behavior existed for less than 6 months, and has been changed now for over 10 months.

-brandon

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

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.

After having used "git stash clear" at a bad time once, I am wary of stashing work that I actually want to keep. I prefer workflows where my mistakes can be (easily) corrected.

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.

Sometimes, I also want stash to store away changes to untracked files (to get a clean working directory), but that is not possible.

Maybe I just don't quite understand what git stash is about ...

Anders.

Anders Melchiorsen <mail@cup.kalibalik.dk> 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^

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.
 

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.

On 10/19/08, Shawn O. Pearce <spearce@spearce.org> wrote:

What version of git are you using? I am using git-1.6.0.2 on Linux and "-A" is illegal option for "git commit"

--Leo--

Leo Razoumov <slonik.az@gmail.com> wrote:

Oh.  Sorry.  I thought I saw a patch for that go by.  I guess I mean:

	git add -A && git commit

Hi,

Shawn O. Pearce wrote:

Just a side note: I, for example, have a stash in which some "valgrind ..." string is prepended to some lines in some test scripts. I apply the stash on different branches and after testing I reset the file (or checkout -f another branch). I never really want to commit these changes.

So, the alternative for this use case (if there was no git-stash) is to have a "valgrind" branch somewhere and do some "cherry-pick -n" of those commits, right?

Hmm, it seems that this is the better way in the long run. But "git-stash" seemed to be the natural way at first.

Regards,
  Stephan

Stephan Beyer <s-beyer@gmx.net> writes:

I'd just use an appropriate patch file kept around in a parent dir or something... :-)

-Miles

On Sun, Oct 19, 2008 at 11:40:30AM -0700, Shawn O. Pearce wrote:

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.

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).

I guess we are viewing the tool oppositely. :)

-Peff

Jeff King <peff@peff.net> writes:

The equivalent would be:

	git checkout -m -b jk/maint-fix-whatever origin/maint

no need for stash, wip-commit, nor cherry-pick.

The advantage of using "stash then stash apply" (not "stash pop") or "wip-commit with cherry-pick" is that you can reset, take a deep breath, and redo it, when the resulting merge conflict gets too hairy.

I agree with you; it really is the "diff saved somewhere, later applied".

Anders Melchiorsen <mail@cup.kalibalik.dk> writes:

I certainly do, and my impression is that some of the biggest boosters of stash have always been the git heavy hitters (it's certainly not one of these "implemented due to nagging by newbies" features)...

-Miles

Anders Melchiorsen wrote:

I use stash quite a lot. It's useful for me because my co-workers sometimes pull from me so I cannot use 'wip' commits (without annoying my co-workers anyway).

I never use "stash clear", but always do "stash pop", so my stash-stack is hardly ever deeper than one. It would be a lot worse for us to get a "wip" commit accidentally propagated and built on further. It's happened and it's no fun what so ever as it requires team coordination and rewrite of published history to get it back to a good state.

I commit regularly enough that it doesn't take me long at all to re-do the index changes.

git add . git stash --index

Anders Melchiorsen wrote:

There is another use for stash, as has previously been described by someone else on this list. That is for incrementally splitting up changes made to the working directory into a series of commits, _and_ testing each commit.

This is what the 'git stash save --keep-index' functionality was invented for, but I do not consider this single option to completely satisfy the requirements. The idea is to be able to 'git add -i' commits to the index and then stash away all of the remaining commits so that the commits in the index can be tested alone. After testing, you may decide that you want to move commits from the index into the stash set or vice versa as appropriate before committing.

Easily performing the operations in the previous sentence is what is missing. Additional hunks can be added easily, but they can not be un-staged easily. Maybe the interactive mode of git-add needs a '-p' sub-command which will allow selecting from the set of staged hunks, and un-staging individually in the same way that the 'p' sub-command allows staging hunks.

There is an example of this workflow in the stash man page, but I think it needs to be changed. It is suggested:

   # ... hack hack hack ...
   $ git add --patch foo            # add just first part to the index
   $ git stash save --keep-index    # save all other changes to the stash
   $ edit/build/test first part
   $ git commit -m 'First part'     # commit fully tested change
   $ git stash pop                  # prepare to work on all other changes
   # ... repeat above five steps until ...

The commit and pop currently need to be changed to something like:

   # git reset --hard
   # git stash pop --index
   # git commit -m 'First part'

Otherwise you are prone to merge conflicts in the working directory which are not straight-forward to reconcile. When there are merge conflicts, the changes from the stash are staged for committing, and the files with conflicts are 'Changed but not updated'. The user must reconcile the conflicts and then 'git reset'.

I'm sure the user's reaction (as mine was) will be WTF!?. I initially concluded that this work-flow was just broken. It is still usable, but far from perfect.

There is now a 'git stash drop' which can be used to drop individual stashes, and a 'git stash pop' to apply and then drop an individual stash.

The apply can always be redone.

   git reset --hard && git stash apply --index

But, I wouldn't be against making --index the default.

-brandon