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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux