Re: How do i get news of git releases

From: Jeff King <peff@peff.net>
Date: Sep 22, 2025, 20:38 UTC
Message-ID: <20250922203815.GA2264272@coredump.intra.peff.net>
In-Reply-To: <1ff96277-c9e7-483e-ac98-b109b9603475@velocifyer.com>

[please keep responses on-list]

On Mon, Sep 22, 2025 at 04:27:44PM -0400, 𝕍𝕖𝕝𝕠𝕔𝕚𝕗𝕪𝕖𝕣 wrote:

Show 19 quoted lines

> > The Git project doesn't maintain any RSS feeds that I'm aware of.
> > However, releases are pushed to GitHub (among many other mirrors), and
> > they do provide feeds. So I think pointing your feed-reader at:
> > 
> >    https://github.com/git/git/releases.atom
> > 
> > would work.
> > 
> > The project doesn't use GitHub's Releases feature specifically, but I
> > think annotated tags that are pushed to the repo end up there, too. The
> > resulting feed entries are a little bare. Possibly they could be
> > populated with the release notes, but from the Git project's
> > perspective, the GitHub repo is really just a Git mirror. Presumably it
> > would require some scripting around GitHub's API for the tag pushes to
> > also create Release entries (and then probably somebody would want the
> > same for the GitLab mirror, and so on).
> 
> Why do the Git tags not have the changelog? You can use git-tag -a to create
> a tag with a changelog.

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), but there may be some possible downsides:

  1. I'm not sure if anybody depends on the current format for
     scripting.

  2. They can't be revised if we later fix up the Release Notes (e.g.,
     typo fixes, but also they were recently all retroactively brushed
     up to be renderable as asciidoc).

  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.

-Peff