Re: [PATCH] doc/fsck: discuss mix of --connectivity-only and --dangling

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 1, 2019, 02:50 UTC
Message-ID: <xmqqlg1z9uko.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190227145928.GA3727@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

> I'm actually a little torn on this. We could consider this a bug, and
> the "option" to disable it when you want things to go fast is to say
> "--no-dangling". That leaves no way to say "show me the list of
> unreachable objects, but don't bother spending extra time on dangling
> analysis". But I don't think I've ever really wanted that list of
> unreachable objects anyway (and besides, you could do it pretty easily
> with cat-file, rev-list, and comm).
>
> So I sketched up what it might look like to just fix the bug (but kick
> in only when needed), which is below.

[jch: I am still mostly offline til the next week, but I had a chance to sit in front of my mailbox long enough, so...]

As the primariy purose of the --conn-only option being such, perhaps we should have made --no-dangling the default when --conn-only is in effect.

But if --conn-only is made to do the right thing while showing dangling and unreachable properly sifted into their own bins, like this patch does, what's the difference between that and the normal --no-conn-only, other than performance and corrupt blobs left unreported? Perhaps if we are going that route, it might even make sense to rename --conn-only to --skip-parsing-blobs or something.

Thanks.