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

From: Eric Raible <raible@gmail.com>
Date: Sep 11, 2008, 02:46 UTC
Message-ID: <279b37b20809101946k309ad113neb7d051f1c6c410e@mail.gmail.com>
In-Reply-To: <eafc0afe0809101912v72916d3hce9ae5d6812f0db8@mail.gmail.com>

On Wed, Sep 10, 2008 at 7:12 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.

That doesn't really address the problem. This is an updated example that specifically ignores the file:

# 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 echo file42 > .gitignore git status # -> new file: file42 ls # -> file42, or course git reset --hard ls # -> nothing

So not only was file42 never actually tracked by git (IMHO - I realize that this is debatable) but it was also specifically ignored, and it is _still_ deleted w/out a trace!

I realize that "git reset" will simply unstage the new file in either case (w or w/out .gitignore), but the consequences of an accidental "git reset --hard" are pretty severe in this case. This behavior seems definitely contrary to Linus's explanation:

   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.

- Eric