diff --git a/Outreachy-Participants.md b/Outreachy-Participants.md new file mode 100644 index 000000000..53c7fed07 --- /dev/null +++ b/Outreachy-Participants.md @@ -0,0 +1,60 @@ +--- +layout: default +title: Outreachy participants +--- + +This document collects the list of contributors who've contributed +to Git via Outreachy. + +### Winter 2024-2025 + +1. Seyi Kuforiji [ [blog](https://seyi-kuforiji-902b48.gitlab.io/) ] +2. Usman Akinyemi [ [blog](https://uniqueusman.hashnode.dev/tag/outreachy) ] + +#### References + +- [Rev News - Dec 2024](https://git.github.io/rev_news/2024/12/31/edition-118/) + +### Winter 2023-2024 + +1. Achu Luma [ [blog](https://lumap.gitlab.io/posts/) ] + +#### References + +- [Rev News - Dec 2023](https://git.github.io/rev_news/2023/11/30/edition-105/) + +### Winter 2020-2021 + +1. Sangeeta [ [blog](https://sangu09.github.io) ] +2. Joey Salazar [ [blog](https://jsal.home.blog/) ] +3. Charvi Mendiratta [ [blog](https://charvi-077.github.io/blog/) ] + +#### References + +- [Rev News - Dec 2020](https://git.github.io/rev_news/2020/12/26/edition-70/) + +### Winter 2019-2020 + +1. Heba W. [ [blog](https://medium.com/@heba.waly) ] +2. Miriam Rubio [ [blog](https://mirucam.gitlab.io/outreachy_blog/) ] + +#### References + +- [Rev News - Dec 2019](https://git.github.io/rev_news/2019/12/25/edition-58/) + +### Winter 2018-2019 + +1. Slavica Đukić [ [blog](https://slavicadj.github.io/blog/) ] +2. Tanushree Tumane [ [blog](https://tanu1596.blogspot.com/) ] + +#### References + +- [Rev News - Nov 2018](https://git.github.io/rev_news/2018/11/21/edition-45/) + +### Winter 2017-2018 + +1. Olga Telezhnaia [ [blog](https://medium.com/@olyatelezhnaya) ] + +#### References + +- [Rev News - Nov 2017](https://git.github.io/rev_news/2017/11/22/edition-33/) diff --git a/_posts/2025-08-31-edition-126.markdown b/_posts/2025-08-31-edition-126.markdown index 2645376d9..bb1f32be1 100644 --- a/_posts/2025-08-31-edition-126.markdown +++ b/_posts/2025-08-31-edition-126.markdown @@ -204,7 +204,7 @@ welcome your thoughts and feedback!_ some weeks are more demanding than others, but having a framework keeps me grounded and ensures I can keep giving my best to Git. -* **Can you share how GSoC helped enhance your technical and +* **Can you share how Outreachy helped enhance your technical and non-technical skills (like communication, project management, etc.)?** My C and low-level engineering skills have improved immensely through diff --git a/_posts/2025-09-30-edition-127.markdown b/_posts/2025-09-30-edition-127.markdown new file mode 100644 index 000000000..bf5ec5474 --- /dev/null +++ b/_posts/2025-09-30-edition-127.markdown @@ -0,0 +1,475 @@ +--- +title: Git Rev News Edition 127 (September 30th, 2025) +layout: default +date: 2025-09-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 127 (September 30th, 2025) + +Welcome to the 127th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](http://git.github.io). + +This edition covers what happened during the months of August and September 2025. + +## Discussions + + + + + +### Support + +* [Doing blobless clone by default; switching between blobless, treeless and full clones by a command](https://lore.kernel.org/git/79ed51fbd94ec2793ab0388b33963b366e48c590.camel@aegee.org/) + + Dilyan Palauzov (Дилян Палаузов) sent an email to the Git mailing + list where he proposed making blobless cloning + (`--filter=blob:none`) the default behavior for `git clone` via a + global configuration option. He also suggested adding a command to + download all locally missing history, a command to convert a + repository to a pure treeless or pure blobless clone, and a config + option to make blobless clone the default behavior when running just + `git clone `. + + He said that most users used `git clone` to build or change software, not to + immediately analyze history with commands like `git log`. Therefore, + a reduced data download would speed up initialization, save + bandwidth, and reduce server load. + + Kristoffer Haugsbakk replied saying the proposed command to + "download all locally missing history" for treeless and blobless + clones "sounds like git-backfill(1)". He also noted that he had + "never used blob/treeless" clones himself. + + Derrick Stolee, who likes to be called just "Stolee", and who + contributed the `git backfill` command, replied to Kristoffer + confirming that `git backfill` is intended to assist with downloading + the missing blobs in a blobless partial clone. + + About treeless clones though, he noted that `git backfill` is not + optimized for them, and that treeless clones are generally not + intended for "refilling," as downloading missing trees is + "particularly expensive". + + Stolee suggested using `scalar clone`, which is already shipped with + Git, instead of making blobless cloning the default, as + `scalar clone` was contributed partly to allow users to opt into a + version of `git clone` that incorporates "best practices and + advanced features as they are developed", while `git clone` + maintains backward compatibility. He recognized that `scalar clone` + might not be "discoverable enough" though. + + Junio Hamano replied to Stolee's suggestion that a future command + like `git big-clone` could emerge from the feedback on + `scalar clone`. He said a separate command like `git big-clone` + would not be discoverable enough either. Instead as a new feature + matures, it should be a welcome change for `git clone` to borrow it + as a new option. Such optimizations (like those for large repos) + could be automatically enabled based on the repository's size, + provided it was done with end-user consent. + + Patrick Steinhardt replied to Stolee about treeless clones. He + agreed that the existing command `git backfill` is not optimized for + refilling treeless clones, and proposed an idea to backfill trees by + batching based on depth, but concluded that this method was + "definitely not ideal" and would perform "way worse compared to + backfilling blobs". + + Patrick also said that for these reasons he generally recommends not + to use treeless clones at all. + + Stolee replied to Patrick agreeing with the general caution + regarding treeless clones, and that they were "not a good approach + for doing ongoing work as a human". + + However he noted that they are useful if a user needs the speed of a + shallow clone combined with the ability to analyze commit history + (though with no path history) for an "ephemeral scenario like a CI + build". But they are a "tool for a very narrow case" and should only + be used by those who understand how to avoid their pitfalls. Patrick + then agreed with that point of view. + + Konstantin Ryabitsev, the system administrator for kernel.org, + replied to the original email from Dilyan about making blobless + clones the default behavior for `git clone`. He said a + counter-rationale to this proposal was that shallow clones (which + include blobless clones) generate significantly more load on the + server side. + + The reason is that for these partial clones, no pre-existing packs + are available for the operation, requiring more computation from the + server. So changing the default behavior for `git clone` could + likely result in slower clones for everyone and lead to more + unavailable servers due to the high load. + + Ben Knoble also replied to Dilyan's original email by opposing the + proposal to make blobless clones the default behavior while agreeing + that managing this preference via a config option was a reasonable + compromise. + + Ben's opinion was that such a default behavior would defeat the + "tremendous advantage of distributed version control", which is about + having the whole repository available independently. It would also + make some of his use cases more difficult as he frequently clones + repositories specifically to run "history spelunking searches". + + He noted that he primarily deals with repositories where the issue + isn't about clones, but about mismanaging large binary files in + history, which causes large blobs and clone times. + +## Developer Spotlight: Toon Claes + +* **Who are you and what do you do?** + + I'm Toon from Belgium. My name is pronounced like "tone" (rhymes with + "bone"), and not like the "toon" in "cartoon", but usually I'm already + happy if people remember my name 😉. + + I'm employed by GitLab for more than 8 years, and since late 2024 I've + been part of the Git team, contributing to the Git project. I've started + my professional career in 2008 building software for a payment terminal + running embedded GNU/Linux using C & C++. Later I've transitioned into + doing web and mobile development for a while. And now recently, I've + been circling back to more lower-level programming, contributing to Git + using C. + +* **What would you name your most important contribution to Git?** + + I'm fairly new in the Git community, but recently I've been working on + adding [`git last-modified`(1)](https://git.github.io/htmldocs/git-last-modified.html). + It's a sub-command that will be released in Git v2.52. This command + finds the commit that last modified each path in a tree. It can + be used on forges (like GitLab, GitHub, Codeberg), to show commit + data in a tree view. + +* **What are you doing on the Git project these days, and why?** + + The subcommand [`git last-modified`(1)](https://git.github.io/htmldocs/git-last-modified.html) + was recently merged in the 'master'. But there's more work to be + done to improve its performance. + +* **If you could get a team of expert developers to work full time on + something in Git for a full year, what would it be?** + + Once data is committed to Git, and it's made part of the history (i.e. + committed or merged into the default branch), it's trapped forever. This + is a core principle of Git: you cannot rewrite history without changing + commit hashes. This is very powerful, but also problematic in some + scenarios. + + For example, at my $DAYJOB we receive commonly the request from + customers to remove confidential or sensitive information from a Git + repository. This is not possible without rewriting history. Or when, by + accident, large files are committed to Git, you cannot get them out + (without rewriting history). Or people might want to remove/change + their personal information in a repository, for example when they + transition genders. + + Can we (and should we?) build something that removes and overwrites + pieces of history, without changing commit hashes? It's a slippery + slope, because from experience I know Git users are very creative and + might use this feature in ways it was not intended for. + +* **If you could remove something from Git without worrying about + backwards compatibility, what would it be?** + + The use of the double `..` and triple `...` dot notation in + [`gitrevisions(7)`](https://git-scm.com/docs/gitrevisions#_dotted_range_notations) + and `git diff(1)`. I even once ranted about it in [a video](https://www.youtube.com/watch?v=phThP8DwJVs). + +* **What is your favorite Git-related tool/library, outside of + Git itself?** + + I'm a big fan of [Magit][1]. It's arguably the best tool to interact + with Git and I also learned a lot from it. I consider myself an + advanced Git user, but I wouldn't be able to split up changes in + several commits without [Magit][1]. + +[1]: https://magit.vc/ + +* **Do you happen to have any memorable experience w.r.t. contributing + to the Git project? If yes, could you share it with us?** + + One of my earliest contributions to Git was a bug fix in the code used + by `git bundle create`. We noticed sometimes references didn't end up in + the bundle. After a lot of digging I submitted a patch that removed + about 30 lines of code written way back in 2007. The code from 2007 + caused references to be skipped if they were modified while the + `git bundle create` process was running. But it wasn't needed anymore + due some changes made in 2013, although no one ever realized that. + You can read more about it [in the patch][2]. + + It was really satisfying to submit a patch that was nothing more than + code deletion of really old code (and adding some tests). And it taught + me to write a good commit message, which I was praised for by + [the maintainer][3]. It was a very nice experience as a newcomer in the + community. + +[2]: https://lore.kernel.org/git/20241211-fix-bundle-create-race-v3-1-0587f6f9db1b@iotcl.com/ +[3]: https://lore.kernel.org/git/xmqqzfl4l22t.fsf@gitster.g/ + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I mostly live in Emacs and my terminal (zsh). I consume email in Emacs + using [notmuch][4]. To submit patches I use [b4][5], which I also + sometimes use to pull in patches. But I also sometimes pull in + the branches from [Junio's fork][6] or the fork shared across + my colleagues. + + In Git, I compile and unit test changes using Meson. Its use was + introduced in the Git project around the [end of 2024][7]. It's + reliable because it prevents me from forgetting to recompile + before running tests; it's fast because it parallelizes compilation + by default and automatically [uses Ccache][8]; it allows out-of-tree + builds, which is really convenient if you want to benchmark various + revisions of Git. + +[4]: https://notmuchmail.org/doc/latest/notmuch-emacs.html +[5]: https://github.com/mricon/b4 +[6]: https://github.com/gitster/git +[7]: https://lore.kernel.org/git/20241206-pks-meson-v11-0-525ed4792b88@pks.im/ +[8]: https://mesonbuild.com/Feature-autodetection.html#ccache + +* **What is your advice for people who want to start Git development? + Where and how should they start?** + + Learn to navigate [the mailing list archive][9]. It lacks structure so + things can be hard to find, but there's so much information up there. If + you're interested in a topic, or you think you've found the bug, start digging. + Use [`git blame(1)`][10] to find the commit that introduced the changes + and look up the conversation around it in the mailing list archive. + This will help you understand why some decisions are made. Also it + familiarizes you with the people in the community, how they think, + how they communicate, and what's expected from you. Having the + knowledge from those conversations can help you build a strong case + whenever you're submitting a feature change or bug fix. + +[9]: https://lore.kernel.org/git +[10]: https://git-scm.com/docs/git-blame + + +## Other News + +__Various__ + ++ [What’s next for Git? 20 years in, the community is still pushing forward](https://github.blog/open-source/whats-next-for-git-20-years-in-the-community-is-still-pushing-forward/) + by Lee Reilly on GitHub Blog - mainly about + the [Git Merge 2025 talks lineup](https://git-merge.com/#speakers). ++ [Git Developers Debate Making Rust Mandatory](https://www.phoronix.com/news/Git-Weighs-Mandatory-Rust) + by Michael Larabel on Phoronix. ++ [A policy for `Link:` tags](https://lwn.net/Articles/1037069/) (for Linux), + by Jonathan Corbet on LWN\.net. ++ [Working almost continuously for six months](https://www.linkedin.com/feed/update/urn:li:activity:7378744230275350528/), Yasin Dehfuli completed the [Persian translation of the ProGit book](https://git-scm.com/book/fa/v2). ++ An initiative [to refresh the look and content of https://git-scm.com/](https://github.com/git/git-scm.com/issues/2046) has been kicked off by Toon Claes. Contributions welcome, especially from visual designers! + + +__Light reading__ + ++ [git-flow-next: The Next Iteration of Advanced Git Workflows](https://www.git-tower.com/blog/git-flow-next) + by Bruno Brito on Tower Blog. ++ [A kludgy new way to git-blame](https://benknoble.github.io/blog/2025/09/17/blame/) + by D. Ben Knoble on his Junk Drawer personal blog, + about the new `git-greb` script that feeds `git grep` to `git blame` + (with appropriate options) in order to blame matching lines. ++ [My new git utility `what-changed-twice` needs a new name](https://blog.plover.com/2025/09/21/#what-changed-twice) + by Mark Dominus (陶敏修) on his The Universe of Discourse blog, + about the tool to help get related changes into the same commit. ++ [Supercharge your Git workflows](https://about.gitlab.com/blog/supercharge-your-git-workflows/) + by Darwin Sanoy on GitLab Blog, about how to + optimize `git clone` operations in any environment, reducing clone time and disk space, + with the [Git Much Faster](https://gitlab.com/gitlab-accelerates-embedded/misc/git-much-faster) script. + + Compare with [Scalar](https://github.com/microsoft/scalar), + a tool that helps Git scale to handle large Git repositories + by enabling some advanced Git features. + Scalar was first mentioned in [Git Rev News Edition #60](https://git.github.io/rev_news/2020/02/19/edition-60/), + and now is part of Git: [scalar - A tool for managing large Git repositories](https://git-scm.com/docs/scalar). + [The Story of Scalar](https://github.blog/2022-10-13-the-story-of-scalar/) + was mentioned in [Edition #92](https://git.github.io/rev_news/2022/10/26/edition-92/). ++ [The Origin Story of Merge Queues](https://mergify.com/blog/the-origin-story-of-merge-queues) + by Julien Danjou on Mergify Blog. + This article traces merge queues history + (from Bors and Homu to Bulldozer, Kodiak, Mergify, GitHub and GitLab), + why they emerged, and how they became a standard in modern software development. + + [Mergify.com](https://mergify.com/), + a web service for automating pull requests (free for open-source projects), + was mentioned in [Git Rev News Edition #87](https://git.github.io/rev_news/2022/05/26/edition-87/). ++ [Git - Fun Facts](https://dev.to/rubansi/git-fun-fact-45de) + by Rubansi Vincent on DEV\.to: + a mix of fun and surprising facts about Git. ++ [diff --stat for binary files (in the Jujutsu version control system)](https://neugierig.org/software/blog/2025/08/jj-binary-stat.html) + by Evan Martin on neugierig\.org: Tech Notes. + + [Jujutsu (`jj`)](https://jj-vcs.github.io/jj/) is a Git-compatible version control system + written in Rust, first mentioned in + [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [Jujutsu For Busy Devs, Part 2: "How Do I...?"](https://maddie.wtf/posts/2025-07-21-jujutsu-for-busy-devs/entry/1) + by Madeleine Mortensen, continues the [Jujutsu For Busy Devs](https://maddie.wtf/posts/2025-07-21-jujutsu-for-busy-devs) + series, mentioned in [Git Rev News Edition #125](https://git.github.io/rev_news/2025/07/31/edition-125/). ++ [Dear GitHub: no YAML anchors, please](https://blog.yossarian.net/2025/09/22/dear-github-no-yaml-anchors) + by William Woodruff (yossarian) on his ENOSUCHBLOG blog. + He says that they are redundant with existing functionality, + make CI/CD human and machine comprehension harder, + and their support in GitHub Actions does not introduce any new, previously unavailable features. ++ [Custom VC-Focused Emacs Functions I Created to Enhance My Git Workflow](https://www.rahuljuliato.com/posts/vc-git-functions) + by Rahul M. Juliato on Rahul's Blog. ++ [How to delete all squash-merged local git branches with one terminal command](https://whitep4nth3r.com/blog/how-to-delete-all-squash-merged-local-git-branches-with-one-terminal-command/) + (which you probably shouldn't use), + by Salma Alam-Naylor on her blog. ++ [finding deleted content using git logs](https://kjelsrud.dev/blog/finding-deleted-content-using-git-logs/) + by Sindre Kjelsrud, also known as “Sid”, on Sids' blog: + a short note on `git log -S`. ++ [Git exclude, a handy feature you might not know about](https://marijkeluttekes.dev/blog/articles/2025/09/03/git-exclude-a-handy-feature-you-might-not-know-about/) + by Marijke Luttekes on her blog, about `.git/info/exclude`. ++ [Git Dual Remotes](https://zanshin.net/2025/09/02/git-dual-remotes/): + a short note by Mark H. Nichols on his Zanshin.net personal site, + about the difference between `git push` and `git fetch` with multiple URLs, + and `jj git push --all-remotes`. ++ [Migrating from Gitea to Forgejo the long way](https://msfjarvis.dev/posts/migrating-from-gitea-to-forgejo-the-long-way/) + by Harsh Shandilya on his blog.
+ [Gitea](https://about.gitea.com/) and [Forgejo](https://forgejo.org/) are software forges. ++ [Some thoughts on personal git hosting](https://shkspr.mobi/blog/2025/09/some-thoughts-on-personal-git-hosting/) + by Terence Eden on Terence Eden’s Blog. ++ [Setting up cgit with Caddy v2 web server](https://www.sixfoisneuf.fr/posts/setting-up-cgit-with-caddy2/) + by Simon Garrelou on his SixFoisNeuf blog (2022). ++ [Sourcegraph went dark](https://www.eric-fritz.com/articles/sourcegraph-went-dark/) + by Eric Fritz on his blog (2024), + about the work that went into ensuring that references are kept alive + after the `sourcegraph/sourcegraph` repository went private + (there is a public snapshot available at [sourcegraph/sourcegraph-public-snapshot](https://github.com/sourcegraph/sourcegraph-public-snapshot), + which is a read-only archived repository). ++ [How to use stacked PRs to unblock your entire team](https://graphite.dev/blog/stacked-prs) + by Ninad Pathak on Graphite Blog (2024), and
+ [A guide to using Graphite's stacked PRs for GitHub users](https://dev.to/semgrep/a-guide-to-using-graphites-stacked-prs-for-github-users-5c47) + by Martin Jambon for Semgrep on DEV\.to. + + See also [Stacked Branches with GitButler](https://blog.gitbutler.com/stacked-branches-with-gitbutler/) + by Scott Chacon on the GitButler Blog, + mentioned in [Git Rev News Edition #118](https://git.github.io/rev_news/2024/12/31/edition-118/). + + See also [Understanding the Stacked Pull Requests Workflow](https://www.git-tower.com/blog/stacked-prs/) by Bruno Brito on Tower's blog, + mentioned in [Git Rev News Edition #111](https://git.github.io/rev_news/2024/05/31/edition-111/) + together with various other articles and tools about stacked diffs, stacked PRs, and stacked branches. + + See also [Rethinking code reviews with stacked PRs](https://www.aviator.co/blog/rethinking-code-reviews-with-stacked-prs/#) + by Ankit Jain on the Aviator blog, + mentioned in [Git Rev News Edition #115](https://git.github.io/rev_news/2024/09/30/edition-115/) + with links to more sites and tools related to stacked PRs, etc. ++ [GitButler's new patch based Code Review (Beta)](https://blog.gitbutler.com/gitbutlers-new-patch-based-code-review) + by Scott Chacon on GitButler's Blog. ++ [first-class merges and cover letters](https://dotat.at/@/2025-09-11-cover-letter.html) + by Tony Finch on his blog. + + +__Slightly heavier reading__ + ++ [Quo Vadis, Code Review? Exploring the Future of Code Review](https://arxiv.org/abs/2508.06879), + a scientific article from August 2025, arXiv:2508.06879 + (most authors of the paper are from Blekinge Institute of Technology, Karlskrona, Sweden). ++ [Code Review as Decision-Making -- Building a Cognitive Model from the Questions Asked During Code Review](https://arxiv.org/abs/2507.09637), + a scientific article from July 2025, arXiv:2507.09637 + (all authors are from Lund University, Lund, Sweden). + Submitted to _Empirical Software Engineering_, Springer Nature. + + +__Easy watching__ + ++ [Git Mini Summit 2025 Videos](https://blog.gitbutler.com/git-mini-summit-2025) + by Scott Chacon on GitButler's Blog. ++ Kinetic Merge in action + + [Merging through a file split](https://youtu.be/JHb9DKK0LIA) + + [Complex merge demonstration](https://youtu.be/6jry6NKxGJA) + + [Merging code embedded inside an if-statement](https://www.youtube.com/watch?v=sm4Naq_zJU0&t=2s) ++ [12 Git commands visualized in 3D: a spatial approach to understanding version control](https://www.youtube.com/watch?v=C2aFC8wFp2A) + [4:58], on the Initial Commit channel on YouTube. ++ [Stacked Branches With Lazygit](https://www.youtube.com/watch?v=M6S-9Y8peDY) + [12:18] by Jesse Duffield (Lazygit author) on YouTube. + + [lazygit](https://github.com/jesseduffield/lazygit) is a simple [windowed] terminal UI for Git, + written in Go. It was first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/). + + +__Git tools and sites__ + ++ [Kinetic Merge](https://github.com/sageserpent-open/kineticMerge) + is a command-line tool that helps you merge a heavily refactored codebase and stay sane. + Its goals are to: + + Merge two branches of a Git repository *holistically across the entire codebase*. + + Take into account the motion of code in either branch due to refactoring. + + Handle file renames, file splits, file concatenation. + + Handle code being excised from one place in a file and moved elsewhere in that file or to somewhere within another file, or hived off all by itself in its own new file. + + Work alongside the usual Git workflows, allowing ordinary Git merge to take over at the end if necessary. + + Be a simple command line tool that tries to do as much as it can without supervision, and with minimal supervision when complexities are encountered. + + Written in Scala, under an MIT license. ++ [Git Much Faster](https://gitlab.com/gitlab-accelerates-embedded/misc/git-much-faster) + is a comprehensive benchmarking tool for comparing different Git clone strategies, + especially for large repositories. + Written as a Bash shell script, under MIT license. ++ [_prek_](https://prek.j178.dev/) is a reimagined version of [pre-commit](https://pre-commit.com/), built in Rust. + It is a framework to run hooks written in many languages, + and it manages the language toolchain and dependencies for running the hooks. + prek is not production-ready yet: some subcommands and languages are not implemented. + Under MIT license. + + See also [Ready prek go!](https://hugovk.dev/blog/2025/ready-prek-go/) + article by Hugo van Kemenade on his blog. ++ [git-sqlite](https://github.com/cannadayr/git-sqlite) + is a collection of shell scripts, + including a custom diff and merge driver for SQLite, + that allows a SQLite database to be tracked using the Git version control system. + Under MIT license. + ++ [LearnGit.io](https://learngit.io/) teaches version control + using animated visualizations of Git internals—and is + [now free](https://learngit.io/posts/learngit-io-is-now-free-for-students) for students and teachers. + Created by Jack Lot of [The Modern Coder](https://www.youtube.com/@themoderncoder) YouTube channel, + LearnGit offers 41 video lessons across 11 modules, along with quizzes, + a Git command search, and high-quality written documentation. + Educators can email jack@learngit.io for bulk vouchers. + First mentioned in [Git Rev News Edition #108](https://git.github.io/rev_news/2024/02/29/edition-108/). ++ [GitFichas](https://gitfichas.com/en) (also know as GitStudyCards) + is a collection of study cards about Git, + for devs that might need a refresher about Git commands. + GitFichas is now [open-source](https://github.com/jtemporal/gitfichas) + and undergoing some construction. ++ Git's home page now has a [Learn](https://git-scm.com/learn) section, including [a handy Git Cheat Sheet](https://git-scm.com/cheat-sheet), contributed by the ever-industrious + [Julia Evans](https://jvns.ca/). These contributions are part of [the initiative to refresh the look and contents of git-scm.com](https://github.com/git/git-scm.com/issues/2046). + + +## Releases + ++ Git for Windows [v2.51.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.51.0.windows.2) ++ Gerrit Code Review [3.13.0-rc0](https://www.gerritcodereview.com/3.13.html#3130) ++ Bitbucket Data Center [10.0](https://confluence.atlassian.com/bitbucketserver/release-notes-872139866.html) ++ GitHub Enterprise [3.17.6](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.6), +[3.16.9](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.9), +[3.15.13](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.13), +[3.14.18](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.18) ++ GitLab [18.4.1, 18.3.3, 18.2.7](https://about.gitlab.com/releases/2025/09/25/patch-release-gitlab-18-4-1-released/), +[18.4](https://about.gitlab.com/releases/2025/09/18/gitlab-18-4-released/), +[18.3.2, 18.2.6, 18.1.6](https://about.gitlab.com/releases/2025/09/10/patch-release-gitlab-18-3-2-released/) ++ GitKraken [11.4.0](https://help.gitkraken.com/gitkraken-desktop/current/) ++ Sourcetree [4.2.14](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.14.html) ++ tig [2.6.0](https://github.com/jonas/tig/releases/tag/tig-2.6.0) ++ Garden [2.3.0](https://github.com/garden-rs/garden/releases/tag/v2.3.0) ++ Git Cola [4.15.0](https://github.com/git-cola/git-cola/releases/tag/v4.15.0) ++ GitButler [0.16.8](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.16.8), +[0.16.7](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.16.7) ++ Kinetic Merge [1.9.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.9.0) ++ git-credential-oauth [0.16.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.16.0) ++ Tower for Mac [14.4, 14.5](https://www.git-tower.com/release-notes/mac) ++ git-flow-next [0.1](https://git-flow.sh/) + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Toon Claes, Johannes Schindelin, +Bruno Brito, Gerard Murphy, Jack Lot, Ben Knoble +and Štěpán Němec. diff --git a/_posts/2025-10-31-edition-128.markdown b/_posts/2025-10-31-edition-128.markdown new file mode 100644 index 000000000..40be28f55 --- /dev/null +++ b/_posts/2025-10-31-edition-128.markdown @@ -0,0 +1,549 @@ +--- +title: Git Rev News Edition 128 (October 31st, 2025) +layout: default +date: 2025-10-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 128 (October 31st, 2025) + +Welcome to the 128th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](http://git.github.io). + +This edition covers what happened during the months of September and October 2025. + +## Discussions + +### General + +* [Git participated in GSoC (Google Summer of Code) 2025](https://summerofcode.withgoogle.com/programs/2025/organizations/git) + + All the contributors have successfully passed their final evaluation + and published a final report: + + - Lucas Oshiro [worked](https://lucasoshiro.github.io/gsoc-en/#weeks) on the + [Machine-Readable Repository Information Query Tool](https://summerofcode.withgoogle.com/programs/2025/projects/fGgMYHwl) + project. He was mentored by Patrick Steinhardt and Karthik Nayak. The final + report can be found on + [his website](https://lucasoshiro.github.io/gsoc-en/#final-report). + + - Meet Soni [worked](https://inosmeet.github.io/posts/gsoc25/) on the + [Consolidate ref-related functionality into git-refs](https://summerofcode.withgoogle.com/programs/2025/projects/xVrT5e2q) + project. He was mentored by Patrick Steinhardt and Jialuo She. The final + report can be found on + [his website](https://inosmeet.github.io/posts/gsoc25/gsoc25_final/). + + - Ayush Chandekar [worked](https://ayu-ch.github.io/) on the + [Refactoring in order to reduce Git’s global state](https://summerofcode.withgoogle.com/programs/2025/projects/no7dVMeG) + project. He was mentored by Christian Couder and Ghanshyam Thakkar. The final + report can be found on + [his website](https://ayu-ch.github.io/2025/08/29/gsoc-final-report.html). + + Kaartic Sivaraam and Christian Couder were + ["org admins"](https://developers.google.com/open-source/gsoc/help/oa-tips). + + Congratulations to the contributors, their mentors and the org admins! + +* [Git Merge 2025 conference](https://git-merge.com/) and [Contributor's Summit 2025](https://lore.kernel.org/git/aOQVeVYY6zadPjln@nand.local/) + + The Git Merge conference happened on + [September 29th and 30th](https://github.blog/open-source/git/20-years-of-git-2-days-at-github-hq-git-merge-2025-highlights/) + in San Francisco, hosted by [GitHub](https://github.com/) at their + GitHub HQ. The [session records](https://www.youtube.com/playlist?list=PLNXkW_le40U6Ms1XlsYKi_yUh5J2FOSlf) + are available. + + On the second day, there was also + [the Contributor's Summit](https://lore.kernel.org/git/aOQVeVYY6zadPjln@nand.local/). + The [full notes](https://docs.google.com/document/d/1arvvXP8DrF3F8PCKQOmGvYh5jUg8P9Clx9m-FgDD4EI/) + as well as [notes broken down by topic](https://lore.kernel.org/git/aOQV6iM49QDhcC+C@nand.local/#r) + are available. + +* [Git Mini Summit 2025](https://lore.kernel.org/git/aGwHt9HCd86hVuKh@pks.im/) + + On August 28 in Amsterdam, a [Git Mini Summit](https://lore.kernel.org/git/aGwHt9HCd86hVuKh@pks.im/) + happened as + [a co-hosted event of the Open Source Summit Europe](https://osseu2025.sched.com/event/28R2Q/git-mini-summit-additional-fee-pre-registration-required), + sponsored by GerritForge, GitButler, GitLab, and Google. + The [schedule](https://drive.google.com/file/d/1vacimnS9NUTcYUsRe8100El8Hdl_C7GD/view) + and [session records](https://blog.gitbutler.com/git-mini-summit-2025) + are available. + + + + +### Support + ++ [[Change] Git build issue on NonStop](https://lore.kernel.org/git/01c101dc2842$38903640$a9b0a2c0$@nexbridge.com/) + + Randall S. Becker reported on the mailing list that CI tests on the + NonStop x86 platform were broken after the `uintptr_t` type started + to be used in [clar](https://github.com/clar-test/clar) tests when + displaying error messages in test failures (in case pointer comparisons + fail). + + Jeff King, alias Peff, replied to Randall that `uintptr_t` was + already used in many places in the regular code, and guessed the + issue might come from how clar defined that type. He noted though + that the line in the clar test where `uintptr_t` appeared also + contained `PRIxPTR` which is a macro that is not used in the regular + code. So he wondered if just replacing that macro with `PRIuMAX` + (which is often used) would be enough to fix the issue. + + `PRIxPTR`, `PRIuMAX` and similar macros are format specifier macros + from the C standard library (defined in ``) that provide + portable ways to print integer types using functions like `printf()` + across different platforms. They are all named in the same way, with + `PRI` meaning `printf`, the next letter indicating the format, like + `x` for hexadecimal and `u` for unsigned decimal, and the last part + indicating the type, like `PTR` for pointer-sized integers, `MAX` + for maximum-width integers, `64` for 64-bit, etc. + + Randall replied to Peff that replacing `PRIxPTR` with `PRIuMAX` + would work, and that he was going to try it. + + Patrick Steinhardt also replied to Randall and Peff saying it would + work, and asked Peff if he wanted to send that change. + + Peff replied to Patrick that he'd be happy if Patrick sent the + change, but noted that using `PRIxMAX` might be better than + `PRIuMAX` as the code wanted to print hexadecimal values. + + Patrick then reported to Peff that Peff's suggestion to use the + `PRIxMAX` or `PRIuMAX` format specifier macros didn't work on 32 bit + systems, because casting a pointer to an integer of different size + (the pointer is 32 bits, but `uintmax_t` is 64 bits) fails. + + Patrick proposed using `%p` as a format specifier saying it might be + a better trade-off. The downside was that the output format would be + unpredictable across platforms as `%p` doesn't have a standardized + output format. So tests that validated the exact error message + format would have to be dropped. But at least `%p` would work + everywhere and produce stable output. + + Junio Hamano, the Git maintainer, agreed with Patrick that `%p` was + "the most appropriate solution". + + Randall then confirmed that `%p` worked on NonStop x86 even if the + man pages warned to the contrary. + + The `%p` solution was eventually merged to the 'master' branch. + + +## Developer Spotlight: Kristoffer Haugsbakk + +* **Who are you and what do you do?** + + I’m Kristoffer from Norway. My day job is working on a Java webapp + primarily used for clinical mental health questionnaires. + +* **What would you name your most important contribution to Git?** + + One I like was when I and the mailing list collaborators fixed a bug + related to Git notes handling by [git-format-patch(1)][1]. It’s + small and niche but Git notes handling is very important to me; I + think Notes are a great way to maintain metadata between patch + submissions. In fact I think it’s great for most commit metadata + that I am interested in maintaining. + +[1]: https://git-scm.com/docs/git-format-patch + +* **What are you doing on the Git project these days, and why?** + + The one I am focusing on is improving the [git-patch-id(1)][2] + documentation. It so happens that you can use that command to make a + commit—patch-id mapping for the whole repository, which you then in + turn can use to make an improved [git-cherry(1)][3] oneliner (one + that says what the upstream commit hash is) as well as, say, using + commands like git-range-diff to see if the upstream committer made + any changes to your submission like fixing commit message typos. But + most uses of this command that I see just use it to figure out what + the patch ID of one single commit is and have to script everything + around that, like loop over [git-rev-list(1)][4]. + +[2]: https://git-scm.com/docs/git-patch-id +[3]: https://git-scm.com/docs/git-cherry +[4]: https://git-scm.com/docs/git-rev-list + +* **If you could get a team of expert developers to work full time on + something in Git for a full year, what would it be?** + + I would ask them to find a way for projects to define their own + conventions and preferences that can be easily shared with all + contributors. Something better than asking each contributor to + download and install hooks. Projects need a better and more + declarative way to configure how their project is supposed to + work. One example might be that a project does not want merge + commits to land in the mainline. It should be simple to take that + high-level goal and make sure that the in-effect central repository + never gets any merge commits. + + Git will not be replaced any time soon, despite it being more + difficult to use than it ought to be. But we can already see what + the effects of the high difficulty of using it is: some projects + outsource all commit messages to issue trackers, and change + proposals (pull requests and patch series descriptions) to webapp + forges. (Meaning they don’t even duplicate the PR description + somewhere in Git like in a commit message.) What you end up with is + still Git but with all the interesting information living at least + one hyperlink away. + +* **If you could remove something from Git without worrying about + backwards compatibility, what would it be?** + + I can’t think of a single thing to remove that would have a big + impact. + + I guess I would remove [git-filter-branch(1)][5]. People can use + [git-filter-repo(1)][6]. And with that one removed I wouldn’t have to ask + people to not use it any more. ;) + +[5]: https://git-scm.com/docs/git-filter-branch +[6]: https://github.com/newren/git-filter-repo + +* **Documentation contributions require understanding both the technical + implementation and the user perspective. How do you approach + bridging that gap? Do you have strategies for ensuring documentation + stays accurate as code evolves?** + + Most of the challenge in bridging the gap for me is about trying to + describe things accurately while not being tedious and verbose. The + worst challenge is when I realistically have one paragraph to + explain something but there are eight factors to mention. (Not a + real case; just the feeling of a challenge that I have encountered + before.) + + For things that are either just difficult or have many factors to + consider I think the best approach we have right now is to mention + other documentation pages in parentheses. An obvious candidate is + [gitglossary(7)][7] where we can gather all kinds of jargon and be + as verbose as we want to. :) + + I don’t have any strategies for ensuring that documentation stays + accurate as code evolves. Let’s take something concrete as an + example: an update to the documentation adds a very similar + paragraph to two documentation pages. That is an obvious maintenance + burden since a later update is likely to necessitate a change in + both places, but you are likely to only deal with one of them. The + obvious fix is to parameterize the paragraph. But I don’t have good + indirect experience with that in [AsciiDoc][8]; the last time I saw + something parameterized was when an [AsciiDoc][8] macro forced + inline formatting to be handled literally. The cure seems worse than + the disease to me. + + The best I can do now when making updates is to investigate the + lines that I am changing and find the histories of any possible + near-duplicate texts. + +[7]: https://git-scm.com/docs/gitglossary +[8]: https://asciidoc.org/ + +* **What is your favorite Git-related tool/library, outside of Git + itself?** + + [Magit][9]. An Emacs Git frontend. + +[9]: https://magit.vc/ + +* **Do you happen to have any memorable experience w.r.t. contributing + to the Git project? If yes, could you share it with us?** + + When I added a test case to `t/t7001-mv.sh` that [made the continuous + build routine on Windows (CI) time out][16]. The test was + `test_expect_failure` and triggered a C assertion, and the Windows + CI pops up a modal dialog on assertion failures. That dialog is of + course never dismissed by any operator and so the suite eventually + timed out. + +[16]: https://lore.kernel.org/git/pull.1908.git.1745593515875.gitgitgadget@gmail.com/ + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I use the builtin commands for making patches and sending them + ([git-format-patch(1)][10] and [git-send-email(1)][11]). For programming and + writing I use the basic, needed tools along with Emacs. Very + occasionally I will use GDB. + +[10]: https://git-scm.com/docs/git-format-patch +[11]: https://git-scm.com/docs/git-send-email + +* **What is your advice for people who want to start Git development? + Where and how should they start?** + + Find something technically wrong in the documentation and fix + it. That’s what I did in 2016; I wanted to test out this new (to me) + “email-based workflow”. Focus on fixing things instead of + subjectively improving something. Because someone might object and + propose that you send a new version. Making subjective documentation + improvements is the next step in terms of difficulty I guess. + + It sounds trivial but someone used to Git forges will have enough + challenges just sending proper patches to the project over email. + + Also read through [`Documentation/SubmittingPatches`][12]. I don’t + really see many corrections that refer to other documents. You could + of course get a correction that refers to some [*lore*][13] but that + is unlikely to happen for simple changes if you just structure it + similar to recent, accepted submissions that you find. + +[12]: https://git-scm.com/docs/SubmittingPatches +[13]: https://lore.kernel.org/git + +* **If there's one tip you would like to share with other Git + developers, what would it be?** + + You won’t get any C programming tips from me since I can’t write or + edit three lines of C code without segfaulting five times. + + Take advantage of the fact that the Git history is so + well-structured. Maybe you find some questionable behavior or + code. Use the “pickaxe” technique (see [git-log(1)][14]) on some + good candidate text and trace the behavior back to the start. Maybe + the commit message explains the issue or behavior. If not use + `refs/notes/amlog` (which you should be “subscribed” to already) and + see if something relevant was discussed on the patch discussion. If + not there is likely to be no written record out there; another thing + that this project is disciplined about is keeping the relevant + discussion on the mailing list, not the mailing list and N other + satellite fora. + + Those links (to commits and archived emails) are very valuable when + you want to discuss a change to something that has been in + [git(1)][15] for years and years. + +[14]: https://git-scm.com/docs/git-log#Documentation/git-log.txt--Gregex +[15]: https://git-scm.com/docs/git + +## Other News + +__Various__ + ++ [Git considers SHA-256, Rust, LLMs, and more](https://lwn.net/Articles/1042172/) + by Jonathan Corbet on LWN\.net. ++ [Git Developers Talk About Potentially Releasing Git 3.0 By The End Of Next Year](https://www.phoronix.com/news/Git-3.0-Release-Talk-2026) + by Michael Larabel on Phoronix. ++ [GitHub is migrating to Azure! And goodbye to new development for a year.](https://www.redhotcyber.com/en/post/github-is-migrating-to-azure-and-goodbye-to-new-development-for-a-year/) + by Redazione RHC on Red Hot Cyber. ++ [Fedora Moves Towards Forgejo](https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/) + by Matthew Miller and Akashdeep Dhar on December 4, 2024 + in Fedora Magazine. + + [Forgejo](https://forgejo.org/) is a self-hosted lightweight software forge, + written in Go; nowadays a hard fork of Gitea (which in turn was based on Gogs). + It was first mentioned in passing in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/). + + +__Light reading__ + ++ [Building for the future: on Tangled's existence and direction](https://anirudh.fi/future) + by Anirudh Oppiliappan on their blog; + also published [at icy takes blog](https://icy.leaflet.pub/3m47cll72hs25) on ATProto. + + [Tangled.sh](https://blog.tangled.sh/intro) is a new social-enabled Git collaboration platform + built on top of the AT Protocol / ATProto + (which is behind the [BlueSky](https://bsky.app/) microblogging federated social media service). + It was first mentioned in [Git Rev News Edition #125](https://git.github.io/rev_news/2025/07/31/edition-125/). ++ [6 months of Tangled: a quick recap, and notes on the future](https://blog.tangled.org/6-months) + by Anirudh Oppiliappan and Akshay Oppiliappan on Tangled Blog. ++ [Socially self-hosting source code with Tangled on Bluesky](https://anil.recoil.org/notes/disentangling-git-with-bluesky) + by Anil Madhavapeddy, Professor of Planetary Computing, on his blog. ++ [Redistributing Git with Nostr](https://fiatjaf.com/18ff5416.html) + by início on their blog. + + There exists [gitstr (`git str`)](https://github.com/fiatjaf/gitstr), + which is a tool to send and receive Git patches + over [Nostr](https://nostr.com/), using [NIP-34](https://github.com/nostr-protocol/nips/pull/997) + (first mentioned in [Git Rev News Edition #109](https://git.github.io/rev_news/2024/03/31/edition-109/)). + + Note that [git-credential-oauth](https://github.com/hickford/git-credential-oauth), + a Git credential helper that securely authenticates to GitHub, GitLab, BitBucket and Gerrit + using [OAuth](https://datatracker.ietf.org/wg/oauth/about/), + can replace the "create an account; pick a password; confirm an email address; set up SSH keys for pushing" steps. ++ [How GitHub won software development](https://www.infoworld.com/article/4069045/how-github-won-software-development.html) + by Nick Hodges on Rubber Duck Reflections opinions blog on InfoWorld. ++ [You already have a git server](https://maurycyz.com/misc/easy_git/) + on Maurycy's blog; + describes how one can serve Git repositories via SSH (with SSH access) + or via dumb HTTP (with a web server). ++ [Simple automated deployments using git push](https://garrido.io/notes/simple-automated-deployments-git-push/) + by Gabriel Garrido on his blogs / notes (2024). ++ [Discussion of the Benefits and Drawbacks of the Git Pre-Commit Hook](https://yeldirium.de/2025/10/09/pre-commit-hooks/index.html) + by Hannes Leutloff on his blog. ++ [You can use `fzf` to review git commits](https://jvns.ca/til/fzf-preview-git-commits/) + by Julia Evans in her TIL (Today I've Learned) section. + + See also [Improving shell workflows with fzf](https://seb.jambor.dev/posts/improving-shell-workflows-with-fzf/), + mentioned in [Git Rev News Edition #74](https://git.github.io/rev_news/2021/04/30/edition-74/), and + [Curing A Case Of Git-UX](https://oppi.li/posts/curing_a_case_of_git-UX/), + mentioned in [Git Rev News Edition #126](https://git.github.io/rev_news/2025/08/31/edition-126/). ++ [Switch to Jujutsu already: a tutorial](https://www.stavros.io/posts/switch-to-jujutsu-already-a-tutorial/) + by Stavros on Stavros' Stuff. + + [Jujutsu (`jj`)](https://jj-vcs.github.io/jj/) is a Git-compatible version control system + written in Rust, which was first mentioned in + [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [Magit Is Amazing!](https://heiwiper.com/posts/magit-is-awesome/) + by Abdallah Maouche (heiwiper) on his blog + (how it does things that others need to use Jujutsu over Git for). + + [Magit](https://magit.vc/) is a popular [Emacs](https://www.gnu.org/software/emacs) editor interface to Git, + first mentioned (in passing) in [Git Rev News Edition #6](https://git.github.io/rev_news/2015/08/05/edition-6/). ++ [Branching in a Sapling Monorepo](https://engineering.fb.com/2025/10/16/developer-tools/branching-in-a-sapling-monorepo/) + + [Sapling](https://sapling-scm.com/) is a scalable, user-friendly, and open-source source control system + that powers Meta's (Facebook's) monorepo. + It was first mentioned in [Git Rev News Edition #93](https://git.github.io/rev_news/2022/11/30/edition-93/). ++ [Stop Rebasing Everything: Your Git History Isn’t That Special](https://dev.to/dolig/stop-rebasing-everything-your-git-history-isnt-that-special-ln3), + an argument in the merge-vs-rebase debate. + by Guillaume on DEV\.to. ++ [Diff Algorithms](https://flo.znkr.io/diff/) + by Florian Zenker on his website.
+ The result of this exploration was [znkr.io/diff](https://znkr.io/diff), + a difference algorithm module for Go. + + Note that with [`git diff`](https://git-scm.com/docs/git-diff) + you can choose between `myers` (default), `minimal`, `patience` and `histogram` algorithms. ++ [Git Super-Power: The Three-Way Merge](https://qsantos.fr/2024/05/01/git-super-power-the-three-way-merge/) + by Quentin Santos on his blog (2024).
+ Provides the following tl;dr: `git config --global merge.conflictstyle diff3`. ++ [Anyone Can Commit Code as You on GitHub (Here's How to Stop Them)](https://www.nickyt.co/blog/anyone-can-commit-code-as-you-on-github-heres-how-to-stop-them-2in7/) + with signed commits (with tutorial focusing on macOS using GPG Keychain). + Written by Nick Taylor on his Just Some Dev blog. ++ [GitHub Ensloppification](https://dbushell.com/2025/08/11/github-ensloppification/) + by David Bushell on his blog. ++ ["GitHub" Is Starting to Feel Like Legacy Software](https://www.mistys-internet.website/blog/blog/2024/07/12/github-is-starting-to-feel-like-legacy-software/) + rant by Misty De Méo on her blog (2024). ++ [Implementing Conventional Commits with Jira Ticket Prefix Validation](https://heristop.github.io/blog/2024-07-09-conventional-commit-jira/) + by Alexandre Mogère (heristop) on Zazen Code. + + The [Conventional Commits](https://www.conventionalcommits.org/) specification + was first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/), + and in many editions since. ++ [Conventional Commits considered harmful](https://larr.net/p/cc.html) + (or rather overly strict enforcement of the standard), + rant by Salih Muhammed, with a few further links. ++ [Contribute to GitFichas](https://jtemporal.com/contribute-to-gitfichas/) + by Jessica Temporal on her blog. + + [GitFichas](https://gitfichas.com/en) (also know as GitStudyCards) + is a collection of study cards about Git, + for devs that might need a refresher about Git commands. + Mentioned in [the previous edition of Git Rev News](https://git.github.io/rev_news/2025/09/30/edition-127/). + + +__Easy watching__ + ++ [Gerrit User Summit 2025, featuring also GitButler and Jujutsu](https://www.youtube.com/playlist?list=PLySCWiWz9cNuiJK2Uy3foHGvkxL3fBLUC) + by Luca Milanesio on GerritForge's YouTube channel. ++ [Jujutsu at Google](https://www.youtube.com/watch?v=v9Ob5yPpC0A&list=PLOU2XLYxmsILM5cRwAK6yKdtKnCK6Y4Oh&index=8) + ([slides](https://drive.google.com/file/d/1dVzug1lHoOxdbFu8gcCJCu-G_uVMUATI/edit)) + on Google for Developers channel on YouTube; + part of [JJ Con 2025 playlist](https://www.youtube.com/playlist?list=PLOU2XLYxmsILM5cRwAK6yKdtKnCK6Y4Oh).
+ In this talk, Martin von Zweigbergk presents + on Jujutsu architecture and future plans.
+ JJ Con 2025 was a dedicated conference hosted by Google + for the [Jujutsu](https://jj-vcs.github.io/jj/latest/) version control system. ++ [Solving Git's Pain Points with Jujutsu (with Martin von Zweigbergk)](https://www.youtube.com/watch?v=ulJ_Pw8qqsE) + on Developer Voices channel on YouTube. + + +__Scientific papers__ + ++ Ya-Nan Li, Yaqing Song, Qiang Tang, Moti Yung: + _"End-to-End Encrypted Git Services"_, + Cryptology {ePrint} Archive, Paper 2025/1208, + , + DOI:10.1145/3719027.3744815 + + See [_"Scientists develop end-to-end encryption for git services"_](https://techxplore.com/news/2025-10-scientists-encryption-git.html) + article by University of Sydney, edited by Stephanie Baum, reviewed by Robert Egan, + on TechXplore. ++ S.R.P. van Hal, M. Post, K. Wendel: + _"Generating Commit Messages from Git Diffs"_, + [arXiv:1911.11690](https://arxiv.org/abs/1911.11690) (2019)
+ mentions "inherent shortcoming of current commit message generation models, + which perform well by memorizing certain constructs." + + +__Git tools and sites__ + ++ [diff-modulo-base](https://git.sr.ht/~nhaehnle/diff-modulo-base) + is a tool that allows you to compare the relevant changes + of two versions of a rebased branch given three input diffs: + two _base_ diffs that show the changes since the respective merge bases + and a _target_ diff between the branches you are actually interested in. + + It is very similar to (and actually builds on) `git range-diff`, + but differs in resulting output. + Written in Rust, under MIT License. ++ [Worktree Manager](https://github.com/jarredkenny/worktree-manager) (wtm) + is a fast, modern CLI tool for managing Git worktrees in bare repositories. + Written in TypeScript for Bun, under MIT License. ++ [git-metrics](https://github.com/jdrouet/git-metrics) + is a Git extension that makes it possible to track metrics about your project, + which are stored within the git repository (using `git notes`). + Written in Rust, under MIT License.
+ Described in [Build metrics and budgets with git-metrics](https://dev.to/jdrouet/build-metrics-and-budgets-with-git-metrics-4pb4) + article by Jérémie Drouet on DEV\.to (2024). + + There is another [git-metrics](https://github.com/Praqma/git-metrics) tool, + by the Praqma / Eficode DevOps company, + which consists of a set of scripts to analyse a Git repository for metrics + such as lead time and open branches. Written in Python, no license provided. + It was mentioned in passing in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/). ++ [git-spice](https://abhinav.github.io/git-spice/) is a tool for stacking Git branches. + It lets you manage and navigate stacks of branches, conveniently modify and rebase them, + and create GitHub Pull Requests or GitLab Merge Requests from them. + Written in Go, under GPL 3.0 License. + + A _stacked branch_ refers to a set of branches that build upon each other in a linear sequence. + Stacked branches or stacked diffs were first mentioned in [Git Rev News #44](https://git.github.io/rev_news/2018/10/24/edition-44/), + and most recently in [Git Rev News #127](https://git.github.io/rev_news/2025/09/30/edition-127/), + where you can find even more links about this technique. ++ [Git Granary](https://git.dbushell.com/dbushell/granary) + is a [Git Large File Storage](https://git-lfs.com/) (LFS) + server implementation written in TypeScript. Under MIT License. + Git Granary was designed for self-hosted personal use.
+ See [Git Granary](https://dbushell.com/2024/07/25/git-granary/) + blog post by David Bushell on his blog (2024). ++ [gibr](https://github.com/ytreister/gibr) is a Git CLI tool + for intelligently creating branch names. + It connects your Git workflow to your issue tracker for that purpose; + currently supporting GitHub, GitLab, Jira, and Linear + (with Monday\.com support planned). + Written in Python, under MIT License. ++ [0github.com](https://0github.com/) + is a service offering a heatmap diff viewer for code reviews, + color-coding every diff line/token by how much human attention it probably needs. + To try it, replace github.com with 0github.com in any GitHub pull request URL. + The [cmux](https://cmux.dev/) engine it uses is open source (MIT License). + It uses a LLM (Large Language Model) to perform this task. + + +## Releases + ++ Git [2.51.2](https://lore.kernel.org/git/xmqqo6psjq2n.fsf@gitster.g/), +[2.51.1](https://lore.kernel.org/git/xmqqa51suhh5.fsf@gitster.g/) ++ Git for Windows [v2.51.2(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.2.windows.1), +[v2.51.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.1.windows.1), +[v2.51.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.51.0.windows.2) ++ GitHub Enterprise [3.18.0](https://docs.github.com/enterprise-server@3.18/admin/release-notes#3.18.0) ++ GitLab [18.5.1, 18.4.3, 18.3.5](https://about.gitlab.com/releases/2025/10/22/patch-release-gitlab-18-5-1-released/), +[18.5](https://about.gitlab.com/releases/2025/10/16/gitlab-18-5-released/), +[18.4.2, 18.3.4, 18.2.8](https://about.gitlab.com/releases/2025/10/08/patch-release-gitlab-18-4-2-released/) ++ Gerrit Code Review [3.10.9](https://www.gerritcodereview.com/3.10.html#3109), +[3.13.0-rc0](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.0-rc1](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.0-rc2](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.0-rc3](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.0-rc4](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.0-rc5](https://www.gerritcodereview.com/3.13.html#3130) ++ GitKraken [11.5.1](https://help.gitkraken.com/gitkraken-desktop/current/), +[11.5.0](https://help.gitkraken.com/gitkraken-desktop/current/) ++ GitHub Desktop [3.5.3](https://desktop.github.com/release-notes/) ++ Git Cola [4.16.0](https://github.com/git-cola/git-cola/releases/tag/v4.16.0) ++ GitButler [0.16.10](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.16.10), +[0.16.9](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.16.9) ++ Kinetic Merge [1.10.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.10.0), +[1.9.1](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.9.1) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Kristoffer Haugsbakk, Lee Reilly, +Luca Milanesio and Štěpán Němec. diff --git a/rev_news/drafts/edition-127.md b/rev_news/drafts/edition-127.md deleted file mode 100644 index c4615b51b..000000000 --- a/rev_news/drafts/edition-127.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: Git Rev News Edition 127 (September 30th, 2025) -layout: default -date: 2025-09-30 12:06:51 +0100 -author: chriscool -categories: [news] -navbar: false ---- - -## Git Rev News: Edition 127 (September 30th, 2025) - -Welcome to the 127th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), -a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to -subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](http://git.github.io). - -This edition covers what happened during the months of August and September 2025. - -## Discussions - - - - - - - - - -## Other News - -__Various__ - - -__Light reading__ - - - -__Git tools and sites__ - - -## Releases - - -## Credits - -This edition of Git Rev News was curated by -Christian Couder <>, -Jakub Narębski <>, -Markus Jansen <> and -Kaartic Sivaraam <> -with help from XXX. diff --git a/rev_news/drafts/edition-129.md b/rev_news/drafts/edition-129.md new file mode 100644 index 000000000..2dd203329 --- /dev/null +++ b/rev_news/drafts/edition-129.md @@ -0,0 +1,604 @@ +--- +title: Git Rev News Edition 129 (November 30th, 2025) +layout: default +date: 2025-11-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 129 (November 30th, 2025) + +Welcome to the 129th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](http://git.github.io). + +This edition covers what happened during the months of October and November 2025. + +## Discussions + + + + + +### Support + ++ [[Bug report] git cherry-pick silently ignores error whereas git apply fails for hunk apply](https://lore.kernel.org/git/CAEyHQXWd77_jJachC6FYbWMJ+L=KkKoUqiACQ7z8r-ZwYq8JYw@mail.gmail.com/) + + Bhavik Bavishi filed and sent a bug report to the mailing + list. Running `git cherry-pick` failed to apply some changes but + didn't report any error. On the contrrary when creating a patch + using `git format-patch` from the same commit and applying it using + `git apply --verbose`, the latter command also failed to apply the + same changes but errored out. It seemed that there shouldn't be such + a behavior discrepancy and that `git cherry-pick` should have + reported an error too. + + Johannes Sixt, suggested using `git apply --3way` to apply the + patch. He was interested not only on the success or failure of the + command but also on the end result of applying the patch. Was that + end result similar as the result from `git cherry-pick` or + different? + + Bhavik reported back that indeed `git apply --3way` succeeded and + produced the same end result as `git cherry-pick`. Even if it looked + like `git cherry-pick` worked as expected, that still seemed a + strange behavior though. + + Johannes Sixt replied that a merge strategy is used by both + `git cherry-pick` and `git apply --3way`. Unlike a simple patch + application, a merge strategy is intelligent enough to detect if a + change has already been applied. He illustrated this with an example + where text repeats in a file, but only specific instances are + modified. + + In the meantime, Chris Torek also replied to Bhavik providing a + wealth of explanations. He explained that `git apply` works with a + *patch*, which is essentially a "we expect the file looks like this" + instruction. If the file doesn't match the expected context lines + exactly, the patch fails. + + In contrast, `git cherry-pick` performs a *3-way merge*. It locates + a "common base version" (the ancestor), compares it to "Ours" + (current branch), and "Theirs" (the commit being picked) . If the + merge logic sees that "Theirs" introduces a change that "Ours" has + already made, it silently discards the duplicate change rather than + erroring out. This confirms that the command was working as + intended, using the full history to resolve what looked like a + conflict to the simpler `git apply` tool. + + Bhavik thanked Chris for the helpful explanations. + +## Developer Spotlight: Ayush Chandekar + +_Editor’s note: This edition features a retrospective interview with a +contributor who contributed to Git through a mentoring program. +We hope the reflections shared by the GSoC contributor will +provide an insightful perspective that benefits the community. +As always, we welcome your thoughts and feedback!_ + +* **Who are you and what do you do?** + + I am Ayush Chandekar, a GSoC 2025 alumnus under Git, my project was + titled '[Refactoring in order to reduce Git’s global state](https://summerofcode.withgoogle.com/programs/2025/projects/no7dVMeG)'. + Currently I am an engineering undergraduate at IIT Roorkee, + I consider myself to be a jack of all trades, with interests + ranging from low-level programming to game development, + cybersecurity, and blockchain. I am also a member of + [SDSLabs](https://sdslabs.co/), a student run technical club + at my university which also focuses on making software and + tech accessible for the campus. + + As a kid I always enjoyed tinkering with computers and would + spend majority of my time on games, but slowly I started enjoying + the chance that development gave me to be the one behind the scene, + controlling and making stuff which works. My approach is driven by + curiosity and a desire to understnd how things really function. + Whenever I start learning something new, I naturally end up going + deeper and deeper into the smaller, niche details, not because + I have to, but because it genuinely fascinates me. I enjoy peeling + back the layers, figuring out the underlying mechanisms, and + understanding the “why” behind everything I work on. It’s that + curiosity that keeps pulling me into new domains and motivates me + to keep exploring. Apart from this, for fun, I like to participate + in hackathons, GameJams and Cyber security Capture-The-Flag(CTFs) + competitions. Outside of tech, I enjoy listening to music, brewing + coffee, skateboarding, and learning guitar, they help me unwind + and keep a balance beyond the screen. + +* **How did you initially become interested in contributing to Git, + and what motivated you to choose it as your GSoC project?** + + I wanted to start my journey of contributing to open source projects. + Before that, I was working on small C projects, and that’s when I + came across Git. I was immediately drawn to understanding how + developers actually work on Git itself. The workflow felt new to me, + kind of old-school in a good way, and it definitely took some time + to get used to, but I really enjoyed the process. As I dug deeper, + I realized how Git's internals work, and that made me even more + curious. The idea that I could learn from such a mature codebase, + while also improving a tool used globally, was extremely motivating. + It felt like the perfect place to challenge myself, improve my skills, + and contribute to a big project. + +* **Is there any aspect of Git that you now see differently after + having contributed to it?** + + It is about how there are so many different commands. Before my GSoC, + I was only aware of the usual `git push`, `git pull`, `git clone`, + etc. Now, I know many more commands like `git bisect`, `git range-diff`, + etc. I even understand how some of them work internally. Contributing + to Git really opened my eyes to the depth and complexity of the tool. + +* **How do you balance your contributions with other responsibilities + like work or school?** + + Balancing contributions with other responsibilities is a bit + challenging. As an undergrad student, I’m involved in various + activities at my university, including sports and other commitments, + so my schedule gets busy. But whenever I sit down to work or study, + I get very absorbed in it, and I often end up spending long stretches + of time without even realizing it. That focus helps me make steady + progress even with a packed routine. + +* **Can you share how GSoC helped enhance your technical and + non-technical skills (like communication, project management, + etc.)?** + + GSoC helped me grow in both technical and non-technical areas. + On the technical side, I became much more comfortable reading + large codebases, debugging tricky issues, and writing clean, + well-structured patches. I also learned the importance of clear + and detailed commit messages. On the non-technical side, GSoC + improved my communication skills a lot, especially explaining + my ideas, asking the right questions, and discussing feedback + with the community. It also taught me how to plan my work, break + tasks into smaller steps, and manage my time over a long project. + Overall, it made me more confident in collaborating in an open-source + environment. I would also like to thank my mentor, Christian, for + his guidance and patience throughout the project. His feedback + played a big role in helping me improve. + +* **What was your biggest takeaway or learning from GSoC that + you now apply regularly in your work?** + + My biggest takeaway from GSoC was the importance of writing + clear and detailed commit messages. Before the program, I + didn’t pay much attention to how a commit was explained, + but contributing to Git made me realise how essential it + is. A good commit message not only describes what changed + but also why the change was necessary, making it much easier + for reviewers and future contributors to understand the context. + + Another major learning was understanding how to handle reviews + from multiple people. In the Git community, different contributors + often suggest different things, and figuring out how to take in + all that feedback while still taking ownership of my work was a + big shift for me. I learned how to look at each suggestion carefully, + understand the reasoning behind it, and decide what improves the + patch. It also taught me when to explain my choices and when to + adjust my approach. This experience helped me become more confident + in iterating on my work and communicating clearly, while staying + responsible for the decisions I make. + +* **What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it?** + + There were a few challenges which I faced. Initially, it was + getting accustomed to the mailing list workflow as it was new to + me. Most of the challenges were making sure that the community + accepted your patches. A lot of people reviewed my patches and + got different responses. Here, I learnt to take ownership of + my patches. + +* **Have you thought about mentoring new GSoC / Outreachy students?** + + Yes, I’ve definitely thought about mentoring future GSoC students, + most likely as a co-mentor. I feel it would be a great way to + give back to the community and support newcomers the same way + I was supported. + +* **If you could remove something from Git without worrying about + backwards compatibility, what would it be?** + + It would be removing the global state from Git, which was my + GSoC project and is also an ongoing effort in the community + for the maintainability and modularity of the codebase. + +* **What upcoming features or changes in Git are you particularly + excited about?** + + I've been following Patrick's [patch series on `git history`](https://public-inbox.org/git/20251027-b4-pks-history-builtin-v6-0-407dd3f57ad3@pks.im/). + I am excited for that feature to release. + +* **What is your favorite Git-related tool/library, outside of Git + itself?** + + I have heard of [Jujutsu](https://jj-vcs.github.io/jj/latest/), + I haven't tried it yet but it seems cool, other than that + sticking to my essentials, GitLab and GitHub. + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I just use Gmail to view and reply mails most of the time. But when + it comes to sending patches, I use the good ol' `git send-email`. + I had set up [mutt](http://www.mutt.org/) once, but didn't use it + as much. + +* **How do you envision your own involvement with Git or other open + source projects in the future?** + + I don't have anything planned out in particular but I do really + admire the way my mentor and other contributors in the organisation + contribute, open source is something which basically runs the world, + organisations like Git and Linux function because of collective and + voluntary efforts and they are what makes the world as it is today + and carrying that forward I want to contribute in a way which makes + softwares accessible to everyone and help build up on these + foundational blocks. + +* **What is your advice for people who want to start Git development? + Where and how should they start?** + + Git is an amazing project to learn all aspects of development. + It helps you to learn/improve your C and debugging skills. Another + important thing is how you get to work with different contributors + in the community. You get reviews from everyone which helps you + understand different perspectives. To start with, I would suggest + going through this page called '[Hacking Git](https://git.github.io/Hacking-Git/)' + and checking different articles mentioned there along with the + [Contribution Guidelines](https://git-scm.com/docs/MyFirstContribution). + It is quite difficult to decide what to work on initially, as there + are no traditional issues as other organizations have. Being active + on the mailing list, checking out the ongoing topics might help you + decide what to work on. Everyone on the mailing list and discord is + very friendly and is always looking forward to help you out so feel + free to ask if you have any doubts :) + +* **Would you recommend other students or contributors to participate + in the GSoC, Outreachy or other mentoring programs, working on Git? + Why? Do you have advice for them?** + + As I answered before, it is sometimes difficult to decide what you + can work on. I feel that for Git, since projects are already listed + on the [GSoC and Outreachy pages](https://git.github.io/SoC-2025-Ideas/), + it takes away the pain of figuring out where to start. You just need + to pick a project that interests you and then spend some time studying + it. Other than that, you’re also mentored by someone experienced in + Git development, and with their guidance you’re able to follow best + practices and learn a lot of new things. These programs really help + build confidence, especially when contributing to a large and complex + codebase. You also get to improve your communication skills through + discussions, reviews, and patch iterations. And most importantly, it + opens doors for future contributions, networking, and long-term + involvement in open source. My advice would be to learn to be patient + with reviews. A lot of people in the community contribute voluntarily, + so you may not get reviews on your patches quickly, and that’s + completely normal. + + +## Other News + +__Various__ + +- [What’s new in Git 2.52.0?](https://about.gitlab.com/blog/whats-new-in-git-2-52-0/) + by Christian Couder, Patrick Steinhardt, Toon Claes on GitLab Blog. + Highlights include `git last-modified` command, + `git fast-export` and `git fast-import` signature-related improvements, + new and improved `git maintenance` strategies, + new subcommand for new `git repo` to display repository metrics, etc. +- [Highlights from Git 2.52](https://github.blog/open-source/git/highlights-from-git-2-52/) + by Taylor Blau on GitHub Blog. + Mentions `git last-modified` command for tree-level blame information, + advanced repository maintenance strategies for `git maintenance`, + new sub-commands be added to `git refs`, new `git repo` command, etc. +- [lakeFS Acquires DVC, Uniting Data Version Control Pioneers to Accelerate AI-ready Data](https://lakefs.io/media-mentions/lakefs-acquires-dvc-uniting-data-version-control-pioneers/) + announcement by LakeFS on their Mentions Media page. + - [DVC Joins lakeFS: Your Questions Answered!](https://dvc.org/blog/dvc-joins-lakefs-your-questions-answered/) + by Jeny De Figueiredo on DVC Blog. + - [A Shared Vision for the Future of DVC](https://dvc.org/blog/a-shared-vision-for-the-future-of-dvc/) + by Dmitry Petrov on DVC Blog. + - See also [“Data Management” section of Awesome MLOps](https://github.com/kelvins/awesome-mlops#data-management), + mentioned in [Git Rev News Edition #116](https://git.github.io/rev_news/2024/10/31/edition-116/), + in which edition you can also find references to DVC and lakeFS, + and other similar tools (though the list there is missing + [Meltano](https://meltano.com/) (first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/)) and + [Pachyderm](https://www.pachyderm.com/) (first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/)). +- [20 Years of Git, 2 days at GitHub HQ: Git Merge 2025 highlights 🎉](https://github.blog/open-source/git/20-years-of-git-2-days-at-github-hq-git-merge-2025-highlights/) + by Lee Reilly on GitHub Blog. + - See also [the previous edition of Git Rev News](https://git.github.io/rev_news/2025/10/31/edition-128/) + for more links about Git Merge 2025. + + +__Light reading__ + +- [Version Control in the Age of AI: The Complete Guide](https://www.git-tower.com/blog/version-control-in-the-age-of-ai) + by Bruno Brito on Git Tower blog. +- [Analyzing 10 years of accepted patch series to Git](https://benknoble.github.io/blog/2025/11/14/git-patch-series-length/) + by D. Ben Knoble on his Junk Drawer personal blog. +- [Mergiraf: syntax-aware merging for Git](https://lwn.net/Articles/1042355/) + by Daroc Alden on LWN\.net. + - [Mergiraf](https://mergiraf.org/introduction.html) is a merge-conflict resolver + that uses a generic algorithm plus a small amount of language-specific knowledge + to solve conflicts that Git's default strategy cannot. + It was mentioned in [Git Rev News Edition #117](https://git.github.io/rev_news/2024/11/30/edition-117/). + - The Mergiraf author recommends using the tool together with + [Difftastic](https://difftastic.wilfred.me.uk/), a structural diff tool + that understands syntax, mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/). +- [Should I Switch From Git to Jujutsu](https://etodd.io/2025/10/02/should-i-switch-from-git-to-jujutsu/) + by Evan Todd on his personal blog. + - [Jujutsu (`jj`)](https://jj-vcs.github.io/) is a Git-compatible + version control system written in Rust, which was first mentioned + in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). + - See also [Switch to Jujutsu already: a tutorial](https://www.stavros.io/posts/switch-to-jujutsu-already-a-tutorial/) + by Stavros on Stavros’ Stuff, + mentioned in [the previous edition](https://git.github.io/rev_news/2025/10/31/edition-128/). +- [Why Git is the first tool every new developer needs to learn](https://www.howtogeek.com/beginning-git-what-it-is-and-why-its-crucial/) + by Graeme Peacock on How-To Geek. +- [Git for Vibe Coders](https://www.kdnuggets.com/git-for-vibe-coders), + just enough to stop Claude from accidently deleting your code and database. + By Abid Ali Awan on KDnuggets. +- [4 advanced git commands you probably haven't heard of](https://www.howtogeek.com/advanced-git-commands-you-probably-havent-heard-of/): + [`git clean`](https://git-scm.com/docs/git-clean), + [`git bisect`](https://git-scm.com/docs/git-bisect), + [`git cherry-pick`](https://git-scm.com/docs/git-cherry-pick), + [`git revert`](https://git-scm.com/docs/git-revert), + by Bobby Jack on How-To Geek. +- [Setting File Permissions in Git](https://www.tvaidyan.com/2025/11/13/setting-file-permissions-in-git/) + by Tom Vaidyan on his personal blog; + though I wonder why he shows low-level `git update-index --chmod=+x ` ("plumbing") + first, instead of user-facing `git add --chmod=+x ` ("porcelain" command). +- [Why You Should Be Using Git Worktrees](https://blog.randombits.host/why-you-should-be-using-git-worktrees/) + by Conor in Quick Tip on their Random Bits personal blog + (it includes their helper `gwc`, i.e. git worktree create, shell script). +- [tree-me: Because git worktrees shouldn't be a chore](https://haacked.com/archive/2025/11/21/tree-me/) + by Phil Haack on his You've Been Haacked blog. +- [Use skip-worktree to ignore modified files](https://www.brandonpugh.com/til/git/skip-worktree-ignore-modified-files/) + by Brandon Pugh in "TIL: Today I learned..." section on his blog. +- [Managing Multiple Projects in One Repository: Submodules, Subtrees, Monorepos & Partial Cloning Explained](https://dev.to/k-kibet/managing-multiple-projects-in-one-repository-submodules-subtrees-monorepos-partial-cloning-21mc) + by Kibet Korir (K-kibet) for Codespear on DEV\.to. +- [Automatically switching Git Identities and SSH Keys on the same machine](https://dev.to/enbis/automatically-switching-git-identities-and-ssh-keys-on-the-same-machine-75n) + with the help of `includeIf` directive in the `.gitconfig` file, + by Enrico Bison (enbis) on DEV\.to. See also: + - [Splitting SSH and git configs](https://iamjonfry.com/splitting-ssh-and-git-configs/) + mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/). + - [How to Use Multiple Git Configs on One Computer](https://www.freecodecamp.org/news/how-to-handle-multiple-git-configurations-in-one-machine/) + mentioned in [Git Rev News Edition #71](https://git.github.io/rev_news/2021/01/28/edition-71/). + - [How I configure my Git identities](https://www.benji.dog/articles/git-config/) + mentioned in [Git Rev News Edition #117](https://git.github.io/rev_news/2024/11/30/edition-117/). + - [One PC, Multiple Git Configs (This Will Save You Time!)](https://medium.com/@matteopampana/one-pc-multiple-git-configs-this-will-save-you-time-f702880744f7) + mentioned in [Git Rev News Edition #120](https://git.github.io/rev_news/2025/02/28/edition-120/). +- [Git: Amend any commit](https://ylan.segal-family.com/blog/2025/11/15/git-ammend-any-commit/) + (scripting around `git commit --amend`, and `git commit --fixup` + `git rebase --autosquash`) + by Ylan Segal on his "on.code && such" blog. +- [If You Think YOUR Commit Messages Are Bad, Just Wait...](https://dev.to/sylwia-lask/if-you-think-your-commit-messages-are-bad-just-wait-3fgk) + by Sylwia Laskowska on DEV\.to, + with others providing more examples in comments. +- [Mistakes I see engineers making in their code reviews](https://www.seangoedecke.com/good-code-reviews/) + by Sean Goedecke on his blog. +- [Testable Dotfiles Management With Chezmoi](https://shunk031.me/post/testable-dotfiles-management-with-chezmoi/) + by Shunsuke Kitada (北田 俊輔), Ph.D. on shunk031\.me. +- [Backing up my repositories to self-hosted Gitea](https://blog.kulman.sk/self-hosted-gitea-backup/) + by Igor Kulman on his personal blog. + - [Gitea](https://about.gitea.com/) is a Go-based software forge, + a fork of [Gogs](https://gogs.io/). + It was first mentioned in [Git Rev News Edition #23](https://git.github.io/rev_news/2017/01/25/edition-23/). +- [Fixing Vercel's 'Git Author Must Have Access' Error](https://www.pavlinbg.com/posts/fix-vercel-git-author-error), + which was caused by the way how Vercel handles multiple accounts. + Written by Pavlin Gunov (PavlinBG) on his blog. +- [Running DVC on a SLURM cluster](https://dvc.org/blog/dvc-slurm-cluster-exscientia/) + by Dom Miketa on DVC Blog (2024). + - [DVC](https://dvc.org/) (Data Version Control), + an open-source version control system for data science projects, + was first mentioned in [Git Rev News Edition #23](https://git.github.io/rev_news/2017/01/25/edition-23/). + + +__Easy watching__ + +- [How to ensure the Git community is / stays healthy: Emily Shaffer / Patrick Steinhardt & guests](https://www.youtube.com/watch?v=vKsOFHNSb4Q) + on GitButler channel on YouTube [duration: 44:42]. + + +__Git tools and sites__ + +- [gitlogue](https://github.com/unhappychoice/gitlogue) + is a cinematic Git commit replay tool for the terminal, + turning your Git history into a living, animated story; + with realistic typing animations, syntax highlighting, and file tree transitions, + transforming code changes into a visual experience. + Written mainly in Rust, under ISC License. +- [PyDriller](https://github.com/ishepard/pydriller) is a Python framework + that helps developers in analyzing Git repositories. + With PyDriller you can easily extract information about + commits, developers, modified files, diffs, and source code. + Written in Python, under Apache 2.0 license. +- [tree-me](https://github.com/haacked/dotfiles/blob/main/bin/tree-me) + is a minimal git worktree helper + that leverages git's native capabilities. + It uses git-like subcommands and follows conventions so you don’t have to think: + auto-detects repository name from your git remote, + auto-detects default branch, organizes by repo, provides tab completion, etc. + Single bash script, part of [haacked dotfiles](https://github.com/haacked/dotfiles). + No license. + - See also [Worktree Manager](https://github.com/jarredkenny/worktree-manager) (wtm), + a fast, modern CLI tool for managing Git worktrees in bare repositories, + mentioned in [Git Rev News Edition #128](https://git.github.io/rev_news/2025/10/31/edition-128/). +- [Spelungit](https://github.com/haacked/spelungit) is a Model Context Protocol (MCP) server + for exploring Git commit history using semantic search. + With this tool you can search through commits with natural language commands + like "Search git history to find out why was this class added?", + or "search_commits(query="authentication login changes", limit=5)". + Uses Microsoft's all-MiniLM-L6-v2 embeding model via [sentence-transformers](https://www.sbert.net/), + or deterministic hash-based embeddings when sentence-transformers is unavailable. + Written in Python (with a few Bash scripts), under MIT License. + - See also [Spelungit: When `git log --grep` isn't enough](https://haacked.com/archive/2025/09/29/announcing-spelungit/) + by Phil Haack on You've Been Haacked blog. +- [forgit](https://github.com/wfxr/forgit) is a utility tool + powered by [fzf](https://github.com/junegunn/fzf) (command-line fuzzy finder) + for using Git interactively. + Written in shell, under MIT license. +- [gitnr](https://github.com/reemus-dev/gitnr) is a cross-platform CLI utility + to create `.gitignore` files using one or more templates + from [TopTal](https://github.com/toptal/gitignore) (), + [GitHub](https://github.com/github/gitignore), or your own collection. + Written in Rust, under MIT License. +- [`mani`](https://manicli.com/) is a CLI tool + that helps you manage multiple repositories. + It's useful when you are working with microservices, multi-project systems, + multiple libraries, or just a collection of repositories + and want a central place for pulling all repositories and running commands across them. + Written in Go, under MIT License. +- [eget](https://github.com/zyedidia/eget) is a command-line tool + for easily fetching and extracting pre-built binaries from GitHub releases. + Written in Go, under MIT License. +- [dunk](https://github.com/darrenburns/dunk) is a tool + to provide prettier git diffs in the terminal + by pipe-ing `git diff` output into it (`git diff | dunk` or `git diff | dunk | less -R`). + In is very early stages of development. + Written in Python, under MIT License. + - See also [git-delta](https://dandavison.github.io/delta/), + a syntax-highlighting pager for git, diff, grep, and blame output. + It was first mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/), + though there is another [delta](https://github.com/octavore/delta) + command-line diff tool which was first mentioned in [edition #9](https://git.github.io/rev_news/2015/11/11/edition-9/). + - See also [diff-so-fancy](https://github.com/so-fancy/diff-so-fancy) tool, + which beside piping `git diff` output to it, + can also be used as `core.pager` and `interactive.diffFilter`. + It was first mentioned in [Git Rev News Edition #13](https://git.github.io/rev_news/2016/03/16/edition-13/). + - There is also [`contrib/diff-highlight`](https://github.com/git/git/tree/master/contrib/diff-highlight) + diff pager script in the Git repository, written in Perl. + It was mentioned in [Git Rev News Edition #53](https://git.github.io/rev_news/2019/07/24/edition-53/). +- [GitType](https://github.com/unhappychoice/gittype) is a CLI tool + that turns your own source code into typing challenges. + Because why practice with boring [lorem ipsum](https://www.lipsum.com/) + when you can type your beautiful `fn main()` implementations? + Written in Rust, under MIT License. +- [Serie](https://github.com/lusingander/serie) is a TUI tool that + provides rich git commit graph in your terminal. + Written in Rust, under MIT License. + - See also [tig](https://jonas.github.io/tig/), + an ncurses-based text-mode interface for Git, + first mentioned in [Git Rev News Edition #18](https://git.github.io/rev_news/2016/08/17/edition-18/). +- [prettydiff](https://github.com/prettydiff/prettydiff) is a beautifier and language aware + code comparison tool for many languages. It also minifies and a few other things. + There is web service showing how the tool works at . + Written in TypeScript and HTML, + under [CC0](https://creativecommons.org/public-domain/cc0/) license. +- [fnox: Fort Knox for your secrets](https://fnox.jdx.dev/) + is a tool to manage secrets with encryption, or cloud providers, or both. + Fnox uses a simple TOML config file (`fnox.toml`) that you check into Git; + secrets are either encrypted inline, or provided as references + that points to a secret in age, AWS, 1Password, etc. + Written in Rust, under MIT License. +- [asdf](https://asdf-vm.com/guide/introduction.html) is a tool version manager. + All tool version definitions are contained within one file (`.tool-versions`) + which you can check in to your project's Git repository to share with your team, + ensuring everyone is using the exact same versions of tools. + Written mainly in Bash and Go, under MIT License. +- [grebedoc.dev](https://grebedoc.dev/) is a service + that offers static site hosting for Git forges; + it publishes the `pages` branch in your Git repository as a website on your domain. + More specifically, it is a public deployment of + [git-pages](https://codeberg.org/git-pages/git-pages) + and [Caddy](https://caddyserver.com/), configured to work especially with + [Codeberg](https://codeberg.org/) but also with other Git forges. + It is operated by Catherine 'whitequark' and teammates. + - Compare with [GitHub Pages](https://docs.github.com/en/pages), + [GitLab Pages](https://docs.gitlab.com/user/project/pages/), + [static websites on Bitbucket Cloud](https://support.atlassian.com/bitbucket-cloud/docs/publishing-a-website-on-bitbucket-cloud/), + [Codeberg Pages](https://codeberg.page/) (can't guarantee high availability), + [sourcehut pages](https://srht.site/), and + [Cloudflare Pages](https://pages.cloudflare.com/) (JAMstack platform), etc. +- [gitsuggest](https://github.com/csurfer/gitsuggest) is a tool + to suggest GitHub repositories based on the repositories you have shown interest in + by “starring”. It is using Latent Dirichlet Allocation (LDA) method. + There is also [gitSuggest](http://www.gitsuggest.com/) service (in beta), on Heroku. + Written on Python, under MIT License. +- [Josh](https://josh-project.github.io/josh/) (Just One Single History) + ([repo](https://github.com/josh-project/josh)) + is a tool that combines the advantages of monorepos with those of multirepos + by leveraging a blazingly-fast, incremental, and reversible implementation + of git history filtering. + Note that to guarantee filters are reversible + Josh restricts the kind of filter that can be used. + Use cases include partial cloning, workspaces, simplified CI/CD; + this tool also provides GraphQL API. + Josh is distributed via [Docker Hub](https://hub.docker.com/r/joshproject/josh-proxy), + and you can start it with appropriate `docker run` command. + See its [Frequently Asked Questions](https://josh-project.github.io/josh/faq.html#frequently-asked-questions) + for comparison with `git sparse-checkout`, partial clone, submodules, `git subtree`, + and `git filter-repo`. + Written mainly in Rust, under MIT License. +- [Furgit](https://villosa.lindenii.org/furgit//repos/furgit/) + ([GitHub mirror](https://github.com/runxiyu/furgit)) + is a fast Git library in pure Go (and a little bit of optional Go Assembly). + Written for [Lindenii Villosa](https://villosa.lindenii.org/villosa//repos/villosa/) + (successor to [Lindenii Forge](https://forge.lindenii.org/forge/-/repos/server/)), + a software forge primarily designed for self-hosting + by small organizations and individuals. + Under AGPL 3.0 license. +- [git-embigenner](https://github.com/veqqq/git-embigenner) + is a very simple shell script to cheat a highscore on GitHub, + which will spam commits to populate your profile's contribution graph. + - Compare with [Git Draw](https://github.com/ben174/git-draw), + a Chrome extension which will allow you to freely draw on your GitHub heatmap, + mentioned in [Git Rev News Edition #12](https://git.github.io/rev_news/2016/02/10/edition-12/)
+ and [gitfiti](https://github.com/gelstudios/gitfiti), + a tool for crafting graffiti in a GitHub commit history calendar, + mentioned in [Git Rev News Edition #41](https://git.github.io/rev_news/2018/07/18/edition-41/). + - Contrast [Vigilante Justice on GitHub: GitHub Graffiti](https://trufflesecurity.com/blog/vigilante-justice-on-github) by Dylan Ayrey, + mentioned in [Git Rev News Edition #118](https://git.github.io/rev_news/2024/12/31/edition-118/), + about how you can paint funny pixel art (graffiti) with fake commit Git histories + on spammer/phisher’s GitHub profiles (on their activity heatmap plot) + + +## Releases + ++ Git [2.52.0](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/), +[2.52.0-rc2](https://lore.kernel.org/git/xmqqzf8rqihh.fsf@gitster.g/), +[2.52.0-rc1](https://lore.kernel.org/git/xmqqqzubhyj9.fsf@gitster.g/), +[2.52.0-rc0](https://lore.kernel.org/git/xmqqwm47t4x3.fsf@gitster.g/) ++ Git for Windows [v2.52.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.52.0.windows.1), +[v2.52.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.52.0-rc2.windows.1), +[v2.52.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.52.0-rc1.windows.1), +[v2.52.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.52.0-rc0.windows.1) ++ GitLab [18.6.1, 18.5.3, 18.4.5](https://about.gitlab.com/releases/2025/11/26/patch-release-gitlab-18-6-1-released/), +[18.6](https://about.gitlab.com/releases/2025/11/20/gitlab-18-6-released/), +[18.5.2, 18.4.4, 18.3.6](https://about.gitlab.com/releases/2025/11/12/patch-release-gitlab-18-5-2-released/) ++ Bitbucket Data Center [10.1](https://confluence.atlassian.com/bitbucketserver/release-notes-872139866.html) ++ Gerrit Code Review [3.10.9](https://www.gerritcodereview.com/3.10.html#3109), +[3.11.6](https://www.gerritcodereview.com/3.11.html#3116), +[3.11.7](https://www.gerritcodereview.com/3.11.html#3117), +[3.12.3](https://www.gerritcodereview.com/3.12.html#3123), +[3.13.0-rc5](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.0](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.1](https://www.gerritcodereview.com/3.13.html#3131) ++ GitHub Enterprise [3.18.1](https://docs.github.com/enterprise-server@3.18/admin/release-notes#3.18.1), +[3.17.7](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.7), +[3.16.10](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.10), +[3.15.14](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.14), +[3.14.19](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.19) ++ GitKraken [11.6.0](https://help.gitkraken.com/gitkraken-desktop/current/) ++ GitHub Desktop [3.5.4](https://desktop.github.com/release-notes/) ++ Git Cola [4.16.1](https://github.com/git-cola/git-cola/releases/tag/v4.16.1) ++ GitButler [0.18.1](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.18.1), +[0.18.0](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.18.0) ++ Kinetic Merge [1.11.2](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.11.2), +[1.11.1](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.11.1), +[1.11.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.11.0) ++ Tower for Mac [15](https://www.git-tower.com/blog/tower-mac-15) ([YouTube tour](https://youtu.be/xTrxb2dJP8M)) ++ Tower for Windows [10](https://www.git-tower.com/blog/tower-windows-10) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Bruno Brito and D. Ben Knoble.