Re: git stash data loss

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> 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?

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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]