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

Eric Raible <raible@gmail.com> writes:

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.