Re: git reset --hard should not irretrievably destroy new files

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 4, 2016, 19:08 UTC
Message-ID: <xmqq1sxn7bqx.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAJZCeG1Eu+5DfaxavX_WGUCa+SY+yepDWZhPXxiFcV__h0xjrw@mail.gmail.com>

Julian de Bhal <julian.debhal@gmail.com> writes:

> The behaviour that would make the most sense to me (personally) would be
> for a hard reset to unstage new files,...

I think _sometimes_ that may be useful. I haven't thought things through yet to arrive the final decision, but one thing that must be kept in mind by anybody who wants to move this topic forward is that a path that does not exist in the HEAD commit MUST be removed from the index and the working tree upon "git reset --hard" when the path resulted from a mergy operation. I.e. in this sequence:

    $ git merge other-branch ;# or git cherry-pick one-commit
    ... try to resolve conflicts, make a mess, decide
    ... to try it again from scratch
    $ git reset --hard
    $ git merge other-branch ;# or git cherry-pick one-commit

the "reset --hard" step MUST remove new paths that existed only on the other-branch (or in one-commit), which by definition would have auto-resolved cleanly, from the index and the working tree. There are other commands (e.g. "git am -3", "git apply -3", "git rebase") that are "mergy" and their intermediate states must be handled the same way.

If a very simple to explain and understand rule can be used to tell if a new path (i.e. a path that exists in the index and in the working tree, but is not in the HEAD commit) is what was created manually by the end user without any other copy (i.e. "create newfile && edit newfile && git add newfile") and is not a result of a mergy operation being abandoned, then I think it is OK to allow "reset --hard" to leave the working tree files untracked, but if the rule becomes anything complex to understand for the users, I think it would make the behaviour of "reset --hard" hard to explain, understand AND anticipate---and at that point, we would be better off keeping the "You said 'hard', we clean 'hard' to match HEAD" behaviour of "reset --hard" and EDUCATE users not to say 'hard' too casually. There may be a room for new option that unconditionally leave the new working tree files untracked so that users can choose between the two, if we end up going that route.