Usability of git stash

Usability of git stash

[Anders Melchiorsen]

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.

Re: Usability of git stash

[Brandon Casey]

Anders Melchiorsen wrote:

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

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

-brandon

Re: Usability of git stash

[David Kastrup]

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

> Anders Melchiorsen wrote:
>
>> 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.
>
> See the documentation, apply has a '--index' option.

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

Re: Usability of git stash

[Brandon Casey]

David Kastrup wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
> 
>> Anders Melchiorsen wrote:
>>
>>> 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.
>> See the documentation, apply has a '--index' option.
> 
> 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 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.

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

$ 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

Re: Usability of git stash

[Anders Melchiorsen]

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.

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.

Re: Usability of git stash

[Shawn O. Pearce]

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.

Re: Usability of git stash

[Leo Razoumov]

On 10/19/08, Shawn O. Pearce <spearce@spearce.org> wrote:
> [..snip..]
> 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
>
> [..snip..]

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

Re: Usability of git stash

[Shawn O. Pearce]

Leo Razoumov <slonik.az@gmail.com> wrote:
> On 10/19/08, Shawn O. Pearce <spearce@spearce.org> wrote:
> > [..snip..]
> > 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
> >
> > [..snip..]
> 
> 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"

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

	git add -A && git commit

-- 
Shawn.

Re: Usability of git stash

[Stephan Beyer]

Hi,

Shawn O. Pearce wrote:
> 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.

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>, PGP 0x6EDDD207FCC5040F

Re: Usability of git stash

[Miles Bader]

Stephan Beyer <s-beyer@gmx.net> writes:
> 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.

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

-Miles

-- 
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like.  Otherwise the
programs they write will be pretty weird.  -- Donald Knuth

Re: Usability of git stash

[Jeff King]

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

Re: Usability of git stash

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

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

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 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 agree with you; it really is the "diff saved somewhere, later applied".

Re: Usability of git stash

[Miles Bader]

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

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

-- 
Liberty, n. One of imagination's most precious possessions.

Re: Usability of git stash

[Andreas Ericsson]

Anders Melchiorsen 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.
> 

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

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

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.

> 
> 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 commit regularly enough that it doesn't take me long at all to re-do
the index changes.

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

git add .
git stash --index

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Usability of git stash

[Brandon Casey]

Anders Melchiorsen 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.

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.

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

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

The apply can always be redone.

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

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

-brandon