RE: git fetch --prune fails with "fatal: bad object"

[<rsbecker@nexbridge.com>]

On Friday, May 31, 2024 7:28 PM, Junio C Hamano wrote:
>"Curley Joe" <m48cv7wg9w@liamekaens.com> writes:
>
>> git fetch --prune fails with "fatal: bad object" for refs that have an
>> invalid sha1 pointer. It would be nice if "git fetch --prune" could
>> prune these refs, because it is a hassle to do it manually. ("git
>> fetch --prune" only shows the first invalid ref, and you have to run
>> "git fsck" and parse it to find the rest.) If it seems like adding
>> this functionality to --prune is a bad idea, then how about adding an
>> option like "--prune-invalid" ?
>
>A question and a comment.
>
> - Why did the repository got into this state in the first place?
>   It seems that it would be much better solution to prevent refs
>   from having garbage values in them or to prevent objects that are
>   necessary from going away than any "prune invalid refs" feature.

I agree. However, there are some configurations where disk write caches are enabled and require a sync or some other flush operation to force a complete write to disk. In such situations, corruptions are always possible despite the best efforts by the application.

> - "fetch" still feels a wrong place to have the feature, if it is
>   about fixing a local repository corruption.  You should be able
>   to recover from such a broken ref even if you are only working
>   locally without fetching from anybody.

I think fsck would be a better place for this.

>If you can somehow _enumerate_ such broken refs, you could drive update-ref to
>remove them.  Naïvely, an obvious place to add such a feature might be the "for-
>each-ref" command that is used to list refs with various criteria, so it might look like:
>
>   $ git for-each-ref --format='%(refname)' --broken |
>     xargs git update-ref -d
>
>or something?