From: Taylor Blau <me@ttaylorr.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Luca Milanesio <luca.milanesio@gmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>,
Martin Fick <mfick@nvidia.com>
Subject: Re: Should object repacking only update server-info for packs instead of doing it for refs?
Date: Tue, 15 Oct 2024 09:56:41 -0400 [thread overview]
Message-ID: <Zw50mSKuyvlMDTAQ@nand.local> (raw)
In-Reply-To: <Zw5cvnkBQ1MzIS79@pks.im>
On Tue, Oct 15, 2024 at 02:14:59PM +0200, Patrick Steinhardt wrote:
> > >> I think it's reasonable to skip this step when repacking, but of course
> > >> we would still want to update info/packs (assuming that the repack
> > >> wasn't a noop, of course).
> > >
> > > It certainly may be reasonable. But in my opinion, it would be even more
> > > reasonable to not use the dumb HTTP transport at all. If you don't there
> > > is no reason to run git-update-server-info(1) in the first place, so
> > > you'd neither generate info/refs nor info/packs.
> >
> > I don’t believe anyone uses it anymore, but someone *may* still use
> > it, and therefore, Git should update the info/packs during geometric
> > repacking. However, why not introduce a “kill switch” in git config to
> > disable it so that all tools can automatically skip the expensive
> > info/packs (and info/refs) updates?
>
> We already have those, see "repack.updateServerInfo" and
> "receive.updateServerInfo". Not quite a single kill switch, but it is
> possible :)
There is also 'git repack -n' (which I know GitHub uses) to disable
updating info/refs and info/packs as a command-line flag (if for
whatever reason modifying the 'git repack' invocation is more
convenient than touching the repository configuration).
Thanks,
Taylor
prev parent reply other threads:[~2024-10-15 13:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-14 20:07 Should object repacking only update server-info for packs instead of doing it for refs? Martin Fick
2024-10-14 20:33 ` Luca Milanesio
2024-10-14 21:25 ` Taylor Blau
2024-10-15 11:02 ` Patrick Steinhardt
2024-10-15 11:52 ` Luca Milanesio
2024-10-15 12:14 ` Patrick Steinhardt
2024-10-15 13:56 ` Taylor Blau [this message]
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=Zw50mSKuyvlMDTAQ@nand.local \
--to=me@ttaylorr.com \
--cc=git@vger.kernel.org \
--cc=luca.milanesio@gmail.com \
--cc=mfick@nvidia.com \
--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.