All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
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 09:07:01 +0900	[thread overview]
Message-ID: <xmqqh6lmwogq.fsf@gitster.g> (raw)
In-Reply-To: <ZVTJFOSnVonoPgZk@tanuki> (Patrick Steinhardt's message of "Wed, 15 Nov 2023 14:35:16 +0100")

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?

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.

  reply	other threads:[~2023-11-16  0:07 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 [this message]
2023-11-16 11:19             ` Patrick Steinhardt
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=xmqqh6lmwogq.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    --cc=peff@peff.net \
    --cc=ps@pks.im \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.