> The only prior state when the file didn't exist was before git was initialized. And I'd say the state of a repo with no commits is an empty tree, which is co

> The only prior state when the file didn't exist was before git was initialized. And I'd say the state of a repo with no commits is an empty tree, which is completely rational and consistent. It's what you get when you clone a repo with no commits, for example. If you `git reset --hard` to this state, that's what you get. The ironclad rule is ANYTIME you run `git reset --hard` you are going to reset the work tree and have the potential to remove files and lose uncommitted changes. That command exists for this reason and is quite useful for when you want to remove and throw away anything that might have changed. Although `git reset` and `git checkout` are overloaded in IMHO confusing ways, `git reset --hard` does exactly what it says it will - the other usages are the odd ones. Don't ever do `git reset --hard` if you have uncommitted changes (e.g. the repo is dirty). There's no special case for "before the first commit". Another way to untangle the two issues 1. prior to first commit / invented previous state and 2. git reset --hard eats your file is to note that `git reset --hard` would "eat" an indexed, but not committed, file in exactly the same way if you `reset --hard` to a prior commit when there are prior commits too. No difference. If you `git reset --hard` with uncommitted changes to an previously committed file, indexed or not, the changes are reverted too. It's the whole point to `reset --hard`.