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@xxxxxxxxx> wrote: > On Wed, Sep 10, 2008 at 7:12 PM, Changsheng Jiang <jiangzuoyan@xxxxxxxxx> 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 > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
