From: Jeff King <peff@peff.net>
Date: Mon, 22 Sep 2025 21:35:58 GMT
Subject: Re: How do i get news of git releases
Message-ID: <20250922213558.GA2269472@coredump.intra.peff.net>
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