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

From: Christian Couder <christian.couder@gmail.com>
Date: Dec 4, 2016, 10:47 UTC
Message-ID: <CAP8UFD2rsxjmmVnPBmDFDx_-+Xr12wqGRqOMuMfrnu_ReSCm1A@mail.gmail.com>
In-Reply-To: <CAJZCeG0p5UrqM4oSOJ1ALKqNG8SyYh8cexKaN9R6RYYzPsMfxQ@mail.gmail.com>

On Sun, Dec 4, 2016 at 1:57 AM, Julian de Bhal <julian.debhal@gmail.com> wrote:

Show 14 quoted lines

> On Sat, Dec 3, 2016 at 6:11 PM, Christian Couder
> <christian.couder@gmail.com> wrote:
>> 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.

Yeah, but not everyone knows it is recoverable and using fsck to recover is not nice and easy for the user. So having a bloblog for example in .git/logs/blobs/, like the reflogs we already have, but for blobs, could help even if (first) it's just about writing the filenames and sha1s related to the blobs we stop referencing.

> 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?

Well, when we start talking about creating new objects, then someone usually says that it is what "git stash" is about. So the discussion then often turns to how can we make people more aware of "git stash", or incite them to create an alias or a shell function that does a "git stash" before "git reset --hard ...", or teach them to use "git reset --keep ..." when it does what they want and is safer...

> 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.

I suggest we start with just logging blobs that we have already created (when they have been "git add"ed) but that we are dereferencing. If we can agree on that, it will already help and not be very costly performance wise. After that we could then start thinking about creating blobs for all the content we discard, which could be done only in a beginner mode (at least at first) to make sure it has no performance impact if people rely on "git reset --hard" being fast.