On Fri, Mar 01, 2019 at 11:50:31AM +0900, Junio C Hamano wrote: > > 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. > > 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. Yes, perhaps. Though after thinking on this for a few days, I actually think there is no real reason not to just have --dangling do the right thing here (and we're still much faster than a full fsck, and not much slower than the current code unless you happen to have a large number of unreachable commits and trees). And then if the user says "--no-dangling", we can be even faster (i.e., the same as the current code). We could also make "--no-dangling" the default for "--connectivity-only", though I do not have a strong feeling either way. > 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. In addition to not opening blobs, we won't actually do fsck checks on any of the objects. So in git.git, for instance, we do not warn about the missing tagger in the v0.99 tag when --connectivity-only is in use. -Peff
