> On May 24, 2016, at 2:20 AM, Christian Couder <[email protected]>
> wrote:
>
> On Mon, May 23, 2016 at 11:16 PM, Junio C Hamano <[email protected]> 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?
>>>> 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.
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
