Re: [PATCH 2/2] fsck: lazily load types under --connectivity-only
- From
Jeff King <peff@peff.net>
- Date
- Jan 26, 2017, 19:12 UTC
- Message-ID
- <20170126191205.iu54sxbjisucsv6t@sigill.intra.peff.net>
- In-Reply-To
- <xmqqziid4puz.fsf@gitster.mtv.corp.google.com>
On Thu, Jan 26, 2017 at 10:51:00AM -0800, Junio C Hamano wrote:
Show 20 quoted lines
> > 2. It serves as a cross-check that the coercion in (1a) is > > correct (i.e., we'll complain about a parent link that > > points to a blob). But we get most of this for free > > already, because right after coercing, we'll parse any > > non-blob objects. So we'd notice then if we expected a > > commit and got a blob. > > > > The one exception is when we expect a blob, in which > > case we never actually read the object contents. > > > > So this is a slight weakening, but given that the whole > > point of --connectivity-only is to sacrifice some data > > integrity checks for speed, this seems like an > > acceptable tradeoff. > > The only weakening is that a non-blob (or a corrupt blob) object > that sits where we expect a blob (because the containing tree or the > tag says so) would not be diagnosed as an error, then? I think that > is in line with the spirit of --connectivity-only and is a good > trade-off.
Correct. The corrupt-blob case we always knew was a tradeoff (that's the whole point of --connectivity-only). We could add back in the "we expect a blob, is it really one?" at the moment we traverse to it, but IMHO it's not interesting enough to even be worth the sha1_object_info() lookup time.
-Peff