git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Marc Branchaud <marcnarc@xiplink.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Recovering from gc errors
Date: Tue, 14 Nov 2017 05:53:06 +0000
Message-ID: <20171114055306.3tfi726wzmkcfluk@sigill.intra.peff.net> (raw)
In-Reply-To: <4f548c23-7bb5-a672-21bb-6c1dd6de6139@xiplink.com>

On Mon, Nov 13, 2017 at 04:13:19PM -0500, Marc Branchaud wrote:

> Various incantations of "git show ... 9c355a7726e31" only fail with the same
> error, so I can't determine much about the problematic commit. Luckily I'm
> not particularly concerned with losing objects, as I push any important
> progress to named refs in backup repos.

Doing "git show" will require looking at the parent commit to produce
the diff. Probably "git show -s" would work. But in general for poking
at corruption, something bare-bones like "git cat-file commit 9c355a77"
is going to be your best bet.

> But I would like to clean this up in my local repo so that gc stops failing.
> I tried simply removing this and other loose commits that trip up gc (i.e.
> the objects/9c/355a7726e31b3033b8e714cf7edb4f0a41d8d4 file -- there are 49
> such files, all of which are several months old), but now gc complains of a
> bad tree object:

You can't generally fix corruption issues by deleting objects[1]. The
"source" that makes Git want to have these objects is the refs and
reflogs. So your best bet is to find which of those point to the
problematic objects and delete them.

I'd start by seeing if the breakage is reachable from any refs:

  git rev-list --objects --all >/dev/null

If that command succeeds, then all your refs are intact and the problem
is in the reflogs. You can try to figure out which, but I'd probably
just blow them all away:

  rm -rf .git/logs

If the rev-list fails, then one or more branch is corrupted.
Unfortunately the usual efficient tools for asking "which branch
contains this object" are likely to be broken by the corruption. But you
can brute-force it, like:

  git for-each-ref --format='%(refname)' |
  while read ref; do
    git rev-list --objects "$ref" >/dev/null 2>&1 ||
    echo "$ref is broken"
  done

Hopefully that turns up only branches with little value, and you can
delete them:

  git update-ref -d $broken_ref

-Peff

[1] A note on my "you can't fix corruption by deleting objects".

    Since abcb86553d (pack-objects: match prune logic for discarding
    objects, 2014-10-15) , git-gc also traverses the history graph of
    unreachable but "recent" objects. This is to keep whole chunks of
    the history graph intact during the gc grace period (which is 2
    weeks by default). So object themselves _can_ be a source of
    traversal for git-gc.

    We do that traversal with the ignore_missing_links flag, so
    breakages in the unreachable objects _shouldn't_ cause what you're
    seeing. IIRC we did turn up a bug or two with ignore_missing_links.
    The only one I could find was a3ba6bf10a (revision.c: ignore broken
    tags with ignore_missing_links, 2017-05-20), which I think wouldn't
    generate the output you're seeing.

  reply	other threads:[~2017-11-14  5:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 21:13 Marc Branchaud
2017-11-14  5:53 ` Jeff King [this message]
2017-11-14 15:39   ` Marc Branchaud
2017-11-14 16:48     ` Eric Sunshine
2017-11-15  0:19     ` Jeff King

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171114055306.3tfi726wzmkcfluk@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=marcnarc@xiplink.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

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git