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

From: Elijah Newren <newren@gmail.com>
Date: Sep 11, 2008, 02:38 UTC
Message-ID: <51419b2c0809101938v30e5a1aflf944027aedc2d900@mail.gmail.com>
In-Reply-To: <eafc0afe0809101914lff5b23ehaf625d702fbd9b5d@mail.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