Re: [PATCH] revision: ignore non-existent objects in resolve-undo list

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 18, 2022, 16:32 UTC
Message-ID: <xmqqfsflum70.fsf@gitster.g>
In-Reply-To: <20221018175530.086c8c74@apus>

Mathias Rav <m@git.strova.dk> writes:

> Garbage collection could inadvertently prune blobs mentioned only in the
> resolve-undo extension prior to the bugfix in 5a5ea141e7
> ("revision: mark blobs needed for resolve-undo as reachable", 2022-06-09).

Older versions of Git did not consider blobs referenced by the resolve-undo as reachable, and allowed "git gc" to expire them out of existence. And "git fsck" in these versions did report that these blobs are unreachable.

Newer versions of Git on the other hand do consider these blobs as reachable, so "git gc" would not expire them. And "git fsck" would complain when they are missing, because by definition we should not lose reachable objects.

The error discussed recently on the list was only because older version was used to "git gc" away blobs that are still in use.

I think the right solution for such a transitory error is not to hide the problem and pretend that such a blob reference does not exist, which is what ...

> Fix the error by emitting a warning when the resolve-undo list mentions
> objects that do not exist and then ignoring the nonexistent object.

... this approach is about. I think it is backwards to sweep the problem under the rug without fixing the underlying problem.

We should instead be removing the reference that is no longer even usable for the purpose of resolve-undo, e.g. when "rerere forget <pathspec>" reads from the resolve-undo extension to recreate the conflicts.

Perhaps "git reflog --state-fix" is a good model to follow. Back when the option was introduced, we found that there was a buggy implementation of "git gc" that did not consider commits referenced by reflog entries reachable and removed them, breaking "git reflog". The solution was to remove these reflog entries that accidentally lost commits that they reference because they no longer are usable.

The manual procedure Peff gave in the thread does work OK, but if it makes it more friendly, a new option to "update-index" to fix the index file by removing things that refer to missing objects would not be a bad idea.

Thanks.