git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Mar 5, 2019, 04:26 UTC
Message-ID
<20190305042601.GF19800@sigill.intra.peff.net>
In-Reply-To
<xmqqlg1z9uko.fsf@gitster-ct.c.googlers.com>
On Fri, Mar 01, 2019 at 11:50:31AM +0900, Junio C Hamano wrote:
Show 14 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.
> 
> 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.

Show 6 quoted lines
> 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
Previous: Junio C HamanoNext: Jeff King
Message 4 of 7 in “doc/fsck: discuss mix of --connectivity-only and --dangling”
  1. doc/fsck: discuss mix of --connectivity-only and --danglingJeff King, Feb 27, 2019
  2. Jeff KingFeb 27, 2019
  3. Junio C HamanoMar 1, 2019
  4. Jeff KingMar 5, 2019
  5. 0/2 fsck --connectivity-only --danglingJeff King, Mar 5, 2019
  6. 1/2 doc/fsck: clarify --connectivity-only behaviorJeff King, Mar 5, 2019
  7. 2/2 fsck: always compute USED flags for unreachable objectsJeff King, Mar 5, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.