How do i get news of git releases

How do i get news of git releases

[𝕍𝕖𝕝𝕠𝕔𝕚𝕗𝕪𝕖𝕣]

[-- Attachment #1.1: Type: text/plain, Size: 394 bytes --]

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 ‮

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: How do i get news of git releases

[Jeff King]

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

Re: How do i get news of git releases

[Jeff King]

[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

Re: How do i get news of git releases

[Junio C Hamano]

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.

Re: How do i get news of git releases

[Junio C Hamano]

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.

Re: How do i get news of git releases

[Jeff King]

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

Re: How do i get news of git releases

[Christian Couder]

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

[𝕍𝕖𝕝𝕠𝕔𝕚𝕗𝕪𝕖𝕣]

[-- Attachment #1.1: Type: text/plain, Size: 668 bytes --]

> 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)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: How do i get news of git releases

[Christian Couder]

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.

Re: How do i get news of git releases

[Junio C Hamano]

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.