On Thu, Jan 26, 2017 at 10:51:00AM -0800, Junio C Hamano wrote: > > 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