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

From: Eric Raible <raible@gmail.com>
Date: Sep 11, 2008, 21:24 UTC
Message-ID: <279b37b20809111424y73a3f6b9xe7f5019b9ba0da16@mail.gmail.com>
In-Reply-To: <3ab397d0809111022m24c81bd9y2520f6be478babd3@mail.gmail.com>

On Thu, Sep 11, 2008 at 10:22 AM, Jeff Whiteside <jeff.m.whiteside@gmail.com> wrote:

> And if you want to delete all untracked files
>      ls | sed s/`git status --index --filenamesonly`//g | rm
>      ls | sed s/`git status --commitrepo --filenamesonly`//g | rm
>            (I realize those commands don't actually work, but I'm a noob.)

"git clean" (http://www.kernel.org/pub/software/scm/git/docs/git-clean.html) will delete untracked file.

> So that 'tracked by git' isn't just another ambiguous semantic.

While I can't find where it might be explicitly defined, it does seem clear that a file/dir is "tracked" as soon as it's added.

My question is why "git reset --hard" can't make a special case for _newly added_ tracked files. After all, "git status" knows that they're "new files", and "git reset --hard" could realize that wiping them off the face of the earth isn't the most helpful thing possible.

- Eric