Re: Git reset --hard with staged changes

[Dale Worley <worley@alum.mit.edu>]

From: Pierre-François CLEMENT <likeyn <at> gmail.com>
> You create a new (untracked) file.
> You use git-reset's hard mode to go one commit back, the new
> (untracked) file's still there.
> You add/stage that new file.
> You use git-reset's hard mode again to go one commit back, and the new
> untracked file you just staged gets deleted.
> 
> Also, according to Git-scm
> (http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository):
> 
> "Tracked files are files that were in the last snapshot [...].
> Untracked files are everything else."
> 
> So it seems to me like staged untracked files shouldn't be considered
> as tracked files, and thus shouldn't be removed. Or maybe, git-reset's
> hard mode should always delete everything including untracked files?
> It would also make sense, given the numerous modes it has.

There's a core question that must be answered:  What, *exactly*, is a
"tracked file"?

If you look at that passage in the book, it continues:

"Tracked files are files that were in the last snapshot; they can be
unmodified, modified, or staged. Untracked files are everything else — any
files in your working directory that were not in your last snapshot and are
not in your staging area."

But if you look carefully, that passage gives two definitions of "untracked
files", and *they don't agree*, specifically in the case of a file that is
in the index but not in the base commit.  And that's the case we're considering.

To fix this, you've got to figure out what the definition of "tracked file"
is supposed to be, and then ensure that everything (code and documentation)
is consistent with that.

(As far as I can tell from Git's behavior, the definition of tracked file is
"any file that is in the base commit or in the index".  Based on that
definition, "git reset --hard" is working as documented.)

Dale