From: Jeff King <peff@peff•net>
To: Junio C Hamano <gitster@pobox•com>
Cc: Kevin Puetz <PuetzKevinA@johndeere•com>,
"brian m. carlson" <sandals@crustytoothpaste•net>,
"git@vger•kernel.org" <git@vger•kernel.org>
Subject: Re: [Bug] git fetch --dry-run --filter makes changes to .git/config
Date: Thu, 18 Sep 2025 16:39:16 -0400 [thread overview]
Message-ID: <20250918203916.GA1199728@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqms6r7bf7.fsf@gitster.g>
On Thu, Sep 18, 2025 at 01:28:28PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff•net> writes:
>
> > It would probably be better if it established a separate tmp-objdir area
> > (like we do for pushes before we commit to storing them), fetched the
> > objects into that, and then threw away the result. That technique did
> > not exist back when "fetch --dry-run" was added, but it probably
> > wouldn't be too hard to do now.
>
> It is true that the quarantine mechanism did not exist. But I am
> not sure if a true dryness is actually better. We do verify that
> the incoming objects thrown at us by the other side are healthy, so
> the only difference is that our object database will have extra
> unreachable objects that are known to be healthy between the time
> you run a dry fetch and the time you then run a real one. And these
> extra objects that are healthy will help your real fetch go faster
> if the dry fetch and real fetch are run back to back thanks to "do
> we have all the necessary objects already, just that they may not be
> connected to the refs yet?" check.
>
> So it may not be hard with the building blocks, but I am not sure if
> it is a good idea to do so in the first place.
Yeah, I see how the current behavior could be useful. In this particular
case the objects _aren't_ really healthy. They are promisor cruft that
violates all the usual everything_local() rules (but at least we set up
the config to mark them as such). But I take your point that we probably
shouldn't change anything here.
You _can_ do the tmp-objdir thing yourself with GIT_OBJECT_DIRECTORY, as
I showed earlier. It is unfortunate that doing so updates the repo
config, though. That may show a mismatch in how the promisor information
is stored (it is really a property of the packfile in the object
directory, but the config mechanism stores it in the main repo). But it
is probably not worth trying to revisit at this point. It is only when
you start to play weird games like "this repo's object directory is not
$GIT_DIR/objects" that you run into these distinctions.
-Peff
next prev parent reply other threads:[~2025-09-18 20:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-17 14:44 [Bug] git fetch --dry-run --filter makes changes to .git/config Kevin Puetz
2025-09-17 21:21 ` brian m. carlson
2025-09-17 23:23 ` Kevin Puetz
2025-09-18 19:20 ` Jeff King
2025-09-18 20:28 ` Junio C Hamano
2025-09-18 20:39 ` Jeff King [this message]
2025-09-18 20:46 ` Junio C Hamano
2025-09-18 21:55 ` Kevin Puetz
2025-09-18 22:21 ` rsbecker
2025-09-19 15:31 ` Kevin Puetz
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=20250918203916.GA1199728@coredump.intra.peff.net \
--to=peff@peff$(echo .)net \
--cc=PuetzKevinA@johndeere$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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