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

[Junio C Hamano <gitster@pobox.com>]

Eric Raible <raible@gmail.com> writes:

> 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"?

Of course.  The --hard option is called --hard without inviting short
option for a reason.

I am actually somewhat sympathetic to your point, but you would want
"reset --hard" to remove that path when a path does not exist in the HEAD
but in index in other cases.  And it is my experience (and I presume you
can guess I have longer git experience than any of you ;-) that far more
often than not that is what is desirable.

Consider:

 (1) Your branch does not have "path";

 (2) You once thought you want addition of the "path" made in another
     branch;

 (3) So you did:

    $ git checkout another -- path

 (4) After more hacking, it turns out that the avenue you chose to reach
     your goal, including the addition of the "path", was a mistake, and
     you regret having wasted some time.  You want to go back to the
     current HEAD:

    $ git reset --hard

The state after (3) is "HEAD does not have path, index and work tree has
it".  In step (4) you would want "git reset --hard" to get rid of such a
path.

And it is no different from the case where you add the path manually to
the index.  Both are "you thought you wanted it, but you changed your
mind".

Another example is getting rid of crufts from a conflicted merge.  It may
bring in many new paths in your index and the working tree.  You would
want a "git reset --hard" to get rid of all of them.  Not removing the
paths that are not in HEAD but in index and working tree is far worse in
this case because merging is often done from other people's tree that you
may not be familiar with (i.e. you wanted to study their tree after
merging), so it is harder for you to hand-clean after "reset" if a hard
reset does not do it for you.