Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"

[Mike Hommey <mh@glandium.org>]

On Wed, Sep 10, 2008 at 12:12:21PM -0700, Eric Raible wrote:
> In http://marc.theaimsgroup.com/?l=git&m=114917892328066
> (references by http://git.or.cz/gitwiki/GitFaq), Linus says:
> 
> 'And "git reset" won't be deleting files it doesn't track (it had _better_
> not touch them), even more so when it has been told to ignore them, so it
> makes total sense to _not_ delete them when doing that reset.'
> 
> Now consider this example:
> 
> # Create a single commit in a new repo (so that we have a HEAD)
> mkdir xx
> cd xx
> git init
> git commit --allow-empty -m"initial"
> # Add an important file
> echo "Important stuff" > file42
> git add file42
> git status # -> new file:   file42
> ls # -> file42, or course
> git reset --hard
> ls # -> nothing
> 
> I would argue that as a "new file" (as reported by git status)
> that file42 was never actually tracked by git.  Sure, it _would_
> have been tracked in the future, but git never actually tracked it
> (it's not part of any commits).
> 
> So in this scenario wouldn't it make more sense for
> "git reset --hard" to handle file42 as "git reset" does
> instead of deleting it w/out a trace [1]?
> 
> The same question goes for "git checkout -f", too, I suppose.
> 
> I actually accidentally deleted hundred of newly added files yesterday
> doing just this.  https://mozy.com/?code=V3D4MM) saved my butt,
> but it wasn't pleasant.
> 
> - Eric
> 
> [1] - There's not even a reflog entry.  Sure, "git fsck" can be
> used, but that's hardly a friendly fallback.

Note that reflog only contains references to commit sha1s, so it can't
track index status. An index log could be interesting, though, but it
would need to expire much faster than reflog.

Mike