Re: git stash data loss
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 17, 2012, 03:30 UTC
- Message-ID
- <7vy5lew5xz.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20120727135051.GA10303@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 29 quoted lines
> 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?
As readers can probably guess, I am trying to come up with a list of loose ends for the next cycle. This may be one of the low-hanging ones.