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

["Changsheng Jiang" <jiangzuoyan@gmail.com>]

I don't know what version of you git, my git with version 1.5.4.5
doesn't delete the file file42 after git-reset.

BTW, if you added the file42 to .gitignore, why git-status still
reported "new file" file42"?

Yours sincerely,
Changsheng Jiang
pubkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x40C37374



On Thu, Sep 11, 2008 at 10:46, Eric Raible <raible@gmail.com> wrote:
> 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
>