From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] doc/fsck: discuss mix of --connectivity-only and --dangling
Date: Mon, 4 Mar 2019 23:26:01 -0500 [thread overview]
Message-ID: <20190305042601.GF19800@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqlg1z9uko.fsf@gitster-ct.c.googlers.com>
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
next prev parent reply other threads:[~2019-03-05 4:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-27 14:55 [PATCH] doc/fsck: discuss mix of --connectivity-only and --dangling Jeff King
2019-02-27 14:59 ` Jeff King
2019-03-01 2:50 ` Junio C Hamano
2019-03-05 4:26 ` Jeff King [this message]
2019-03-05 4:45 ` [PATCH v2 0/2] fsck --connectivity-only --dangling Jeff King
2019-03-05 4:46 ` [PATCH v2 1/2] doc/fsck: clarify --connectivity-only behavior Jeff King
2019-03-05 4:47 ` [PATCH v2 2/2] fsck: always compute USED flags for unreachable objects Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190305042601.GF19800@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).