git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sitaram Chamarty <sitaramc@gmail.com>
To: Shawn Pearce <spearce@spearce.org>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: does a successful 'git gc' imply 'git fsck'
Date: Sun, 2 Dec 2012 14:16:33 +0530	[thread overview]
Message-ID: <CAMK1S_gUB6tpNQTLGTPPAvQ87+mX2HGiN1xpA7KoH33MX9tFBw@mail.gmail.com> (raw)
In-Reply-To: <CAJo=hJvHeA4g1fJZXm9VxpdvMFoHeEJW_r5YtXTDACEp09Xm_Q@mail.gmail.com>

On Sun, Dec 2, 2012 at 9:58 AM, Shawn Pearce <spearce@spearce.org> wrote:
> On Sat, Dec 1, 2012 at 6:31 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
>> Background: I have a situation where I have to fix up a few hundred
>> repos in terms of 'git gc' (the auto gc seems to have failed in many
>> cases; they have far more than 6700 loose objects).  I also found some
>> corrupted objects in some cases that prevent the gc from completing.
>>
>> I am running "git gc" followed by "git fsck".  The majority of the
>> repos I have worked through so far appear to be fine, but in the
>> larger repos (upwards of 2-3 GB) the git fsck is taking almost 5 times
>> longer than the 'gc'.
>>
>> If I could assume that a successful 'git gc' means an fsck is not
>> needed, I'd save a lot of time.  Hence my question.
>
> Not really. For example fsck verifies that every blob when
> decompressed and fully inflated matches its SHA-1. gc only checks

OK that makes sense.  After I posted I happened to check using strace
and kinda guessed this from what I saw, but it's nice to have
confirmation.

> connectivity of the commit and tree graph by making sure every object
> was accounted for. But when creating the output pack it only verifies
> a CRC-32 was correct when copying the bits from the source to the
> destination, it does not verify that the data decompresses and matches
> the SHA-1 it should match.
>
> So it depends on what level of check you need to feel safe.

Yup; thanks.

All the repos my internal client manages are mirrored in multiple
places, and they set (or were at least told to set, heh!)
receive.fsckObjects so the lesser check is fine in most cases.

-- 
Sitaram

  reply	other threads:[~2012-12-02  8:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-02  2:31 does a successful 'git gc' imply 'git fsck' Sitaram Chamarty
2012-12-02  4:28 ` Shawn Pearce
2012-12-02  8:46   ` Sitaram Chamarty [this message]
2012-12-02  9:31 ` Junio C Hamano
2012-12-03 13:14   ` Sitaram Chamarty
2012-12-03 13:46   ` Matthieu Moy
2012-12-03 14:06     ` Junio C Hamano

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=CAMK1S_gUB6tpNQTLGTPPAvQ87+mX2HGiN1xpA7KoH33MX9tFBw@mail.gmail.com \
    --to=sitaramc@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.org \
    /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).