Re: Usability of git stash

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Oct 20, 2008, 16:33 UTC
Message-ID: <iLaWuW8h9LOhSqXlSRIQTWkC7QR2AL4JEb3gIbblWjY2dzOepLLfdg@cipher.nrlssc.navy.mil>
In-Reply-To: <87prly5k5r.fsf@cup.kalibalik.dk>

Anders Melchiorsen wrote:

Show 8 quoted lines

> 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