Re: git stash data loss

[Jeff King <peff@peff.net>]

On Thu, Aug 16, 2012 at 08:30:48PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > On Fri, Jul 27, 2012 at 09:29:53AM -0400, Jeff King wrote:
> >
> >> If we put actual files inside "x", which git does track, then they would
> >> be part of the stash, and should be properly retained. But they're not:
> >> 
> >>   $ rm x && mkdir x && echo foo >x/file
> >> 
> >> Now we have some precious contents in the form of "x/file". They are
> >> untracked by git, but git should be careful about removing them.
> >> 
> >>   $ git stash
> >>   Saved working directory and index state WIP on master: 2d32d3a initial
> >>   HEAD is now at 2d32d3a initial
> >>   $ ls -l x
> >>   -rw-r--r-- 1 peff peff 0 Jul 27 09:19 x
> >>   $ git stash show --raw
> >>   :100644 000000 e69de29... 0000000... D  x
> >> 
> >> Now this _is_ data loss. Stash blows away untracked files inside the
> >> directory, but does not record them in the resulting stash. And that
> >> should be fixed.
> >
> > Hrm. The problem is that after creating the stash, we then run "git
> > reset --hard" to drop the changes that we just stashed. But that is not
> > always accurate. It will not usually touch untracked files, but it might
> > if they have D/F conflicts with tracked files. So we need to replace
> > that "git reset --hard" with some safer command that will notice we are
> > about to overwrite untracked files. But I am not sure what that command
> > would be.
> 
> Is this something we still want to keep track of?

Yeah, I think it is worth fixing. It's a somewhat rare case, but data
loss is bad. I was hoping you would respond with "...and here is the
magical incantation of git commands to make the working directory look
like we want". I couldn't come up with one. We may need a new option to
reset or read-tree.

-Peff