From: Junio C Hamano <gitster@pobox.com>
To: "Curley Joe" <m48cv7wg9w@liamekaens.com>
Cc: git@vger.kernel.org
Subject: Re: git fetch --prune fails with "fatal: bad object"
Date: Fri, 31 May 2024 16:27:43 -0700 [thread overview]
Message-ID: <xmqqplt1d0k0.fsf@gitster.g> (raw)
In-Reply-To: <16919-1717194882-875013@sneakemail.com> (Curley Joe's message of "Fri, 31 May 2024 22:34:42 +0000")
"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.
- "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?
next prev parent reply other threads:[~2024-05-31 23:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-31 22:34 git fetch --prune fails with "fatal: bad object" Curley Joe
2024-05-31 23:27 ` Junio C Hamano [this message]
2024-05-31 23:36 ` rsbecker
2024-06-01 15:53 ` Junio C Hamano
2024-06-04 10:44 ` Jeff King
2024-06-04 17:50 ` Junio C Hamano
2024-06-05 8:45 ` Jeff King
2024-06-04 20:09 ` Fred Long
2024-06-05 8:47 ` Jeff King
2024-06-05 23:43 ` Fred Long
2024-06-06 1:14 ` Jeff King
2024-06-06 20:12 ` Fred Long
2024-06-08 11:20 ` Jeff King
2024-06-08 21:02 ` Fred Long
2024-06-11 7:31 ` Jeff King
2024-06-13 3:29 ` Fred Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqplt1d0k0.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=m48cv7wg9w@liamekaens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).