From: Patrick Steinhardt <ps@pks.im>
To: Taylor Blau <me@ttaylorr.com>
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 13:02:29 +0200 [thread overview]
Message-ID: <Zw5LwB2ap1QnmG6L@pks.im> (raw)
In-Reply-To: <Zw2MVqi0FLcMuR8Z@nand.local>
On Mon, Oct 14, 2024 at 05:25:42PM -0400, Taylor Blau wrote:
> On Mon, Oct 14, 2024 at 09:33:17PM +0100, Luca Milanesio wrote:
> > > It seems counterintuitive that an operation designed to repack
> > > objects would be performing maintenance of any sort on refs?
> >
> > True, it should not touch info/refs IMHO, as you’re really not
> > changing any refs.
>
> Right. I don't think that the current behavior is a bug, but just that
> it's doing unnecessary work from within 'git repack' to update the
> info/refs file when it's known ahead of time that the refs haven't
> changed.
>
> 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.
We have been discussing in the past whether the dumb HTTP protocol
should be deprecated, and in the context of that discussion we were also
wondering whether we should start disabling git-update-server-info(1) by
default. Users don't generally need this, and most server operators
don't need this nowadays, either. So why generate data that is useless
in almost all cases?
Patrick
next prev parent reply other threads:[~2024-10-15 11:02 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 [this message]
2024-10-15 11:52 ` Luca Milanesio
2024-10-15 12:14 ` Patrick Steinhardt
2024-10-15 13:56 ` Taylor Blau
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=Zw5LwB2ap1QnmG6L@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=luca.milanesio@gmail.com \
--cc=me@ttaylorr.com \
--cc=mfick@nvidia.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.
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).