From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
git@vger.kernel.org, Karthik Nayak <karthik.188@gmail.com>
Subject: Re: [PATCH] commit-graph: disable GIT_COMMIT_GRAPH_PARANOIA by default
Date: Thu, 16 Nov 2023 12:19:14 +0100 [thread overview]
Message-ID: <ZVX6so-Gj_ES_FR8@tanuki> (raw)
In-Reply-To: <xmqqh6lmwogq.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]
On Thu, Nov 16, 2023 at 09:07:01AM +0900, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> >> Yeah. Just like we auto-enabled GIT_REF_PARANOIA for git-gc, etc, I
> >> think we should do the same here.
> >
> > I'm honestly still torn on this one. There are two cases that I can
> > think of where missing objects would be benign and where one wants to
> > use `git rev-list --missing`:
> >
> > - Repositories with promisor remotes, to find the boundary of where
> > we need to fetch new objects.
> >
> > - Quarantine directories where you only intend to list new objects
> > or find the boundary.
> >
> > And in neither of those cases I can see a path for how the commit-graph
> > would contain such missing commits when using regular tooling to perform
> > repository maintenance.
>
> I can buy the promisor remotes use case---we may expect boundary
> objects missing without any repository corruption. I do not know
> about the other one---where does our "rev-list --missing" start
> traversing in a quarantine directory is unclear. Objects that are
> still in quarantine are not (yet) made reachable from any refs, so
> even "rev-list --missing --all" would not make a useful traversal,
> no?
You typically know about the new tips when having a quarantine
directory. So you can discover the boundary between objects in your
quarantine directory and your main object database by executing `git
rev-list $NEWREVS --missing=print` and execute that command with
`GIT_OBJECT_DIRECTORY=$quarantine`. The benefit is that this scales with
the number of objects in the quarantine, and not with the size of the
overall repository.
As mention, this is really niche, but we do plan to use this in Gitaly
eventually.
> In any case, it sounds like you are not torn but are convinced that
> we should leave this loose by default ;-) and after thinking it over
> again, I tend to agree that it would be a better choice, as long as
> the feature "rev-list --missing" has any good use case other than
> corruption in repository.
>
> So,... thanks for pushing back.
Okay, glad to hear that I'm not totally bonkers then. I'm going to wait
another few days for additional feedback before sending a v2. But if
what I'm saying also makes sense to others then v2 would only squash in
the diff I sent to run the subset of tests that is now failing with
`GIT_COMMIT_GRAPH_PARANOIA=true`.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-11-16 11:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 10:23 [PATCH] commit-graph: disable GIT_COMMIT_GRAPH_PARANOIA by default Patrick Steinhardt
2023-11-14 10:35 ` Patrick Steinhardt
2023-11-14 14:42 ` Taylor Blau
2023-11-14 16:48 ` Junio C Hamano
2023-11-14 16:51 ` Junio C Hamano
2023-11-14 19:43 ` Jeff King
2023-11-15 0:44 ` Junio C Hamano
2023-11-15 1:36 ` Jeff King
2023-11-15 13:35 ` Patrick Steinhardt
2023-11-16 0:07 ` Junio C Hamano
2023-11-16 11:19 ` Patrick Steinhardt [this message]
2023-12-06 19:49 ` Jeff King
2023-11-20 11:01 ` [PATCH v2] " Patrick Steinhardt
2023-11-23 11:44 ` Junio C Hamano
2023-11-24 11:07 ` Patrick Steinhardt
2023-11-24 11:08 ` [PATCH v3] " Patrick Steinhardt
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZVX6so-Gj_ES_FR8@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=karthik.188@gmail.com \
--cc=peff@peff.net \
/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.
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 NNTP newsgroup(s).