Git stash behavior

Git stash behavior

[sivno.20.toranaga-san]

Hello all,

I am using git stashes to ensure that my source builds and tests
correctly. My general work flow is this: Before committing I create a
stash and clean everything:

    git stash save -q --keep-index --include-untracked

Then I perform some tests (mvn compile test), after that I restore
everything:

    git stash pop -q

I am using this from a pre-commit hook so I really need this to work
reliably. The problem is that I think that it really doesn't. I created
a small gist to show the problem here:

https://gist.github.com/x2b/3cc3d8aa8979561de4b5

There are actually multiple problems here:

1.

If an untracked file already exists then git refuses to pop the stash.
This is certainly the desired behavior in most cases. However, I would
appreciate a "--force" option to override it.

2.

As you can see the content of the "untracked" file in the gist is the
same in the stash and the working directory. Is it really necessary to
abort the operation in this case??

3.

The most severe problem is that after unsuccessfully trying to pop the
stash the "first_untracked" file is restored while the "untracked" file
is not. The stash is *partially* applied to the working directory. It
seems like git restores some files before giving up after encountering
the first file which can't be restored. I think this behavior is not
generally what is expected. Git should either fail and leave the working
directory as-is or succeed and change the directory's content.
Since there is no "--force" option (see 1.) it is necessary to remove
the already restored untracked files by hand before attempting to pop
the stash once more (this is really inconvenient to me).

While these are not technically bugs I would appreciate it if you could
address these issues all the same.

x2b

Re: Git stash behavior

[Ed Avis]

You may want to see this recent thread about a similar feature:

<http://thread.gmane.org/gmane.comp.version-control.git/275607>

-- 
Ed Avis <eda@waniasset.com>