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

From: Junio C Hamano <gitster@pobox.com>
Date: May 31, 2024, 23:27 UTC
Message-ID: <xmqqplt1d0k0.fsf@gitster.g>
In-Reply-To: <16919-1717194882-875013@sneakemail.com>

"Curley Joe" <m48cv7wg9w@liamekaens.com> writes:

Show 7 quoted lines

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

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

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?