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

["Eric Raible" <raible@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