threads / discuss / 64182
Subject: How do i get news of git releases
How do i get changelogs for git in a convinent format (like email or RSS or Atom)?ย I see that i can get changelogs in /Documentation/RelNotes/ but then i have to check the folder manually instead of it being in my email and RSS and Atom client (Thunderbird).
-- George truly, ๐๐๐๐ ๐๐๐๐ช๐๐ฃ This email does not constitute a legally binding contract โฎ
Jeff KingRe: How do i get news of git releases
On Mon, Sep 22, 2025 at 01:43:31PM -0400, ๐๐๐๐ ๐๐๐๐ช๐๐ฃ wrote:
> How do i get changelogs for git in a convinent format (like email or RSS or > Atom)?ย I see that i can get changelogs in /Documentation/RelNotes/ but then > i have to check the folder manually instead of it being in my email and RSS > and Atom client (Thunderbird).
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).
I think it may also be a reasonable feature for git-scm.com to have its own RSS feed. It already has to know about all of the releases (so it can point to the most recent one, for example). Most of the development for that site happens at https://github.com/git/git-scm.com. So if you or anybody is interested in adding the feature, it would probably make sense to start a discussion there.
-Peff
Junio C HamanoRe: How do i get news of git releases
Jeff King <peff@peff.net> writes:
> 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). > > I think it may also be a reasonable feature for git-scm.com to have its > own RSS feed. It already has to know about all of the releases (so it > can point to the most recent one, for example). Most of the development > for that site happens at https://github.com/git/git-scm.com. So if you > or anybody is interested in adding the feature, it would probably make > sense to start a discussion there.
It would give us a bit finer grained report to trigger updates to the blob RelNotes symbolic link points at, if the rss geneators can monitor such things.
Christian CouderRe: How do i get news of git releases
On Mon, Sep 22, 2025 at 7:43โฏPM ๐๐๐๐ ๐๐๐๐ช๐๐ฃ <velocifyer@velocifyer.com> wrote:
> > How do i get changelogs for git in a convinent format (like email or RSS > or Atom)? I see that i can get changelogs in /Documentation/RelNotes/ > but then i have to check the folder manually instead of it being in my > email and RSS and Atom client (Thunderbird).
Not sure it is what you need, but just in case, there is:
https://github.com/chriscool/getreleases
that we use to automatically generate release information that we publish in our Git Rev News newsletter:
https://git.github.io/rev_news/archive/
You can use it like this:
$ ./get_releases.py --get "Git" --exact --since 2025-07-24 Getting releases for exactly "Git" since 2025-07-24
> Requesting https://lore.kernel.org/git/?q=d%3A20250724..+%5BANNOUNCE%5D+Git
+ Git [2.51.0](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/), [2.51.0-rc2](https://lore.kernel.org/git/xmqqh5ybcfwt.fsf@gitster.g/), [2.51.0-rc1](https://lore.kernel.org/git/xmqqikizoybn.fsf@gitster.g/), [2.51.0-rc0](https://lore.kernel.org/git/xmqqms8f5889.fsf@gitster.g/
The URL for each release points to the announcement email on the mailing list archive. That email contains the release notes.
Re: How do i get news of git releases
> The URL for each release points to the announcement email on the > mailing list archive. That email contains the release notes.
If they already have the realease notes on the mailing list, why do they not have a seprate "git-announce" mailing list with just the release notes and other important announcements
-- George truly, ๐๐๐๐ ๐๐๐๐ช๐๐ฃ Improve your wifi reception for free <https://www.youtube.com/watch?v=LY8Wi7XRXCA> This email does not constitute a legally binding contract โฎ Remember to reply all on mailing lists (this is here so i don't forget to use reply all)(If you are reading this i forgot to remove it)
Christian CouderRe: How do i get news of git releases
On Tue, Sep 23, 2025 at 9:42โฏPM ๐๐๐๐ ๐๐๐๐ช๐๐ฃ <velocifyer@velocifyer.com> wrote:
> > > The URL for each release points to the announcement email on the > > mailing list archive. That email contains the release notes.
> If they already have the realease notes on the mailing list, why do they > not have a seprate "git-announce" mailing list with just the release > notes and other important announcements
We try to keep everything on a single mailing list as much as possible to not split the community. Also what is important depends a lot on the reader. For example Git for Windows or Git Rev News announcements might be important for some but not for others. So many people would have to sort things out anyway even if there were separate mailing lists.
Junio C HamanoRe: How do i get news of git releases
Christian Couder <christian.couder@gmail.com> writes:
> On Tue, Sep 23, 2025 at 9:42 PM > <velocifyer@velocifyer.com> wrote: >> >> > The URL for each release points to the announcement email on the >> > mailing list archive. That email contains the release notes. > >> If they already have the realease notes on the mailing list, why do they >> not have a seprate "git-announce" mailing list with just the release >> notes and other important announcements > > We try to keep everything on a single mailing list as much as possible > to not split the community.
I do not see how the presence of an "announce-only" list would fracture the community. You could make such a list strictly read-only for participants (i.e. only the list owners can send things out, responses may be routed to those on whose behalf the message was sent to the list, just to /dev/null, or perhaps to the main list) for make it even clear that the secondary list is for announce-only and any discussion about the items announced would still happen on the main list.
It does take resources and coordination. It won't happen without anybody spending an extra effort.
Because those who would be writing the announce material for such a secondary list are making enough efforts to help this community thrive already, I do not particularly see the initial "why not a separate announce list" question a very productive thing to think about or respond to. Unless the requestor is proposing to help such an effort on continuous basis, that is.
> Also what is important depends a lot on the reader. For example > Git for Windows or Git Rev News announcements might be important > for some but not for others. So many people would have to sort > things out anyway even if there were separate mailing lists.
That's very true.
Jeff KingRe: How do i get news of git releases
[please keep responses on-list]
On Mon, Sep 22, 2025 at 04:27:44PM -0400, ๐๐๐๐ ๐๐๐๐ช๐๐ฃ wrote:
> > 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
Junio C HamanoRe: How do i get news of git releases
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?
> 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.
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.
Jeff KingRe: How do i get news of git releases
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