Any comment about upcoming Git Rev News edition 120

[chriscool]

A currently mostly empty draft is there:

https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-120.md

Feel free to comment in this issue, suggest topics, suggest persons to interview, or use the edit button (that looks like a pen) to edit and create a pull request with the changes you would like.

Let's try to publish this edition around the end of February 2025!

Thanks!

cc @jnareb @mjaix @sivaraam @gitster @stepnem

[chriscool]

120 editions at the rate of one per month means 10 years of Git Rev News!

[sivaraam]

That's awesome ro hear, Christian! It's a great milestone for us. 🎉

Do you think we could do something special this edition to mark the occasion?

On the top of my head:

• Publish a special interview curating answers from all the core Git Rev News editors. No idea what the topic of this should be.
• Do some analysis on the editions so far to gather some interesting insights and publish the same? Metrics like:
  • Number of people who have contributed to Rev News.
  • Number of articles that we've written
  • Number of links that have been shared so far.
  • etc.
    I'm not sure how interesting / helpful this would be. I'm just thinking out loud.

Kindly share your opinions about these and other ideas you have.

[chriscool]

I am not sure if we should do something special for this edition. The first edition was published on March 25, 2015, so maybe we should do something special for edition 121 that we will publish at the end of March 2025.

In early April 2025 there will be Git's 20th anniversary. Maybe worth doing something for that too.

Yeah, an analysis on the editions so far might be interesting. We could use an AI tool to help with this by the way. (Either by feeding it with all the editions or by asking it to write a script to parse them.)

I have been thinking also about opening a discussion on maybe using AI tools to summarize automatically a lot of mailing list discussion threads and putting them on a website. But we might want to ask directly on the mailing list instead of on Git Rev News. I think @mricon talked about something like this in a mailing list thread a few years ago.

[jnareb]

Yeah, an analysis on the editions so far might be interesting. We could use an AI tool to help with this by the way. (Either by feeding it with all the editions or by asking it to write a script to parse them.)

Feeding all Git Rev News the editions, unless we use fine-tuning techniques (teaching some fundamental pre-trained LLM on all Git Rev News editions) to the LLM might exceed its maximal context size.

Asking it to write a script, then reviewing such script, might be a better idea.

I have been thinking also about opening a discussion on maybe using AI tools to summarize automatically a lot of mailing list discussion threads and putting them on a website. But we might want to ask directly on the mailing list instead of on Git Rev News. I think @mricon talked about something like this in a mailing list thread a few years ago.

The problem with AI summaries is that from time to time LLM hallucinates and invents something that was not present, even if its task is only to summarize. There were enough of problems with AI generated summaries that some of companies (Apple?) turned them off.

[mricon]

I have been thinking also about opening a discussion on maybe using AI tools to summarize automatically a lot of mailing list discussion threads and putting them on a website. But we might want to ask directly on the mailing list instead of on Git Rev News. I think @mricon talked about something like this in a mailing list thread a few years ago.

I'm still kinda working on it off and on -- for example, a nice service would be to have a "smart digest" mode that instead of sending a bunch of messages for the user to review, would summarize them instead, e.g. "new threads," "hot threads," etc. There are several problems I keep running into:

1. Cost quickly becomes prohibitive if you use commercial services. Tokenizing long discussion threads is not cheap, even after you play with removing excessive quoting, etc.
2. If you use a local LLM (like ollama), then you have to make the context window large enough, which makes it super slow. If you don't make a large context window, then the LLM nears on useless, because it loses track of what happened earlier in the thread.
3. The LLM isn't necessarily great at parsing complex interleaved discussions that are common on the mailing lists. Some more expensive models cope with it better than others, but every now and again it will completely misattribute something to a wrong person.
4. There's no single "summarize" mode that would satisfy everyone, even if you load the prompt with a bunch of conditions such as "analyze from the point of view of the project manager in charge of code review," etc.
5. Every now and again the LLM is hilariously or dangerously wrong, and this is my greatest worry -- that over-relying on the "smart digest" service would be worse than doing nothing.

[chriscool]

@jnareb and @mricon thanks a lot for your input on this!

I agree that automatically summarizing a lot of mailing list discussion threads using AI may not be practical and accurate enough yet.

As part of my job at GitLab, I have access to Claude 3.5 Sonnet, so I can ask it to write a script to do some analysis on the editions so far if we want to do this. I think it might be a good idea actually. We just need to come up with the metrics or results we are interested in and how the script should compute them. For example for the number of people who have contributed, it could be computed based on the "Credits" section at the bottom of each edition, or on the Git commits on the file for that edition, or maybe on both. For this one I think using the "Credits" section is probably best.

[sivaraam]

As part of my job at GitLab, I have access to Claude 3.5 Sonnet, so I can ask it to write a script to do some analysis on the editions so far if we want to do this. I think it might be a good idea actually.

Sounds interesting. Feel free to let me know if I could help with anything. I'll be glad to :-)

[chriscool]

Thanks @sivaraam for the interview and for your PR about Git being accepted in GSoC 2025!

About this PR though, I think it's better if those news are at the top in the ### General section rather than in the links section. Sorry for overlooking this when reviewing the PR. Let me know if I can move it there.

[chriscool]

Draft email sent: https://lore.kernel.org/git/CAP8UFD2NSvRJo4XUmuWFVfqN-XF4_Qiqu2VncEdWVi00qSLNaA@mail.gmail.com/

[chriscool]

As part of my job at GitLab, I have access to Claude 3.5 Sonnet, so I can ask it to write a script to do some analysis on the editions so far if we want to do this. I think it might be a good idea actually.

Sounds interesting. Feel free to let me know if I could help with anything. I'll be glad to :-)

Thanks a lot @sivaraam! I think a lot of testing will be needed.

Anyway I think we should discuss this elsewhere first to get a better idea of what we want do. Maybe we can discuss this as part of the next edition as it will likely be where we publish the results. Or maybe we should open a separate issue? For now I have started discussing it as part of the next edition in #753 (comment), so let's either continue over there or open a separate issue.

If we open an issue to start working on the script, it should likely be in a separate repo, where we will develop that script, for example maybe https://github.com/chriscool/getreleases/ where there are other scripts dedicated to Git Rev News.

[bpugh]

@jnareb some last minute links for consideration:

• https://blog.gitbutler.com/interdiff-review-with-git-range-diff/
• https://www.brandonpugh.com/blog/git-stash-without-the-branch-name/

No worries if you'd rather wait till next edition.

[jnareb]

My links have landed in abcad67

[jnareb]

@jnareb some last minute links for consideration:

• https://blog.gitbutler.com/interdiff-review-with-git-range-diff/
• https://www.brandonpugh.com/blog/git-stash-without-the-branch-name/

No worries if you'd rather wait till next edition.

Thanks for the suggestions. I have added them in f160b0a.

[chriscool]

@bpugh thanks for the suggestion!

@jnareb thanks for the great links!

[chriscool]

Thanks @stepnem and @mjaix for the fixes in #754 !

[chriscool]

Edition published and announced in: https://lore.kernel.org/git/CAP8UFD08323p2kb2KkCk9V7PZNWCHdBQRbuzSH-jj6Rb9y7MXA@mail.gmail.com/

[sivaraam]

About this PR though, I think it's better if those news are at the top in the ### General section rather than in the links section. Sorry for overlooking this when reviewing the PR. Let me know if I can move it there.

Sorry. I completely overlooked this. Moving that would've been totally fine thing too. I'm not sure if it makes sense to move it now as we've already. Let's correct this the next time we post information about GSoC such as posting selected GSoC candidates 🙂

[chriscool]

@sivaraam No worries, not a big deal. And I don't think it makes sense to move it now as we've already published the edition and the email version seems to have been sent by @mjaix already (thanks by the way).

Yeah, next time, especially when we will announce the selected GSoC contributors, let's put it into its own article in the "Discussions" -> "General" section.