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

From: Julian de Bhal <julian.debhal@gmail.com>
Date: Dec 4, 2016, 00:57 UTC
Message-ID: <CAJZCeG0p5UrqM4oSOJ1ALKqNG8SyYh8cexKaN9R6RYYzPsMfxQ@mail.gmail.com>
In-Reply-To: <CAP8UFD0ipS_4p+njfbbDGpYSDJhp43e9XDP69MOruZz9c136ew@mail.gmail.com>

On Sat, Dec 3, 2016 at 6:11 PM, Christian Couder <christian.couder@gmail.com> wrote:

Show 8 quoted lines

> On Sat, Dec 3, 2016 at 6:04 AM, Julian de Bhal <julian.debhal@gmail.com> wrote:
>> but I'd be nearly as happy if a
>> commit was added to the reflog when the reset happens (I can probably make
>> that happen with some configuration now that I've been bitten).
>
> Not sure if this has been proposed. Perhaps it would be simpler to
> just output the sha1, and maybe the filenames too, of the blobs, that
> are no more referenced from the trees, somewhere (in a bloblog?).

Yeah, after doing a bit more reading around the issue, this seems like a smaller part of destroying local changes with a hard reset, and I'm one of the lucky ones where it is recoverable.

Has anyone discussed having `git reset --hard` create objects for the current state of anything it's about to destroy, specifically so they end up in the --lost-found?

I think this is what you're suggesting, only without checking for references, so that tree & blob objects exist that make any hard reset reversible.

Cheers

Jules

P.s. Thank you for such a warm welcome while I blunder through unfamiliar protocols.