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.
--

[ message continues ]

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
--

[ message continues ]