From: Jeff King <peff@peff•net>
To: Junio C Hamano <gitster@pobox•com>
Cc: 𝕍𝕖𝕝𝕠𝕔𝕚𝕗𝕪𝕖𝕣 <velocifyer@velocifyer•com>, git@vger•kernel.org
Subject: Re: How do i get news of git releases
Date: Mon, 22 Sep 2025 17:35:58 -0400 [thread overview]
Message-ID: <20250922213558.GA2269472@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqtt0urxva.fsf@gitster.g>
On Mon, Sep 22, 2025 at 02:16:57PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff•net> writes:
>
> > Yes, they're already annotated tags. But they contain only the version
> > number and signature. I suppose they could include the whole set of
> > release notes (and it looks like we used to do that in some very old
> > tags),
>
> Eh, which one? I do not recall ever doing so, but I may be
> mistaken.
>
> "git show v0.99.1" gives both tag object contents *and* the output
> from "git show v0.99.1^0" for the commit, so it is possible that I
> never did so, but those who ask "git show" may get such an
> impression?
I looked at:
git for-each-ref --format='%(objectsize) %(refname)' refs/tags |
sort -n
which shows a few bigger ones. v0.99.5 is the biggest, with what looks
like shortlog output plus some hand-written notes. Ditto v1.4.3.2.
But yeah, it is not very many.
> > 3. The resulting objects would be much larger (the v2.51.0 tag is 974
> > bytes, but Documentation/RelNotes/2.51.0 is 14K, and some are even
> > larger). Git may open them frequently to peel the tags, which may
> > make some operations slower. Though it might be OK; we try to cache
> > peeled values in packed-refs, and possibly the peeling code could
> > learn to parse more progressively (e.g., grab the first 1K to see
> > if we hit the end-of-header there).
> >
> > Those aren't necessarily show-stoppers, but just some top-of-the-head
> > thoughts. Junio (the maintainer, who actually makes the tags) might have
> > more thoughts on why we used to do that sometimes and don't now.
>
> I think #3 is a show-stopper.
>
> We will keep the RelNotes file updated with every batch that updates
> the 'master' front, so the contents of that imaginary tag that has
> the copy of the release notes would become identical to the in-tree
> blob at the point of a release. There has to be a very good reason
> why it is beneficial to _duplicate_ the information, not the other
> way around to ask why we do not duplicate the information in
> different places, I think.
Yeah, I agree the duplication is kind of unseemly. The main reason, I
think, would be: some third-party tools may mine information out of the
tag automatically, but do not know how to find Documentation/RelNotes.
I'm assuming GitHub would do that for the releases page (but actually, I
do not know).
If we did care about populating their releases page with more info, I
suspect using their API to pass along the content would be a better
solution.
-Peff
next prev parent reply other threads:[~2025-09-22 21:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-22 17:43 How do i get news of git releases 𝕍𝕖𝕝𝕠𝕔𝕚𝕗𝕪𝕖𝕣
2025-09-22 20:14 ` Jeff King
[not found] ` <1ff96277-c9e7-483e-ac98-b109b9603475@velocifyer.com>
2025-09-22 20:38 ` Jeff King
2025-09-22 21:16 ` Junio C Hamano
2025-09-22 21:35 ` Jeff King [this message]
2025-09-22 21:05 ` Junio C Hamano
2025-09-23 9:43 ` Christian Couder
2025-09-23 19:41 ` 𝕍𝕖𝕝𝕠𝕔𝕚𝕗𝕪𝕖𝕣
2025-09-24 8:38 ` Christian Couder
2025-09-24 18:51 ` Junio C Hamano
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=20250922213558.GA2269472@coredump.intra.peff.net \
--to=peff@peff$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=velocifyer@velocifyer$(echo .)com \
/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