From: Eric Raible <raible@gmail.com>
Date: Thu, 11 Sep 2008 20:50:27 GMT
Subject: Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
Message-ID: <loom.20080911T204256-821@post.gmane.org>
In-Reply-To: <51419b2c0809101938v30e5a1aflf944027aedc2d900@mail.gmail.com>

Elijah Newren <newren <at> gmail.com> writes:

> Anyway, Eric wasn't really talking about ignoring files, since he was
> explicitly adding them for the next commit.  It's just that at some
> point he changed his mind and decided he didn't want to include any of
> the changes he had already made in the next commit, but was surprised
> when git reset --hard deleted the files from both the index and
> working copy instead of just the index.  git reset --hard really is
> meant for throwing away unwanted stuff (particularly including in the
> working directory), but I can see how he may have expected behavior
> more along the lines of git rm --cached for those particular files.  I
> don't agree with that viewpoint (I see files as tracked as soon as you
> stage it, not once you commit it), but I can see where the expectation
> comes from.
> 
> Just my thoughts,
> Elijah

Yes, you have a 100% correct understand of what I'm trying to say.
But can you see a downside to "git reset --hard" treating newly
added files as "git reset"?

Wiping out existing files (with no realistic recovery) is a bit harsh,
isn't it?  Especially when AFAICS there's no downside to leaving the
untracked files as they were before they were "git add"-ed.

- Eric