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

quoted text
> 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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html