On Friday, May 31, 2024 7:28 PM, Junio C Hamano wrote:
>"Curley Joe" <m48cv7wg9w@xxxxxxxxxxxxxx> 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?
