On Friday, May 31, 2024 7:28 PM, Junio C Hamano wrote:

"Curley Joe" [off-list ref] writes:

quoted

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?