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