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

["Elijah Newren" <newren@gmail.com>]

On Wed, Sep 10, 2008 at 8:14 PM, Changsheng Jiang <jiangzuoyan@gmail.com> wrote:
> I think the current behavior is better than you described. If you want
> to ignore some files, you can added it to the exclude file. All files
> not excluded in the repo directory is maintained by git.

No, there's a limbo state -- the "untracked" files shown by git status
(which is the default state; these are files that have not been
explicitly requested to be ignored or be tracked).  Note the quote
from Linus at the beginning of Eric's email that specifically
references this.

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