Re: Git reset --hard with staged changes

[Christian Couder <christian.couder@gmail.com>]

On Mon, May 23, 2016 at 11:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>>> This should be clarified to define what a tracked file is. I propose appending:
>>>
>>>     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.
>>
>> Would you like to send a patch with something like the above?
>
> 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.

>> I don't know if something about why it is like this, or why it is the
>> right thing to do, at least for recovering from merges, should be
>> added though.
>
> I excuse you as it seems that you haven't read my response ;-)
>
>>> 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
>
>  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.
>
> 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.