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

> Anyway, Eric wasn't really talking about ignoring files, since he was
> explicitly adding them for the next commit.  It's just that at some
> point he changed his mind and decided he didn't want to include any of
> the changes he had already made in the next commit, but was surprised
> when git reset --hard deleted the files from both the index and
> working copy instead of just the index.  git reset --hard really is
> meant for throwing away unwanted stuff (particularly including in the
> working directory), but I can see how he may have expected behavior
> more along the lines of git rm --cached for those particular files.  I
> don't agree with that viewpoint (I see files as tracked as soon as you
> stage it, not once you commit it), but I can see where the expectation
> comes from.
> 
> Just my thoughts,
> Elijah