Re: Git reset --hard with staged changes

From: Yotam Gingold <yotam@yotamgingold.com>
Date: May 30, 2016, 05:07 UTC
Message-ID: <4067AC3B-D369-4E86-9EB9-ED19FD362E2D@yotamgingold.com>
In-Reply-To: <CAP8UFD0yB8XjUi0f2OTUrW9W1UPC_ekY3+8--CC5rk_5RciYAA@mail.gmail.com>

Show 9 quoted lines

> On May 24, 2016, at 2:20 AM, Christian Couder <christian.couder@gmail.com> wrote:
> 
> On Mon, May 23, 2016 at 11:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> 
>> 
>> I am not sure if that is a good addition, though.
> 
> I am not sure either, but at least if something like that is added,
> people may complain less.

The present documentation is at best wrong and at worst misleading. I read Junio's enumerations of the situations, and I appreciate that the current behavior of git reset --hard cannot be changed because of the many tools that rely on the current behavior. After reading it, I have modified my proposed amendment to the git reset --hard documentation:

    A file is considered tracked if it exists in a prior commit or in the
    staging area. Note that a newly added file not in any prior commit will be
    removed. This is useful for aborting a failed merge.

Shall I submit a patch?

Show 8 quoted lines

>>>> I would also like to propose that the staging area's tree object be saved,
>>>> ..
>>> Yeah, it might be a good idea.
>> 
>> Two issues with that "proposal" is that
>> 
>> 1. the index may not be writable as a tree (think: during a
>>    conflict resolution); and

So why not do it only when possible? But in this case (and every case), wouldn't a solution be to create a tree that is not the index just for the reflog?

>> 2. the sole point of "reset --hard" is to "discard the changes".
>>    If you want to instead save them away, there is another command
>>    that was designed to do just that.

git stash isn't relevant here. git reset --hard deletes data from disk that has only ever been in the staging area. Many commands in git can be "undone" due to the fact that it is a version control system and there is a reflog. This is not one of those. git reset --hard can cause a catastrophic loss of data, with no way to undo it.

Show 6 quoted lines

>> It wasn't all that surprising that those on stackoverflow would
>> think such a proposal is a good idea, but I somehow was hoping you
>> have been around here long enough to know "git stash" ;-)
> 
> Yeah, we can try to teach people about git stash and git reset --keep
> instead, but I doubt that it will be very effective.

git stash doesn't make sense in this context. The documentation for git reset --hard is misleading. The error is unrecoverable. How could anyone but a git developer know this?

Yotam