diff --git a/GSoC-Participants.md b/GSoC-Participants.md new file mode 100644 index 0000000000..d9a68bf751 --- /dev/null +++ b/GSoC-Participants.md @@ -0,0 +1,211 @@ +--- +layout: default +title: GSoC participants +--- + +This document collects the list of contributors who've contributed +to Git via GSoC. + + + +### 2025 + +1. Ayush Chandekar [ [project](https://summerofcode.withgoogle.com/programs/2025/projects/no7dVMeG) ] [ [final report](https://ayu-ch.github.io/2025/08/29/gsoc-final-report.html) ] [ [blog](https://ayu-ch.github.io/) ] +2. Lucas Seiki Oshiro [ [project](https://summerofcode.withgoogle.com/programs/2025/projects/fGgMYHwl) ] [ [final report](https://lucasoshiro.github.io/gsoc-en/#final-report) ] [ [blog](https://lucasoshiro.github.io/gsoc-en/#weeks) ] +3. Meet Soni [ [project](https://summerofcode.withgoogle.com/programs/2025/projects/xVrT5e2q) ] [ [final report](https://inosmeet.github.io/posts/gsoc25/gsoc25_final/) ] [ [blog](https://inosmeet.github.io/posts/gsoc25/) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/programs/2025/organizations/git) +- [Rev News article](https://git.github.io/rev_news/2025/05/31/edition-123/) + +### 2024 + +1. Jialuo She [ [project](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF) ] [ [final report](https://luolibrary.com/2024/08/25/GSoC-Final-Report/) ] [ [blog](https://luolibrary.com/) ] +2. Ghanshyam Thakkar [ [project](https://summerofcode.withgoogle.com/archive/2024/projects/e9C4rhrv) ] [ [final report](https://spectre10.github.io/posts/gsoc_final_report/) ] [ [blog](https://spectre10.github.io/) ] +3. Chandra Pratap [ [project](https://summerofcode.withgoogle.com/archive/2024/projects/tlh611d7) ] [ [final report](https://chand-ra.github.io/2024/08/24/GSoC-Final-Report.html) ] [ [blog](https://chand-ra.github.io/) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2024/organizations/git) +- [Rev News article](https://git.github.io/rev_news/2024/05/31/edition-111/) + +### 2023 + +1. Shuqi Liang [ [project](https://summerofcode.withgoogle.com/archive/2023/projects/Rkbc1Abe) ] [ [final report](https://cheskaqiqi.github.io/2023/08/22/Final/) ] [ [blog](https://cheskaqiqi.github.io/tags/GSoC/) ] +2. Kousik Sanagavarapu [ [project](https://summerofcode.withgoogle.com/archive/2023/projects/rck3kmq2) ] [ [final report](https://five-sh.github.io/2023/08/26/the-final-report) ] [ [blog](https://five-sh.github.io/blog) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2023/organizations/git) +- [Rev News article](https://git.github.io/rev_news/2023/06/30/edition-100/) + +### 2022 + +1. Shaoxuan Yuan [ [project](https://summerofcode.withgoogle.com/archive/2022/projects/hz4rcOUB) ] [ [final report](https://ffyuanda.github.io/blog/GSoC-final-blog/) ] [ [blog](https://ffyuanda.github.io/tags/#learn) ] +2. Abhradeep Chakraborty [ [project](https://summerofcode.withgoogle.com/archive/2022/projects/UPtA6qdf) ] [ [final report](https://medium.com/@abhra303/gsoc-final-report-feaaacfae737) ] [ [blog](https://medium.com/@abhra303) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2022/organizations/git) +- [Rev News article](https://git.github.io/rev_news/2022/06/30/edition-88/) + + +### 2021 + +1. ZheNing Hu [ [project](https://summerofcode.withgoogle.com/archive/2021/projects/5443907994779648) ] [ [final report](https://github.com/adlternative/adlternative.github.io/blob/gh-pages/blogs/gsoc/GSOC-Git-Final-Blog.md) ] [ [blog](https://github.com/adlternative/adlternative.github.io/tree/gh-pages/blogs/gsoc/) ] +2. Atharva Raykar [ [project](https://summerofcode.withgoogle.com/archive/2021/projects/5071550033690624) ] [ [final report](https://github.com/tfidfwastaken/gitnotes/blob/main/final-report.md) ] [ [blog](https://github.com/tfidfwastaken/gitnotes/tree/main) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2021/organizations/6398200235163648) +- [Rev News article](https://git.github.io/rev_news/2021/05/27/edition-75/) + + +### 2020 + +1. Shourya Shukla [ [project](https://summerofcode.withgoogle.com/archive/2020/projects/4541259818991616) ] [ [final report](https://shouryashukla.blogspot.com/2020/08/the-final-report.html) ] [ [blog](https://shouryashukla.blogspot.com/search/label/GSoC) ] +2. Abhishek Kumar [ [project](https://summerofcode.withgoogle.com/archive/2020/projects/6510085276172288) ] [ [final report](https://github.com/abhishekkumar2718/GSoC20/blob/master/README.md) ] [ [blog](https://abhishekkumar2718.github.io/gsoc/) ] +3. Hariom Verma [ [project](https://summerofcode.withgoogle.com/archive/2020/projects/6123927484497920) ] [ [final report](https://harry-hov.github.io/blogs/posts/the-final-report) ] [ [blog](https://harry-hov.github.io/blogs/posts/) ] + + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2020/organizations/5445576591671296) +- [Rev News article](https://git.github.io/rev_news/2020/05/28/edition-63/) + + +### 2019 + +1. Rohit Ashiwal [ [project](https://summerofcode.withgoogle.com/archive/2019/projects/5390155215536128) ] [ [final report](https://web.archive.org/web/20210727190950/https://rashiwal.me/2019/final-report/) ] [ [blog](https://web.archive.org/web/20210515085551/https://rashiwal.me/) ] +2. Matheus Tavares [ [project](https://summerofcode.withgoogle.com/archive/2019/projects/4787791739748352) ] [ [final report](https://matheustavares.gitlab.io/posts/gsoc-final-report) ] [ [blog](https://matheustavares.gitlab.io/tags/git/) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2019/organizations/6548634445807616) +- [Rev News - May 2019](https://git.github.io/rev_news/2019/05/22/edition-51/) + + +### 2018 + +1. Pratik Karki [ [project](https://summerofcode.withgoogle.com/archive/2018/projects/5389615745728512) ] [ [final report](https://github.com/prertik/GSoC2018?tab=readme-ov-file) ] [ [blogs](https://prertik.github.io/categories/git/) ] +2. Paul-Sebastian Ungureanu [ [project](https://summerofcode.withgoogle.com/archive/2018/projects/6700324135895040) ] [ [final report and blogs](https://github.com/ungps/gsoc2018?tab=readme-ov-file) ] +3. Alban Gruin [ [project](https://summerofcode.withgoogle.com/archive/2018/projects/6165469845258240) ] [ [final report](https://github.com/agrn/gsoc2018?tab=readme-ov-file) ] [ [blogs](https://blog.pa1ch.fr/category/gsoc-2018.html) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2018/organizations/4840889583140864) +- [Rev News - May 2018](https://git.github.io/rev_news/2018/05/16/edition-39/) + +### 2017 + +1. Prathamesh Chavan [ [project](https://summerofcode.withgoogle.com/archive/2017/projects/5434523185577984) ] [ [final report](https://docs.google.com/document/d/1RmUvJBf4x8TI71Fltg8xWP-s7zkhz3bGPyEJMgRx91Y/edit#heading=h.5r7i4cugqwi3) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2017/organizations/5061577619275776) +- [Rev News - Oct 2017](https://git.github.io/rev_news/2017/10/11/edition-32/) + +### 2016 + +1. Pranit Bauva [ [project](https://summerofcode.withgoogle.com/archive/2016/projects/5595001820020736) ] [ [final report](https://docs.google.com/document/d/1Uir0a8cRYlWANuzoU4iTDtEvPukvtTJcC_dB3KJUgqM/edit#heading=h.mipx2w79za4f) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2016/organizations/5532648021688320#projects-list) +- [Rev News - Oct 2016](https://git.github.io/rev_news/2016/09/14/edition-19/) + +### 2015 + +1. Karthik Nayak [ [project](https://www.google-melange.com/archive/gsoc/2015/orgs/git/projects/karthiknayak94.html) ] [ [fork](https://github.com/KarthikNayak/git) ] [ [a mailing list mail](https://public-inbox.org/git/553F7A50.1080907@gmail.com/) ] +2. Paul Tan [ [project](https://www.google-melange.com/archive/gsoc/2015/orgs/git/projects/pyokagan.html) ] [ [fork](https://github.com/pyokagan/git) ] [ [a mailing list mail](https://public-inbox.org/git/CACRoPnQ5_r-26J4gBHc27KZt3X9KAU7eFkA3vz_GE6_dP-Uyug@mail.gmail.com/) ] + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2015/orgs/git) +- [Rev News - May 2015](https://git.github.io/rev_news/2015/05/13/edition-3/#other-news) + +### 2014 + +1. Tanay Abhra [ [project](https://www.google-melange.com/archive/gsoc/2014/orgs/git/projects/tanayabh.html) ] +2. Fabian Ruch [ [project](https://www.google-melange.com/archive/gsoc/2014/orgs/git/projects/bafain.html) ] + + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2014/orgs/git) +- [GSoC retrospective](https://public-inbox.org/git/vpqsik1yg1l.fsf@anie.imag.fr/) + + +### 2013 + +***Did not participate*** + + +### 2012 + +1. Thomas Gummerer [ [project](https://www.google-melange.com/archive/gsoc/2012/orgs/git/projects/tgummerer.html) ] +1. Michael Schubert [ [project](https://www.google-melange.com/archive/gsoc/2012/orgs/git/projects/schu.html) ] +1. Florian Achleitner [ [project](https://www.google-melange.com/archive/gsoc/2012/orgs/git/projects/flyingflo.html) ] + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2012/orgs/git) + + +### 2011 + +1. Carlos Martín Nieto [ [project](https://www.google-melange.com/archive/gsoc/2011/orgs/git/projects/carlosmn.html) ] +1. Ramkumar Ramachandra [ [project](https://www.google-melange.com/archive/gsoc/2011/orgs/git/projects/artagnon.html) ] +1. Fredrik Gustafsson [ [project](https://www.google-melange.com/archive/gsoc/2011/orgs/git/projects/iveqy.html) ] + + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2011/orgs/git) + + +### 2010 + +1. Vicent Marti [ [project](https://www.google-melange.com/archive/gsoc/2010/orgs/git/projects/tanoku.html) ] +1. Ramkumar Ramachandra [ [project](https://www.google-melange.com/archive/gsoc/2010/orgs/git/projects/artagnon.html) ] +1. Bo Yang [ [project](https://www.google-melange.com/archive/gsoc/2010/orgs/git/projects/struggleyb.html) ] + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2010/orgs/git) + +### 2009 + +1. Nick Edelen [ [project](https://www.google-melange.com/archive/gsoc/2009/orgs/git/projects/sirnot.html) ] + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2009/orgs/git) + + +### 2008 + +1. Joshua Roys (_project_: GitTorrent) [ [final e-mail](https://lore.kernel.org/git/48C05FB5.3010901@gmail.com/) ] +2. Sverre Rabbelier (_project_: git-statistics) [ [final e-mail](https://lore.kernel.org/git/bd6139dc0809041544o427356c9i40a28b1c182817eb@mail.gmail.com/) ] +3. Lea Wiemann (_project_: Gitweb caching) [ [idea discussion](https://lore.kernel.org/git/483C4CFF.2070101@gmail.com/#t) ] +4. Marek Zawirski (_project_: Eclipse plugin push support) [ [final e-mail](https://lore.kernel.org/git/48C564ED.7050402@gmail.com/) ] +5. Miklos Vajna (_project_: git-merge builtin) [ [final e-mail](https://lore.kernel.org/git/20080904225559.GP16514@genesis.frugalware.org/) ] +6. Stephan Beyer (_project_: git-sequencer) [ [final e-mail](https://lore.kernel.org/git/20080904223653.GA15170@leksak.fem-net/) ] + +#### References + +- [GSoC archive](https://developers.google.com/open-source/gsoc/2008?csw=1#git-development-community) +- [Mail about GSoC participant summary](https://lore.kernel.org/git/200809042315.58898.jnareb@gmail.com/) +- [GSoC selection summary](https://lore.kernel.org/git/20080422013201.GA4828@spearce.org/) + + +### 2007 + +1. Carlos Rica (_project_: Shell script to C builtin conversions) +2. Luiz Capitulino (_project_: Libification) + +#### References + +- [GSoC archive](https://developers.google.com/open-source/gsoc/2007?csw=1#git-development-community) +- [GSoC report](https://lore.kernel.org/git/20070903034201.GP18160@spearce.org/) diff --git a/General-Application-Information.md b/General-Application-Information.md index 54b275c28c..7a2402b95d 100644 --- a/General-Application-Information.md +++ b/General-Application-Information.md @@ -9,7 +9,9 @@ programs can get information about what the Git project would like to see in an application. *Please read this page completely before focusing on a project or a - microproject ideas, or microproject general information.* + microproject ideas, or microproject general information. + Specifically, also read the "AI guidelines" section to know our + stance regarding the usage of AI tools.* ## Microproject (required) @@ -66,6 +68,13 @@ does [Junio's "What's cooking in git.git" emails](https://lore.kernel.org/git/?q say about it? In general it's a good idea to describe all your Git related work so far with a good amount of detail. +If the mentoring program allows different project "sizes", like for +example 'Small', 'Medium' and 'Large', or different project +"duration", like from 12 weeks to 22 weeks, please tell us in you +application which project size or duration you prefer. It's usually +not difficult for us to adapt a project we propose to different sizes +or durations. + Applicants must send drafts of their proposal on the mailing-list before submitting it officially to GSoC or Outreachy to get feedback from the community. They are strongly encouraged to publish a draft on @@ -123,50 +132,154 @@ are interested in, it is a good idea to: used for searching the mailing list and linking to previous discussions.) +## AI guidelines + +The use of Artificial Intelligence related tools ("AI" or "AIs" for +short), like Large Language Models ("LLMs"), by developers is becoming +more and more popular, but that's not a reason to blindly use them, +especially when working on the Git project. + +### Legal issues + +In general, it's not clear if AI generated code or documentation are +acceptable in the Git project. Authors contributing to Git are +required to "sign off" the patches they contribute, and to agree with +the Developer’s Certificate of Origin, also called DCO, (see +), while the DCO +says basically that authors of a patch should be sure about the origin +of its content. + +As we cannot usually be sure how AIs have been trained and that they +are not just repeating proprietary existing code or documentation they +saw during their training, we cannot accept much AI generated code or +documentation in general. Now, if it's only a few lines to fix a bug +or to implement a common pattern or summarize something, and if that +looks specific enough to a current concrete problem a developer is +working on, that might be OK. + +Anyway as the situation is not clear for the Git project and probably +many other open source projects, you should be very prudent regarding +this. + +### Be very careful with AI output + +For a number of reasons, not just legal ones, developers should really +make sure that they treat what AIs produce very carefully. They +should: + + - triple check everything, especially regarding our guidelines + (indent, style, commit message guidelines, etc, see especially the + SubmittingPatches and CodingGuidelines docs as well as the other + pages on this website) and the feedback reviewers already gave + them or others, + + - build and test changes, using existing, new or manual tests, to + check that the changes are correct, perform well and don't produce + garbage output, + + - doubt anything they don't fully understand, or anything that might + not match our guidelines or feedback, and + + - fix, simplify, adapt, reword or change anything that is + suspicious, bloated, too formal, or that they don't understand, or + that doesn't match our guidelines or our feedback. + +Yeah, AIs still often hallucinate or just produce bad code, commit +messages, documentation or output, even when you point out their +mistakes. + +### We don't accept AI output as-is + +It's unacceptable to send us something that is obvious AI slop, or +that sounds overly formal or bloated, or that looks good on the +surface but makes no sense, or that senders don’t understand or cannot +explain. It just wastes our time and we cannot accept it. We want to +interact with and mentor humans, not AIs. + +For example, it's unacceptable to have an AI generate a commit message +where it just describes what the code in the commit does, instead of +the purpose of the change, and then send that to us. + +In general, it's unacceptable to send AI-generated patches or messages +as-is to the mailing list or to mentors' or developers' personal email +addresses. We won't consider candidates doing that. + +For another, unfortunately common, example, it's unacceptable to send +us an application that has obviously been AI generated and doesn't +follow our guidelines or the feedback we previously gave to other +applicants. Those applications will be dropped. + +### Blindly using AI is far worse than not applying + +As bad AI use is growing in general, not just to apply to mentoring +programs, more and more tools and ways are being developed to find out +and fight against bad AI use. + +So people who apply by sending us AI generated output as-is, not only +waste their time, and our time, for no result, but they also leave +evidence on our mailing list archive of their bad behavior. + +For example, employers already use social media screening tools or +candidate assessment software when hiring people, and it's likely that +those tools, which often already use AI, are, or will be able to find +out soon about such bad behavior. + +### Better ways to use AIs + +Developers would often likely get better results, learn more and have +a better overall experience by asking AIs to only explain things, and +guide them step by step towards producing a solution by themselves, +rather than by asking for a full solution that they would then mostly +copy-paste. + +They can also use AIs to help with debugging, or with checking for +obvious mistakes, things that can be improved, things that don't match +our style, guidelines or our feedback, before sending it to us. + ## Note about the number of slots The Git organization usually has very limited mentoring capacity. -These days we usually accept around 2 or 3 students per season -(Winter or Summer). +These days we usually accept between around 1 to 3 GSoC contributors +(in the Summer) or Outreachy interns (in the Winter). ## Note about giving back and mentoring -We appreciate very much students and interns who stay around after the -mentoring period is over. It is very nice to see them on the mailing -list, even if they don't contribute much. It's of course better when -they continue to contribute though, even by just reviewing a patch -from time to time. +We appreciate very much GSoC contributors and Outreachy interns who +stay around after the mentoring period is over. It is very nice to see +them on the mailing list, even if they don't contribute much. It's of +course better when they continue to contribute though, even by just +reviewing a patch from time to time. Some people have been around for more than 10 years, others have become regular contributors and that's great! One very nice way to contribute and to give back is to mentor or -co-mentor other students or interns coming after you. It helps create -more opportunities for more students and interns like you, as -mentoring capacity is the main factor preventing us from accepting -more students and interns. If each student or intern accepted to -co-mentor twice (for example once in Summer and once in Winter) just -after they have been mentored, our mentoring capacity could increase -significantly each year. - -Even though successful former students/interns usually have adequate -technical ability to be a successful mentor, unfortunately few of them -have been willing to just co-mentor once along with an experienced -mentor. +co-mentor other contributors or interns coming after you. It helps +create more opportunities for more contributors and interns like you, +as mentoring capacity is the main factor preventing us from accepting +more contributors and interns. If each contributor or intern accepted +to co-mentor twice (for example once in the Summer and once in the +Winter) just after they have been mentored, our mentoring capacity +could increase significantly each year. + +Even though successful former contributors/interns usually have +adequate technical ability to be a successful mentor, unfortunately +few of them have been willing to just co-mentor once along with an +experienced mentor. Other free or open source projects have done better than us on this. At the Google Summer of Code Mentor Summit for example, more -than 30% of the mentors were former students. +than 30% of the mentors are usually former contributors. Here is a quote by a mentor (Carlos Fernandez Sanz) on the GSoC Mentors List, that describes very well how we see GSoC and Outreachy: "GSoC is (for us, anyway) more about growing the community than getting stuff done. If they don't stick around their value diminishes -a lot, even if they do a great job [...]. The students that did a -great job but completely left the community [...] are just a memory... -the ones that have been with us and that are now mentors [...], long -after they participated in GSoC, are the ones we love :-)" +a lot, even if they do a great job [...]. The [contributors] that did +a great job but completely left the community [...] are just a +memory... the ones that have been with us and that are now mentors +[...], long after they participated in GSoC, are the ones we love :-)" Consider showing us in your application previous mentoring, giving back and community activities that you have done, especially related @@ -180,21 +293,22 @@ Refactoring projects are usually easier to do step by step, and to get code merged step by step which is encouraging. In general refactoring projects are worthwhile to do even if the -project is not finished at the end of the GSoC and even if the student -or intern stops contributing after that. In those cases it is often a -good idea to later finish the refactoring either by ourselves or by -proposing it to another GSoC student or Outreachy intern. This way the -work of both students and mentors is not likely to be wasted. +project is not finished at the end of the GSoC and even if the +contributor or intern stops contributing after that. In those cases it +is often a good idea to later finish the refactoring either by +ourselves or by proposing it to another GSoC contributor or Outreachy +intern. This way the work of contributors, interns and mentors is not +likely to be wasted. With a project that implements a feature, there is a risk, if it's too complex or too difficult, that the feature will not be finished and that nothing, or nearly nothing, will have been merged during the GSoC or Outreachy internship. There is also the risk that another way to implement the feature will appear later in the GSoC or Outreachy -internship, and all, or nearly all, the work of the student or intern -and mentors will have been mostly wasted. It could also appear that -the use cases the feature was envisioned to be used in, are better -addressed by other improvements or a different workflow. +internship, and all, or nearly all, the work of the contributor or +intern and mentors will have been mostly wasted. It could also appear +that the use cases the feature was envisioned to be used in, are +better addressed by other improvements or a different workflow. Another potential issue is that a new feature might be prone to naming or user interface discussions which could last for a long time or @@ -239,7 +353,7 @@ earlier than you. This means that you might have to find a project idea that we haven't proposed in our idea list. The good side of this is that this project idea along with your -enthousiasm for it and the skills you show might encourage Git +enthusiasm for it and the skills you show might encourage Git developers to mentor you even if they weren't planning to mentor in the first place. It could also happen that someone, who was only planning to co-mentor, could agree to fully mentor you alone. diff --git a/General-Microproject-Information.md b/General-Microproject-Information.md index 2f1be88b9f..c98caeab81 100644 --- a/General-Microproject-Information.md +++ b/General-Microproject-Information.md @@ -9,7 +9,8 @@ It is strongly recommended that people who want to apply to the Git project for the Google Summer of Code (GSoC), Outreachy, or other such mentoring programs, called "applicants" in this document, submit a small code-related patch to the Git project as part of their -application. +application. We call the whole process of submitting such a small +code-related patch a "microproject". People who want to get involved in Git development outside mentoring programs can also benefit from information on this page to get @@ -17,6 +18,12 @@ started, though it might be a bit less relevant to them. If they want, they can use something like "[FirstTimer]", "[Newbie]", "[Newcomer]" instead of "[GSoC]" or "[Outreachy]" in the emails they send. +Anyway if you want to work on a microproject, or more generally if you +want to start getting involved in Git development, please read on +*all* the rest of this page. + +## What is a microproject? + Think of these microprojects as the "Hello, world" of getting involved with the Git project; the coding aspect of the change can be almost trivial, but to make the change the applicant has to become familiar @@ -32,28 +39,29 @@ well using the Git development process. It is *expected* that what you send will need several rounds of reviews and discussions. If you are not sure at all about a patch you -can put "[GSoC][RFC/PATCH]" or "[Outreachy][RFC/PATCH]", depending on -the mentoring program you are applying for, at the beginning of its -subject. +can mark it as RFC in the subject. See [section below](#use-a-tag-like-gsoc-outreachy-etc-in-your-subject) +about how to mark patches as RFC. -Consider [a sample email thread](http://public-inbox.org/git/1386590745-4412-1-git-send-email-t.gummerer@gmail.com/T/#u), +Consider [a sample email thread](https://public-inbox.org/git/1386590745-4412-1-git-send-email-t.gummerer@gmail.com/T/#u), which shows how a developer proposed a change and a patch to implement it. The problem being solved, the design of the proposed solution, and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC contributor, or Outreachy intern, you will be playing the role of the developer and engaging in a -similar discussion. Get familar with the flow, need for clarity on -both sides (i.e. you need to clearly defend your design, and need to +similar discussion. Get familiar with the flow, need for clarity on +both sides (i.e. you need to clearly explain your design, and need to ask for clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the discussion, to learn what is expected of you. +## Summary of the steps needed to complete a microproject + To complete a microproject, you will have to go through approximately the following steps: * Download the source code: clone the repository using the - [Git via Git](http://git-scm.com/downloads) instructions and read + [Git via Git](https://git-scm.com/downloads) instructions and read the `README` file. * Build the source code: this is described in the file `INSTALL`. @@ -66,13 +74,13 @@ the following steps: described in `Documentation/SubmittingPatches`. A more detailed step-by-step guide could be found in [`Documentation/MyFirstContribution.txt`](https://git-scm.com/docs/MyFirstContribution). -* The "[Hacking Git](https://git.github.io/Hacking-Git/)" page +* The "[Hacking Git](/Hacking-Git/)" page could also serve as a handy resource. It points to resources on various topics related to working on Git. * Select a microproject and check that it has not yet been taken or - discussed by searching the mailing list. - [Public Inbox](http://public-inbox.org/git/) is your friend. + discussed by searching the mailing list. Please read all the + sections below related to finding or selecting a microproject. * Send an email to the mailing list where you describe the microproject you want to work on, the way you want to do it, and @@ -89,7 +97,7 @@ the following steps: * Commit your change. Surprise: we use Git for that, so you will need to gain at least - [a basic familiarity](http://git-scm.com/documentation) with using + [a basic familiarity](https://git-scm.com/docs) with using Git. Make sure to write a good commit message that explains the reason for the change and any ramifications. You can find information on writing a good commit message in the @@ -97,29 +105,32 @@ the following steps: Remember to make sure that you agree with our "Developer's Certificate of Origin" (whose text is contained in `Documentation/SubmittingPatches`), and to - signify your agreement by adding a `Signed-off-by` line. + signify your agreement by adding a `Signed-off-by` line. Instructions + on how to add the sign-off is covered in the `SubmittingPatches` + document. * *Optional, but recommended:* - With an account at GitHub, you can use GitHub CI to test your changes + + With an account at GitHub or GitLab, you can use the CI to test your changes on Linux, Mac and Windows. See - [examples](https://github.com/git/git/actions/workflows/main.yml) - of recent CI runs. + [GitHub exmamples](https://github.com/git/git/actions/workflows/main.yml), [GitLab examples](https://gitlab.com/git-scm/git/-/pipelines) of recent CI runs. - To run these tests against your own branch, - [create a fork](https://help.github.com/articles/fork-a-repo/) - of [Git](https://github.com/git/git) on GitHub and switch to it. At the + To run these tests against your own branch: + * **GitHub**: [create a fork](https://help.github.com/articles/fork-a-repo/) of [Git](https://github.com/git/git) on GitHub and switch to it. At the top bar select [Actions tab](https://github.com/git/git/actions) and perform the initial setup to enable it for your fork. After enabling it, CI will run for a specific branch of your fork whenever you push new changes to it in GitHub. You can monitor the test state of all your branches in the same [Actions tab](https://github.com/git/git/actions) of your fork. + * **GitLab**: [create a fork](https://docs.gitlab.com/user/project/repository/forking_workflow/#create-a-fork) of [Git](https://gitlab.com/git-scm/git) on GitLab and switch to it. CI will run for a specific branch of your fork whenever you push new changes + to it in GitHub. You can monitor the test state of all your branches in the [Build > Pipeline](https://gitlab.com/git-scm/git/-/pipelines) section of your fork. If a branch did not pass all test cases then it is marked with a red cross. In that case you can click on the failing job and navigate to - "ci/run-build-and-tests.sh" and/or \ - "ci/print-test-failures.sh". You can also + `ci/run-build-and-tests.sh` and/or \ + `ci/print-test-failures.sh`. You can also download "Artifacts" which are tarred (or zipped) archives with test data - relevant for debugging. Fix the problem and push your fix to your GitHub fork. + relevant for debugging. Fix the problem and push your fix to your fork. This will trigger a new CI build. Ensure all tests pass. * Submit your change to the Git mailing list. For this step you @@ -131,8 +142,8 @@ the following steps: [submitGit](https://submitgit.herokuapp.com/). When you submit your patch, please mention that you plan to apply - for the GSoC or Outreachy. You can use "[GSoC][PATCH ...]" or - "[Outreachy][PATCH ...]" in the subject of the emails you send for + for the GSoC or Outreachy. You can use "[GSoC PATCH ...]" or + "[Outreachy PATCH ...]" in the subject of the emails you send for that purpose. This will ensure that we take special care not to overlook your application among the large pile of others. @@ -156,18 +167,28 @@ Applicants please attempt only **ONE** microproject. We want quality, not quantity! (Also, it takes work to collect the ideas, and it would be nice to have enough microprojects for everybody.) +### Change only a few files + This means that for a microproject that consists in refactoring or rewriting a small amount of code, your patch should change only **ONE** file, or perhaps 2 files if they are closely related, like "foo.c" and "foo.h". If you change a test file, the title of your patch (after the -"[GSoC][PATCH ...]" or "[Outreachy][PATCH ...]" part) should start +"[GSoC PATCH ...]" or "[Outreachy PATCH ...]" part) should start with "tXXXX: " where tXXXX is the start of the filename of the test script you change. If you change "foo.c" or "foo.h", the title of your patch should probably start with "foo: ". -In general it's a good idea to check on the mailing list archive what +If you create a function to refactor existing code, it's possible that +more files would be changed, but the changes should be trivial in most +of them. + +### Research existing related work + +In general it's a good idea to check on the mailing list archive +([lore.kernel.org](https://lore.kernel.org/git/) and +[Public Inbox](https://public-inbox.org/git/) are your friends) what other GSoC or Outreachy applicants attempting a microproject have already been told this year or any previous year, as hopefully it will help you avoid some mistakes. As some microproject ideas haven't @@ -181,6 +202,8 @@ problems when working on your real GSoC or Outreachy project. So it's a very good thing to show that you have researched your microproject and taken into account what you have found. +### After it's done, work on different things + If you've already done a microproject and are itching to do more, then get involved in other ways, like finding and fixing other problems in the code, or improving the documentation or code comments, or helping @@ -189,17 +212,36 @@ questions on the mailing list or in IRC, or writing new tests, etc., etc. In short, start doing things that other Git developers do! Alternatively you can of course focus on your project proposal. -## How to find other ideas for microprojects +## Be very careful when using AI tools + +There is an "AI guidelines" section on our +General-Application-Information page: + +https://git.github.io/General-Application-Information/ + +Please read it and make sure you use AI very carefully. + +## How to find ideas for microprojects First check the specific page(s) or information about Git microprojects related to your program that should have been published on this site or on the GSoC or Outreachy site. But then still read on everything below! -Any small code-related change would be suitable. Just remember to keep -the change small! It is much better for you to finish a small but -complete change than to try something too ambitious and not get it -done. +It's also possible that we haven't taken the time to put up a page +listing microprojects ideas for your program. The pages we used to +create for that were named "XXXX Applicant Microprojects" where XXXX +is the program name and a date, for example "SoC 2016 Applicant +Microprojects" for the GSoC in 2016, or "Outreachy Winter 2021-2022 +Applicant Microprojects" for Outreachy in 2021-2022. See the following +directory to find these old pages that might still be useful: + +https://git.github.io/Historical-SoC-Outreachy/ + +Any small code-related change would be suitable for a +microproject. Just remember to keep the change small! It is much +better for you to finish a small but complete change than to try +something too ambitious and not get it done. Though we don't require that your patch be accepted into the "master" branch by the time of your formal application, we still expect that a @@ -271,6 +313,11 @@ list. In general it's a very good idea to check that you can reproduce the bug on the latest version of Git before working on it. +Also some bugs are difficult to understand and require too much or too +difficult work for a microproject, so don't spend too much time on +them if it appears that they might not be simple to fix, and don't +hesitate to ask on the mailing list if they are a good microproject. + ### Searching for #leftoverbits in the mailing list People have recently started to add "#leftoverbits" to their emails @@ -284,6 +331,9 @@ But don't forget to search to check if what you find has already been addressed. If it has not been addressed, please ask first on the mailing list if it's a good idea to work on that. +As for bugs, and many things really, you can also ask if you are not +sure it's simple enough to fix. + ### Searching the code base itself Your best bet is probably to search for strings like "FIXME", "TODO", @@ -326,14 +376,53 @@ to"... It's likely that you will introduce yourself to the community around the same time you are going to start working on a micro-project. +### Tell us about you, or not + We don't require you to send us a special introductory email or to tell us about your skills, interests, experience, background, etc. Feel free to tell us what you want about yourself if you wish though. -But please, make it clear that you are interested in a specific -mentoring program and use the right tag, like [GSoC], [Outreachy], etc -at the beginning of the subject of your emails. +Make sure to specify your mentoring program clearly as +[suggested below](#use-a-tag-like-gsoc-outreachy-etc-in-your-subject). + +### Thoroughly check your eligibility in the program + +Before you introduce yourself, it's very important that you thoroughly +check as soon as possible that you are eligible for the mentoring +program you are interested in. + +This is especially important for Outreachy, which has strict rules and +is enforcing them. Their rules are available on: + +https://www.outreachy.org/docs/applicant/#eligibility + +Especially if you are a student, please check the section about the +rules for students, and especially check this one: + +"University students must have 42 consecutive days free from school +and exams during the internship period." + +The Outreachy organizers will check this rule with your university. +They will disqualify you if there is any requirement, especially this +one, that you don't meet. + +If you start applying to the Git project, this will deter others from +applying. We usually have very few projects and can only accept very +few applicants. So if others want to apply, they know they will have +to compete with you and possibly others, and they might prefer to find +another project with less competition. + +It happened recently that only two people applied for a project we +proposed, and both were later found to not be eligible because of +their university requirements. So in the end, we couldn't mentor +anyone for the project we proposed, which is bad for everyone. + +So please thoroughly check your eligibility before introducing +yourself, and please confirm in your introduction that you have +checked all the requirements and that you indeed meet them all. + +### Don't ask us to find a micro-project for you As we usually don't know your interests, skills, experience, background, etc, it's hard for us to select a micro-project for @@ -341,6 +430,8 @@ you, and it's part of your job as an applicant to research a good micro-project for you. It will show us that you will be able to select a good project for you and properly research it. +### Do ask for help, but be specific + You can ask for help if there are things you don't understand in a micro-project description, or if you have some trouble working on your micro-project or even finding a micro-project. But please be very @@ -400,6 +491,27 @@ other applicants or contributors participating in GSoC or Outreachy have been doing in the past, for example what kind of microproject they have chosen, how their proposal looked like, etc. +If you're using `format-patch` for sending your patches to the mailing list, +you can add this tag as follows: + +``` +git format-patch --subject-prefix='GSoC PATCH' + +(or) + +git format-patch --subject-prefix='Outreachy PATCH' +``` + +If you want to mark your patch as RFC, use + +``` +git format-patch --rfc --subject-prefix='GSoC PATCH' + +(or) + +git format-patch --rfc --subject-prefix='Outreachy PATCH' +``` + ### Reply inline Many people these days use the "top posting" posting style, but we @@ -460,10 +572,14 @@ or another pronoun to talk about you. Programs like Outreachy or GSoC usually have requirements for applicants. Sometimes applicants have to be accepted by the program -after they have shown they satisfy the requirements. +organizers after they have shown they satisfy the requirements. + +In any case it's interesting for us and others to know soon how you +currently stand regarding the requirements and maybe the acceptance +process. -In any case it's interesting for us to know soon how you currently -stand regarding the requirements and maybe the acceptance process. +See also the "Thoroughly check your eligibility in the program" +section above. ### Tell us what steps you have already taken diff --git a/Hacking-Git.md b/Hacking-Git.md index 9d20bd5ef5..7dd16d6658 100644 --- a/Hacking-Git.md +++ b/Hacking-Git.md @@ -3,12 +3,15 @@ layout: default title: Hacking Git --- -The goal of this document is not to be a tutorial, but rather to -point to interesting material that has already been written. +The goal of this document is not to be a tutorial, but rather to point +to interesting material that has already been written. -The goal is also not to list all the articles about Git or its -internals. There are a lot of good resources, including free -[books](http://git-scm.com/book/en/v2/), about that elsewhere. +The goal is also not to list all the articles, tools or resources +about Git or its internals. There are a lot of good resources, +including [free books](http://git-scm.com/book/en/v2/), and the +[archive of our newsletter](https://git.github.io/rev_news/archive/), +about that elsewhere. So on this page we focus on what is the most +interesting for developers starting to work on Git. Contributions are welcome though! Please contact us on the Git Mailing list (at [git@vger.kernel.org](mailto:git@vger.kernel.org)) or open an @@ -18,7 +21,9 @@ suggest improvements. Thanks! ## Building Git -* ["`INSTALL`"](https://github.com/git/git/blob/master/INSTALL) +* ["`INSTALL`"](https://github.com/git/git/blob/master/INSTALL) to build using [Make](https://www.gnu.org/software/make/). + +* ["`meson.build`"](https://github.com/git/git/blob/master/meson.build) to build using [Meson](https://mesonbuild.com/). * ["Installing from Source"](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git#_installing_from_source) in the Pro Git book @@ -30,16 +35,20 @@ suggest improvements. Thanks! * [Fabien Sanglar's Git Source Code Review](https://fabiensanglard.net/git_code_review/architecture.php) +* [DeepWiki git/git, an AI generated introduction level overview](https://deepwiki.com/git/git) + * [Boost Your Programming Skills by Reading Git's Code](https://www.freecodecamp.org/news/boost-programming-skills-read-git-code/) ## Getting started hacking and contributing * ["My First Contribution"](https://git-scm.com/docs/MyFirstContribution) -* ["My First Object Walk"](https://github.com/git/git/blob/master/Documentation/MyFirstObjectWalk.txt) +* ["My First Object Walk"](https://github.com/git/git/blob/master/Documentation/MyFirstObjectWalk.adoc) * [Matheus' tutorial](https://matheustavares.gitlab.io/posts/first-steps-contributing-to-git) +* [Eric Ju's "Contribute-to-Git: A beginner's Guide" wiki](https://gitlab.com/gitlab-org/git/-/wikis/Contribute-to-Git:-A-beginner's-Guide) + * ["Hacking Git"](https://git-scm.com/docs/user-manual#hacking-git) in the Git User's Manual * ["`Documentation/technical`"](https://github.com/git/git/tree/master/Documentation/technical), technical documentation (also viewable at `https://git-scm.com/docs/`) @@ -52,15 +61,17 @@ suggest improvements. Thanks! * ["`SubmittingPatches`"](https://git-scm.com/docs/SubmittingPatches/) -* [Git for Windows' "Good commits"](https://github.com/git-for-windows/git/wiki/Good-commits) +* [Git for Windows' "Good commits"](https://gitforwindows.org/good-commits) ## Process related tools and sites * [GitGitGadget](https://gitgitgadget.github.io/) makes it easy to send patches to the mailing list. -* [lore.kernel.org/git](https://lore.kernel.org/git/) is our prefered mailing list archive. +* [Sending patches by email with git](https://flusp.ime.usp.br/git/sending-patches-by-email-with-git/) is Matheus' git send-email tutorial. -* [public-inbox](https://public-inbox.org/README.html) is the software behing lore.kernel.org. +* [lore.kernel.org/git](https://lore.kernel.org/git/) is our preferred mailing list archive. + +* [public-inbox](https://public-inbox.org/README.html) is the software behind lore.kernel.org. * [lore+lei](https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started) helps take advantage of lore/public-inbox. @@ -76,16 +87,12 @@ suggest improvements. Thanks! * [Junio's "What's cooking in git.git" emails](https://lore.kernel.org/git/?q=s%3A%22What%27s+cooking+in+git.git%22) list the status of various development topics. -* [Git's release calendar](https://tinyurl.com/gitCal) shows the planned release cycles, the maintainer's planned offline time, the Review Club meetings and possibly other events. +* [Git's release calendar](https://tinyurl.com/gitCal) shows the planned release cycles, the maintainer's planned offline time, and possibly other events. * [Git Rev News](https://git.github.io/rev_news/archive/) newsletter. * [Git Merge conference](https://git-merge.com/). -* [Review Club announces and discussions on the list](https://lore.kernel.org/git/?q=s%3A%22Review+Club%22). - -* [Review Club meeting notes](https://docs.google.com/document/d/14L8BAumGTpsXpjDY8VzZ4rRtpAjuGrFSRqn3stCuS_w) Google doc. - * [Discussions about Contributor(s) Summits on the list](https://lore.kernel.org/git/?q=s%3AContributor*+Summit) ## Branching workflow @@ -96,13 +103,13 @@ suggest improvements. Thanks! * [`gitworkflows`](https://git-scm.com/docs/gitworkflows) manual page -* ["How to maintain Git"](https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt) +* ["How to maintain Git"](https://github.com/git/git/blob/master/Documentation/howto/maintain-git.adoc) * ["How the Creators of Git do Branching"](https://hackernoon.com/how-the-creators-of-git-do-branches-e6fcc57270fb), and the associated [gitworkflow](https://github.com/rocketraman/gitworkflow) repository ## Debugging -* [Git for Windows' Debugging Git](https://github.com/git-for-windows/git/wiki/Debugging-Git) +* [Git for Windows' Debugging Git](https://gitforwindows.org/debugging-git) * [Launching GDB explanations in CodingGuidelines](https://github.com/git/git/blob/v2.27.0/Documentation/CodingGuidelines#L441-L445) @@ -124,8 +131,12 @@ suggest improvements. Thanks! * [#git-devel IRC channel archive](https://colabti.org/irclogger/irclogger_logs/git-devel) +* [Git Community Discord Server](https://discord.gg/NKY7fFue) + * [git-mentoring mailing list](https://groups.google.com/forum/#!forum/git-mentoring) +* ["A note from the maintainer"](https://github.com/git/git/blob/todo/MaintNotes) + ## Mentoring programs * [Google Summer of Code](https://summerofcode.withgoogle.com/) diff --git a/Mentoring-Program-Guide.md b/Mentoring-Program-Guide.md index f54a5b8371..52d2b47960 100644 --- a/Mentoring-Program-Guide.md +++ b/Mentoring-Program-Guide.md @@ -35,7 +35,7 @@ actually starts, (GSoC calls this the "Community Bonding" period,) is a blog. You might want to check which blogging tools previous Outreachy -interns and GSoC students used. Using a Git related tools is of course +interns and GSoC contributors used. Using a Git related tools is of course a good idea. - [Miriam Rubio's Outreachy intership experiences](https://mirucam.gitlab.io/outreachy_blog/) @@ -57,7 +57,7 @@ abilities and dedication. A good example is Matheus' GSoC blog posts: [Matheus Tavares' GSoC posts](https://matheustavares.gitlab.io/tags/gsoc/) Tip: It's better if you can decide the day for your weekly blog post -as soon as you set up you blog. Then tell your mentor about that day +as soon as you set up you blog. Then tell your mentors about that day right away, and try as much as possible to post every week on that day. This will help establish a routine, that will make things easier for both you and your mentors. @@ -67,6 +67,32 @@ blog post during the week as you are working on your project. This way it can also serve you as a todo list, a notebook, a list of current issues, etc. +## Social media and blog post content + +In general posting about your GSoC on social media (like LinkedIn) is +nice too. You can put links to your blog post in your social media +posts, as they are usually shorter than blog posts. + +You can start blogging as soon as your mentors contact you after you +have been officially selected to participate in the mentoring +program. It's in fact a nice idea to start blogging right after they +have contacted you. + +In all your posts (on your blog or social media), when you mention +your mentors and when they are mentoring you as part of their job, +it's nice to mention the companies they are working for too. Some +mentors could mentor you in their free time, and might not want their +employer mentioned though. So if you are not sure that it's part of +their job, just ask them before posting. In case of Outreachy if some +company sponsors your internship, it's a very good idea to mention +them too. + +The more these companies get good mentions in the media about your +GSoC, and the more good work you deliver during it, the more likely +they are to allow their employees to mentor others, or even to sponsor +mentoring programs (like Outreachy internships for example), or maybe +to hire or help you in the future. + ## Regular updates Mentors should be regularly updated about your work, so they can know @@ -110,15 +136,15 @@ mailing list, it is important that you cover all the following topics: 4. what things you think should be easier 5. what you are planning to work on and how -The reason we ask for 2), 3) and 4) is that often interns or students -don't know about things, like existing documentation, historical -discussions, debugging scripts, features, tools or techniques, that -could help them understand what's going on, or work in a more -efficient way. If a mentor doesn't know that the intern or student is -blocked or slowed by something or has a hard time moving forward, it's -difficult for the mentor to help. So it's important for interns or -students to reflect on the issues, blocks, inefficiencies, complex -things that they are facing. +The reason we ask for 2), 3) and 4) is that often interns or +contributors don't know about things, like existing documentation, +historical discussions, debugging scripts, features, tools or +techniques, that could help them understand what's going on, or work +in a more efficient way. If a mentor doesn't know that the intern or +contributor is blocked or slowed by something or has a hard time +moving forward, it's difficult for the mentor to help. So it's +important for interns or contributors to reflect on the issues, +blocks, inefficiencies, complex things that they are facing. Notifying the mailing list or your mentors about a blog post, should not prevent you from emailing or contacting the mailing list or your @@ -178,9 +204,9 @@ list that people debug together or discuss together something over email in a very real-time way (at least similar as instant messaging chat). -Such chats can sometimes help a student or intern (or even long timers -on the project) move very fast in a short amount of time. So consider -taking advantage of that. +Such chats can sometimes help a contributor or intern (or even long +timers on the project) move very fast in a short amount of time. So +consider taking advantage of that. It's also easier for mentors to help (or understand how they could help) when discussing informally using a real time or near real time @@ -418,7 +444,7 @@ below: - [Git's SubmittingPatches doc](https://github.com/git/git/blob/master/Documentation/SubmittingPatches) This documentation contains the - [Developer's Certificate of Origin, or DCO for short](https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L227-L263), + [Developer's Certificate of Origin, or DCO for short](https://git-scm.com/docs/SubmittingPatches#sign-off), which you have to know about when contributing to Git. - [Git's license](https://github.com/git/git/blob/master/COPYING) @@ -464,12 +490,156 @@ it's not part of your main work. - [GSoC website](https://summerofcode.withgoogle.com) +# Roadblocks and Benefits + +Successfully participating in a mentoring program with Git can boost +your career in a number of different ways. Also even if it requires +working regularly and being open to mentoring, it's not very +difficult. We estimate that around 80% or more of the people we accept +succeed. + +## Roadblocks + +It's possible that you will encounter difficulties in moving forward +in your project. We try to list a few common ones here, along with +some advice to help overcome them. + +In general it's a good idea to discuss such issues with your mentor(s) +as early as possible. This way you might get some help and be able to +try different solutions before it's too late. One possible way to +alleviate some issues could be to extend the mentoring period if the +mentoring program allows it. + +### Dedicated time + +The main thing that could prevent you from succeeding is not having or +dedicating enough time to work on your project. Some people we +mentored had university classes, or found a full time job, or took +some long vacation, or spent a lot of time with their family, which +prevented them from dedicating enough time to their project. This +resulted in us having to fail them, which is sad for everyone. + +If you are planning to spend a significant amount of time doing other +things than working on your project during the mentoring program, it +might be better to not participate in it in the first place. You will +save yourself and your mentor(s) a significant amount of frustration, +and you will likely allow someone else to be successfully mentored and +gain a lot from that experience. + +Other roadblocks can more easily be overcome than not dedicating +enough time. Even if you can work a lot, you will need a bit of free +time during the mentoring program, so you may make things very +difficult for yourself if you are planning to work on both your +project and other things at the same time. Be considerate towards +yourself and do not put yourself in such a bad situation in the first +place. + +### Asking for help + +Another thing that could slow you is if it's difficult for you to +share with your mentor(s) about the technical hurdles you face. It +could be that you have trouble debugging or understanding how things +work or are supposed to work, and are afraid of asking for help. + +When we review your work, we provide technical suggestions, but when +you are starting it or in the middle of it, you are usually alone and +it can be difficult for you to ask your mentor(s) to take a look at +it. Please consider that the more transparent you are about your work, +and the more precise and specific you are in your questions, the +easier it is for us to help you, and for you to move forward. + +We only request that you spend around 10 minutes trying to find a +solution by yourself before you ask us about something. When you have +tried to find a solution, it's also a good idea to tell us what you +have tried or how you searched, as we can often help you be more +efficient in this too. + +### Personal issues + +Yet another roadblock that could sometimes prevent you from succeeding +is personal issues of different kinds. They are sometimes related to +your family or your partner. They are sometimes related to the other +potential roadblocks above. + +In general it's a good idea to talk about them early with your mentor, +as we just cannot properly handle difficult personal situations we are +not aware of. And regular communication, even using video chat, might +not be enough to suspect that your personal situation might be +difficult, if you are not explicit about it. + +## Benefits + +There are a lot of benefits in participating in mentoring programs +with the Git project, not just the fact that the programs pay the +participants a significant amount of money. + +And it's not limited to the first time you participate. The more you +participate, the more benefits you will reap. Participating as a +mentor or a co-mentor after you have been mentored, or becoming a +regular contributor, will also reflect very well on you and increase a +number of benefits you get. It's also relatively easy, as you have +already overcome the most difficult parts. + +### Career boost + +A number of former participants in a mentoring program with us have +reported that it significantly boost their career, as they much more +easily got job interviews, and then job offers with more well known +companies. + +### Improved technical skills + +Former participants also reported that they felt their software +engineering skills improved significantly. + +This is not just that they became more proficient with Git and source +code management in general. It's a also at least about improved +programming, testing, reviewing and collaborating skills. + +### Improved self confidence + +We believe that being able to contribute significantly to a well known +project like Git, also helps improve participants' self-confidence. +They are likely to be less afraid to participate in and contribute to +more complex software projects. + +### Improved Internet credibility + +We strongly encourage the participants we mentor to create a blog +about their work and regularly post on their blog, as we believe that +it helps them in many ways. We encourage them to post on social media +too. + +We also mention participants in our Git Rev News newsletter both after +they have been selected into a mentoring program, and after they +successfully finished it. + +Sometimes they get mentioned, or interviewed, in the blog posts of +some well known Git related companies too, like for example: + + - [this GitLab blog post about Outreachy](https://about.gitlab.com/blog/2021/04/15/outreachy-sponsorship-winter-2020/), or + - [this GitHub blog post about the Git 2.43 release](https://github.blog/2023-11-20-highlights-from-git-2-43/), + where Kousik's GSoC 2023 work is mentioned. + +### Meeting us at some conferences + +We try to help successful participants come to the +[Git Merge conference](https://git-merge.com/) +and meet the community, often including their mentor(s), there. For +that the Git project offers to reimburse the participants' travel +expenses. + +This is sometimes not possible due to visa issues, or the fact that +the Git Merge unfortunately doesn't happen every year, though. + # Conclusion -Hope you got an idea about how things usually go during the mentoring -period of a mentoring program such as GSoC or Outreachy. Hope you are -also aware of the people, communication means and resources available -to help you, as well as the rules you have to follow. +We hope you got an idea about how you will likely work with your +mentor(s) and how things usually go during the mentoring period of a +program such as GSoC or Outreachy. We hope you are also aware of the +people, communication means and resources available to help you, as +well as the rules you have to follow, the roadblocks you might +encounter and the benefits you may reap. As a reminder, don't be surprised if your mentors ask for things that are a bit different than what is described here. Typically your diff --git a/Outreachy-21-Microprojects.md b/Outreachy-21-Microprojects.md index 2c9762fdc7..cffa96590f 100644 --- a/Outreachy-21-Microprojects.md +++ b/Outreachy-21-Microprojects.md @@ -89,6 +89,6 @@ untracked file in the submodule directory. This is inconsistent with what `git describe --dirty` says when run in the submodule directory in that state. -Fix `git diff` to use the same definition of dirtyness for such a +Fix `git diff` to use the same definition of dirtiness for such a submodule directory (or the other way around). [[cf](https://lore.kernel.org/git/xmqqo8m1k542.fsf@gitster.c.googlers.com)] diff --git a/Outreachy-Participants.md b/Outreachy-Participants.md new file mode 100644 index 0000000000..53c7fed07e --- /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/SoC-2014-Microprojects.md b/SoC-2014-Microprojects.md index dceeccf260..f735a8a307 100644 --- a/SoC-2014-Microprojects.md +++ b/SoC-2014-Microprojects.md @@ -28,7 +28,7 @@ and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC student, you will be playing the role of the developer and engaging in a similar discussion. Get -familar with the flow, need for clarity on both sides (i.e. you need +familiar with the flow, need for clarity on both sides (i.e. you need to clearly defend your design, and need to ask clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md index 8d558eca09..2248169e81 100644 --- a/SoC-2015-Ideas.md +++ b/SoC-2015-Ideas.md @@ -77,7 +77,7 @@ look for the commit which fixed a bug. It is already possible using "git bisect", but the user has to type "good" to mean "the bug is there" and "bad" to mean "the bug is fixed", which isn't convenient. -It would be nice to allow the user to explicitely say "git bisect +It would be nice to allow the user to explicitly say "git bisect fixed" and "git bisect unfixed" instead. It is actually much harder than defining "fixed"/"unfixed" as aliases for "bad"/"good". diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md index b8df3a6ede..de0a0a7293 100644 --- a/SoC-2015-Microprojects.md +++ b/SoC-2015-Microprojects.md @@ -28,7 +28,7 @@ and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC student, you will be playing the role of the developer and engaging in a similar discussion. Get -familar with the flow, need for clarity on both sides (i.e. you need +familiar with the flow, need for clarity on both sides (i.e. you need to clearly defend your design, and need to ask clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the diff --git a/SoC-2016-Ideas.md b/SoC-2016-Ideas.md index 9d66a0c6d2..c5044c32c6 100644 --- a/SoC-2016-Ideas.md +++ b/SoC-2016-Ideas.md @@ -267,7 +267,7 @@ compressed data from one packfile to another. This would involve looking at the code in git to copy over optimisations as well as figuring out what parts of libgit2 should be -changed to accomodate these new capabilities. +changed to accommodate these new capabilities. - Language: C - Difficulty: medium diff --git a/SoC-2016-Microprojects.md b/SoC-2016-Microprojects.md index 3d3bebda50..54c5184b1b 100644 --- a/SoC-2016-Microprojects.md +++ b/SoC-2016-Microprojects.md @@ -40,7 +40,7 @@ and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC student, you will be playing the role of the developer and engaging in a similar discussion. Get -familar with the flow, need for clarity on both sides (i.e. you need +familiar with the flow, need for clarity on both sides (i.e. you need to clearly defend your design, and need to ask clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the @@ -272,7 +272,7 @@ When you find something you are interested to work on, please ask first on the mailing list if it's worth doing and if it's appropriate for a microproject before starting to work on what you find. Even if it looks straitforward, there could be hidden reasons why it is too -difficult or just innappropriate. +difficult or just inappropriate. ### Searching the code base itself diff --git a/SoC-2017-Microprojects.md b/SoC-2017-Microprojects.md index a0b349c9f5..ef4a09b3e0 100644 --- a/SoC-2017-Microprojects.md +++ b/SoC-2017-Microprojects.md @@ -33,7 +33,7 @@ and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC student, you will be playing the role of the developer and engaging in a similar discussion. Get -familar with the flow, need for clarity on both sides (i.e. you need +familiar with the flow, need for clarity on both sides (i.e. you need to clearly defend your design, and need to ask clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the @@ -262,7 +262,7 @@ When you find something you are interested to work on, please ask first on the mailing list if it's worth doing and if it's appropriate for a microproject before starting to work on what you find. Even if it looks straitforward, there could be hidden reasons why it is too -difficult or just innappropriate. +difficult or just inappropriate. ### Searching the code base itself diff --git a/SoC-2018-Microprojects.md b/SoC-2018-Microprojects.md index 7b4adf734b..8a33938ff8 100644 --- a/SoC-2018-Microprojects.md +++ b/SoC-2018-Microprojects.md @@ -33,7 +33,7 @@ and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC student, you will be playing the role of the developer and engaging in a similar discussion. Get -familar with the flow, need for clarity on both sides (i.e. you need +familiar with the flow, need for clarity on both sides (i.e. you need to clearly defend your design, and need to ask clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the diff --git a/SoC-2019-Ideas.md b/SoC-2019-Ideas.md index 94315b9c3e..da3b6c8f36 100644 --- a/SoC-2019-Ideas.md +++ b/SoC-2019-Ideas.md @@ -120,7 +120,7 @@ projects versus projects that implement new features though. Git has an old problem of duplicated implementations of some logic. For example, Git had at least 4 different implementations to format command output for different commands. Our previous GSoC -students and Outreachy interns unified some of the formating logic +students and Outreachy interns unified some of the formatting logic into [ref-filter](https://github.com/git/git/blob/master/ref-filter.h) and got rid of similar logic in some command specific files. Current task is to continue this work and reuse ref-filter formatting logic in @@ -137,7 +137,7 @@ See discussion in: - Possible mentors: Christian Couder, Thomas Gummerer A number of Git commands, like `git log`, can show commit information -in a configurable way using ["pretty" formats](https://github.com/git/git/blob/master/Documentation/pretty-formats.txt). +in a configurable way using ["pretty" formats](https://github.com/git/git/blob/master/Documentation/pretty-formats.adoc). Such formats though don't yet support some features that users would like, for example to display a log like the following: diff --git a/SoC-2019-Microprojects.md b/SoC-2019-Microprojects.md index 80ef93c4d2..9bec90f907 100644 --- a/SoC-2019-Microprojects.md +++ b/SoC-2019-Microprojects.md @@ -33,7 +33,7 @@ and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC student, you will be playing the role of the developer and engaging in a similar discussion. Get -familar with the flow, need for clarity on both sides (i.e. you need +familiar with the flow, need for clarity on both sides (i.e. you need to clearly defend your design, and need to ask clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the diff --git a/SoC-2020-Ideas.md b/SoC-2020-Ideas.md index f2e94aba4e..ce6d43cd62 100644 --- a/SoC-2020-Ideas.md +++ b/SoC-2020-Ideas.md @@ -27,7 +27,7 @@ page though. Git has an old problem of duplicated implementations of some logic. For example, Git had at least 4 different implementations to format command output for different commands. Our previous GSoC -students and Outreachy interns unified some of the formating logic +students and Outreachy interns unified some of the formatting logic into [ref-filter](https://github.com/git/git/blob/master/ref-filter.h) and got rid of similar logic in some command specific files. Current task is to continue this work and reuse ref-filter formatting logic in @@ -45,7 +45,7 @@ See discussion in: A number of Git commands, like `git log`, can show commit information in a configurable way using -["pretty" formats](https://github.com/git/git/blob/master/Documentation/pretty-formats.txt). +["pretty" formats](https://github.com/git/git/blob/master/Documentation/pretty-formats.adoc). Such formats though don't yet support some features that users would like, for example to display a log like the following: diff --git a/SoC-2021-Ideas.md b/SoC-2021-Ideas.md index 1d1fc3f821..9a69ccb007 100644 --- a/SoC-2021-Ideas.md +++ b/SoC-2021-Ideas.md @@ -32,7 +32,7 @@ possible the same code and syntax as the ref-filter formats. Git used to have an old problem of duplicated implementations of some logic. For example, Git had at least 4 different implementations to format command output for different commands. Our previous GSoC -students and Outreachy interns unified some of the formating logic +students and Outreachy interns unified some of the formatting logic into [ref-filter](https://github.com/git/git/blob/master/ref-filter.h) and got rid of similar logic in some command specific files. diff --git a/SoC-2022-Ideas.md b/SoC-2022-Ideas.md index 8e3bc62e96..90a0ab1cb6 100644 --- a/SoC-2022-Ideas.md +++ b/SoC-2022-Ideas.md @@ -83,7 +83,7 @@ logic. For example, Git had at least 4 different implementations to format command output for different commands. Our previous GSoC students and Outreachy interns unified some of the -formating logic into +formatting logic into [ref-filter](https://github.com/git/git/blob/master/ref-filter.h) and got rid of similar logic in some command specific files. Current task is to continue this work and reuse ref-filter formatting logic in diff --git a/SoC-2022-Microprojects.md b/SoC-2022-Microprojects.md index 250c7b4693..6def7c11d8 100644 --- a/SoC-2022-Microprojects.md +++ b/SoC-2022-Microprojects.md @@ -1,6 +1,7 @@ --- layout: default title: SoC 2022 Applicant Microprojects +navbar: false --- ## Introduction diff --git a/SoC-2023-Ideas.md b/SoC-2023-Ideas.md index 89b4ec2a87..582cfcd75c 100644 --- a/SoC-2023-Ideas.md +++ b/SoC-2023-Ideas.md @@ -1,6 +1,7 @@ --- layout: default title: SoC 2023 Ideas +navbar: false --- This is the idea page for Summer of Code 2023 for Git. @@ -76,7 +77,7 @@ logic. For example, Git had at least 4 different implementations to format command output for different commands. Our previous GSoC students and Outreachy interns unified some of the -formating logic into +formatting logic into [ref-filter](https://github.com/git/git/blob/master/ref-filter.h) and got rid of similar logic in some command specific files. Current task is to continue this work and reuse ref-filter formatting logic in diff --git a/SoC-2024-Ideas.md b/SoC-2024-Ideas.md new file mode 100644 index 0000000000..041eba592c --- /dev/null +++ b/SoC-2024-Ideas.md @@ -0,0 +1,207 @@ +--- +layout: default +title: SoC 2024 Ideas +navbar: false +--- + +![git logo >](https://git-scm.com/images/logos/downloads/Git-Logo-2Color.svg) + +This is the idea page for Summer of Code 2024 for Git. + +*Please completely read the [general application information](https://git.github.io/General-Application-Information) +page before reading the idea list below.* + +## Summer of code main project ideas + +**Students**: Please consider these ideas as starting points for +generating proposals. We are also more than happy to receive proposals +for other ideas related to Git. Make sure you have read the "Note +about refactoring projects versus projects that implement new +features" in the [general application information](https://git.github.io/General-Application-Information) +page though. + +### Note about limit of project selection + +Kindly note that considering the bandwidth of available mentors, the +Git project would only mentor up to 3 contributors this year. + +This is not a hard and fast rule. It may change if more community members are +willing to mentor in the coming days. For instance, this may happen when +a new project is proposed and some community member volunteers to mentor +the same. + +### Move existing tests to a unit testing framework + +Git has a lot of test cases that need to be migrated to use a new unit +testing framework. This typically involves moving code from both: + + - a "t/helper/test-*.c" test helper in C, and + - a "t/*.sh" test script in shell that invokes the test helper + +over to a single "t/unit-tests/t-*.c" in C using the unit testing +framework. + +Our Outreachy intern ported some of the unit tests. + +**Note**: Owing to additional care needed to convert +reftable unit tests in `t0032-reftable-unittest.sh`, +it is covered as a separate project below. +So, this project solely focuses on unit tests _other than_ +the reftable ones. + +- See: + + - this discussion + - + - + - + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Christian Couder < > +* Kaartic Sivaraam < > + +### Convert reftable unit tests to use the unit testing framework + +The "reftable" unit tests in `t0032-reftable-unittest.sh` +predate the unit testing framework that was recently +introduced into Git. These tests should be converted to use +the new framework. + +See: + + - this discussion + - + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Low + +Languages: C, shell(bash) + +Possible mentors: +* Patrick Steinhardt < > +* Karthik Nayak < > +* Christian Couder < > + +### Implement consistency checks for refs + +The git-fsck(1) command is used to check various data +structures for consistency. Notably missing though are +consistency checks for the refdb. While git-fsck(1) +implicitly checks some of the properties of the refdb +because it uses its refs for a connectivity check, these +checks aren't sufficient to properly ensure that all refs +are properly consistent. + +The goal of this project would be to introduce consistency +checks that can be implemented by the ref backend. Initially +these checks may only apply to the "files" backend. With the +ongoing efforts to upstream a new "reftable" backend the +effort may be extended. + +See: + + - + - + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Patrick Steinhardt < > +* Karthik Nayak < > + +### Refactor git-bisect(1) to make its state self-contained + +The git-bisect(1) command is used to find a commit in a +range of commits that introduced a specific bug. Starting a +bisection run creates a set of state files into the Git +repository which record various different parameters like +".git/BISECT_START". These files look almost like refs +due to their names being all-uppercase. This has led to +confusion with the new "reftable" backend because it wasn't +quite clear whether those files are in fact refs or not. + +As it turns out they are not refs and should never be +treated like one. Overall, it has been concluded that the +way those files are currently stored is not ideal. Instead +of having a proliferation of files in the Git directory, it +was discussed whether the bisect state should be moved into +its own "bisect-state" subdirectory. This would make it more +self-contained and thereby avoid future confusion. It is +also aligned with the sequencer state used by rebases, which +is neatly contained in the "rebase-apply" and "rebase-merge" +directories. + +The goal of this project would be to realize this change. +While rearchitecting the layout should be comparatively easy +to do, the harder part will be to hash out how to handle +backwards compatibility. + +See: + + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Patrick Steinhardt < > +* Karthik Nayak < > +* Christian Couder < > + +### Implement support for reftables in "dumb" HTTP transport + +Fetching Git repositories uses one of two major protocols: + + - The "dumb" protocol works without requiring any kind of + interactive negotiation like a CGI module. It can thus + be served by a static web server. + + - The "smart" protocol works by having the client and + server exchange multiple messages with each other. It is + more efficient, but requires support for Git in the + server. + +While almost all servers nowadays use the "smart" protocol, +there are still some that use the "dumb" protocol. + +The "dumb" protocol cannot serve repositories which use the +"reftable" backend though. While there exists a "info/refs" +file that is supposed to be backend-agnostic, this file does +not contain information about the default branch. Instead, +clients are expected to download the "HEAD" file and derive +the default branch like that. This file is a mere stub in +the "reftable" backend though, which breaks this protocol. + +The goal of this project is to implement "reftable" support +for "dumb" fetches. + +See: + + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Patrick Steinhardt < > +* Karthik Nayak < > diff --git a/SoC-2024-Microprojects.md b/SoC-2024-Microprojects.md new file mode 100644 index 0000000000..c832f49f30 --- /dev/null +++ b/SoC-2024-Microprojects.md @@ -0,0 +1,144 @@ +--- +layout: default +title: SoC 2024 Applicant Microprojects +navbar: false +--- + +## Introduction + +First make sure you read and understand +[our general guidelines and suggestions for microprojects](https://git.github.io/General-Microproject-Information). + +There are some suggestions on how you can find some microprojects on your own in the document. + +## Ideas for microprojects + +### Add more builtin patterns for userdiff + +"git diff" shows the function name corresponding to each hunk after +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...), +the way to find the function name is built-in Git's source code as +regular expressions (see userdiff.c). A few languages are common +enough to deserve a built-in driver, but are not yet recognized. For +example, shell. + +This project requires a very good knowledge of regular expressions. + +It is easy though to find examples of how this can be done by +searching the code base and the mailing list archive, as this has +already been done for a number of languages. + +### Replace a run_command*() call by direct calls to C functions + +See for example what Junio did in +[ffcb4e94d3](https://github.com/git/git/commit/ffcb4e94d3) (bisect: do +not run show-branch just to show the current commit, 2021-07-27). + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +### Use `test_path_is_*` functions in test scripts + +Find one test script that verifies the presence/absence of +files/directories with 'test -(e|f|d|...)' and replace them with the +appropriate `test_path_is_file`, `test_path_is_dir`, etc. helper +functions. Note that this conversion does not directly apply to control +flow constructs like `if test -e ./path; then ...; fi` because the +replacements are intended to assert the condition instead of merely +testing for it. Check [this link](https://public-inbox.org/git/CAPig+cRfO8t1tdCL6MB4b9XopF3HkZ==hU83AFZ38b-2zsXDjQ@mail.gmail.com/) +for an elaborate clarification on identifying `test -e` +instances that should / should not be replaced. + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +### Avoid suppressing `git`'s exit code in test scripts + +The Git project uses a large collection of integration tests written in +Shell to guard against regressions when adding new features or fixing +bugs. The scripts in question can be found in the `t` directory +[here][git-t]. + +While it is perfectly OK to use [pipes][wikipedia-pipes] when writing +integration tests, we must be careful to avoid writing a pipeline that +suppresses the exit code of a Git process, like so: + +``` +git | +``` + +...since the exit code of `git ` would be suppressed by the +pipe. If `git ` crashed, we would not catch it in the above +example when running the integration suite. + +Other examples to avoid include: + +``` +# bad: + $(git ) + +# also bad: + <) +EOF +``` + +...since the exit code of `git ` is hidden behind the +subshell in both instances. + +On the other hand, both of the following examples are OK, since neither +hides the exit code of running `git `: + +``` +# good: +var=$(git ) + +# also good: + | | git +``` + +(provided that neither `` or `` are +`git`). + +See the commit +[c6f44e1da5](https://github.com/git/git/commit/c6f44e1da5e88e34) +for example, and then do the same thing in one other test script. + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +[git-t]: https://github.com/git/git/tree/master/t +[wikipedia-pipes]: https://en.wikipedia.org/wiki/Pipeline_(Unix) + +### Use unsigned integral type for collection of bits. + +Pick one field of a structure that (1) is of signed integral type and (2) is +used as a collection of multiple bits. Discuss if there is a good reason +why it has to be a signed integral field and change it to an unsigned +type otherwise. [[thread](https://public-inbox.org/git/xmqqsiebrlez.fsf@gitster.dls.corp.google.com)] + +Even though the amount of code to write is small, these projects +involve a lot of prior work to understand the specification and deal +with all potential corner-cases. + +### Modernize a test script + +A number of our test scripts have been written a long time ago in a +style that is now outdated. + +In the following email it is explained in details how to modernize and +clean up the t7001 test script: + + + +t7001 is not the only test script where similar changes could be made +though. + +Find one test script that needs some of the same changes and make +them. Please make sure that the test script is not already being +worked on by asking on the mailing list before starting to work on it. + +There should be only one kind of change per commit. For example if one +of your commits indents test bodies with TABs, instead of spaces, then +this should be the only kind of change in this commit. diff --git a/SoC-2025-Ideas.md b/SoC-2025-Ideas.md new file mode 100644 index 0000000000..fac121ab43 --- /dev/null +++ b/SoC-2025-Ideas.md @@ -0,0 +1,172 @@ +--- +layout: default +title: SoC 2025 Ideas +--- + +![git logo >](https://git-scm.com/images/logos/downloads/Git-Logo-2Color.svg) + +This is the idea page for Summer of Code 2025 for Git. + +*Please completely read the [general application information](https://git.github.io/General-Application-Information) +page before reading the idea list below.* + +## Summer of code main project ideas + +**Students**: Please consider these ideas as starting points for +generating proposals. We are also more than happy to receive proposals +for other ideas related to Git. Make sure you have read the "Note +about refactoring projects versus projects that implement new +features" in the [general application information](https://git.github.io/General-Application-Information) +page though. + +### Note about limit of project selection + +Kindly note that considering the bandwidth of available mentors, the +Git project would only mentor up to 3 contributors this year. + +This is not a hard and fast rule. It may change if more community members are +willing to mentor in the coming days. For instance, this may happen when +a new project is proposed and some community member volunteers to mentor +the same. + + +### Consolidate ref-related functionality into git-refs + +This project aims to streamline Git's reference management into the existing +`git-refs` command by consolidating functionality currently spread +across multiple commands. The new command will provide subcommands for listing, +getting, checking existence, writing, and optimizing references, replacing the +functionality currently handled by git-update-ref(1), git-for-each-ref(1), +git-show-ref(1), and git-pack-refs(1). + +The consolidation work should ensure backward compatibility with existing +commands. The work involves C programming in Git's codebase, creating +comprehensive tests, and updating documentation. + +Required skills include C programming, familiarity with Git's codebase, and experience with command-line tool development. The project is expected to take 12 weeks, with existing commands being maintained for backward compatibility while development focuses on the new unified interface. + +Getting started: Build Git from source, study the existing ref-related commands, and submit a micro-patch to demonstrate familiarity with the codebase. + +_Expected Project Size_: 175 hours or 350 hours + +_Difficulty_: Medium + +_Languages_: C, shell(bash) + +_Possible mentors_: + +* Patrick Steinhardt < > +* Jialuo She < > +* Christian Couder < > +* Ghanshyam Thakkar < > + + +### Refactoring in order to reduce Git's global state + +This project focuses on modernizing Git's environment handling by refactoring +the `environment.c` code to reduce global state. The goal is to move environment +variables and configuration from global scope into more appropriate local +contexts, primarily into the `struct repository` / `struct repository_settings` +structure. This architectural improvement will make the codebase more +maintainable and potentially enable better multi-repository handling in the +future. The project involves careful refactoring of Git's core environment +handling code, requiring strong C programming skills and attention to detail. + +The student will identify global variables that can be moved to local scope, +implement the necessary structural changes, and ensure all affected code paths +continue to work correctly. This includes updating tests, fixing any +regressions, and documenting the architectural changes. + +_Expected Project Size_: 90 or 175 hours or 350 hours + +_Difficulty_: Medium + +_Languages_: C, shell(bash) + +_Possible mentors_: + +* Patrick Steinhardt < > +* Karthik Nayak < > +* Jialuo She < > +* Christian Couder < > +* Ghanshyam Thakkar < > + + +### Machine-Readable Repository Information Query Tool + +This project aims to create a new Git command dedicated to querying repository +metadata and configuration in a structured, machine-readable format. Currently, +much of this functionality exists within git-rev-parse(1), which has evolved +beyond its original purpose. The new command will provide a cleaner, more +focused interface for programmatically accessing repository information using +JSON output. + +The student will design and implement this new command, focusing on identifying +what repository information should be exposed, designing a consistent JSON +schema, and implementing the necessary interfaces to Git's internal APIs. Key +challenges include determining which subset of information from git-rev-parse to +expose via this new command, ensuring backward compatibility, and creating a +clean, well-documented command interface that's useful for scripts and tools. + +While this is an exploratory project that hasn't been extensively discussed in +the Git community, it addresses a real need for better programmatic access to +repository information. + +_Expected Project Size_: 175 hours or 350 hours + +_Difficulty_: Medium + +_Languages_: C, shell(bash) + +_Possible mentors_: + +* Patrick Steinhardt < > +* Karthik Nayak < > +* Ghanshyam Thakkar < > + + +### Implement support for reftables in "dumb" HTTP transport + +Fetching Git repositories uses one of two major protocols: + + - The "dumb" protocol works without requiring any kind of + interactive negotiation like a CGI module. It can thus + be served by a static web server. + + - The "smart" protocol works by having the client and + server exchange multiple messages with each other. It is + more efficient, but requires support for Git in the + server. + +While almost all servers nowadays use the "smart" protocol, +there are still some that use the "dumb" protocol. + +The "dumb" protocol cannot serve repositories which use the +"reftable" backend though. While there exists a "info/refs" +file that is supposed to be backend-agnostic, this file does +not contain information about the default branch. Instead, +clients are expected to download the "HEAD" file and derive +the default branch like that. This file is a mere stub in +the "reftable" backend though, which breaks this protocol. + +The goal of this project is to implement "reftable" support +for "dumb" fetches. + +See: + + - + +**Note**: While both ideas are valuable, we prioritize the 'Consolidate ref-related +functionality into git-refs' proposal over support for reftables in "dumb" HTTP transport. If we receive applications for both +projects, preference will be given to applications focusing on the git-refs +consolidation work. + +_Expected Project Size_: 175 hours or 350 hours + +_Difficulty_: Medium + +_Languages_: C, shell(bash) + +_Possible mentors_: +* Patrick Steinhardt < > +* Karthik Nayak < > diff --git a/SoC-2025-Microprojects.md b/SoC-2025-Microprojects.md new file mode 100644 index 0000000000..5a5db49eae --- /dev/null +++ b/SoC-2025-Microprojects.md @@ -0,0 +1,181 @@ +--- +layout: default +title: SoC 2025 Applicant Microprojects +--- + +## Introduction + +First make sure you read and understand +[our general guidelines and suggestions for microprojects](https://git.github.io/General-Microproject-Information). + +There are some suggestions on how you can find some microprojects on your own in the document. + +## Ideas for microprojects + +### Modernize Test Path Checking in Git's Test Suite + +Help improve Git's test suite by converting old-style path checks to use modern +helper functions. We'll be replacing basic shell test commands like `test -f` +with Git's dedicated test helpers like `test_path_is_file`. + +#### Steps to Complete +1. Find a test script using old-style path checks: + ```sh + git grep "test -[efd]" t/ + ``` + +2. Look for patterns like: + ```sh + test -f path/to/file # old way + test_path_is_file path/to/file # new way + + test -d some/directory # old way + test_path_is_dir some/directory # new way + ``` + +3. Important: Only replace checks that are actually testing for conditions, not + those used in flow control. For example: + ```sh + # DON'T change this - it's flow control + if test -e "file.txt"; then + do_something + fi + + # DO change this - it's a test assertion + test -e "file.txt" || error "file.txt should exist" + ``` + +#### Notes +- Start small: Pick a test file with just a few instances to convert +- Run the test suite after your changes to ensure nothing breaks +- Follow Git's commit message style +- Include which command you used to find the instances in your commit message + +#### Need Help? +- Reference [this discussion](https://public-inbox.org/git/CAPig+cRfO8t1tdCL6MB4b9XopF3HkZ==hU83AFZ38b-2zsXDjQ@mail.gmail.com/) + for detailed examples. +- If you can't find any instances to fix, let us know what search command you + used + + +### Add more builtin patterns for userdiff + +"git diff" shows the function name corresponding to each hunk after +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...), +the way to find the function name is built-in Git's source code as +regular expressions (see userdiff.c). A few languages are common +enough to deserve a built-in driver, but are not yet recognized. For +example, shell. + +This project requires a very good knowledge of regular expressions. + +It is easy though to find examples of how this can be done by +searching the code base and the mailing list archive, as this has +already been done for a number of languages. + +### Replace a run_command*() call by direct calls to C functions + +See for example what Junio did in +[ffcb4e94d3](https://github.com/git/git/commit/ffcb4e94d3) (bisect: do +not run show-branch just to show the current commit, 2021-07-27). + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +### Avoid suppressing `git`'s exit code in test scripts + +The Git project uses a large collection of integration tests written in +Shell to guard against regressions when adding new features or fixing +bugs. The scripts in question can be found in the `t` directory +[here][git-t]. + +While it is perfectly OK to use [pipes][wikipedia-pipes] when writing +integration tests, we must be careful to avoid writing a pipeline that +suppresses the exit code of a Git process, like so: + +``` +git | +``` + +...since the exit code of `git ` would be suppressed by the +pipe. If `git ` crashed, we would not catch it in the above +example when running the integration suite. + +Other examples to avoid include: + +``` +# bad: + $(git ) + +# also bad: + <) +EOF +``` + +...since the exit code of `git ` is hidden behind the +subshell in both instances. + +On the other hand, both of the following examples are OK, since neither +hides the exit code of running `git `: + +``` +# good: +var=$(git ) + +# also good: + | | git +``` + +(provided that neither `` or `` are +`git`). + +See the commit +[c6f44e1da5](https://github.com/git/git/commit/c6f44e1da5e88e34) +for example, and then do the same thing in one other test script. + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +[git-t]: https://github.com/git/git/tree/master/t +[wikipedia-pipes]: https://en.wikipedia.org/wiki/Pipeline_(Unix) + +### Use unsigned integral type for collection of bits. + +Pick one field of a structure that (1) is of signed integral type and (2) is +used as a collection of multiple bits. Discuss if there is a good reason +why it has to be a signed integral field and change it to an unsigned +type otherwise. [[thread](https://public-inbox.org/git/xmqqsiebrlez.fsf@gitster.dls.corp.google.com)] + +Even though the amount of code to write is small, these projects +involve a lot of prior work to understand the specification and deal +with all potential corner-cases. + +### Modernize a test script + +A number of our test scripts have been written a long time ago in a +style that is now outdated. + +In the following email it is explained in details how to modernize and +clean up the t7001 test script: + + + +t7001 is not the only test script where similar changes could be made +though. + +Find one test script that needs some of the same changes and make +them. Please make sure that the test script is not already being +worked on by asking on the mailing list before starting to work on it. + +There should be only one kind of change per commit. For example if one +of your commits indents test bodies with TABs, instead of spaces, then +this should be the only kind of change in this commit. + +#### Notes +- only work on `t/t????-*.sh` scripts. +- pick just one script (so as to avoid exhausting the pool for other candidates). +- When converting `test -[def]` to use `test_path_exists()` and cousins + only convert instances which semantically are assertions (i.e. used as part + of a &&-chain). diff --git a/_layouts/default.html b/_layouts/default.html index 05271afeb3..0e1406e3ef 100644 --- a/_layouts/default.html +++ b/_layouts/default.html @@ -7,6 +7,7 @@ + diff --git a/_posts/2015-04-15-edition-2.markdown b/_posts/2015-04-15-edition-2.markdown index 5fe0358011..9ce60b992f 100644 --- a/_posts/2015-04-15-edition-2.markdown +++ b/_posts/2015-04-15-edition-2.markdown @@ -169,7 +169,7 @@ His patch does basically: ``` Duy Nguyen suggested instead to avoid any FILE* interface and either -mmap the entire file, or read (with bufferring) from a file +mmap the entire file, or read (with buffering) from a file descriptor, as Git already does to read the index-pack file. But Peff said that it would be very inefficient too, and that there are no good NUL safe function to read from a file descriptor. diff --git a/_posts/2015-05-13-edition-3.markdown b/_posts/2015-05-13-edition-3.markdown index f5d494ec2e..3a81e27976 100644 --- a/_posts/2015-05-13-edition-3.markdown +++ b/_posts/2015-05-13-edition-3.markdown @@ -56,12 +56,12 @@ colors. When people have finished documenting everything, which is anyway a good thing, then Git commands can be introduced in the context in which they are useful. For example as people are drawing boxes and -arrows on diagrams, they can be teached the `git clone`, `git push` +arrows on diagrams, they can be taught the `git clone`, `git push` and other Git commands that can be associated with the code sharing arrows. Teaching this way makes people 'build' their knowledge, talk to each -other about their workflows and visualy document their use of +other about their workflows and visually document their use of Git. This whole process makes Git more accessible and friendly, which is @@ -141,8 +141,8 @@ Sébastien's work is very welcome. Unfortunately git developers can have different views on how to group commands together. So it can be difficult for them to agree on such -kind of changes. Long discussions because of small personnal -preferences - we call that bikesheedding - can sometimes go on for a +kind of changes. Long discussions because of small personal +preferences - we call that bikeshedding - can sometimes go on for a while. In the case of Sébastien's patch series, many developers helped or got diff --git a/_posts/2015-08-05-edition-6.markdown b/_posts/2015-08-05-edition-6.markdown index bea80587ff..29965bb760 100644 --- a/_posts/2015-08-05-edition-6.markdown +++ b/_posts/2015-08-05-edition-6.markdown @@ -25,7 +25,7 @@ Git 2.5 is out! The project maintainer, Junio C. Hamano, has [shared his thought He goes on to talk about some of his favourite new features included in the release, such as a new short hand `branch@{push}` that "denotes the remote-tracking branch that tracks the branch at the remote the branch would be pushed to", and a new option `--ws-error-highlight` that can be used with `git diff` and friends to show whitespace breakages in deleted and context lines. -Be sure to see the post for more on the new features, or checkout the [release notes in the source](https://github.com/git/git/blob/master/Documentation/RelNotes/2.5.0.txt) for all the nitty gritty details. +Be sure to see the post for more on the new features, or checkout the [release notes in the source](https://github.com/git/git/blob/master/Documentation/RelNotes/2.5.0.adoc) for all the nitty gritty details. ### Did you know? @@ -122,7 +122,7 @@ Then Linus Torvalds explained the situation this way: > an "evil merge" is something that makes changes that came from neither > side and aren't actually resolving a conflict. -Linus then started a discussion about wether the `-p` option in `git +Linus then started a discussion about whether the `-p` option in `git log` should imply `--cc`: > That said, I do wonder if we should just make "-p" imply "--cc". Right diff --git a/_posts/2015-09-09-edition-7.markdown b/_posts/2015-09-09-edition-7.markdown index da15b2d141..9024c85aa4 100644 --- a/_posts/2015-09-09-edition-7.markdown +++ b/_posts/2015-09-09-edition-7.markdown @@ -212,7 +212,7 @@ entries has only two bytes. The limit is then 65535 entries. René then sent a patch series to add tests for this problem and then fix it. The first patch contains the following code, which tests that a suitable `zipinfo` command is available on the current machine, and -sets the ZIPINFO prerequesite if this is the case: +sets the ZIPINFO prerequisite if this is the case: ``` +ZIPINFO=zipinfo diff --git a/_posts/2015-10-14-edition-8.markdown b/_posts/2015-10-14-edition-8.markdown index 539f498648..d9de76ea47 100644 --- a/_posts/2015-10-14-edition-8.markdown +++ b/_posts/2015-10-14-edition-8.markdown @@ -84,7 +84,7 @@ to git/git, and Lars has since posted [a version 2](https://public-inbox.org/git/1443981977-64604-1-git-send-email-larsxschneider%40gmail.com/) and [a version 3 of his patches](https://public-inbox.org/git/1444586102-82557-1-git-send-email-larsxschneider%40gmail.com/), -so an interesting way to test patchs will perhaps be available soon +so an interesting way to test patches will perhaps be available soon to Git developers. @@ -271,7 +271,7 @@ __Git tools and sites__ * [git-nerps](https://github.com/mk-fg/git-nerps) - Tool to encrypt and manage selected files (or parts of files) in a Git repository. See also the [blog post](http://blog.fraggod.net/2015/09/01/transparent-and-easy-encryption-for-files-in-git-repositories.html) by its creator, Mike Kazantsev. * [git-ftp](http://git-ftp.github.io/git-ftp/) - Git powered FTP client written as shell script -* [git-punish](http://git-punish.io/) - more for fun than anything else, this is a shortcut for runnig git blame and posting it's output to [git-punish.io](http://git-punish.io) +* [git-punish](http://git-punish.io/) - more for fun than anything else, this is a shortcut for running git blame and posting it's output to [git-punish.io](http://git-punish.io) * [git:ghost](http://gitghost.org/) - Publish posts to your Ghost blog using git * [Helix GitSwarm](http://www.perforce.com/downloads/helix-gitswarm) - a joint effort between Perforce and GitLab * [Tower's resources for learning Git](http://www.git-tower.com/learn/) - not sure if this is new, but it hasn't been in our newsletter yet. diff --git a/_posts/2016-01-13-edition-11.markdown b/_posts/2016-01-13-edition-11.markdown index 858af32c51..6e0439d34d 100644 --- a/_posts/2016-01-13-edition-11.markdown +++ b/_posts/2016-01-13-edition-11.markdown @@ -38,7 +38,7 @@ and: It's interesting because there has been a lot of work during the past years to develop news ways to store refs. Especially there has been -[attemps to store refs in databases like LMDB](https://public-inbox.org/git/1441245313-11907-1-git-send-email-dturner%40twopensource.com/), that have been covered in +[attempts to store refs in databases like LMDB](https://public-inbox.org/git/1441245313-11907-1-git-send-email-dturner%40twopensource.com/), that have been covered in [Git Rev News edition 7](https://git.github.io/rev_news/2015/09/09/edition-7/). This new approach tries to store refs using git's own object database @@ -52,7 +52,7 @@ Following some comments by Junio, Shawn agreed that his implementation has some hacks to handle "HEAD", which is a special ref, and to handle the fact that gitlinks were made to only point to commits, not tags. -Michael Haggerty wondered if the negociation phase that happens when +Michael Haggerty wondered if the negotiation phase that happens when doing a 'git fetch' could be sped up by such an implementation. This started a discussion between Shawn, Junio and Michael about how the "refs/" hierarchy could be improved. @@ -85,7 +85,7 @@ specific to each worktree and some that are not. There are two pattern lists. One is a default pattern list built into the git binary, and the other one in ".git/info/config.worktree" is a user writable pattern list. Those two pattern lists are merged -internaly to specify which config options are worktree specific. +internally to specify which config options are worktree specific. The worktree specific config options should then be put in ".git/worktrees/NAME/config.worktree" where NAME is a specific @@ -101,7 +101,7 @@ Max Kirillov first suggested the following: > mark repositories which use per-worktree config with an > extension? -Max is refered to the extension mechanism that has been released in +Max is referred to the extension mechanism that has been released in the brand new Git 2.7.0 and that [was mentioned in some places](http://lwn.net/Articles/668163/). diff --git a/_posts/2016-02-10-edition-12.markdown b/_posts/2016-02-10-edition-12.markdown index 0839f8f347..e3c3292ade 100644 --- a/_posts/2016-02-10-edition-12.markdown +++ b/_posts/2016-02-10-edition-12.markdown @@ -97,7 +97,7 @@ Peff also investigated different ways to fix it but concluded: > ever of removing it. and then sent a patch to "drop support for git-over-rsync". This -patch, on top of explaning the above, contains: +patch, on top of explaining the above, contains: > We never made an official deprecation notice in the release > notes for git's rsync protocol, but the tutorial has marked diff --git a/_posts/2016-04-20-edition-14.markdown b/_posts/2016-04-20-edition-14.markdown index d5ff0ecb3c..a61170cb67 100644 --- a/_posts/2016-04-20-edition-14.markdown +++ b/_posts/2016-04-20-edition-14.markdown @@ -97,7 +97,7 @@ must be run manually for now, and running daemons on Windows might require some admin rights. The recently merged effort on improving the untracked cache in the -index was also mentionned. +index was also mentioned. * [Linux Kernel Development - Going Faster Than You Think](https://github.com/gregkh/kernel-development) @@ -129,7 +129,7 @@ This makes the Linux Kernel the largest software project ever. Around 10 000 lines are added, 5300 lines are removed, and 1800 lines are modified, everyday! -That's on average 7.8 changes per hour accross the whole tree with 5% +That's on average 7.8 changes per hour across the whole tree with 5% in the core, 10% in the networking subsystem, and 55% in the drivers. This goes against any previously thought methodology for stable diff --git a/_posts/2016-05-11-edition-15.markdown b/_posts/2016-05-11-edition-15.markdown index 7c12855728..8f2bdf66a2 100644 --- a/_posts/2016-05-11-edition-15.markdown +++ b/_posts/2016-05-11-edition-15.markdown @@ -52,7 +52,7 @@ Another activity is related to defending the license, which is the GPLv2. For example, there have previously been vendors distributing Git with some changes, but without providing the source code for the Git version they were distributing. So far it has been possible to resolve these cases, but -it is not completely clear if all vendors are currently fullfilling all of +it is not completely clear if all vendors are currently fulfilling all of their obligations. If any developers who have contributed to Git want to take a closer look at what the vendors are doing, Conservancy is able to help them. @@ -165,7 +165,7 @@ just after having run `git grep`. This year only one student, Pranit Bauva, will participate in the Google Summer of Code 2016 under the Git project. He will work on -incrementaly rewriting in C the parts of "git bisect" that are still +incrementally rewriting in C the parts of "git bisect" that are still in shell. He will be mentored by Lars Schneider and Christian Couder. ## Developer Spotlight: David Turner @@ -253,7 +253,7 @@ __Various__ * [Fun with a new feature in recent Git](https://git-blame.blogspot.de/2016/05/fun-with-new-feature-in-recent-git.html) by Junio C Hamano * [4200 miles, 5GBs, 1 min: cloning with mirrors and Git LFS](http://blogs.atlassian.com/2016/04/bitbucket-data-center-smart-mirroring-with-git-lfs-support/) from Atlassian's Kelvin Yap * [GitHub: Import repositories with large files](https://github.com/blog/2163-import-repositories-with-large-files), by Jonathan Hoyt -* [Git Tips, Tricks and Workflows](http://www.fullstackradio.com/41) from the Full Stack Radio podcast epsiode 41, featuring Jason McCreary +* [Git Tips, Tricks and Workflows](http://www.fullstackradio.com/41) from the Full Stack Radio podcast episode 41, featuring Jason McCreary * [One Commit. One Change.](https://medium.com/@fagnerbrack/one-commit-one-change-3d10b10cebbf#.1zqmjhd8q) by Fagner Brack * [Fast-Forward and parent reversal](http://dwim.me/2016/01/11/fast-foward-and-parent-reversal.html) by Carlos Martín Nieto * An interesting way of collecting your Git tricks using the [Gingko App](https://gingkoapp.com/git-notes) diff --git a/_posts/2016-07-20-edition-17.markdown b/_posts/2016-07-20-edition-17.markdown index 1121afbb7b..c74e9aac1a 100644 --- a/_posts/2016-07-20-edition-17.markdown +++ b/_posts/2016-07-20-edition-17.markdown @@ -99,7 +99,7 @@ Recently David replied to the above: > real-world work, I am convinced it is a great complementary tool to > git-submodule. It seems odd to me to have one in core and one not. -And David also detailled some of the work he plans to do on `git +And David also detailed some of the work he plans to do on `git subtree`. ### Support @@ -116,7 +116,7 @@ Ovatta Bianca asked: Philip Oakley answered: -> A snaphot is like a tar or zip of all your tracked files. This means it is +> A snapshot is like a tar or zip of all your tracked files. This means it is > easier to determine (compared to lots of diffs) the current content. > > Keeping all the snapshots as separate loose items, when the majority of @@ -240,7 +240,7 @@ One hard problem in Git that would probably need such team of experts for a full year is resumable clone / resumable fetching. It is something that people want to have, but it turns out it is something really hard to implement reasonably. It can be worked around by using git bundles, which hopefully -be automated and standarized; but it is still a workaround, not a solution. +be automated and standardized; but it is still a workaround, not a solution. * If you could remove something from Git without worrying about backwards compatibility, what would it be? diff --git a/_posts/2016-08-17-edition-18.markdown b/_posts/2016-08-17-edition-18.markdown index c8a0652048..a62b4aed3c 100644 --- a/_posts/2016-08-17-edition-18.markdown +++ b/_posts/2016-08-17-edition-18.markdown @@ -229,7 +229,7 @@ __Git tools and sites__ * Gmane (a mailing list archive that was used heavily by some Git developers) [shut down its web site](https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502). This issue was covered in the ["Ingebrigtsen: The End of Gmane?"](https://lwn.net/Articles/695695/) short note on LWN.net, which got included in the ["Announcements" section of LWN.net Weekly Edition for August 4, 2016](http://lwn.net/Articles/695980/); comments there mention that threaded view in Gmane web interface had no equal in other mail archive sites. There is also [Alternatives to mid.gmane.org?](https://public-inbox.org/git/%3C481D1EE2-6A66-418F-AB28-95947BBF3680@gmail.com%3E/) thread, listing among others [MARC.info](https://marc.info/?l=git) and public-inbox. [A note from the maintainer](https://public-inbox.org/git/%3Cxmqq1t1twymf.fsf@gitster.mtv.corp.google.com%3E/) got updated in light of this change. -* [public-inbox](https://public-inbox.org/), which is under heavy developement by Eric Wong, has +* [public-inbox](https://public-inbox.org/), which is under heavy development by Eric Wong, has [a git archive](https://public-inbox.org/git/) that is now used a lot instead of Gmane. [It allows](https://public-inbox.org/design_www.html) looking up existing Gmane links using their Gmane id with URLs like diff --git a/_posts/2016-10-19-edition-20.markdown b/_posts/2016-10-19-edition-20.markdown index 4b61c9ea98..86ee316871 100644 --- a/_posts/2016-10-19-edition-20.markdown +++ b/_posts/2016-10-19-edition-20.markdown @@ -219,7 +219,7 @@ Junio Hamano [reminded](https://public-inbox.org/git/xmqqy42afvy1.fsf@gitster.mt that `contrib/` area is not the place for random git-related things. > Unlike the earlier days of Git, if a custom command that uses Git is -> very userful, it can live its own life and flourish within the much +> very useful, it can live its own life and flourish within the much > larger Git userbase we have these days. The proposed script was then therefore published as diff --git a/_posts/2017-10-11-edition-32.markdown b/_posts/2017-10-11-edition-32.markdown index 846184d862..2ec0779e31 100644 --- a/_posts/2017-10-11-edition-32.markdown +++ b/_posts/2017-10-11-edition-32.markdown @@ -345,7 +345,7 @@ have. It would be as if the worktree was partitioned into separate using submodule commit hashes. Importantly, it should be possible for the user's local server repo (is there a word for this 'on-server personal fork'?) to also be a narrow clone, as distinct from the -golden server which would alway a full width, and able to serve narrow +golden server which would always a full width, and able to serve narrow packs. The other aspect of Git would be to include practical user examples on diff --git a/_posts/2017-11-22-edition-33.markdown b/_posts/2017-11-22-edition-33.markdown index 298083b161..080eb06e4c 100644 --- a/_posts/2017-11-22-edition-33.markdown +++ b/_posts/2017-11-22-edition-33.markdown @@ -89,7 +89,7 @@ Jonathan Nieder answered: > want to switch to LF endings, in which case I suggest the "single > fixup commit" strategy. -He suggested though to declare explicitely all the files as non text +He suggested though to declare explicitly all the files as non text files in `.gitattributes` using the `-text` flag, so that Git will not be tempted to change line endings. diff --git a/_posts/2017-12-20-edition-34.markdown b/_posts/2017-12-20-edition-34.markdown index ee4c0a9197..acff8d432d 100644 --- a/_posts/2017-12-20-edition-34.markdown +++ b/_posts/2017-12-20-edition-34.markdown @@ -310,7 +310,7 @@ __Various__ * [Git Essentials, 2nd Edition](https://www.packtpub.com/application-development/git-essentials-second-edition) * [Git: Version Control for Everyone](https://www.packtpub.com/application-development/git-version-control-everyone) (which was [reviewed](https://git-blame.blogspot.com/2013/02/git-version-control-for-everyone.html) by Junio C Hamano on his blog) * [Discussions on Hacker News](https://news.ycombinator.com/item?id=15819033) - about [the hash transition plan](https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt). + about [the hash transition plan](https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.adoc). * [Protecting code integrity with PGP](https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md) (beta), part of Useful IT Policies project * [Effortlessly maintain a high quality change log with Git notes](https://harrow.io/blog/effortlessly-maintain-a-high-quality-change-log-with-little-known-git-tricks/) by Lee Hambley diff --git a/_posts/2018-03-21-edition-37.markdown b/_posts/2018-03-21-edition-37.markdown index 3b5ba0edea..4b59ec3333 100644 --- a/_posts/2018-03-21-edition-37.markdown +++ b/_posts/2018-03-21-edition-37.markdown @@ -101,7 +101,7 @@ similar as Dscho's alternative strategy. Phillip suggested using In a subsequent email replying to himself Dscho elaborated on a possible new subcommand. He proposed -`git rebase --replay-latest-commits 3` and a sightly different way to +`git rebase --replay-latest-commits 3` and a slightly different way to copy commits to the git-rebase-todo file so that it contains commits with resolved merge conflicts. diff --git a/_posts/2018-04-18-edition-38.markdown b/_posts/2018-04-18-edition-38.markdown index bee7863d5f..8289698a52 100644 --- a/_posts/2018-04-18-edition-38.markdown +++ b/_posts/2018-04-18-edition-38.markdown @@ -338,7 +338,7 @@ __Git tools and sites__ + [Guiffy](https://www.guiffy.com/), the advanced cross-platform diff/merge + [gitworkflow repository](https://github.com/rocketraman/gitworkflow) is a documentation repository for [gitworkflows](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/gitworkflows.html): see [How the Creators of Git do Branching](https://hackernoon.com/how-the-creators-of-git-do-branches-e6fcc57270fb), by Raman Gupta (mentioned in [Git Rev News Edition 27](https://git.github.io/rev_news/2017/05/17/edition-27/)) -+ [git-immersion](https://github.com/jce-il/git-immersion) repository for [git-immersion excercise](http://jce-il.github.io/git-immersion/index.html) guided tour ++ [git-immersion](https://github.com/jce-il/git-immersion) repository for [git-immersion exercise](http://jce-il.github.io/git-immersion/index.html) guided tour + [commit -> public-inbox link helper](https://public-inbox.org/git/nycvar.QRO.7.76.6.1804041821420.55@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz/) script by Johannes Schindelin was posted on git mailing list + [kaizenboard](https://kaizenboard.xyz/#/) - GitHub issues on a Kanban board diff --git a/_posts/2018-05-16-edition-39.markdown b/_posts/2018-05-16-edition-39.markdown index a58d63adaa..194bf450bc 100644 --- a/_posts/2018-05-16-edition-39.markdown +++ b/_posts/2018-05-16-edition-39.markdown @@ -323,7 +323,7 @@ __Git tools and sites__ [CLI tool called microplane](https://github.com/Clever/microplane) they developed to make changes across many repos. * [Some mutt(1) patches and scripts](https://public-inbox.org/git/20180422205859.GA16261@syl.local/T/#u) by Taylor Blau, posted on Git mailing list. * [Gitwin - Git Server for Windows](https://itefix.net/gitwin), a packaging of Git, OpenSSH, Nginx and many other related tools to make it a ready-to-use solution as a secure Git repository on Windows. -* [git-vanity-sha](https://github.com/mattbaker/git-vanity-sha) will try to tweak the commiter timestamp to produce vanity hex prefix for commit SHA; it is similar in function to [git-sham](https://bitbucket.org/tpettersen/git-sham) which does it and more by appending different random series of three emojis, and which was covered in [Git Rev News Edition 4](https://git.github.io/rev_news/2015/06/03/edition-4/). +* [git-vanity-sha](https://github.com/mattbaker/git-vanity-sha) will try to tweak the committer timestamp to produce vanity hex prefix for commit SHA; it is similar in function to [git-sham](https://bitbucket.org/tpettersen/git-sham) which does it and more by appending different random series of three emojis, and which was covered in [Git Rev News Edition 4](https://git.github.io/rev_news/2015/06/03/edition-4/). * [git-shame](https://github.com/drench/git-shame) finds out to blame for stale remote branches. * [Tugboat](https://tugboat.qa/) is a service allowing you to generate preview of your working website for every pull request, tag or branch and share it (and see visual regressions). Works with GitHub, Bitbucket, and Gitlab. * [git-driven-refactoring](https://github.com/bdpalladino/git-driven-refactoring) -- sample code for "Git Driven Refactoring" presentation by Ashley Ellis Pierce at [RubyConf 2017](https://www.youtube.com/watch?v=3OgbQOsW61Y), [GitHub Universe 2017](https://www.youtube.com/watch?v=rK8yHl0cHoc) and [Git Merge 2018](https://www.youtube.com/watch?v=e9K1gHYIE2c&list=PL0lo9MOBetEGIifU90rTn5zQaX5NibX08&index=6). diff --git a/_posts/2018-06-20-edition-40.markdown b/_posts/2018-06-20-edition-40.markdown index 860ae0e4d0..0c6e7870a7 100644 --- a/_posts/2018-06-20-edition-40.markdown +++ b/_posts/2018-06-20-edition-40.markdown @@ -129,7 +129,7 @@ Ondrej listed commands using `cd src && git status` to reproduce the issue which is that "`git status` reports as if all files in the repository are deleted". -As noone had replied, Ondrej asked on May 27th if anyone had time to +As no one had replied, Ondrej asked on May 27th if anyone had time to look at this. Philip Oakley replied to Ondrej asking for more information about the diff --git a/_posts/2018-07-18-edition-41.markdown b/_posts/2018-07-18-edition-41.markdown index 543c5451b9..a06aecaefa 100644 --- a/_posts/2018-07-18-edition-41.markdown +++ b/_posts/2018-07-18-edition-41.markdown @@ -36,7 +36,7 @@ With Brian's latest patches Git would work using NewHash, including passing the test suite, though it would be incompatible with current Git. -As the [hash function transition plan](https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt) +As the [hash function transition plan](https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.adoc) tells that a Git using NewHash should be able to communicate through fetching and pushing with a Git using SHA-1, the next step is to implement such kind of communication and that's what Brian started to @@ -139,7 +139,7 @@ __Various__ - [Supercharging the Git Commit Graph III: Generations and Graph Algorithms](https://blogs.msdn.microsoft.com/devops/2018/07/09/supercharging-the-git-commit-graph-iii-generations/) - [Supercharing the Git Commit Graph IV: Bloom Filters](https://blogs.msdn.microsoft.com/devops/2018/07/16/super-charging-the-git-commit-graph-iv-bloom-filters/) -* Echoes of Microsoft acquring GitHub (see [Git RevNews Edition #40](https://git.github.io/rev_news/2018/06/20/edition-40/)) +* Echoes of Microsoft acquiring GitHub (see [Git RevNews Edition #40](https://git.github.io/rev_news/2018/06/20/edition-40/)) - [Microsoft Buys GitHub: Three Weeks Later](https://www.linuxjournal.com/content/microsoft-buys-github-three-weeks-later) by Marcel Gagné - [Opinion: GitHub vs GitLab](https://www.linuxjournal.com/content/opinion-github-vs-gitlab) by Matt Lee (with a bit of history) diff --git a/_posts/2018-08-22-edition-42.markdown b/_posts/2018-08-22-edition-42.markdown index 6b23618c54..a1c955e740 100644 --- a/_posts/2018-08-22-edition-42.markdown +++ b/_posts/2018-08-22-edition-42.markdown @@ -25,7 +25,7 @@ This edition covers what happened during the month of July 2018. discussed the state of NewHash work, i.e. the process of selecting Git's next-generation hash function. [This discussion has concluded](https://public-inbox.org/git/20180724190136.GA5@0f3cdde9c159/) with the selection of SHA-256. An -[update to `hash-function-transition.txt` to change `NewHash` to `SHA-256`](https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt) +[update to `hash-function-transition.txt` to change `NewHash` to `SHA-256`](https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.adoc) is queued in the `next` branch. + ++ [[ANNOUNCE] Virtual Contributor's Summit 2023](https://public-inbox.org/git/ZMATKIaU1A1D0wJg@nand.local/) + + Taylor Blau from GitHub announced that GitHub will host a Virtual + Contributor's Summit this year. Previously he + [announced](https://lore.kernel.org/git/ZJoDjnr+FkgrDsKA@nand.local/) + that there would be no Git Merge in-person event this year. + + The announce of the Virtual Contributor's Summit 2023 contained + links for participants to register, to suggest topics and to vote on + proposed topics. ### Reviews @@ -92,8 +101,8 @@ This edition covers what happened during the months of June 2023 and July 2023. Trace2 code wouldn't be in `git-std-lib.a`. They pointed out that it should be possible to use the Trace2 tracing functions everywhere in the Git code, even in low-level functions. Calvin replied that he - would look into possible solutions like redrawing the boundaries of the library or stubbing - out tracing in it to accommodate that need. + would look into possible solutions like redrawing the boundaries of + the library or stubbing out tracing in it to accommodate that need. Phillip Wood commented on a few patches saying he liked the idea, but suggested that the library should also contain the code related @@ -307,9 +316,6 @@ __Light reading__ by Pradumna Saraf on DEV\.to - though the guide is limited to simple aliases, and does not cover forcing an alias to be treated as a shell command, or tricks that one can use for advanced handling of alias parameters. -+ [The Magic of Empty Git Commit](https://dev.to/pradumnasaraf/the-magic-of-empty-git-commit-1di4) - by Pradumna Saraf on DEV\.to - a simple description on how to create - an empty commit, and why one would might want one. + [.gitattributes Best Practices](https://rehansaeed.com/gitattributes-best-practices/) by Muhammad Rehan Saeed on his blog (2020). + [The Power of Git: A Guide to Collaborative Version Control](https://dev.to/opensauced/the-power-of-git-a-guide-to-collaborative-version-control-dl6) @@ -322,9 +328,10 @@ __Light reading__ by Sage Sharp on their blog (2014). - +__Easy listening__ ++ [Git with Derrick Stolee](https://podrocket.logrocket.com/git-scalar) + on PodRocket (a web development podcast from LogRocket). + __Git tools and sites__ + [Emoji-Log](https://github.com/ahmadawais/Emoji-Log) — A simple Emoji Git commit log messages spec standard. @@ -399,4 +406,6 @@ Christian Couder <>, Jakub Narębski <>, Markus Jansen <> and Kaartic Sivaraam <> -with help from Eren Canpolat and Bruno Brito. +with help from Eren Canpolat, Bruno Brito, +Kristoffer Haugsbakk, Junio Hamano and +Štěpán Němec. diff --git a/_posts/2023-08-31-edition-102.markdown b/_posts/2023-08-31-edition-102.markdown new file mode 100644 index 0000000000..9990a64576 --- /dev/null +++ b/_posts/2023-08-31-edition-102.markdown @@ -0,0 +1,446 @@ +--- +title: Git Rev News Edition 102 (August 31st, 2023) +layout: default +date: 2023-08-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 102 (August 31st, 2023) + +Welcome to the 102nd 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 July 2023 and August 2023. + +## Discussions + + + + + +### Support + ++ [Git Privacy](https://public-inbox.org/git/CTZ9RD9RQ5UO.3OIJX50PKMIR0@anonymous/) + + Nick, alias Nicholas Johnson, asked on the Git mailing list if it + would be possible to implement an integrated feature in Git, perhaps + a config option, to obfuscate the committer and author timestamps + that are stored in commits when they are created. + + Nick is the creator of [Git Privacy](https://git.nicholasjohnson.ch/git-privacy/) + which is a repository containing + [instructions in a README.md file](https://git.nicholasjohnson.ch/git-privacy/tree/README.md) + that already helps developers obfuscate Git timestamps, and also + explains why it can be a good idea to do so. + + The instructions suggest setting the `GIT_AUTHOR_DATE` and + `GIT_COMMITTER_DATE` environment variables when committing, so that + the timestamps in these variables are recorded instead of the + current date, time and timezone. + + Nick thought that using such environment variables or other not + fully integrated mechanisms like Git hooks was too cumbersome and + asked for ideas or feedback about how to improve the situation. + + Junio Hamano, the Git maintainer, replied to Nick, saying that his + opinion was that it might not be worth implementing an integrated + feature, as using such a feature removed "half the value of keeping + your work in [a] source code management system". Especially it would + make it harder to refute possible claims that the source code + contained stolen proprietary IP (Intellectual Property). + + Nick replied that he conceded it might not be worth it to implement + his original suggestion. He said that having Git automatically + converting local time to UTC in the timestamps it records could still + be useful to avoid leaking the developer's time zone. He pointed to + [a Gerrit issue](https://git.issues.gerritcodereview.com/issues/40000039) + about this. + + Junio replied that he still thought it wasn't worth the effort as + there was not enough reason to go against Git's initial design to + store the timezone. + + Nick replied to Junio saying that storing the timezone revealed + private information about developers without much gain, and that a + config option could let users decide about doing this or not. + + This led to a separate sub-thread where Nick and Jason Pyeron + started to design a `--privacy=option1,option2` with corresponding + config variables to change the timezone, specify a date precision, + etc. brian m. carlson said he would support timezone and timestamp + tweaking options and made some technical suggestions too. + + René Scharfe chimed in on the main thread saying that + "timezone and timestamps are personal data, which may only be + collected and processed for a lawful purpose according to the GDPR", + referring to the European Union's + [General Data Protection Regulation](https://gdpr-info.eu/). + So he thought that the user should be able to control if that data + should be stored or not, and it was a usability issue if he could + not easily do that. He also noticed that `git commit` already has a + `--date=` option to change the author date and a `--signoff` + option for adding `Signed-off-by: Author Name ` + trailers. He concluded by saying "adding config options for + controlling timestamp granularity is hard to say no to". + + Nick replied that he was asking for this feature for moral reasons + not for legal ones. He took the example of the + [I2P project](https://geti2p.net/en/) which is a layer on top of + Internet to protect people's activity and location, saying that most + developers of the project don't want their timezones leaked as they + are known only under pseudonyms. + + Junio replied to René saying that the `--date=` option had + good reasons to exist. For example, the committer might be relaying + somebody else's changes, or a system clock might have an issue. He + also thought that the existing two environment variables are the + right place to draw the line, as Git developers shouldn't be + pretending to be security engineers and invent their own time + obfuscating mechanisms. + + In another email, Junio explained in more detail why it's more + important to be able to tweak the author timestamp than the + committer timestamp. He also repeated that two environment variables + were a good place for other security minded people to build on a + quality "privacy enhancing `date` command" that could also be used + outside the Git context. + + Junio replied to himself saying that a "--useless-time" option, or a + "core.uselesstime" configuration variable to make timestamps only + use UTC and be otherwise nearly meaningless could be OK though, as + they wouldn't have "privacy" in their name and wouldn't pretend to be + a quality privacy feature. He laid out how such a feature could + work, and noticed that features like `git log --since=...` wouldn't + then be expected to properly work. + + Nick agreed that such a feature shouldn't use "privacy" in its name, + and said that Junio's proposed feature would satisfy the privacy use + case he was interested in, and that he didn't want more than that. + + Theodore Ts'o then chimed in to point out that "someone still might + be able to figure out information from when a branch gets pushed to + a git repo". He mentioned that for example GitHub, GitHub actions + and integration systems could also leak information about when users + are active. + + Nick replied to Ted saying that protecting privacy had to start + somewhere, even if not all the tools were already doing it. + + Future will tell if someone will actually implement something along + the lines that have been discussed, and whether it will be a + "privacy enhancing `date` command" usable outside the Git context, + or an option integrated into Git. + +## Developer Spotlight: Calvin Wan + +* Who are you and what do you do? + + My name is Calvin Wan and I'm a Software Engineer on the Git Core team + at Google. + + I also enjoy playing poker, volleyball, and ping pong. I play the + World Series of Poker Main Event every year and one of these years I'm + hoping to make the final table 😄 + +* What would you name your most important contribution to Git? + + I'm hoping my in-flight [series for a Git Standard Library](https://public-inbox.org/git/20230810163346.274132-1-calvinwan@google.com/) + will become my most important contribution to Git...at least for now 😄 + +* What are you doing on the Git project these days, and why? + + Currently working on getting Git Standard Library merged -- to + summarize it will serve as the foundation for other libraries in Git + to be built off of. When we first embarked on this journey towards + libification, we had many reasons for doing so, most of which Emily + captured in the [initial proposal](https://lore.kernel.org/git/CAJoAoZ=Cig_kLocxKGax31sU7Xe4==BGzC__Bg2_pr7krNq6MA@mail.gmail.com/). + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + Old style submodules. Submodule development is already difficult to + work on, and having extra bits and pieces in the codebase that exist + for the sole purpose of not breaking old style submodules added an + extra layer of complexity I wish I didn't have to reason about. + +* Do you happen to have any memorable experience w.r.t. contributing to + the Git project? If yes, could you share it with us? + + Attending Git Merge 2022! I enjoyed meeting the people I had been + interacting with on list -- putting a face to the name was + particularly exciting. I also enjoyed the discussions at the + Contributor Summit and the talks that followed. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + I develop using VSCode and send my patches with `git format-patch` and + `git send-email`. For patches upstream, I use `b4 am` + `git am` to + test locally. When I reply to patches I use a script I modified from + Jonathan Tan to set up the replies for `git send-email`. For simple + replies and emails, I use Gmail's plaintext mode. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + I think there are plenty of good resources out there that others have + probably mentioned before ([Pro Git book](https://git-scm.com/book/en/v2), + [MyFirstContribution](https://git-scm.com/docs/MyFirstContribution), + [git-mentoring list](https://groups.google.com/g/git-mentoring/about)), + but the one suggestion I would have is spend less time worrying about + getting the right setup and spend more time getting your patches to list! + + +## Other News + +__Various__ ++ [Highlights from Git 2.42](https://github.blog/2023-08-21-highlights-from-git-2-42/) + by Taylor Blau on GitHub Blog. Those include + faster object traversals with reachability bitmaps, + excluding references by pattern in `git for-each-ref`, + preserving precious objects from garbage collection via `gc.recentObjectsHook`, + and other changes. ++ [Git 2.42 Released With Less Warnings For SHA-256 Usage](https://www.phoronix.com/news/Git-2.42-Released) + by Michael Larabel on Phoronix. ++ [GitLab Gitaly project now supports the SHA-256 hashing algorithm](https://about.gitlab.com/blog/2023/08/28/sha256-support-in-gitaly/) + by John Cai on GitLab Blog. + + [Gitaly](https://gitlab.com/gitlab-org/gitaly) is + an RPC interface to Git used by GitLab, + first mentioned in [Git Rev News Edition #24](https://git.github.io/rev_news/2017/02/22/edition-24/). ++ [Sourceware 25 Roadmap](https://sourceware.org/sourceware-25-roadmap.html): + roadmap for the next 25 years on \[almost] the 25th anniversary + (Sourceware came online on 6 September 1998). + + [Sourceware](https://sourceware.org/) service was first mentioned in + [Git Rev News Edition #88](https://git.github.io/rev_news/2022/06/30/edition-88/). ++ [Lazygit Turns 5: Musings on Git, TUIs, and Open Source](https://jesseduffield.com/Lazygit-5-Years-On/) + by Jesse Duffield on his Pursuit Of Laziness blog. + + [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/); + you can find links to other articles about this tool in [Edition #61](https://git.github.io/rev_news/2020/03/25/edition-61/) + and [#81](https://git.github.io/rev_news/2021/11/29/edition-81/). + + +__Light reading__ ++ [7 Git Mistakes a Developer Should Avoid](https://www.git-tower.com/blog/7-git-mistakes-a-developer-should-avoid/) + by Bruno Brito on Tower Blog, describing why some habits -- + committing unrelated changes together, + writing bad commit messages, + not using `.gitignore`, + leaving outdated merged-in branches, + using force push in a shared repository, + storing API keys and other secrets in a repository, + and storing large binary files -- + cause problems, and how to prevent them + (often how to do it with the help of the Tower Git client). ++ [Simplified: 8 Guidelines for Commit Message](https://dev.to/titusnjuguna/simplified-8-guidelines-for-commit-message-536g) + by Tito (titusnjuguna) on DEV\.to. ++ [Security in Code Reviews: Ensuring Secure and Robust Software Development](https://dev.to/documatic/security-in-code-reviews-ensuring-secure-and-robust-software-development-17kp) + by Jatin Sharma for Documatic, lists some common security vulnerabilities, + presents a few examples of real-world incidents, and explains how to + incorporate security into the code review process (and what the challenges are). ++ [One Git Trick for Perfect Commits](https://0ro.github.io/posts/one-git-trick-for-perfect-commits/) + by Raman Nikitsenka (0ro) on his blog (and [also on DEV\.to](https://dev.to/0ro/one-git-trick-for-perfect-commits-3728)). + The trick to avoid "fix: ..." commits littering history + is to use `git commit --fixup` and `git rebase --interactive --autosquash` + (before submitting changes). ++ [Git Config Articles: Pragmatic Suggestions for Customizing Your Git Setup from Karl Stolley](https://medium.com/pragmatic-programmers/git-config-articles-beec83c82b91) + by Margaret Eldridge in The Pragmatic Programmers on Medium. + It is a list of Git Config articles written by [Karl Stolley](https://medium.com/u/b6139288f4b6) + for The Pragmatic Programmers. ++ [Simplify Your Workflow 📈: A Guide to Standardizing Commit Messages with Husky 🐶 in Monorepos 📦](https://dev.to/harithzainudin/simplify-your-workflow-a-guide-to-standardizing-commit-messages-with-husky-in-monorepos-542l) + by Muhammad Harith Zainudin on DEV\.to. + + [Husky](https://github.com/typicode/husky), a Git hook management tool, was first mentioned in + [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/); + you can find links to other articles talking about it in + [#87](https://git.github.io/rev_news/2022/05/26/edition-87/) and + [#89](https://git.github.io/rev_news/2022/07/31/edition-89/). + + The idea of Monorepos (using a single repository for the whole codebase) + was first mentioned in [Git Rev News Edition #4](https://git.github.io/rev_news/2015/06/03/edition-4/). + You can find links to articles advocating for and against monorepos + in [Git Rev News Edition #47](https://git.github.io/rev_news/2019/01/23/edition-47/), + and a list of pros and cons of monorepos in + [Edition #81](https://git.github.io/rev_news/2021/11/29/edition-81/). + [Monorepo.tools](https://monorepo.tools/) is a place where you can find + information about monorepos and tools for handling them + (this site was first mentioned in [Git Rev News Edition #84](https://git.github.io/rev_news/2022/02/28/edition-84/)). ++ [You won’t believe how much time you will save with this Git pre-push hook](https://www.ivanmorgillo.com/2023/07/23/you-wont-believe-how-much-time-you-will-save-with-this-git-pre-push-hook/) + by Ivan Morgillo on his blog, + about integrating [Git hooks](https://git-scm.com/docs/githooks) with static code analysis tools, + such as [Detekt](https://detekt.dev/) (a static code analyzer for Kotlin), + for Android projects. ++ [Git advanced (text) diff: .odt, .pdf, .doc, .xls, .ppt](https://medium.com/@mbrehin/git-advanced-diff-odt-pdf-doc-xls-ppt-25afbf4f1105) + by Maxime Bréhin on Medium (2016) + describes how to configure [`textconv` gitattribute](https://www.git-scm.com/docs/gitattributes#_performing_text_diffs_of_binary_files) + for those files. ++ [IAMbic: Bridging the Gap Between IAM (Identity and Access Management) Changes and Version Control](https://www.noq.dev/blog/iambic-bridging-the-gap-between-iam-changes-and-version-control) + by Curtis Castrapel on Noq company blog. IAMbic detects IAM changes, + whether you're using Terraform, Cloudformation, + or directly making changes via the AWS Management Console, + and creates Git commits to represent the exact state of your IAM + in a Git repository. ++ [Delta: A new git diff tool to rock your productivity](https://dev.to/cloudx/delta-a-new-git-diff-tool-to-rock-your-productivity-2773) + by Axel Navarro for Cloud(x); on DEV\.to + (posted on 16 Jul 2020, updated on 22 May 2022). + + [Delta](https://dandavison.github.io/delta/), + a syntax-highlighting pager for git, diff, and grep output, + was first mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/). + ++ [Git Files Hidden In Plain Sight 🫥](https://tylercipriani.com/blog/2023/07/31/git-files-hidden-in-plain-sight/) + by Tyler Cipriani on his blog, + about some wonderful bad ideas, + like storing data in a repository in a way that GitHub thinks it is empty. + + +__Easy watching__ ++ [Git Hidden Gems - Enrico Campidoglio - NDC Oslo 2023](https://www.youtube.com/watch?v=WtUCZYyv-_w) + (length: 59:11).
Talks about + [04:15](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=255s) pretty logs, + [08:23](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=503s) pretty diffs, + [10:24](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=624s) staging, + [18:57](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=1137s) searching, + [22:27](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=1347s) automation, + [28:48](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=1728s) dot notation, + [33:20](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=2000s) rebase onto, + [38:24](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=2304s) reflog, and + [45:44](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=2744s) rerere. ++ [Pijul: Version-Control Post-Git • Pierre-Étienne Meunier • GOTO 2023](https://www.youtube.com/watch?v=7MpdZkGj5AI): + the presentation recorded at GOTO Aarhus 2023 (length: 50:10).
+ [Pijul](https://pijul.org/) was first mentioned in + [Git Rev News Edition #9](https://git.github.io/rev_news/2015/11/11/edition-9/). + + +__Git tools and sites__ ++ [Git Tag Ops](https://github.com/iterative/gto) by Iterative\.AI + turns your Git repository into an Artifact Registry. + Together with [DVC](https://dvc.org/) (Data Version Control), + GTO serves as a backbone for Git-based [Iterative Studio Model Registry](https://dvc.org/doc/studio/user-guide/model-registry/what-is-a-model-registry). + GTO works by creating annotated Git tags in a standard format. + Written in Python. + + [DVC](https://dvc.org/) and GitOps were first mentioned in + [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/). ++ [Turtle](https://gitlab.gnome.org/philippun1/turtle) + is a graphical interface for version control intended to run on GNOME and the Nautilus file manager. + Written in Python using GTK4 and libadwaita for the GUI, + and [pygit2](https://www.pygit2.org/) for interacting with Git, + with Nautilus plugin support. + + See [TortoiseGit](https://tortoisegit.org/), + Windows Shell interface to Git, + providing overlay icons showing the file status, + and a powerful context menu for Git in a file manager. + Tracked since [Git Rev News Edition #57](https://git.github.io/rev_news/2019/11/20/edition-57/#releases). + + _Turtles_, _tortoises_, and _terrapins_ are common names + used for animals from a taxonomical order of reptiles named Testudines. ++ [Commit](https://github.com/m1guelpf/commit) + is a command palette-style Git client for blazing-fast commits. + You open it with a keyboard shortcut, write your commit, + and Commit will automatically detect which repo you've been working on. + Written using the [Tauri](https://tauri.app/) toolkit + in TypeScript and Node.js for UI, and Rust for the backend. + Inspired by [TailwindUI's Commit template](https://tailwindui.com/templates/commit). ++ [GitButler](https://docs.gitbutler.com/) (currently in _alpha_ phase) + is intended to be a Source Code Management system designed to manage your branches, + record and backup your work, be your Git client, help with your code, etc.; + focusing on everything after writing code in your editor and before sharing it on GitHub. ++ [GQL](https://amrdeveloper.github.io/GQL/) (Git Query Language) + is a query language with a syntax very similar to SQL, + with a tiny engine to perform queries on Git repositories + on the fly without the need to create database files + or convert `.git` files into any other format. + Written in Rust. + + [Gitana](https://github.com/SOM-Research/Gitana), + [first mentioned](https://livablesoftware.com/gitana-sql-git-repository-inspector/) + in [Git Rev News Edition #7](https://git.github.io/rev_news/2015/09/09/edition-7/), + exports the data contained in one or more Git repositories to a relational database, + relying on an incremental propagation mechanism that refreshes the database content + with the latest modifications in Git repositories. + Gitana has been archived in September 2022 and is not maintained anymore. + Written in Python. + + [gitbase](https://github.com/src-d/gitbase), + [first mentioned](https://www.youtube.com/watch?v=f_G1vwynxTg) + in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/), + is a SQL database interface to Git repositories (on the fly), + implementing the MySQL wire protocol. + It can be used to perform SQL queries about the Git history + and about the Universal AST (Abstract Syntax Tree) of the code itself. + Was a part of now defunct [source{d} Community Edition](https://sourced.tech/products/community-edition/), + still in _alpha_ phase. + Written in Go. + + [MergeStat](https://github.com/mergestat/mergestat) ([demo](https://www.mergestat.com/demo)) + enables SQL queries for data in Git repositories (and related sources, such as the GitHub API). + It allows you to ask questions about the history and contents of your source code. + Written in TypeScript, can use Docker Compose to run locally.
+ [mergestat-lite](https://github.com/mergestat/mergestat-lite) + is a command-line version of the tool, which runs SQL queries against local git repositories. + Written in Go.
+ MergeStat was included in _"SQL for querying Git repos"_ tools list + in [Git Rev News Edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/). + + [World of Code](https://worldofcode.org/) + is an infrastructure for study of software supply chains, + utilizing Tokyo Cabinet, custom binary storage, MongoDB, and Clickhouse + to store data, and which provides shell API + and (limited) Python API for querying data + from 173 million Git repositories on their infrastructure. + Described in an [article on arXiv from 2020](https://arxiv.org/abs/2010.16196). ++ [git-com](https://github.com/masukomi/masuconfigs/blob/master/bin/git-scripts/git-com) + by masukomi is an interactive CLI tool to help you create commit messages + that are not only readable, but follow a standardized format. + Described in [this Mastodon thread](https://fosstodon.org/@masukomi@connectified.com/110808660504633258). + Written in Bash. ++ [git-identity](https://github.com/cookiengineer/git-identity) (in Go) and + [GitID](https://github.com/InderdeepBajwa/gitid) (in TypeScript, uses Node.js) + are both tools that provide a convenient command-line interface + to manage and switch between multiple identities on a single user account. + + +## Releases + ++ Git [2.42.0](https://public-inbox.org/git/xmqqr0nwp8mv.fsf@gitster.g/), +[2.42.0-rc2](https://public-inbox.org/git/xmqqwmxwgfvr.fsf@gitster.g/), +[2.42.0-rc1](https://public-inbox.org/git/xmqqpm3ug824.fsf@gitster.g/), +[2.42.0-rc0](https://public-inbox.org/git/xmqq5y5uli4t.fsf@gitster.g/) ++ Git for Windows [2.42.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.42.0.windows.1), +[2.42.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.42.0-rc2.windows.1), +[2.42.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.42.0-rc1.windows.1), +[2.42.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.42.0-rc0.windows.1) ++ libgit2 [1.7.1](https://github.com/libgit2/libgit2/releases/tag/v1.7.1) ++ Bitbucket Server [8.13](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitHub Enterprise [3.9.4](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.4), +[3.8.9](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.9), +[3.7.16](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.16), +[3.6.18](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.18), +[3.9.3](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.3), +[3.8.8](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.8), +[3.7.15](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.15), +[3.6.17](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.17), +[3.10.0](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.0) ++ GitLab [16.3](https://about.gitlab.com/releases/2023/08/22/gitlab-16-3-released/) +[16.2.4](https://about.gitlab.com/releases/2023/08/11/gitlab-16-2-4-released/), +[16.1.4](https://about.gitlab.com/releases/2023/08/03/gitlab-16-1-4-released/), +[16.2.3](https://about.gitlab.com/releases/2023/08/03/gitlab-16-2-3-released/), +[16.2.2, 16.1.3, and 16.0.8](https://about.gitlab.com/releases/2023/08/01/security-release-gitlab-16-2-2-released/) ++ GitKraken [9.7.1](https://help.gitkraken.com/gitkraken-client/current/), +[9.7.0](https://help.gitkraken.com/gitkraken-client/current/), +[9.6.1](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.2.9](https://desktop.github.com/release-notes/), +[3.2.8](https://desktop.github.com/release-notes/) ++ git-credential-azure [0.2.2](https://github.com/hickford/git-credential-azure/releases/tag/v0.2.2), +[0.2.1](https://github.com/hickford/git-credential-azure/releases/tag/v0.2.1), +[0.2.0](https://github.com/hickford/git-credential-azure/releases/tag/v0.2.0), +[0.1.0](https://github.com/hickford/git-credential-azure/releases/tag/v0.1.0) ++ git-credential-oauth [0.10.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.10.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Calvin Wan and Štěpán Němec. diff --git a/_posts/2023-09-30-edition-103.markdown b/_posts/2023-09-30-edition-103.markdown new file mode 100644 index 0000000000..bc4a44083f --- /dev/null +++ b/_posts/2023-09-30-edition-103.markdown @@ -0,0 +1,278 @@ +--- +title: Git Rev News Edition 103 (September 30th, 2023) +layout: default +date: 2023-09-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 103 (September 30th, 2023) + +Welcome to the 103rd 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 2023 and September 2023. + +## Discussions + +### General + +* [Git participated in GSoC (Google Summer of Code) 2023](https://summerofcode.withgoogle.com/programs/2023/organizations/git) + + The following contributors have successfully passed their final + evaluation and published a final report: + + - Shuqi Liang worked on the + [More Sparse Index Integrations](https://summerofcode.withgoogle.com/programs/2023/projects/Rkbc1Abe) + project. She was mentored by Victoria Dye. The final + report can be found on [her website](https://cheskaqiqi.github.io/2023/08/22/Final/). + + - Kousik Sanagavarapu worked on the + [Unify ref-filter formats with other --pretty formats](https://summerofcode.withgoogle.com/programs/2023/projects/rck3kmq2) + project. He was co-mentored by Christian Couder and Hariom Verma. + The final report can be found on [his website](https://five-sh.github.io/2023/08/26/the-final-report). + + Congratulations to these contributors and their mentors! + + + +### Support + +* [Fetching too many tags?](https://lore.kernel.org/git/274ec1a2152b0fd53b35c1591f5177e0b0713430@rjp.ie/) + + Ronan Pigott noticed that when he fetched from some repos, for + example from the + ["Linux Stable" repo](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux) + on [kernel.org](https://git.kernel.org/), most of the time seemed to + be spent transferring tags from the remote to the client. + + When his local repo was up-to-date and `git fetch` was used with + `--no-tags` (or its `-n` shortcut), it took less than 0.4 seconds + versus more than 1.7 seconds without it. + + He asked if there was a reason for this seemingly useless transfer of + tags even when the remote didn't have to send any commit. + + Peff, alias Jeff King, replied that "this is how the Git protocol + works". He explained that the server only lists all the refs it + knows about, and expects the client to select the refs it wants + among them. "Only the client knows what it already has." For + example, there could be new tags on the server pointing to commits + that the client already has. + + Peff also mentioned that in recent Git versions an extension of the + Git protocol allows clients to list only the refs they are + interested in, so that the server can send "a much smaller ref + advertisement". + + Ronan asked if Peff was talking about the `--negotiation-tip` + option, as some tests using this option didn't result in better + performance. + + Peff replied that `--negotiation-tip` was only useful when there are + commits that should be transferred. When histories on the client and + the server have diverged, this option helps them find a common + commit that can be the base for the commits that will be + transferred. + + Peff said the extension of the Git protocol he was talking about are + "ref-prefix" lines in Git's "v2" protocol, which is the default + protocol since Git v2.29. This protocol allows the client to speak + first and specify which ref prefixes it's interested in with these + "ref-prefix" lines. + + Setting the `GIT_TRACE_PACKET` to `1` allows one to see the packets + exchanged between the client and the server, especially the + "ref-prefix" lines when for example `git fetch --no-tags origin + master` is launched using a recent Git, or the "have" and "want" + lines when client and server have to negotiate a common commit. + + Ronan tested Peff's suggestions and thanked him as he then + understood why the tag advertisement was useful. + + + +## Other News + +__Various__ + +* [Critical GitHub Vulnerability Exposes 4,000+ Repositories to Repojacking Attack](https://thehackernews.com/2023/09/critical-github-vulnerability-exposes.html) + on The Hacker News. The vulnerability was caused by a race condition + within GitHub's repository creation and username renaming operations. +* [Nx lands $16M to build ‘monorepo’ tools for software devs](https://techcrunch.com/2023/09/25/nx-lands-16m-to-build-monorepo-tools-for-software-devs/) + by Kyle Wiggers on TechCrunch. The funding will be used to expand + [Nx](https://nx.dev/)’s fully managed product, + [Nx Cloud](https://nx.dev/nx-cloud/intro/what-is-nx-cloud), + a replacement for existing continuous integration tools, such as Jenkins, + with first class [monorepo](https://monorepo.tools/) support. +* [Harness launches Gitness, an open-source GitHub competitor](https://techcrunch.com/2023/09/21/oh-gitness-harness-launches-gitness-an-open-source-github-competitor/) + by Frederic Lardinois on TechCrunch. + + +__Light reading__ + +* [In a git repository, where do your files live?](https://jvns.ca/blog/2023/09/14/in-a-git-repository--where-do-your-files-live-/) + by Julia Evans on her blog. +* [Don’t create `.gitkeep` files, use `.gitignore` instead](https://adamj.eu/tech/2023/09/18/git-dont-create-gitkeep/) by Adam Johnson. +* [Signing Commits in Git, Explained](https://blog.gitbutler.com/signing-commits-in-git-explained/) + by Scott Chacon on [GitButler](https://gitbutler.com/) Blog. +* [Selecting the Right Git Merging Strategy: Merge Commit, Squash and Merge, or Rebase and Merge](https://akashrajpurohit.com/blog/selecting-the-right-git-merging-strategy-merge-commit-squash-and-merge-or-rebase-and-merge/) + by Akash Rajpurohit on his blog. +* [Drop git pull for fetch and rebase](https://developers.redhat.com/articles/2023/09/07/drop-git-pull-fetch-and-rebase) + by Yftach Herzog on RedHat Developer Blog, arguing that `git fetch` followed + by `git rebase` is a safer alternative (with a feature branch workflow). +* [Advanced Git Commands and Workflows: A Comprehensive Guide for Developers](https://dev.to/documatic/advanced-git-commands-and-workflows-a-comprehensive-guide-for-developers-5865) + by Matías Hernández Arellano for Documatic on DEV\.to; + covers interactive rebase, cherry-picking, `git bisect`, reflog, `git blame`, + and various Git collaboration workflows. +* [Git Delta is a Syntax Highlighting Pager for git, diff, and grep output](https://laravel-news.com/git-delta) + by Paul Redmond on Laravel News blog. [Delta](https://dandavison.github.io/delta/) + was first mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/); + there is a link to [another article about Delta](https://dev.to/cloudx/delta-a-new-git-diff-tool-to-rock-your-productivity-2773) + in [Edition #102](https://git.github.io/rev_news/2023/08/31/edition-102/). + * There is also a [Delta](https://github.com/octavore/delta) command-line diff tool + implemented in Go, with a [dead homepage](http://delta.octavore.com/) + ([archive](https://web.archive.org/web/20201108092055/http://delta.octavore.com/)), + mentioned in [Git Rev News Edition #9](https://git.github.io/rev_news/2015/11/11/edition-9/). +* [Git-Based Software Development Life-Cycle](https://nordstroem.ch/posts/2023-09-10-git-sdlc.html) + by Kris considers whether tools like + [git-appraise](https://github.com/google/git-appraise), + [git-issue](https://github.com/dspinellis/git-issue), and + [git-bug](https://github.com/MichaelMure/git-bug) + that store their information, history, and artifacts directly in the repository + can replace development tools such as + Jira (planning, issue tracking), + Confluence (wiki, documentation platform), + Bamboo (CI/CD server), + Artifactory (storing Docker images and CI/CD artifacts), and + Gerrit (code review). + * [Git Rev News Edition #43](https://git.github.io/rev_news/2018/09/19/edition-43/) + includes a list of similar tools and links related to them. + * [git-appraise](https://github.com/google/git-appraise) was first mentioned + in [Git Rev News Edition #11](https://git.github.io/rev_news/2016/01/13/edition-11/). +* [Delving Deeper into Gitamic: Power and Flexibility Beyond Statamic's Built-In Git Features](https://laravel-news.com/gitamic) + by Eric L. Barnes on Laravel News blog. + [Gitamic](https://marketplace.anystack.sh/item/gitamic) is a premium + [Statamic CMS](https://statamic.com/) add-on that allows you + to take full control of your Git workflow from within your CMS. +* [GitLab CI: 10+ Best Practices to Avoid Widespread Anti-patterns](https://dev.to/zenika/gitlab-ci-10-best-practices-to-avoid-widespread-anti-patterns-2mb5) + by Benoit COUETIL for Zenika on DEV\.to. +* [Fossil Versus Git](https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki) + on Fossil Wiki. + + + +__Easy watching__ + +* [The Git Parable: a different approach to understanding Git](https://www.youtube.com/watch?v=ANNboouhNHE), + a talk by Johan Herland for Tweag, based on Tom Preston-Werner's + [essay of the same name](https://tom.preston-werner.com/2009/05/19/the-git-parable.html) (2009) + covered in [Git Rev News #30](https://git.github.io/rev_news/2017/08/16/edition-30/). + + +__Git tools and sites__ + +* [git-credential-azure](https://github.com/hickford/git-credential-azure) is a credential helper + that authenticates to [Azure Repos](https://azure.microsoft.com/en-us/products/devops/repos). +* [git-vain](https://git.anna.lgbt/anna/git-vain) is a tool to generate + vanity hashes quickly; it can be used for example to make SHA-1 hash + of the HEAD begin with `c0ffee`. Written in Rust. Other similar tools: + * [git-vanity-sha](https://github.com/mattbaker/git-vanity-sha), written in Ruby, + mentioned in [Git Rev News Edition #39](https://git.github.io/rev_news/2018/05/16/edition-39/). + * ~~[git-sham](https://bitbucket.org/tpettersen/git-sham)~~ + (no longer available); first mentioned in + [Git Rev News Edition #4](https://git.github.io/rev_news/2015/06/03/edition-4/). +* [git-issue](https://github.com/dspinellis/git-issue) is a minimalist + decentralized issue management system based on Git, + offering (optional) bidirectional integration with GitHub and GitLab issue management. + Written as set of shell scripts. + * Similarly named [git-issues](https://github.com/duplys/git-issues), written in Python, + was mentioned in [Git Rev News Edition #43](https://git.github.io/rev_news/2018/09/19/edition-43/). +* [Cup](https://cup.flipt.io/) is an extensible server for building automation + around introspection and contributions to Git and SCMs like GitHub. + It is an active experiment into the benefits of managing an API over Git. + Written in Go by [Flipt](https://www.flipt.io/) - the open source, self-hosted + feature flag solution. + * [Flipt](https://www.flipt.io/) itself was mentioned in + [Git Rev News Edition #96](https://git.github.io/rev_news/2023/02/28/edition-96/). +* [Gitness](https://gitness.com/) by [Harness](https://www.harness.io/) + is an open-source code hosting and pipeline engine, + with source control management, Continuous Integration and Continuous Delivery, + that can be easily installed using Docker. Written in Go. + Can be considered the next generation of [Drone](https://www.drone.io/). +* [Gitopia](https://docs.gitopia.com) is the next-generation + Decentralized Code Collaboration Platform + fueled by a decentralized network and interactive token economy. + It is designed to optimize the software development process through collaboration, + transparency, and open source incentivization. + You need to have a [supported wallet](https://docs.gitopia.com/wallet-overview) + with sufficient LORE tokens to use Gitopia's services. + Pushing changes to Gitopia is done with the help of `git-remote-gitopia` helper. + * Compare with [git-ssb](https://scuttlebot.io/apis/community/git-ssb.html) + (see [git-ssb-intro](https://github.com/hackergrrl/git-ssb-intro) guide): + decentralized git repo hosting and issue tracking on secure-scuttlebutt (SSB), + mentioned in [Git Rev News Edition #26](https://git.github.io/rev_news/2017/04/19/edition-26/) + and [#40](https://git.github.io/rev_news/2018/06/20/edition-40/). + * Contrast with [ForgeFed](https://forgefed.org/) (formerly GitPub), + a federation protocol for forge services (ActivityPub extension), mentioned in + [Git Rev News Edition #69](https://git.github.io/rev_news/2020/11/27/edition-69/) + and [#95](https://git.github.io/rev_news/2023/01/31/edition-95/), + and various projects in different stages of development that implement it: + [Vervis](https://vervis.peers.community/), [Forgejo](https://forgejo.org/), + [ForgeFlux](https://forgeflux.org/), and [Forgefriends](https://forgefriends.org/). +* [Mermaid](https://mermaid.js.org/), a JavaScript-based diagramming and charting tool + that can be embedded in Markdown documents + (which [is supported on GitHub](https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/)), + now supports [Gitgraph Diagrams](https://mermaid.js.org/syntax/gitgraph.html). + + +## Releases + ++ Git for Windows [2.42.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.42.0.windows.2) ++ Gerrit Code Review [3.6.7](https://www.gerritcodereview.com/3.6.html#367), +[3.7.5](https://www.gerritcodereview.com/3.7.html#375), +[3.8.2](https://www.gerritcodereview.com/3.8.html#382) ++ GitHub Enterprise [3.10.2](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.2), +[3.10.1](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.1), +[3.9.5](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.5), +[3.8.10](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.10), +[3.7.17](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.17), +[3.6.19](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.19), +[3.10.0](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.0), +[3.9.4](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.4), +[3.8.9](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.9), +[3.7.16](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.16), +[3.6.18](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.18) ++ GitLab [16.4](https://about.gitlab.com/releases/2023/09/22/gitlab-16-4-released/) +[16.3.4 and 16.2.7](https://about.gitlab.com/releases/2023/09/18/security-release-gitlab-16-3-4-released/), +[16.2.6](https://about.gitlab.com/releases/2023/09/12/gitlab-16-2-6-released/), +[16.3.3](https://about.gitlab.com/releases/2023/09/12/gitlab-16-3-3-released/), +[16.3.2](https://about.gitlab.com/releases/2023/09/05/gitlab-16-3-2-released/), +[16.3.1, 16.2.5, and 16.1.5](https://about.gitlab.com/releases/2023/08/31/security-release-gitlab-16-3-1-released/) ++ Bitbucket Server [8.14](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitKraken [9.8.2](https://help.gitkraken.com/gitkraken-client/current/), +[9.8.1](https://help.gitkraken.com/gitkraken-client/current/), +[9.8.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.3](https://desktop.github.com/release-notes/), +[3.3.2](https://desktop.github.com/release-notes/), +[3.3.1](https://desktop.github.com/release-notes/), +[3.3.0](https://desktop.github.com/release-notes/) ++ Tower for Windows [5.1](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) ++ git-credential-azure [0.2.3](https://github.com/hickford/git-credential-azure/releases/tag/v0.2.3) ++ git-credential-oauth [0.10.1](https://github.com/hickford/git-credential-oauth/releases/tag/v0.10.1) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Adam Johnson, Bruno Brito, Mirth Hickford +and Štěpán Němec. diff --git a/_posts/2023-10-31-edition-104.markdown b/_posts/2023-10-31-edition-104.markdown new file mode 100644 index 0000000000..3da7ae02d1 --- /dev/null +++ b/_posts/2023-10-31-edition-104.markdown @@ -0,0 +1,226 @@ +--- +title: Git Rev News Edition 104 (October 31st, 2023) +layout: default +date: 2023-10-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 104 (October 31st, 2023) + +Welcome to the 104th 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 2023 and October 2023. + +## Discussions + +### General + ++ [Git Virtual Contributor’s Summit 2023](https://docs.google.com/document/d/1GKoYtVhpdr_N2BAonYsxVTpPToP1CgCS9um0K7Gx9gQ) + + A virtual summit happened on September 26th and 27th, where the + contributors discussed + [topics that they had previously voted on](https://docs.google.com/spreadsheets/d/1EnhmTeEqRBlEI2pMAO3oZ4rO1xEwBzYp2vS4CMtvge8). + Taylor Blau, who organized the summit, polished and then sent + [the notes that were taken during the summit](https://lore.kernel.org/git/ZRregi3JJXFs4Msb@nand.local/#r) + to the mailing list. + + +### Reviews + ++ [[PATCH] diff --stat: add config option to limit filename width](https://lore.kernel.org/git/87badb12f040d1c66cd9b89074d3de5015a45983.1694446743.git.dsimic@manjaro.org/) + + Dragan Simic sent a patch to the mailing list that added a new + `diff.statNameWidth=` configuration option. The goal with + this option was to make it possible to limit the width of the + filepath part of the "stat" output of `git diff` commands. + + For example, the "stat" output of a `git diff` command contains lines like this: + + ``` + path/to/file.txt | 11 +++++++-- + ``` + + where the "filepath" part, also called "name" or "filename" part, of + that output is `path/to/file.txt` and the "graph" part is + `11 +++++++--`. + + There were already a `diff.statGraphWidth=` configuration + option to limit the width of the graph part, and also + `--stat-name-width=` and `--stat-graph-width=` command + line options to limit the width of the name and graph part, + respectively. So it was logical to add the missing configuration + option. + + These options are especially useful for people using very large + terminals, to prevent "stat" output from using a lot of columns. + + The new `diff.statNameWidth=` was designed to be ignored by + `git format-patch` in the same way as + `diff.statGraphWidth=`, because that command already respects + the traditional 80-column standard. + + Before sending this patch, Dragan had sent + [an RFC email](https://lore.kernel.org/git/eb8f524eca3975f086715ec32a8a1fbb@manjaro.org/) + asking if such a patch would be accepted, which led to an interesting + discussion between him and Junio Hamano, the Git maintainer, about + the fact that we often cannot promise anything about a hypothetical + patch before actually seeing it on the mailing list. + + Junio reviewed the actual patch and wondered if it would be possible + to specify contradictory values for the whole width on one side and + the "name" and "graph" width on the other side. He also suggested + creating a helper function to initialize all the variables that + contain the values of the configuration options for the different + parts, as the code initializing those variables was duplicated in + the code of many Git commands. + + Dragan replied that the diff code already performed "a reasonable + amount of sanity checks and value adjustments". He wondered if + warnings should be emitted in case of contradictory settings though. + + Dragan then agreed that refactoring the code that initialized the + variables would be nice, but he proposed to do it after the current + patch would have been merged. + + Junio and Dragan agreed with doing the refactoring later and + discussed a bit deeper if more changes were needed in this patch, but + it appeared that it could be merged as is, and so it was. + + A few days later Dragan sent + [a patch to refactor the code that initialized the variables](https://lore.kernel.org/git/166396f0a98e248fc3d1236757632c5d648ddc0b.1695364961.git.dsimic@manjaro.org/). + Junio reviewed it and suggested some improvements, which Dragan + implemented in [a second version of the patch](https://lore.kernel.org/git/d45d1dac1a20699e370905b88b6fd0ec296751e7.1695441501.git.dsimic@manjaro.org/). + + This second version was also reviewed by Junio and then merged. + + + + + +## Other News + +__Various__ +* [New book “Boost Your Git DX”](https://adamchainz.gumroad.com/l/bygdx) by Git contributor Adam Johnson, covering tools and configurations to improve your command line workflow. +* [Git 2.42 release: Here are four of our contributions in detail](https://about.gitlab.com/blog/2023/10/12/contributions-to-git-2-42-release/) + by Christian Couder on GitLab Blog. + * [Highlights from Git 2.42](https://github.blog/2023-08-21-highlights-from-git-2-42/) + link can be found in [Git Rev News Edition #102](https://git.github.io/rev_news/2023/08/31/edition-102/). + +__Light reading__ ++ [Some miscellaneous git facts](https://jvns.ca/blog/2023/10/20/some-miscellaneous-git-facts/) + by Julia Evans on her blog. The facts are: + + the “index”, “staging area” and “`--cached`” are all the same thing + + the stash is a bunch of commits + + not all references are branches or tags + + merge commits aren’t empty ++ [Why Git is hard](https://roadrunnertwice.dreamwidth.org/596185.html) + by Nick Eff on his Roadrunner Twice Dreamwidth's journal, + in response to Julia Evans ending her StrangeLoop 2023 keynote talk with + “I still don’t know why Git is hard.” + + There is some discussion on the [programming.dev Lemmy instance](https://programming.dev/post/4051745) + about this post. + + Various attempts to make Git or version control easier include + [Gitless](http://gitless.com/) - first mentioned in [Git Rev News Edition #20](https://git.github.io/rev_news/2016/10/19/edition-20/), + [Jujutsu](https://github.com/martinvonz/jj) - mentioned in [#85](https://git.github.io/rev_news/2022/03/31/edition-85/), + and [EasyGit (eg)](https://github.com/dfabulich/easygit) - seems not to be actively developed. ++ [Investigating Git History](https://www.git-tower.com/blog/investigating-git-history/) + by Kristian Lumme on Tower’s blog. ++ [Measuring Git performance with OpenTelemetry](https://github.blog/2023-10-16-measuring-git-performance-with-opentelemetry/) + by Jeff Hostetler on GitHub Blog. It describes how to use open source + [Trace2](https://github.com/git/git/blob/master/Documentation/technical/api-trace2.adoc) + [receiver component (trace2receiver)](https://github.com/git-ecosystem/trace2receiver) + and [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/) + to capture and visualize telemetry from your Git commands. ++ [What is in that `.git` directory?](https://blog.meain.io/2023/what-is-in-dot-git/) + by Abin Simon on meain/blog. ++ [Versioning data in Postgres? Testing a git like approach](https://www.specfy.io/blog/7-git-like-versioning-in-postgres) + by Samuel Bodin on his Specfy Blog. ++ [Organizing multiple Git identities](https://garrit.xyz/posts/2023-10-13-organizing-multiple-git-identities) + using `.gitconfig` includes, + by Garrit Franke on Garrit's Notes blog. ++ [Linux Fu: Deep Git Rebasing](https://hackaday.com/2023/10/17/linux-fu-deep-git-rebasing/) + by Al Williams on Hackaday. ++ [Git: Rewriting History 101](https://matheustavares.gitlab.io/posts/rewriting-history-101) + by Matheus Tavares (2022). ++ [How to split off an older copy of a file while preserving git line history](https://devblogs.microsoft.com/oldnewthing/20230728-00/?p=108498) + by Raymond Chen on Microsoft's The Old New Thing DevBlog. + + His older article on [how to duplicate a file while preserving git line history](https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904) + was mentioned in [Git Rev News Edition #51](https://git.github.io/rev_news/2019/05/22/edition-51/). ++ [Embracing Database Deployments in CI/CD Practices with Git](https://thenewstack.io/embracing-database-deployments-in-ci-cd-practices-with-git/) + by Vanessa Fox from PlanetScale on TheNewStack. + + [An article](https://planetscale.com/blog/database-branching-three-way-merge-schema-changes) + about [PlanetScale branching support for MySQL](https://planetscale.com/docs/concepts/branching) + was mentioned in [Git Rev News Edition #99](https://git.github.io/rev_news/2023/05/31/edition-99/), + while PlanetScale as solution was mentioned in set of article about databases and versioning + in [Git Rev News Edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/). ++ [TypeScript Monorepo with NPM workspaces](https://www.yieldcode.blog/post/npm-workspaces/) + by Dmitry Kudryavtsev on yield code(); blog. ++ [The "Schrödinger's tree object": is it there or not?](https://matheustavares.gitlab.io/posts/empty-tree): + Matheus Tavares finds about the hard-coded empty tree object (2022). + + + +__Git tools and sites__ ++ [gittuf](https://gittuf.dev/) provides a security layer for Git + using some concepts introduced by [The Update Framework (TUF)](https://theupdateframework.io/). + Among other features it handles key management for all developers on the repository, + allows you to set permissions for repository branches, tags, files, etc.
+ gittuf is a sandbox project at the [Open Source Security Foundation (OpenSSF)](https://openssf.org/) + as part of the [Supply Chain Integrity Working Group](https://github.com/ossf/wg-supply-chain-integrity). + It is currently in _alpha_. Written in Go. ++ [trace2receiver](https://github.com/git-ecosystem/trace2receiver) project + is a [trace receiver](https://opentelemetry.io/docs/collector/trace-receiver/) component library + for an [OpenTelemetry Custom Collector](https://opentelemetry.io/docs/collector/) daemon. + It receives [Git Trace2](https://git-scm.com/docs/api-trace2#_the_event_format_target) telemetry + from local Git commands, translates it into an OpenTelemetry format, and forwards it + to other OpenTelemetry components. Written in Go as a static library component + that must be linked into an OpenTelemetry Custom Collector. ++ [git-bundle-server](https://github.com/git-ecosystem/git-bundle-server) + is a web server & management CLI to host Git bundles for use with Git's + ["bundle URIs" feature](https://git-scm.com/docs/bundle-uri). + By running this software, you can self-host a bundle server. + Written in Go, under active development. Installation on Windows is currently unsupported. ++ [Awesome GitHub Alternatives](https://github.com/ianchanning/awesome-github-alternatives) + is a list of alternatives to GitHub that by default offer Git management in some way. + All self-hosted options are free and open source, with GPL-compatibile licenses. + Not exhaustive. ++ [src (Simple Revision Control)](http://www.catb.org/esr/src/) + is RCS/SCCS reloaded with a modern UI, designed to manage single-file solo projects + kept more than one to a directory. Use it for FAQs, `~/bin` directories, config files, + and the like. Written in Python. + + Mentioned in passing in [Git Rev News Edition #46](https://git.github.io/rev_news/2018/12/19/edition-46/). + + +## Releases + ++ GitHub Enterprise [3.10.3](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.3), +[3.9.6](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.6), +[3.8.11](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.11), +[3.7.18](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.18) ++ GitLab [16.5](https://about.gitlab.com/releases/2023/10/22/gitlab-16-5-released/) ++ Bitbucket Server [8.15](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitKraken [9.9.2](https://help.gitkraken.com/gitkraken-client/current/), +[9.9.1](https://help.gitkraken.com/gitkraken-client/current/), +[9.9.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.4](https://desktop.github.com/release-notes/) ++ TortoiseGit [2.15.0](https://tortoisegit.org/download/) ++ git-credential-oauth [0.11.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.11.0) + +## 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, Adam Johnson and Sven Strickroth. diff --git a/_posts/2023-11-30-edition-105.markdown b/_posts/2023-11-30-edition-105.markdown new file mode 100644 index 0000000000..75a0c12e09 --- /dev/null +++ b/_posts/2023-11-30-edition-105.markdown @@ -0,0 +1,449 @@ +--- +title: Git Rev News Edition 105 (November 30th, 2023) +layout: default +date: 2023-11-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 105 (November 30th, 2023) + +Welcome to the 105th 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 2023 and November 2023. + +## Discussions + +### General + +- Git participates in [Outreachy's December 2023 to March 2024 round](https://www.outreachy.org/alums/2023-12/) + + Achu Luma will work on the "Move existing tests to a unit testing + framework" project. They will be mentored by Christian Couder. + + Congratulations to Luma for being selected! + + Thanks to GitLab for sponsoring this Outreachy internship! Thanks + also to the other contributors who applied and worked on + micro-projects, but couldn’t be selected! We hope to continue to see + you in the community! + + +### Reviews + ++ [[PATCH v2 0/2] Prevent re-reading 4 GiB files on every status](https://lore.kernel.org/git/20231012160930.330618-1-sandals@crustytoothpaste.net/) + + In May 2022 Jason Hatton sent + [an email to the mailing list](https://lore.kernel.org/git/CY4PR16MB1655A1F7DD8B2FABCC30C9DAAFC39@CY4PR16MB1655.namprd16.prod.outlook.com/) + about the fact that any file of a size that is an exact multiple + of 8GiB makes Git extremely slow on the repository. + + He said that he had already opened + [an issue about this on the Git for Windows issue tracker](https://github.com/git-for-windows/git/issues/3833#issuecomment-1116544918) + where Jason, Philip Oakley, brian m. carlson and Johannes + Schindelin, alias Dscho, had already discussed the issue. + + Git uses an `uint32_t` type, a 32 bit long unsigned integer, for + storing the file size in the index. This rolls over if the value is + greater than 2 to the power 32, so with file sizes over 4GiB. When + the size is exactly 4GiB or a multiple of it, like 8GiB, + the rollover makes it zero. + + A zero file size in the index has a special meaning for Git, + though. It tells Git that the file needs to be hashed again. Hashing + a file is supposed to reset its file size in the index to a non-zero + value, but with a 4GiB file size the rollover happens and the file + size is still zero. So the hashing will be performed again and again + by many different Git commands, making Git very slow. + + Jason proposed, as a solution to this problem, to detect when the + rollover would happen, and in that case set the size to 1 instead + of zero. + + Junio C Hamano, the Git maintainer, replied to Jason confirming the + issue and explaining it a bit more in detail. Jason and Junio then + discussed the issue a bit more, while Jason tested locally his + suggested fix and proposed to send a real patch to fix the issue. + + René Scharfe then chimed into the discussion asking if a value other + than one would be better and would avoid other possible issues. + Philip Oakley replied to René suggesting using 0x80000000 instead of + 1 when the rollover is detected. This would make it easier to + detect "almost all incremental and decremental changes in file + sizes", as the file size in the index helps detecting file changes. + + Jason and Philip discussed the issue a bit more and agreed that + using 0x80000000 only for exact multiples of 4GiB would likely be + the best solution. + + Philip and Carlo Marcelo Arenas Belón also tried to help Jason + properly submit a patch to the mailing list. + + Jason then sent + [a patch to the mailing list](https://lore.kernel.org/git/CY4PR16MB16552D74E064638BEC11ECB1AFC59@CY4PR16MB1655.namprd16.prod.outlook.com/) + with the changes and explanation that had been discussed. Torsten + Bögershausen, Philip and Junio reviewed it, and suggested some + improvements. Junio especially requested some tests to be added. + + After some discussions with Jason to clarify what should be + improved, Jason sent + [another version of his patch](https://lore.kernel.org/git/20220507185813.1403802-1-jhatton@globalfinishing.com/). + + It looked like Jason found an issue with the patch due to using + 0x80000000 instead of 1. René and Philip discussed it with Jason, + but there was no clear conclusion. It wasn't even clear if there was + an issue at all. But anyway the work on this stopped for more than + one year. + + Fortunately a few weeks ago, brian m. carlson sent + [a new version of Jason's patch](https://lore.kernel.org/git/20231012160930.330618-1-sandals@crustytoothpaste.net/) + along with another patch adding tests. + + These patches were reviewed by Eric Sunshine, Jeff King, alias Peff, + Junio and Jason. After some discussions it appeared that the patches + were good enough for Junio, so he decided to apply a small change + and then merge them. This issue is therefore fixed in + Git 2.43.0 released on November 20th. + + + +## Developer Spotlight: Alexander Shopov + +* Who are you and what do you do? + + I am Alexander Shopov - a backend engineer in the Amsterdam office of + Uber working on money related systems. I am a long time translator of + FOSS software to Bulgarian - I am coordinating translations of GNOME, + Translation Project and many GNU modules. Bulgarian is an Eastern + South Slavic language written in the Cyrillic alphabet. + +* What would you name your most important contribution to Git? + + I made and now maintain the Bulgarian translation of the text + interface of Git, Gitk, and Git Gui. + +* What is the typical workflow of a contributor engaged in Git + translation? + + There are 19 translations of the text interface of Git, and only 13 of + them are above 80%, so I am not sure about "typical". It is a fairly + standard workflow for a FOSS project. + + Generally one needs to do the following: + + 1. Read the translator-targeted README.md in the po directory + 2. Sync pace with the [calendar of Git releases](https://tinyurl.com/gitcal) + 3. Use the [l10n coordinator repository](https://github.com/git-l10n/git-po) + maintained by Jiang Xin who makes sure translations get integrated upstream. + + Currently the translation is a bit above 5500 messages, which is about + 40k words, 250k of characters, or about 150 pages of text. It can be + intimidating for a new translator. But you can definitely make it: be + patient and translate some messages every release, merge, publish and + repeat. Even better though harder is getting more than one person + translating. + +* Do you contribute to Git in ways other than providing translation? + If so, could you elaborate about them? + + Sadly not that much. On rare occasions I improve messages and mark + strings for translations. Perhaps that will be the way I contribute + unless I find a mentor and something that I find particularly + interesting and important for me. So if anyone is willing to mentor + me, especially in making large repos faster - [ping me](mailto:ash@kambanaria.org). + I can be a competent tester at least. + +* 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? + + Due to its enormous success, Git is being used on humongous code bases + with a crazy number of files, directories, commits and branches. + Working with repos larger than 10GB can be a bit slow. Improving the + experience would be a great thing. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + Backwards compatibility is massively important and I am thankful + developers and users are all invested in this. + + If we treat this as a hypothetical question, there are 3 things to Git: + - the command-line interface + - the wire protocol + - the storage format + + The command-line interface is gradually being improved. The wire + protocol is also a place where there are workarounds for versioning. + The storage format however is another (quite conservative and public) + API. I would remove the old versions and try to design it targeting + projects that are 10-100 times larger than the Linux kernel first. In + for a penny, in for a pound. If we break things, let us break them so + hard that bards will sing songs about us! + +* What is your favorite Git-related tool/library, outside of Git itself? + + I mainly use command line `git` plus `gitk` and `git-gui`. I do like using + the meld diff tool when I work on translations. + +* Do you happen to have any memorable experience w.r.t. contributing + to the Git project? If yes, could you share it with us? + + The initial getting to 100% translated messages was a challenge. I + decided that I should translate Git around December 2013. That was + around 2200 messages at that time and it took me about 3 releases of + Git to reach 100%. Getting to 100% was immensely hard, rewarding and + memorable. Afterwards keeping the translation at 100% was much easier. + +* Is there something you feel could be done to ease the life of + translators? + + The terminology glossary of Git is much larger than 7 years ago, and we + (the translators) should actually update `git://repo.or.cz/git-gui.git::po/glossary` + and merge it in Git. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + I don't know to be honest. If I knew I may have started already. + +* If there's one tip you would like to share with other Git + developers, what would it be? + + That would be the tip of master two years in the future. On a more + serious note - perhaps more tools for migration out of the still + existing proprietary version control systems would be helpful. + + +## Other News + +__Various__ + ++ [Highlights from Git 2.43](https://github.blog/2023-11-20-highlights-from-git-2-43/) + by Taylor Blau on GitHub Blog. Those include new `git repack` tricks + (including adjusting sparse clone filters), nicer looking reverts of reverts + with `git revert`, fixed interaction between `--subject-prefix` and `--rfc` + in `git format-patch`, custom log format options that simulate the decorations, etc. ++ [Gitea Cloud: A brand new platform for managed Gitea Instances](https://blog.gitea.com/gitea-cloud/), + designed for enterprise organizations to set up and run + their own Gitea instances more easily and efficiently. ++ [Announcing DoltgreSQL](https://www.dolthub.com/blog/2023-11-01-announcing-doltgresql/) + by Daylon Wilkins on DoltHub Blog. + + [Git-for-Data, Version-Controlled Database Dolt Gets PostgreSQL-Flavor](https://www.infoq.com/news/2023/11/DoltgreSQL-git-for-data-postgres/) + by Sergio De Simone on InfoQ. + + [Dolt](https://github.com/dolthub/dolt), a version-controlled database, + was first mentioned in [Git Rev News Edition #62](https://git.github.io/rev_news/2020/04/23/edition-62/). ++ [An Interesting CMS With Version Control is Now Open-Source!](https://news.itsfoss.com/tinacms-open-source/) + by Sourav Rudra on It's FOSS News (it's [TinaCMS](https://tina.io/)). ++ [Introducing the Space Git Subtree](https://blog.jetbrains.com/space/2023/11/21/space-git-subtree/) + by Ilia Afanasiev on The Space Blog (where Space is JetBrains' code collaboration platform). ++ [Developers can’t seem to stop exposing credentials in publicly accessible code](https://arstechnica.com/security/2023/11/developers-cant-seem-to-stop-exposing-credentials-in-publicly-accessible-code/) + by Dan Goodin on Ars Technica, and
+ [Uncovering thousands of unique secrets in PyPI packages](https://blog.gitguardian.com/uncovering-thousands-of-unique-secrets-in-pypi-packages/) + by Tom Forbes on GitGuardian Blog. ++ [14 years of JGit/EGit Code Reviews migrated to GerritHub](https://gitenterprise.me/2023/11/21/14-years-of-jgit-egit-code-reviews-migrated-to-gerrithub/) by Luca Milanesio on GerritForge Blog. + + +__Light reading__ + ++ [How I (kind of) killed Mercurial at Mozilla](https://glandium.org/blog/?p=4346) + by Mike Hommey (author of [git-cinnabar](https://github.com/glandium/git-cinnabar), + Git remote helper to interact with Mercurial repositories). ++ Julia Evans continues the series of articles about Git (started in + [Git Rev News #103](https://git.github.io/rev_news/2023/09/30/edition-103/) + with [In a git repository, where do your files live?](https://jvns.ca/blog/2023/09/14/in-a-git-repository--where-do-your-files-live-/) + and + [Git Rev News #104](https://git.github.io/rev_news/2023/10/31/edition-104/) + with [Some miscellaneous git facts](https://jvns.ca/blog/2023/10/20/some-miscellaneous-git-facts/)); + currently there are the following additional posts: + [Confusing git terminology](https://jvns.ca/blog/2023/11/01/confusing-git-terminology/), + [git rebase: what can go wrong?](https://jvns.ca/blog/2023/11/06/rebasing-what-can-go-wrong-/), + [How git cherry-pick and revert use 3-way merge](https://jvns.ca/blog/2023/11/10/how-cherry-pick-and-revert-work/), + and [git branches: intuition & reality](https://jvns.ca/blog/2023/11/23/branches-intuition-reality/). + + Julia Evans (@b0rk@jvns.ca) asked about a read-only FUSE filesystem for a Git repository + where every commit is a folder and the folder contains all the files in that commit + [on Mastodon](https://fosstodon.org/@b0rk@jvns.ca/111462737333140668), so this series may continue + (so far it led to very experimental [git-commit-folders](https://github.com/jvns/git-commit-folders) + tool from her, and [GitMounter](https://belkadan.com/blog/2023/11/GitMounter/) from + Jordan Rose being made public). + + See also [Pain in the dots](https://matthew-brett.github.io/pydagogue/pain_in_dots.html) + by Matthew Brett (part of [Notes and tutorials on git](https://matthew-brett.github.io/pydagogue/git.html)), + about the confusing difference in how two-dot and three-dot notations + behave in `git log` and `git diff`, as an addition to the Julia Evans' article + about confusing Git terminology, the [.. and ... section](https://jvns.ca/blog/2023/11/01/confusing-git-terminology/#and). ++ [How I teach Git](https://blog.ltgt.net/teaching-git/) by Thomas Broyer + on his blog (also [on DEV.to](https://dev.to/tbroyer/how-i-teach-git-3nj3)). + Inspired by Julia Evans' (renewed) interest in Git and her questions on social networks. ++ [Stacked Diffs (and why you should know about them)](https://newsletter.pragmaticengineer.com/p/stacked-diffs) + by Gergely Orosz in The Pragmatic Engineer blog. Another article about Stacked Diffs + can be found in [Git Rev News Edition #44](https://git.github.io/rev_news/2018/10/24/edition-44/). + + Compare and contrast [Ship / Show / Ask: A modern branching strategy](https://martinfowler.com/articles/ship-show-ask.html) + mentioned in [Edition #79](https://git.github.io/rev_news/2021/09/30/edition-79/). ++ [Why I Prefer Trunk-Based Development](https://koenvangilst.nl/blog/trunkbased-development) + by Koen van Gilst on his blog. + + See also [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) + in [Git Rev News Edition #73](https://git.github.io/rev_news/2021/03/27/edition-73/). ++ A bit controversial [Dependencies Belong in Version Control](https://www.forrestthewoods.com/blog/dependencies-belong-in-version-control/) + (even if it's not practical today due to Git's limitations) + by Forrest Smith on his blog. ++ [Managing My Resume with Git: A Version Control Approach](https://dev.to/dunkbing/managing-my-resume-with-git-a-version-control-approach-7hk) + by Bui Dang Binh (dunkbing) on DEV\.to. ++ [See the History of a Method with `git log -L`](https://calebhearth.com/git-method-history) + by Caleb Hearth on his blog; the post lists also a few his other articles about Git: + + [Stash only what `git commit` wouldn't commit](https://calebhearth.com/stash-what-git-wouldnt-commit). + + [Ignore refactoring commits in `git blame`](https://calebhearth.com/rubocop-git-blame). + + [Use your SSH key to sign commits](https://calebhearth.com/sign-git-with-ssh). + + See also, for example, + [Signing Git Commits with SSH Keys](https://blog.dbrgn.ch/2021/11/16/git-ssh-signatures/) + from [Git Rev News Edition #83](https://git.github.io/rev_news/2022/01/31/edition-83/). ++ [Why Git blame sucks for understanding WTF code (and what to use instead)](https://tekin.co.uk/2020/11/patterns-for-searching-git-revision-histories) + by Tekin Süleyman (2020); the author recommend "pickaxe" search with `git log -S` and + `git log -G`, or searching commit messages with `git log --grep`. ++ [How to Resolve Merge Conflicts Using the Merge Editor Feature on VS Code](https://adiati.com/how-to-resolve-merge-conflicts-using-the-merge-editor-feature-on-vs-code) + by Ayu Adiati on Ayu's Notes On Blog (also [on DEV\.to](https://dev.to/adiatiayu/how-to-resolve-merge-conflicts-using-the-merge-editor-feature-on-vs-code-pic), + as part of larger [Open-Source Series' Articles](https://dev.to/adiatiayu/series/15234)). ++ [The Ultimate "git nah" Alias](https://laravel-news.com/the-ultimate-git-nah-alias) + to throw away current changes, untracked files and rebase state, + by Paul Redmond on Laravel News. ++ [Understanding Git: The history and internals](https://graphite.dev/blog/understanding-git) + by Kenneth DuMez on the Graphite Blog (more about history and internals than about + understanding Git). See also: + + [GitHistory page in the archives of Git SCM Wiki](https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitHistory.html), + + [The Git Parable](http://tom.preston-werner.com/2009/05/19/the-git-parable.html), + by Tom Preston-Werner (2009) - the ideas behind the architecture of Git; + covered in [Git Rev News #30](https://git.github.io/rev_news/2017/08/16/edition-30/), + + Will Hay Jr.’s [The Architecture and History of Git: A Distributed Version Control System](https://medium.com/@willhayjr/the-architecture-and-history-of-git-a-distributed-version-control-system-62b17dd37742), + mentioned in [Git Rev News #46](https://git.github.io/rev_news/2018/12/19/edition-46/), + + [The History of Git: The Road to Domination in Software Version Control](https://git.github.io/rev_news/2020/02/19/edition-60/) + referenced in [Git Rev News #60](https://git.github.io/rev_news/2020/02/19/edition-60/). ++ [Tracking SQLite Database Changes in Git](https://garrit.xyz/posts/2023-11-01-tracking-sqlite-database-changes-in-git) + with an appropriate `textconv` gitattribute, by Garrit Franke on Garrit's Notes. ++ [GitHub’s all-in bet on AI may overlook Git](https://www.infoworld.com/article/3710428/githubs-all-in-bet-on-ai-may-overlook-git.html) + by Matt Asay on InfoWorld. ++ [🙏 Please Add .gitattributes To Your Git Repository](https://dev.to/deadlybyte/please-add-gitattributes-to-your-git-repository-1jld) + by Carl Saunders on DEV\.to (2020). + + A `.gitattributes` file [can be used to improve](https://github.com/github-linguist/linguist/blob/master/docs/overrides.md#using-gitattributes) + language detection on GitHub, which is using the + [Linguist](https://github.com/github-linguist/linguist) library. + + +__Easy watching and listening__ + ++ [Git Training](https://www.youtube.com/playlist?list=PL1gv5yv3DoZNIPVAlZRGPEB0fBvflO-xN) + playlist of 45 short YouTube videos by Joost De Cock + provides Git training materials for people who would like to understand + how Git works rather than try to memorize all of its commands + without knowing what they do. ++ The Real Python Podcast: + [Episode 179: Improving Your Git Developer Experience in Python](https://realpython.com/podcasts/rpp/179/) + + + +__Git tools and sites__ + ++ [gitattributes.io](https://gitattributes.io/) is a service to generate + [`.gitattributes`](https://git-scm.com/docs/gitattributes) files, + similar to [gitignore.io](https://www.toptal.com/developers/gitignore/). ++ [githistory.xyz](https://githistory.xyz/) is a service that allows to + quickly browse the history of files in any Git repo (from GitHub, GitLab, Bitbucket). + Also available as Chrome, Firefox, and Visual Studio extensions, + and as `git-file-history` command line tool (in Node.js). + Mentioned in passing in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/). ++ Josh Branchaud (jbranchaud) collected a list of + [Today I Learned (TIL) tips about Git](https://github.com/jbranchaud/til#git). ++ [`lei`](https://public-inbox.org/lei.html) is a command-line tool + for importing and searching email, regardless of whether it is from a personal mailbox + or a public-inbox instance, like [public-inbox.org](https://public-inbox.org/README.html) + or [lore.kernel.org](https://lore.kernel.org/).
+ Warning: `lei` is still in its early stages and may destroy mail. + + See also [lore+lei: part 1, getting started](https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started) + article by Konstantin Ryabitsev (2021). ++ [git-fame](https://github.com/casperdcl/git-fame): Pretty-print + Git repository collaborators sorted by contributions (includes computing + code survival). Written in Python. ++ [git-fame-rb](https://github.com/oleander/git-fame-rb) is a command-line tool + that helps you summarize and pretty-print collaborators, based on the number of contributions. + The statistics are mostly based on the output of `git blame` (counting surviving lines). + Written in Ruby. ++ [GQL (Git Query Language)](https://amrdeveloper.github.io/GQL/) + [[repo](https://github.com/AmrDeveloper/GQL)] + is a SQL-like language to perform queries on `.git` files, + with support for many SQL features + such as grouping, ordering and aggregation functions.
+ You can find more in [How I Created a SQL-like Language to Run Queries on Local Git Repositories](https://www.freecodecamp.org/news/gql-design-and-implementation/) + article by Amr Hesham on freeCodeCamp.
+ See also the following tools: + + [Gitana](https://github.com/SOM-Research/Gitana): SQL-based Project Activity Inspector + (repo archived in 2022), + first mentioned in [Git Rev News Edition #7](https://git.github.io/rev_news/2015/09/09/edition-7/). + + [gitbase](https://github.com/src-d/gitbase): SQL interface to Git repositories, written in Go; + (last release from 2019, [homepage](https://docs.sourced.tech/gitbase) is not working), + first mentioned in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/). + + [git-history](https://datasette.io/tools/git-history) is a tool + for analyzing Git history using SQLite (last release in 2021), + first mentioned in [Git Rev News Edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/). + + [MergeStat](https://github.com/mergestat/mergestat) enables SQL queries + for data in Git repositories (and related sources, such as the GitHub API). + There is also the [`mergestat-lite`](https://github.com/mergestat/mergestat-lite) + command line tool, which runs SQL queries against local Git repositories. + First mentioned in [Git Rev News Edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/). + Actively developed, mergestat-lite is written in Go. ++ [GibleFS](https://github.com/fanzeyi/giblefs) is a toy project + that maps a Git repository to a virtual filesystem, which then can be used + to access the repository at any given commit. Written in Rust, does not seem + to be actively developed. ++ The `Git/fs` binary in [Git9](https://orib.dev/git9.html) + (Git client for Plan 9 non-POSIX filesystem) + serves repository history as a file system. ++ [gitfs](https://github.com/presslabs/gitfs) is a FUSE file system + that fully integrates with Git. You can mount a remote repository's branch locally, + and any subsequent changes made to the files will be automatically committed to the remote. + Written in Python, last release in 2019. + + Note: that is not the only project named gitfs or git-fs. ++ [SlothFS](https://github.com/google/slothfs) is a FUSE filesystem + that provides light-weight, lazily downloaded, read-only checkouts + of manifest-based Git projects. It is intended for use with Android. + Written in Go, repository archived in 2022. ++ [GitMounter](https://belkadan.com/source/GitMounter/) is + a toy FUSE browser for Git repos based on [Suffusion](https://belkadan.com/source/Suffusion/). + Requires FUSE, libgit2, pkg-config, and Swift installed. + Written in Swift. + + +## Releases + ++ Git [2.43.0](https://public-inbox.org/git/xmqqzfz8l5or.fsf@gitster.g/), +[2.43.0-rc2](https://public-inbox.org/git/xmqqo7fwxn4s.fsf@gitster.g/), +[2.43.0-rc1](https://public-inbox.org/git/xmqq8r785ev1.fsf@gitster.g/), +[2.43.0-rc0](https://public-inbox.org/git/xmqqy1fgkqg1.fsf@gitster.g/), +[2.42.1](https://public-inbox.org/git/xmqq4ji4m50l.fsf@gitster.g/) ++ Git for Windows [2.43.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.43.0.windows.1), +[2.43.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.43.0-rc2.windows.1), +[2.43.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.43.0-rc1.windows.1), +[2.43.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.43.0-rc0.windows.1) ++ GitLab [16.6](https://about.gitlab.com/releases/2023/11/16/gitlab-16-6-released/), +[16.5.2](https://about.gitlab.com/releases/2023/11/14/gitlab-16-5-2-released/), +[16.5.1, 16.4.2, 16.3.6](https://about.gitlab.com/releases/2023/10/31/security-release-gitlab-16-5-1-16-4-2-16-3-6-released/) ++ Gerrit Code Review [3.6.8](https://www.gerritcodereview.com/3.6.html#368), +[3.7.6](https://www.gerritcodereview.com/3.7.html#376), +[3.8.3](https://www.gerritcodereview.com/3.8.html#383), +[3.9.0-rc6](https://www.gerritcodereview.com/3.9.html#390) ++ GitHub Enterprise [3.11.0](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.0) ++ GitKraken [9.10.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.5](https://desktop.github.com/release-notes/) ++ Tower for Windows [5.2](https://www.git-tower.com/blog/tower-windows-52/) ++ Tower for Mac [10.2](https://www.git-tower.com/blog/tower-mac-102/) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Alexander Shopov, Luca Milanesio, +Bruno Brito, and Štěpán Němec. diff --git a/_posts/2023-12-31-edition-106.markdown b/_posts/2023-12-31-edition-106.markdown new file mode 100644 index 0000000000..2235b148fc --- /dev/null +++ b/_posts/2023-12-31-edition-106.markdown @@ -0,0 +1,404 @@ +--- +title: Git Rev News Edition 106 (December 31th, 2023) +layout: default +date: 2023-12-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 106 (December 31th, 2023) + +Welcome to the 106th 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 November and December 2023. + +## Discussions + + + +### Reviews + ++ [[PATCH 0/4] Switch links to https](https://lore.kernel.org/git/pull.1589.git.1695392027.gitgitgadget@gmail.com/) + + In September, Josh Soref posted a 4-patch series on the + mailing list to improve the URLs used throughout the documentation + and the code base of the project. + + The main goal was to use HTTPS instead of HTTP in the URLs to + improve user security, but along the way some patches replaced URLs + that didn't work anymore with some new ones pointing to the same + content. + + Eric Sunshine replied to Josh's patches asking why one URL was + changed from `http://json.org/` to `https://www.json.org/` instead + of just replacing `http` with `https`. Josh replied that it was + because that website was self-identifying with the latter URL using a + [meta refresh](https://en.wikipedia.org/wiki/Meta_refresh). + + In the meantime, Junio Hamano, the Git maintainer, replied to some + patches saying that it might not be worth updating some URLs, either + because it was clear from the context that they were old, or because + they were part of some code we borrowed from other projects. In some + cases, they were an argument of a Git command and still just worked, + while the meaning of the command changed a bit when `http` was + replaced with `https`. Junio liked the fact that some broken links + were fixed by the series though. + + Josh then sent a + [version 2 of his patch series](https://lore.kernel.org/git/pull.1589.v2.git.1695553041.gitgitgadget@gmail.com/). + This took into account Eric's comments as a commit message was + improved to say that some changes were made to respect a site's + self-identification. Junio's comments were also taken into account + as a number of URLs that were previously changed were now left + as-is. + + Elijah Newren and Junio commented on this new version. They both + suggested improving commit messages or the cover letter of the + series to better explain the reasons for the changes that were made. + In one case, Elijah and Josh discussed replacing the URL of a + website that seemed to be often down with a link to its content on + the [Internet Archive](https://archive.org/). + + In November, Josh then sent a + [version 3 of his patch series](https://lore.kernel.org/git/pull.1589.v3.git.1700796916.gitgitgadget@gmail.com/) + where the first and second patches had been swapped to avoid some + confusion for reviewers who would ask why some URLs weren't changed + in the first patch overlooking that the second one would change them. + + The other significant change compared to version 2 was that Josh + decided not to replace the URL of the website that was often down + saying "we'll risk users getting hacked content from an arbitrary + [MITM](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) + instead of taking archived authenticated content based on the last + time their web site was properly maintained". + + Elijah replied that he would be fine with using the archived link if + it was better justified in the commit message, but said that he also + agreed with merging the whole series as-is, as he had checked all + the links and they all looked good to him. + + Josh replied he could come back later to change the URL and preferred + the series to be merged as-is. He thanked Elijah for taking the time + to re-check every link, saying he knew exactly how tedious that is. + + Junio agreed with merging the series, which is now part of the + 'master' branch. + + + +## Community Spotlight: VonC + +_[VonC](https://stackoverflow.com/users/6309/vonc) is a +prolific contributor to the Git topic on Stack Overflow. This edition features an +interview with him. Thanks to our [survey respondents](https://git.github.io/rev_news/2023/06/30/edition-100#some-statistics-about-the-ongoing-first-git-rev-news-readers-survey) +for suggesting to interview VonC!_ + +* **Who are you and what do you do?** + + By day, I am an information technology consultant working for a computer services + company in France. By night, I am [VonC on Stack Overflow](https://stackoverflow.com/users/6309), + and I have contributed to various topics since its early days (Sept. 2008). + I do that [every single day](https://meta.stackexchange.com/q/122976/6309). + It includes answering questions about Git: [almost 16K answers](https://stackoverflow.com/search?q=user:6309+[git]) + in 15 years. + +* **What would you name your most important contribution to Git?** + + I do not contribute to Git directly, but I report on Stack Overflow + any interesting [git/git commits](https://github.com/git/git/commits/master) + which provides a new answer to old questions. + + I started in 2012 with questions like "[Squash the first two commits in Git?](https://stackoverflow.com/a/598788/6309)" + and "[How do I remove a submodule?](https://stackoverflow.com/a/16162000/6309)". + Then [1630](https://stackoverflow.com/search?page=33&tab=Newest&pagesize=50&q=user%3a6309%20%22see%20commit%22&searchOn=3) + commits followed over the next decade. + +* **Why answering questions about Git on Stack Overflow?** + + As I mentioned in "[**How to earn a million reputation on Stack Overflow: be of service to others**](https://stackoverflow.blog/2022/10/09/how-to-earn-a-million-reputation-on-stack-overflow-be-of-service-to-others/)", + by **[Ryan Donovan](https://twitter.com/RThorDonovan)**, this is a way to + give back to the community, and to learn in the process. + + I learnt Git itself even before installing it, by answering a few + questions on Stack Overflow, as I detailed in "[How'd you get started?](https://meta.stackexchange.com/a/367773/6309)". + +* **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 mentioned in 2013/2016 the issue of [storing large files in Git repositories](https://stackoverflow.com/a/17897705/6309). + + But nowadays, I would work on the workflow side of Git, and how to make + it easier to use for beginners. I follow [GitButler](https://docs.gitbutler.com/) + and [Scott Chacon](https://twitter.com/chacon)'s work. + + > GitButler is rethinking everything between when you write code in your editor of choice and when you push that code to GitHub for review. + > Why are you making 'wip' commits when your SCM should be recording everything for you? + > Why are everyone's commit messages close to useless? + > Why is `git blame` the best way to get context on the code your team has written? + > Why can't you seamlessly transition work between computers? + +* **If you could remove something from Git without worrying about backward compatibility, what would it be?** + + `git checkout`! It is time. As I [explained in 2020](https://stackoverflow.com/questions/58003030/what-is-the-git-restore-command-and-what-is-the-difference-between-git-restor#comment115524702_58003889), + the `git switch`/`git restore` commands are "[experimental](https://github.com/git/git/commit/4e43b7ff1ea4b6f16b93a432b6718e9ab38749bd)" + in name only, and are here to stay. + +* **What is one of your most favorite features of Git?** + + Coming from CVS/SVN, one of my favorite features of Git is its powerful + branching and merging capabilities. Branches in Git are lightweight and + switching between them is fast, making it convenient to manage multiple + streams of work simultaneously (and you have [`git worktree`](https://stackoverflow.com/a/30185564/6309) + if you want to preserve your current working tree). + + I use those branches and merges with ["gitworkflow" (one word)](https://stackoverflow.com/a/57175304/6309), + using long-lived integration branches (like "`master`/`main`/`release`"), + and "ephemeral" integration branches (like "`public`/`next`/`devel`", + created for a specific release cycle, then deleted and recreated for the + next release cycle). See more at "[gitworkflow workflow](https://stackoverflow.com/a/53405887/6309)" + and "[Handle Git branching for test and production](https://stackoverflow.com/a/44470240/6309)". + +* **What is your favorite Git-related tool/library, outside of Git itself?** + + I often used [github.com/github/gitignore](https://github.com/github/gitignore) + ("**A collection of .gitignore templates**"). I have also used and promoted + [`git filter-repo`](https://github.com/newren/git-filter-repo), to + [remove large files from a Git repository](https://stackoverflow.com/a/76300821/6309). + +* **Could you brief a bit about one of your most memorable experiences with Git?** + + My first `git clone`. + + As mentioned in "[How to earn a million reputation on Stack Overflow: be of service to others](https://stackoverflow.blog/2022/10/09/how-to-earn-a-million-reputation-on-stack-overflow-be-of-service-to-others/)", + at the time I stumbled upon Git (2008/2009), I was managing big Rational + ClearCase repositories of terabytes of data. The idea of cloning a *full* (Git) + repository on my laptop was... incongruous, to say the least! + + I am aware of the debate around monorepo vs. multirepo (which sometimes + goes in hand with the debate around monolith vs. microservices), but I found + in the subsequent years that working with multiple small Git repositories was + much more manageable than working with a single large one, as I used to do + before, using huge [ClearCase VOBs](https://www.ibm.com/docs/en/rational-clearcase/9.0.0?topic=clearcase-about-vobs-versioned-objects). + +* **What is your advice for people who want to start using Git? Where and how should they start?** + + Start with understanding Git **branching**, and operations around branches + (switch, merge, rebase, cherry-pick). + + For that, I always redirect people to "[Learn Git Branching](https://learngitbranching.js.org)" + (`learngitbranching.js.org`): nothing to install, all exercises are done + directly in the browser, and it is very visual. + + I also discourage people from blindly following the "[Git Branching Model](https://nvie.com/posts/a-successful-git-branching-model/)", + where an integration branch like `develop` is merged to another integration + one like `master`. See the links above for "gitworkflow" where I explain + why one should merge to an integration branch, not from it: merging *from* + it means you are merging *everything* currently integrated into that branch. + If you want to "exclude" some of those integrated commits, that becomes a + nightmare to manage. + +* **There's a common conception that "Git is confusing". What are your thoughts about the same?** + + Right... you mean [XKCD 1597, Oct. 2015, "Git"](https://explainxkcd.com/wiki/index.php/1597:_Git). + + The level of integration of Git in IDEs (like Eclipse, IntelliJ, VSCode, ...) + has made Git more accessible to beginners. I often redirect them to a combo + VSCode + [GitLens](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens), + and that is enough to get them started. + + As long as the workflow is clearly defined, and the rebase is understood, + for [managing pull request](https://stackoverflow.com/a/44672221/6309) + (you rebase your local feature branch on top of the target branch, + before force pushing it to the remote repository, [with lease](https://stackoverflow.com/a/52937476/6309) + or [if-includes](https://stackoverflow.com/a/64627761/6309)), the users + manage to get by. The bulk of my training is about the PR (Pull Request) + workflow, which involves `git rebase` (`--onto`), and + `git push --force-with-lease `or `--force-if-includes`. + + But clarifying *why* Git exists, and where it comes from (I have younglings + who have no idea who [Linux Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) + is, and his role in the [creation of Git](https://en.wikipedia.org/wiki/Git#History)) + can help. Git comes with a certain vision of how a VCS should work, and + it has a lot to do with the way the Linux kernel is developed. + +* **If there’s one tip you would like to share with other users of Git, what would it be?** + + Stop using `git checkout`, start using `git switch`/`git restore` instead! + +_Editor's note: We hope you enjoyed this interview. We'll explore if we could +interview other such contributors who don't directly participate in the mailing +list. If you have any suggestions, you're most welcome to share them with us through +[our issue tracker](https://github.com/git/git.github.io/issues) or by writing an +email to <>._ + +## Other News + +__Various__ + ++ [Google Summer of Code 2024: Contribute to GitLab and Git to prepare](https://about.gitlab.com/blog/2023/12/20/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare/) + by Christian Couder and Nick Veenhof on GitLab Blog. ++ [Upcoming changes to repository insights [on GitHub]](https://github.blog/changelog/2023-11-29-upcoming-changes-to-repository-insights/) + on GitHub Blog. ++ [Git platform AllSpice now curries favor with enterprises](https://techcrunch.com/2023/12/05/git-allspice-enterprise-6m/) + by Christine Hall on TechCrunch. ++ [GitLab Duo Code Suggestions is generally available](https://about.gitlab.com/blog/2023/12/22/gitlab-duo-code-suggestions-is-generally-available/) + by David DeSanto on GitLab Blog. + [GitLab Code Suggestions](https://about.gitlab.com/solutions/code-suggestions/) + is an alternative to [GitHub Copilot](https://github.com/features/copilot) + and (to a lesser extent) [OpenAI ChatGPT](https://chat.openai.com/). + + +__Light reading__ + ++ Julia Evans continues her streak of Git-related blog posts with + [Mounting git commits as folders with NFS](https://jvns.ca/blog/2023/12/04/mounting-git-commits-as-folders-with-nfs/) + (and FUSE), about the experimental [git-commit-folders](https://github.com/jvns/git-commit-folders) + tool. This tool was mentioned in [previous Git Rev News](https://git.github.io/rev_news/2023/11/30/edition-105/). ++ Julia Evans also published a few comics about Git at [Wizard Zines comics](https://wizardzines.com/comics/), + for a zine on Git that she is currently writing + (these are only the most recent ones; some earlier comics made it into + [Oh Shit, Git! Recipes for getting out of git mess](https://wizardzines.com/zines/oh-shit-git/) zine): + + [every git jargon](https://wizardzines.com/comics/every-git-jargon/) + + [git discussion bingo](https://wizardzines.com/comics/git-discussion-bingo/) + + [every git command I use](https://wizardzines.com/comics/every-git-command/) + + [meet the branch](https://wizardzines.com/comics/meet-the-branch/) + + [branches have no rules](https://wizardzines.com/comics/branches-have-no-rules/) + (at least no built-in ones, though you can try to enforce some with [git hooks](https://githooks.com/)) + + [`HEAD` and heads](https://wizardzines.com/comics/head-and-heads/) + + [my rules for rebasing](https://wizardzines.com/comics/rules-for-rebasing/) ++ [Every engineer should understand git reflog](https://graphite.dev/blog/every-engineer-should-understand-git-reflog) + by Harsh Siriah on Graphite Blog. ++ [Fine-grained file differences](https://www.johndcook.com/blog/2023/12/13/fine-grained-file-differences/) + by John D. Cook on his blog. ++ [DiffDebugging](https://martinfowler.com/bliki/DiffDebugging.html) + by Martin Fowler on his blog/wiki. Page created in 2004, rewritten in 2013. ++ [Monorepo, Poly-repo, or No Repo at all? + Using Bit to make “irreversible decisions” easy to make and change.](https://blog.bitsrc.io/monorepo-poly-repo-or-no-repo-at-all-830328c7a546) + by Eden Ella on Bits and Pieces blog. + + [Bit](https://bit.dev/), a build system for composable software, + was first mentioned in [Git Rev News Edition #45](https://git.github.io/rev_news/2018/11/21/edition-45/) + (then at the old bitsrc\.io URL). + + It was mentioned again in [Git Rev News Edition #77](https://git.github.io/rev_news/2021/07/31/edition-77/) + in [How to Collaborate on Components across Projects with Bit](https://dev.to/giteden/how-to-collaborate-on-components-across-projects-with-bit-29c3) by Eden Ella on DEV\.to. ++ [Recovering Deleted Files From Your Git Working Tree](https://www.smashingmagazine.com/2023/12/recovering-deleted-files-git-working-tree/) + by Oluwasanmi Akande on Smashing Magazine. ++ [Git Grep Like a Pro: The Complete Guide](https://www.kosli.com/blog/git-grep-like-a-pro-the-complete-guide/) + by Bruce Johnston on Kosli Blog (2022). ++ [Flexible Identities in git](https://belkadan.com/blog/2020/02/Flexible-Identities-in-git/) + proposal (to avoid "deadnaming" and bury an old name while preserving a link to things done under the old name) + by Jordan Rose on -dealloc blog (2020). + + +__Easy watching__ + ++ [Git From the Bits Up](https://www.youtube.com/watch?v=mdvlu_R8EWE) + by Tim Berglund, DataStax. Recorded at [Jfokus](http://www.jfokus.com) 2016. + + +__Git tools and sites__ + ++ [dyff](https://github.com/homeport/dyff) /ˈdʏf/ is a diff tool for YAML files, + and sometimes JSON. Can be used as Git diff driver (see documentation). + Written in Go, uses MIT license. ++ [Git-LaTeXdiff](https://gitlab.com/git-latexdiff/git-latexdiff) is a tool + to graphically visualize differences between different versions of a LaTeX file. + It is a wrapper around Git and [latexdiff](https://www.ctan.org/pkg/latexdiff) + (which is present [on CTAN](https://www.ctan.org/pkg/latexdiff), Comprehensive TeX Archive Network). + `git-latexdiff` is written as a BSD-licensed Bash script, + while `latexdiff` is written in Perl (and is GPLv3-licensed). + The git-latexdiff tool was mentioned in passing in + [Git Rev News Edition #8](https://git.github.io/rev_news/2015/10/14/edition-8/). ++ [git-oops](https://github.com/jvns/git-oops) is a **very experimental** tool + allowing to undo a Git operation without having to remember the specific + invocation, in the style of the undo features in [GitUp](https://gitup.co/), [jj](https://github.com/martinvonz/jj), and [git-branchless](https://github.com/arxanas/git-branchless). + According to its author, it is meant as just a prototype serving + "as inspiration for a better tool that actually works reliably" + (see the repository README for details). Written in Python, MIT license. + Prior art includes: + + One of git-oops inspirations, the [undo command in git-branchless](https://github.com/arxanas/git-branchless/wiki/Command:-git-undo), + described in [git undo: We can do better](https://blog.waleedkhan.name/git-undo/), + which was mentioned in [Git Rev News Edition #76](https://git.github.io/rev_news/2021/06/27/edition-76/). + + A very basic and limited [Git Undo [alias]](https://megakemp.com/2016/08/25/git-undo/), + mentioned in [Git Rev News Edition #19](https://git.github.io/rev_news/2016/09/14/edition-19/) + (resets state using reflog). + + Many IDE and programming editors, their Git-related extensions/plugins, + and Git GUIs have some kind of universal "git undo". One example is + Tower Git GUI, whose undo abilities are described in + [CMD+Z for Git is Here](https://css-tricks.com/cmdz-for-git-is-here/) + (mentioned in [Git Rev News Edition #65](https://git.github.io/rev_news/2020/07/29/edition-65/)). + Contrast with tools of similar scope and/or name, but which do something different: + + [thefuck](https://github.com/nvbn/thefuck), a command line application + which corrects your previous console command (for example Git command) + if you made an error and it _didn't_ do what you wanted; + the tool was mentioned in + [Git Rev News Edition #101](https://git.github.io/rev_news/2023/07/31/edition-101/). + + [git-undo-el](https://github.com/jwiegley/git-undo-el), + a command for Emacs editor to "undo" changes to selected region of a file + through its Git history, mentioned in + [Git Rev News Edition #34](https://git.github.io/rev_news/2017/12/20/edition-34/). ++ [git-vee](https://github.com/mjdominus/git-util/blob/master/bin/git-vee) + is a shell script that prepares a brief summary of how your current branch + has diverged from a corresponding remote branch. Mentioned on + [git-vee](https://www.plover.com/misc/stop-merging/slide019.html) slide + in [Cleaner `git` history](https://www.plover.com/misc/stop-merging/slide001.html) + (also known as "Stop merging master") by Mark Jason Dominus (the author of the tool), + from 2013. ++ [Breezy](https://www.breezy-vcs.org/) is a version control system implemented in Python + with multi-format support and an emphasis on hackability. + Currently, Breezy has built-in support for the Git and Bazaar file formats and network protocols. + GPLv2 licensed. ++ [FlatGitHub](https://flatgithub.com/) or Flat View is a simple tool for exploring + flat data files in GitHub repositories. + Part of the [Flat Data](https://githubnext.com/projects/flat-data) project (formerly GitHub OCTO), + mentioned in [Git Rev News Edition #75](https://git.github.io/rev_news/2021/05/27/edition-75/) + (under old URL) and [Edition #96](https://git.github.io/rev_news/2023/02/28/edition-96/), + which in turn was based on the [“git scraping” approach pioneered by Simon Willison](https://simonwillison.net/2020/Oct/9/git-scraping/), + mentioned in [Git Rev News Edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/). + See the example of [flat-demo-bitcoin-price](https://flatgithub.com/githubocto/flat-demo-bitcoin-price?filename=btc-price-postprocessed.json&sha=78b38f641f8f1ffccae733749545ea42cf5eddf9). ++ [AllSpice.io](https://allspice.io/) is a Git platform for hardware developers + (named after SPICE ("Simulation Program with Integrated Circuit Emphasis"), + a general-purpose, open-source analog electronic circuit simulator). + No free tier. ++ [typos](https://github.com/crate-ci/typos) is a source code spell checker, + which finds and corrects spelling mistakes in source code; + intended to be fast enough to run on monorepos and have few false positives, + so it can safely run unassisted, for example on PRs. Written in Rust. + + Mentioned in [Perl Advent Calendar 2023 - Elves Versus Typos](https://perladvent.org/2023/2023-12-21.html). ++ [dat](https://github.com/dat-ecosystem/dat) is a tool for peer-to-peer sharing + & live synchronization of files via command line. Part of the [dat-ecosystem](dat-ecosystem.org). + You can use the `dat` command line tool to share files with version control, + back up data to servers, browse remote files on demand, and automate long-term data preservation. + Written in JavaScript for running with Node.js. + + +## Releases + ++ Gerrit Code Review [3.9.1](https://www.gerritcodereview.com/3.9.html#391) ++ GitHub Enterprise [3.11.2](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.2), +[3.11.1](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.1), +[3.10.4](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.4), +[3.9.7](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.7), +[3.8.12](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.12), +[3.7.19](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.19), +[3.11.0](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.0) ++ GitLab [16.7](https://about.gitlab.com/releases/2023/12/21/gitlab-16-7-released/), +[16.6.2, 16.5.4, 16.4.4](https://about.gitlab.com/releases/2023/12/13/security-release-gitlab-16-6-2-released/), +[16.6.1, 16.5.3, 16.4.3](https://about.gitlab.com/releases/2023/11/30/security-release-gitlab-16-6-1-released/) ++ GitKraken [9.11.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.6](https://desktop.github.com/release-notes/) ++ Sourcetree [4.2.6](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.6.html) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from VonC, Josh Soref and Štěpán Němec. diff --git a/_posts/2024-01-31-edition-107.markdown b/_posts/2024-01-31-edition-107.markdown new file mode 100644 index 0000000000..4948ef3ea6 --- /dev/null +++ b/_posts/2024-01-31-edition-107.markdown @@ -0,0 +1,304 @@ +--- +title: Git Rev News Edition 107 (January 31st, 2024) +layout: default +date: 2024-01-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 107 (January 31st, 2024) + +Welcome to the 107th 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 December 2023 and January 2024. + +## Discussions + + + + + +### Support + +* [Git Rename Detection Bug](https://public-inbox.org/git/LO6P265MB6736043BE8FB607DB671D21EFAAAA@LO6P265MB6736.GBRP265.PROD.OUTLOOK.COM/) + + Jeremy Pridmore reported an issue to the Git mailing list. He used + [`git bugreport`](https://git-scm.com/docs/git-bugreport), so his + message looks like a filled out form with questions and answers. + + He was trying to cherry-pick changes from one repo (A) to another (B), + while both A and B came from the same original TFS server but with + different set of changes. He was disappointed though because some + files that had been moved in repo A were matched up by the rename + detection mechanism to files other than what he expected in repo B, + and he wondered if the reason for this was the new 'ort' merge + strategy described in a + [blog post by Elijah Newren](https://blog.palantir.com/optimizing-gits-merge-machinery-1-127ceb0ef2a1). + + While not obvious at first, Jeremy's primary problem specifically + centered around cases where there were multiple files with 100% + identical content. For example, originally there could have + been an `orig/foo.txt` file, while one of the descendant repos + does not have that file anymore but instead has two files, + `dir2/foo.txt` and `dir3/foo.txt`, both with contents identical + to the original `orig/foo.txt`. So, Git has to figure out which + one of `dir2/foo.txt` and `dir3/foo.txt` is the result of renaming + `orig/foo.txt`. + + Elijah replied to Jeremy explaining extensively how rename detection + works in Git. Elijah pointed out that Jeremy's problem, as + described, did not involve directory rename detection (despite + looking kind of like a directory rename detection problem). Also, + since Jeremy pointed out that the contents of the "misdetected" + renames had identical contents to what they were paired with, that + meant that only exact renames were involved. Because of these two + factors, Elijah said that the new 'ort' merge strategy, which he + implemented, and which replaced the old 'recursive' strategy, should + use the same rename detection rules as that old strategy for + Jeremy's problem. Elijah suggested adding the `-s recursive` option + to the cherry-pick command to verify this and check if it worked + differently using the old 'recursive' strategy. + + Elijah also pointed out that for exact renames in a setup like this, + other than Git giving a preference to files with the same basename, + if there are multiple choices with identical content then it will + just pick one essentially at random. + + Jeremy replied to Elijah saying that this sounded like what he was + observing. He gave some more examples, showing that when there are + multiple 100% matches, Git didn't always match up the files that he + wanted but matched files differently. Jeremy suggested that + filename similarity (beyond just basename matching) be added as a + secondary criteria to content similarity for rename detection, since + it would help in his case. + + Elijah replied that he had tried a few filename similarity ideas, + and added a "same basename" criteria for inexact renames in the + `ort` merge strategy along these lines. However, he said other + filename similarity measurements he tried didn't work out so well. + He mentioned that they risk being repository-specific (in a way + where they help with merges in some repositories but actually hurt + in others). He also mentioned a rather counter-intuitive result + that filename comparisons could rival the cost of content + comparisons, which means such measurements could adversely affect + performance and possibly even throw a monkey wrench in multiple of + the existing performance optimizations in the current merge + algorithm. + + The thread also involved additional explanations about various facts + involving rename detection. This included details about how renames + are just a hint for developers as they are not recorded, but are + instead computed from scratch in response to user commands. It also + included details about what things like "added by both" means + (namely that both sides added the same filename but with different + contents), why you never see "deleted by both" as a conflict status + (there is no conflict; the file can just be deleted), and other + minor points. + + Elijah also brought up a slightly more common case that mirrors the + problems Jeremy saw, where users could be surprised by the per-file + content similarity matching that Git does. This more general case + arises from having multiple copies of a versioned library. For + example, you may have a "base" version with a directory named + "library-x-1.7/", and a "stable" version has many changes in that + directory, while a "development" branch has removed that directory + but has added both a "library-x-1.8/" and a "library-x-1.9/" + directory which both have changes compared to "library-x-1.7/". In + such a case, if you are trying to cherry-pick a commit involving + several files modified under "library-x-1.7/", where do the changes + get applied? Some users might expect the changes in that commit to + get applied to "library-x-1.8/", while others might expect them to + get applied to "library-x-1.9/". In practice, though, it would not + be uncommon for Git to apply the changes from some of the files in + the commit to "library-x-1.8/" and changes from other files in the + commit to "library-x-1.9/". Elijah explained why this happens and + suggested a hack for users dealing with this particular kind of case + to work around rename detection. + + Philip Oakley then chimed into the discussion to suggest using + "BLOBSAME" for exact renames in the same way as "TREESAME" is used + in `git log` for history simplification. Elijah replied to Philip + that he thinks that 'exact rename' already works. Junio C Hamano, + the Git maintainer, then pointed out that "TREESAME" is a property + of commits, not trees, and suggested using words other than + "BLOBSAME" and "TREESAME" in the context of rename detection. + + Philip and Elijah discussed terminology at more length, agreeing + that good terminology can sometimes help people coming from an "old + centralised VCS" make the mind shift to understand Git's model, but + didn't find anything that would help in this case. + + Finally, Philip requested more information about how Git computes + file content similarity (for inexact rename detection), referencing + Elijah's mention of "spanhash representation". Elijah explained the + internal data structure in detail, and supported his earlier claim + that "comparison of filenames can rival the cost of file content + similarity computations". + + + +## Other News + +__Various__ ++ [The contributions GitLab's Git team made to the Git 2.43 release](https://about.gitlab.com/blog/2024/01/11/the-contributions-we-made-to-the-git-2-43-release/) + by John Cai on GitLab Blog. + + See also [Highlights from Git 2.43](https://github.blog/2023-11-20-highlights-from-git-2-43/) + by Taylor Blau on GitHub Blog, covering different changes, + included in [Git Rev News Edition #105](https://git.github.io/rev_news/2023/11/30/edition-105/). ++ GitHub has [Copilot](https://github.com/features/copilot), + GitLab has [Duo Code Suggestions](https://about.gitlab.com/solutions/code-suggestions/); + now Bitbucket has [integration with Tabnine](https://marketplace.atlassian.com/apps/1227931/tabnine-teams-for-bitbucket-cloud): + [Accelerate your development process with Tabnine AI and Bitbucket](https://community.atlassian.com/t5/Bitbucket-articles/Accelerate-your-development-process-with-Tabnine-AI-and/ba-p/2576062). + + +__Light reading__ ++ [I Taught GIT to High School Students: My Experience as Linux Day Mentor](https://blog.coluzziandrea.com/git-00-linux-day) + by Coluzzi Andrea on his blog (and also [on DEV\.to](https://dev.to/coluzziandrea/i-taught-git-to-high-school-students-3a16)). ++ [How Framer Manages Their Codebase with Tower](https://www.git-tower.com/blog/how-framer-uses-tower/) + by Bruno Brito on Tower’s blog. ++ Julia Evans continues her series of articles about Git with + [Do we think of git commits as diffs, snapshots, and/or histories?](https://jvns.ca/blog/2024/01/05/do-we-think-of-git-commits-as-diffs--snapshots--or-histories/) + and [Inside .git](https://jvns.ca/blog/2024/01/26/inside-git/) + (the latter in both a comic and a text version). ++ [Minimal contents of a .git folder](https://manuel-strehl.de/minimal_git_folder) + by Manuel Strehl on A Peculiar Zoo of Thoughts blog. ++ [Git Config Settings I Always Recommend](https://dev.to/bpugh/git-config-settings-i-always-recommend-11fa) + by Brandon Pugh on DEV\.to (and also [on his blog](https://www.brandonpugh.com/blog/git-config-settings-i-always-recommend/)); + though setting `pull.rebase` to `true` depends on whether project prefers merges or rebases, + and is very project-dependent. ++ [Git Lesson: How to Use .gitignore and .gitkeep?](https://dev.to/ritaly/git-lesson-how-to-use-gitignore-and-gitkeep-5edm) + by Rita {FlyNerd} Lyczywek on DEV\.to (translated [from original article in Polish](https://www.flynerd.pl/2024/01/gitignore-i-gitkeep.html)). ++ [Git Prom! My Favorite Git Alias](https://dev.to/technosophos/git-prom-my-favorite-git-alias-2mbd) + (to fetch the latest upstream HEAD and rebase your current branch on top of it) + by Matt Butcher on DEV\.to. ++ [Integrating DVC and Git LFS via libgit2 filters](https://dvc.ai/blog/dvc-git-lfs) + by Peter Rowlands on DVC AI Blog. [DVC](https://dvc.org/) (Data Version Control) + was first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/), + with links to different articles about it in + [#42](https://git.github.io/rev_news/2018/08/22/edition-42/), + [#63](https://git.github.io/rev_news/2020/05/28/edition-63/), + [#64](https://git.github.io/rev_news/2020/06/25/edition-64/), + [#72](https://git.github.io/rev_news/2021/02/27/edition-72/), + and [#100](https://git.github.io/rev_news/2023/06/30/edition-100/). ++ [Version Control for Machine Learning](https://dagshub.com/blog/version-control/) + by Nikitha Narendra on DagsHub Blog. The [DAGsHub](https://dagshub.com/) service was + first mentioned in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/); + further articles about this web platform for data version control + linked in [Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/), + [#96](https://git.github.io/rev_news/2023/02/28/edition-96/), + and [#97](https://git.github.io/rev_news/2023/03/31/edition-97/). ++ [RFC: Bridging GitHub workflows with b4](https://lore.kernel.org/tools/20231213-fluffy-roaring-capuchin-8024ac@meerkat/T/) + by Konstantin Ryabitsev on Linux kernel tools mailing list via lore.kernel.org. ++ [Jujutsu: a new, Git-compatible version control system](https://lwn.net/Articles/958468/) + by Daroc Alden on LWN\.net ([free link](https://lwn.net/SubscriberLink/958468/09ff53915f2ae020/)). + Jujutsu was first mentioned in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/); + there was also a [Jujutsu: A Git-Compatible VCS](https://www.youtube.com/watch?v=bx_LGilOuE4) + talk by Martin von Zweigbergk at Git Merge 2022, mentioned in passing + in [Git Rev News Edition #91](https://git.github.io/rev_news/2022/09/30/edition-91/). + ++ [Praise, Criticism, and Dialogue](https://rhaas.blogspot.com/2023/12/praise-criticism-and-dialogue.html) + (in open source code review process) + by Robert Haas (PostgreSQL contributor) on his Blogspot blog. ++ [Being friendly: friendly forks 101](https://github.blog/2022-04-25-the-friend-zone-friendly-forks-101/) + and [Being friendly: Strategies for friendly fork management](https://github.blog/2022-05-02-friend-zone-strategies-friendly-fork-management/) + by Lessley Dennington on GitHub Blog (2022). + + + +__Git tools and sites__ ++ [Git-RDM](https://github.com/ctjacobs/git-rdm) had intended to be + a Research Data Management (RDM) plugin for the Git version control system. + It interfaces Git with data hosting services to manage the curation of version controlled files + using persistent, citable repositories. Access to hosting services is managed with + [PyRDM library](https://pyrdm.readthedocs.io/), which supports Figshare, Zenodo, + and (in a limited fashion) DSpace-based services using SWORD protocol version 2. + Written in Python, last released in 2016. + + See also the "[Git-RDM: A research data management plugin for the Git version control system](https://joss.theoj.org/papers/10.21105/joss.00029)" + article in The Journal of Open Source Software (2016). ++ [GitVision](https://github.com/gaspardIV/gitvision) is a web tool + designed to visualize Git repositories in virtual, augmented, and 3D reality. + Developed with Vue 3 in Vite by Kacper Konecki (GaspardIV). + There is a live demo of GitVision at [gitvis.web.app](https://gitvis.web.app/), + including quite a few tiny, small, medium and large example repositories; + you can also visualize your own repository by uploading data prepared using + [GitVision script](https://github.com/GaspardIV/gitvision/tree/main/tool) + (or you can use the tool locally). + + It provides a type of 3D visualization different from the much better known + [Gource](https://gource.io/) visualization tool for source control repositories. + There the repository is displayed as a tree where the root of the repository is the center, + directories are branches and files are leaves. Contributors to the source code + appear and disappear as they contribute to specific files and directories. + + Has different purpose than [Git History.xyz](https://githistory.xyz/) + web app that allows to quickly browse the history of files in any git repo, + mentioned in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/) + and [#105](https://git.github.io/rev_news/2023/11/30/edition-105/). + + See also the [VR-Git: Git Repository Visualization and Immersion in Virtual Reality](https://opus-htw-aalen.bsz-bw.de/frontdoor/deliver/index/docId/2472/file/ICSEA22-VRGit_OberhauserCR2.pdf) (PDF) + paper by Roy Oberhauser (2022). ++ The [Visualize Git](http://git-school.github.io/visualizing-git/) web app illustrates what's going on + under the hood when you use common Git operations. You'll see what exactly is happening + to your commit graph. Powered by D3. Sources on GitHub as [git-school/visualizing-git](https://github.com/git-school/visualizing-git). + This app is quite similar to the free playground mode of + [Visualizing Git Concepts with D3](https://onlywei.github.io/explain-git-with-d3/), + first mentioned in [Git Rev News #69](https://git.github.io/rev_news/2020/11/27/edition-69/). + Compare with: + + [Learn Git Branching](https://learngitbranching.js.org/), + mentioned first in [Git Rev News Edition #30](https://git.github.io/rev_news/2017/08/16/edition-30/). + + [Git Gud](https://nic-hartley.github.io/git-gud/), a visual web-based Git simulator, + meant to help understand Git better, announced by its author Nic Hartley in + [Git Gud at git](https://dev.to/nichartley/git-gud-at-git-5d9k). + First mentioned in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/). + + [Git Gud](https://github.com/benthayer/git-gud), a command line game + designed to help you learn how to use the Git version control system. + Written in Python by Ben Thayer. First mentioned in + [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/). + + [Oh My Git!](https://ohmygit.org/), an open source game about learning Git, + written using the Godot game engine ([source](https://github.com/git-learning-game/oh-my-git)). + There was a lightning talk about this game at FOSDEM 2021: + [Building a Git learning game: A playful approach to version control](https://fosdem.org/2021/schedule/event/git_learning_game/). + First mentioned in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/). + + [Git-Sim](https://github.com/initialcommit-com/git-sim) tool (written in Python) + to visually simulate Git operations in your own repos with a single terminal command. + Described in [Git-Sim: Visually Simulate Git Operations In Your Own Repos](https://initialcommit.com/blog/git-sim) + (mentioned in [Git Rev News Edition #95](https://git.github.io/rev_news/2023/01/31/edition-95/)) + and [Git-Sim 3 Month Dev Update: Community Response, New Features, & The Future](https://initialcommit.com/blog/git-sim-3-month-dev-update) + (mentioned in [Edition #98](https://git.github.io/rev_news/2023/04/30/edition-98/)). ++ [List of git mistakes](https://gist.github.com/jvns/f7d2db163298423751a9d1a823d7c7c1) + people have listed on Mastodon, gathered by Julia Evans (@b0rk@jvns.ca). + + +## Releases + ++ GitHub Enterprise [3.11.3](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.3), +[3.10.5](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.5), +[3.9.8](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.8), +[3.8.13](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.13) ++ GitLab [16.8.1, 16.7.4, 16.6.6, 16.5.8](https://about.gitlab.com/releases/2024/01/25/critical-security-release-gitlab-16-8-1-released/), +[16.8](https://about.gitlab.com/releases/2024/01/18/gitlab-16-8-released/), +[16.7.3](https://about.gitlab.com/releases/2024/01/12/gitlab-16-7-3-released/), +[16.7.2, 16.6.4, 16.5.6](https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/) ++ Bitbucket Server [8.17](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitKraken [9.11.1](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.8](https://desktop.github.com/release-notes/), +[3.3.7](https://desktop.github.com/release-notes/) ++ Tower for Mac [10.3](https://www.git-tower.com/release-notes?show_tab=release-notes) ++ Tower for Windows [5.5](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Elijah Newren, Bruno Brito, Brandon Pugh and Štěpán Němec. diff --git a/_posts/2024-02-29-edition-108.markdown b/_posts/2024-02-29-edition-108.markdown new file mode 100644 index 0000000000..1c53358778 --- /dev/null +++ b/_posts/2024-02-29-edition-108.markdown @@ -0,0 +1,217 @@ +--- +title: Git Rev News Edition 108 (February 29th, 2024) +layout: default +date: 2024-02-29 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 108 (February 29th, 2024) + +Welcome to the 108th 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 January and February 2024. + +## Discussions + + + + + +### Support + +* [[Bug?] "`git diff --no-rename A B`"](https://lore.kernel.org/git/xmqq34uvtpob.fsf@gitster.g/) + + Junio Hamano, the Git maintainer, sent an email to the mailing list + saying that when `git diff` was used with `--no-rename` instead of + `--no-renames`, rename detection was still performed. He + wondered if that was a bug, because either `--no-rename` should be + interpreted as being a shortened form of `--no-renames`, which is + [a valid option](https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---no-renames) + and should disable rename detection, or `--no-rename` should be + rejected with an error message and termination of `git diff`. + + Dragan Simic replied to Junio that indeed, in case the option is not + recognized, an error message should be emitted. + + Jeff King, alias Peff, also replied to Junio saying he tried + `--no-foo`, which properly errored out. He then wondered if it could + be a bug in the `parse-options` code that could be confused because + `git diff` has both `--[no-]rename-empty` and `--no-renames`. As + there is an abbreviation ambiguity between `--no-rename-empty` and + `--no-renames` when `--no-rename` is used, the `parse-options` code + should not allow such an abbreviation and should error out. + + He suggested, as an alternative to fixing the bug, that a new + `--renames` option could be introduced. It would be synonymous to + `--find-renames`, which is currently the only opposite to + `--no-renames`. He proposed a patch to do that and showed that after + his patch, `--no-rename` would properly error out. + + René Scharfe replied to Peff that the issue came from a patch + written in 2019 that disabled abbreviated options when there could + be an ambiguity. The code handling abbreviations would trigger not + only if the condition guarding it was satisfied, but also if it was + reached through a `goto` statement. The patch disabling abbreviated + options only took care of the condition guarding that code, but not of + the `goto` statement. Along with these explanations, René provided a + patch fixing the bug. + + Junio thanked René for spotting the "nasty" bug and said he agreed + that the code was confusing. + + René replied to Junio with a follow-up patch removing the + `goto` statement. + + Peff also replied to René's first patch wondering if it fixed all + the possible issues, but then in a reply to himself agreed that + René's patch was indeed fixing all the issues discussed. + + Junio later merged both of René's patches, and they were part of the + recently released Git versions 2.43.2, 2.43.3 and 2.44.0. + + _Bonus reading_: ["A Case against the GO TO Statement"](https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD215.html) + by Edsger W. Dijkstra + + + +## Other News + +__Various__ + +- The Git project has been accepted as a [Mentor Organization](https://summerofcode.withgoogle.com/programs/2024/organizations/git) for Google Summer of Code (GSoC) 2024. We can still add project ideas to our [idea page](https://git.github.io/SoC-2024-Ideas/), and volunteers to (co-)mentor are still welcome. Feel free to join the discussion in [the corresponding thread](https://public-inbox.org/git/1de82b27-116a-450e-98c0-52eb65a8f608@gmail.com/). Also, feel free to spread the word about Git's participation. ++ [Highlights from Git 2.44](https://github.blog/2024-02-23-highlights-from-git-2-44/) + by Taylor Blau on GitHub Blog. ++ [GitLab's contributions to Git 2.44.0](https://about.gitlab.com/blog/2024/02/26/gitlabs-contributions-to-git-2-44-0/) + by Patrick Steinhardt on GitLab Blog. + + +__Light reading__ + ++ [Git Tips and Tricks: a 3 part series](https://blog.gitbutler.com/git-tips-and-tricks/) + by Scott Chacon on [GitButler](https://gitbutler.com/) blog, + accompanying the video from the talk + [So You Think You Know Git - FOSDEM 2024](https://www.youtube.com/watch?v=aolI_Rz0ZqY) + (available on YouTube); find the talk slides (and later the "official" video) in the [FOSDEM archive](https://fosdem.org/2024/schedule/event/fosdem-2024-3611-so-you-think-you-know-git/). + + [Git Tips 1: Oldies but Goodies](https://blog.gitbutler.com/git-tips-1-theres-a-git-config-for-that/): + conditional configs, git blame and log with line ranges (`-L`), + git blame with following, word diff, resolution reuse (`git rerere`). + + [Git Tips 2: Some Subtle New Things](https://blog.gitbutler.com/git-tips-2-new-stuff-in-git/): + git branch stuff (`--sort`, `--column`), safe force-pushing (`--force-with-lease`), + SSH commit signing, push signing, `git maintenance`. + + [Git Tips 3: Really Large Repositories and Monorepos](https://blog.gitbutler.com/git-tips-3-really-large-repositories/): + prefetching, commit graph, filesystem monitor, partial cloning, sparse checkouts, + the [scalar](https://git-scm.com/docs/scalar) tool. ++ [Git Trailers](https://alchemists.io/articles/git_trailers) by Brooke Kuhlmann. Learn how to + leverage commit metadata for powerful automations and more human-readable commit messages. ++ [More Expressive Commits with Gitmoji ☺️](https://www.git-tower.com/blog/gitmoji/) + by Bruno Brito on Tower’s blog. + + [Gitmoji](https://gitmoji.dev/) was first mentioned in [Git Rev News Edition #47](https://git.github.io/rev_news/2019/01/23/edition-47/), + though then under a [different URL](https://gitmoji.carloscuesta.me/) + (which now redirects to the current one). + + The similar [Emoji-Log](https://github.com/ahmadawais/Emoji-Log) commit log messages standard + was mentioned in [Git Rev News Edition #101](https://git.github.io/rev_news/2023/07/31/edition-101/). ++ [My Git pre-commit hook contained a footgun](https://blog.plover.com/prog/git/hook-disaster.html) + by Mark Dominus (陶敏修) on his blog (The Universe of Discourse). ++ Julia Evans continues her series of blog posts about Git with + [Dealing with diverged git branches](https://jvns.ca/blog/2024/02/01/dealing-with-diverged-git-branches/) + and [Popular git config options](https://jvns.ca/blog/2024/02/16/popular-git-config-options/). + First entry in this series can be found in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/). ++ [Git Battle: YOLO Mode vs. Clean History](https://hankadev.com/git-battle-yolo-mode-vs-clean-history/) + by Hana Klingová on her blog (and also [on DEV.to](https://dev.to/hankadev/git-battle-yolo-mode-vs-clean-history-594d)): + about usefulness of `git commit --fixup` and `rebase.autosquash`. ++ [Restore deleted/lost files with git](https://dev.to/this-is-learning/restore-deletedlost-files-with-git-3lf7) + by Leonardo Montini for This is Learning, part 6 of + [git better - Improve your git skills (6 Part Series)](https://dev.to/balastrong/series/21372). + Originally published [at leonardomontini.dev](https://leonardomontini.dev/git-restore-deleted-file/) + (includes [video version](https://youtu.be/TL_t3aOXumo)). ++ [My favourite Git commit](https://dhwthompson.com/2019/my-favourite-git-commit) (2019) + by David Thompson on his blog, + about the benefits of good commit messages (the example is a one-character change).
+ Includes links to the following recommended articles on the same topic: + + [Telling stories through your commits](https://blog.mocoso.co.uk/posts/talks/telling-stories-through-your-commits/) by Joel Chippindale (2016). + + [A branch in time](https://tekin.co.uk/2019/02/a-talk-about-revision-histories) by Tekin Süleyman (2019). ++ [Contribution experience report: Git](https://antonin.delpeuch.eu/posts/contribution-experience-report-git/) + by Antonin Delpeuch on his blog. + + +__Easy watching__ + ++ [So You Think You Know Git - FOSDEM 2024](https://www.youtube.com/watch?v=aolI_Rz0ZqY) + by Scott Chacon on YouTube, 47 minutes long (mentioned above). + + +__Git tools and sites__ + ++ [Milestoner](https://alchemists.io/projects/milestoner) by Brooke Kuhlmann. Significant updates + have been made where you can build release notes from your commit messages based on Git notes and + trailers in multiple formats: console, AsciiDoc, Markdown, and HTML. Includes automatic calculation + of your next version and automatic tagging. ++ [git-cliff](https://git-cliff.org/) is a highly customizable changelog generator + using regex-powered custom parsers that can generate changelog files for any Git repository + which follows the [conventional commits](https://www.conventionalcommits.org/) specification. + Written in Rust as a command-line application. ++ [LearnGit.io](https://learngit.io) is an upcoming resource for learning Git using videos with + motion graphics. The project is by Jack Lot who posts Git videos on + [The Modern Coder](https://www.youtube.com/@themoderncoder) YouTube channel. Jack is looking for + intermediate/advanced Git users for feedback. If interested email <>. ++ [pg-diff](https://michaelsogos.github.io/pg-diff/) is a PostgreSQL schema and data comparing tool. + Written in JavaScript by Michael Sogos. ++ [Another trivial utility: git-q](https://blog.plover.com/prog/git-q.html) by Mark Dominus + available from [mjdominus personal git-util repository](https://github.com/mjdominus/git-util) + as [`git-q`](https://github.com/mjdominus/git-util/blob/master/bin/git-q). ++ [Aho](https://github.com/djanderson/aho) is a Git implementation in AWK. + It is a _toy project_ to explore some of the internals of Git and newer features of GNU AWK (aka Gawk). + + +## Releases + ++ Git [2.44.0](https://public-inbox.org/git/xmqqbk87w164.fsf@gitster.g/), +[2.43.3](https://public-inbox.org/git/xmqqil2fw16c.fsf@gitster.g/), +[2.44.0-rc2](https://public-inbox.org/git/xmqqbk8brrj3.fsf@gitster.g/), +[2.43.2](https://public-inbox.org/git/xmqqo7cjvuht.fsf@gitster.g/), +[2.44.0-rc1](https://public-inbox.org/git/xmqqttmbvuyh.fsf@gitster.g/), +[2.44.0-rc0](https://public-inbox.org/git/xmqqo7cph7ov.fsf@gitster.g/), +[2.43.1](https://public-inbox.org/git/xmqqttmhh7ow.fsf@gitster.g/) ++ Git for Windows [2.44.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.44.0.windows.1), +[2.44.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.44.0-rc2.windows.1), +[2.44.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.44.0-rc1.windows.1), +[2.44.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.44.0-rc0.windows.1) ++ GitLab [16.9.1, 16.8.3, 16.7.6](https://about.gitlab.com/releases/2024/02/21/security-release-gitlab-16-9-1-released/), +[16.9](https://about.gitlab.com/releases/2024/02/15/gitlab-16-9-released/), +[16.8.2, 16.7.5, 16.6.7](https://about.gitlab.com/releases/2024/02/07/security-release-gitlab-16-8-2-released/) ++ Gerrit Code Review [3.7.7](https://www.gerritcodereview.com/3.7.html#377), +[3.8.4](https://www.gerritcodereview.com/3.8.html#384) ++ GitHub Enterprise [3.12.0](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.0), +[3.11.5](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.5), +[3.10.7](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.7), +[3.9.10](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.10), +[3.8.15](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.15), +[3.11.4](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.4), +[3.10.6](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.6), +[3.9.9](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.9), +[3.8.14](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.14) ++ GitKraken [9.12.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.9](https://desktop.github.com/release-notes/) ++ Sourcetree [4.2.7](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.7.html) ++ Tower for Mac [10.4](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) ++ git-credential-oauth [0.11.1](https://github.com/hickford/git-credential-oauth/releases/tag/v0.11.1) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Brooke Kuhlmann, Jack Lot, Štěpán Němec +and Bruno Brito. diff --git a/_posts/2024-03-31-edition-109.markdown b/_posts/2024-03-31-edition-109.markdown new file mode 100644 index 0000000000..04d9699f09 --- /dev/null +++ b/_posts/2024-03-31-edition-109.markdown @@ -0,0 +1,473 @@ +--- +title: Git Rev News Edition 109 (March 31st, 2024) +layout: default +date: 2024-03-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 109 (March 31st, 2024) + +Welcome to the 109th 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 February and March 2024. + +## Discussions + + + +### Reviews + +* [[PATCH] rebase: make warning less passive aggressive](https://lore.kernel.org/git/pull.1669.git.1708442603395.gitgitgadget@gmail.com/) + + Harmen Stoppels sent a patch to the mailing list that changed an + error message from "No rebase in progress?" to "No rebase in + progress". The rationale is that this error appears when one runs + `git rebase --continue` while there is no rebase going on, so there + is no reason for the question mark. + + Junio Hamano, the Git maintainer, replied to Harmen suggesting using + the imperative mood in the commit message, and saying that the + change in itself is good but that the patch shouldn't have touched + the `po/*.po` files in the project that are used for localization. + Junio also said that we could later add tests for this as it + appeared there was none. + + Michal Suchánek replied to Junio saying that it might have been OK + to touch the `po/*.po` files if the patch had updated the + translations in those files but it hadn't. + + Junio replied to Michal saying that knowing the target language was + needed before removing question marks in those files as it might not + be enough to change a question into a statement. Even if the + author of the patch knew enough, reviewers of the patch might + not, but the biggest problem was bypassing the languages teams. + + Michal replied to Junio asking what was the problem "with not + involving several language teams to remove a question mark". + + Jean-Noël Avila, who is a translator, replied that it didn't bother + him much to edit a sentence to remove a question mark and possibly + adjust it, compared to "translating again and again similar + sentences". + + This led to some confusion as Junio thought that Jean-Noël said that + the "everything in one patch" approach would help translators by not + having them translate "again and again". But Jean-Noël clarified + that he didn't consider changing a question to an assertion is + translating "again and again". He agreed that it was perfectly fine + for translators to have to do those kinds of changes. With "again + and again" he was referring to strings like "could not stat '%s'" + and then "could not stat file '%s'". + + In the meantime Patrick Steinhardt replied to Harmen's initial + message. He suggested converting the error message to start with a + lowercase letter as our guidelines for error messages recommend. + + Harmen then sent + [a version 2 of his patch](https://lore.kernel.org/git/pull.1669.v2.git.1708537097448.gitgitgadget@gmail.com/) + which didn't change any `po/*.po` file and had the error message + start with a lowercase letter. Patrick reviewed that patch and found + it good. + + Kristoffer Haugsbakk chimed into the discussion saying he had + interpreted the original error message as saying "I’m not quite sure + but it looks like you are not in the middle of a rebase?" + + Junio replied to Kristoffer saying that there are indeed examples of + "less assertive" messages in the same rebase command, like "It looks + like 'git am' is in progress. Cannot rebase." But we should be more + assertive as it could help us get valuable bug reports saying for + example "The command said I was not rebasing, but I was! Here is + what I did..." Such bug reports could help us improve how we + determine the state we are in. + + The version 2 of Harmen's patch was later merged to the 'master' + branch. + + + +## Developer Spotlight: Linus Arver + +* Who are you and what do you do? + + I'm one of those so-called "self-taught" developers. My educational + background is in English and tax law (I know, boring right?). Over a + decade ago I thought I would be a corporate attorney, but in law + school I discovered programming and fell completely in love with the + craft, and never looked back! In hindsight it was the second-best + decision I've made in life (the first being getting married to my + lovely wife four years ago). + + I said that I fell into programming during law school. But actually my + original journey started in 7th grade when I tried to pick up C++. I + remember learning control flow, structs and pointers in the first few + chapters of the book I was using, but when it came to the chapter on + OOP and classes, I could not understand why OOP was necessary. + The book I was using just explained why OOP was great, and not + why it would ever be bad. + + Of course, years later I realized that OOP is one of several + paradigms, so perhaps my instinct to question OOP as a panacea was + onto something. In high school and university I remember tinkering + with HTML and websites before smartphones became popular. What a + simpler time it was, back then! + + Fast forward to law school, where I had the idea of writing class + notes using plaintext. Soon after I had the idea of converting these + plaintext notes to prettified outlines, so I needed a way to convert + them to HTML. For better or worse, all this happened before I + discovered Emacs and Org mode (or even Markdown). + + Anyway, I first wrote a plaintext-to-HTML converter in Ruby. Then I + rewrote it in C just for fun. Then again in Haskell (using a minimal + subset of Org mode syntax). As you can see, I sort of got carried away, + haha. + + I would go on to write dozens of pet projects (rudimentary chess + engine, game modding tools, etc) where I got to write tons of code. + I've had the "ugh, did I really write this?" moment too many times to + count. I like to believe that I did the tech industry a favor by not + entering it until I was well versed in fundamental programming and + architectural concepts. 😉 + + Since those law school days I've taken an interest in learning more + languages/ecosystems (e.g., Elixir and Rust). Recently, I've taken a + renewed interest in Literate Programming. I'm toying with the idea of + using it in a somewhat large scale in a future project. It takes a ton + of work to do LP right, but in many ways it's the best possible way to + document code (case in point, the absolutely stellar documentation + standards of the TeX community, such as the glorious TikZ user + manual). + + And I believe that readability is the most important attribute when it + comes to code --- even before correctness! Because at least if the + intent of the author is clear, we can have a (fairly) easy way to fix + things to make it correct. The other way around (correct, but + unreadable code) suffers from stagnation because people become afraid + of touching it, because it's hard to understand. It becomes harder to + extend and grow, which is required of any software worth maintaining + (we call it software for a reason). + + Going back to the question (sorry for rambling a bit there), in my + $DAYJOB I work on microservices, APIs, and backend systems. + Professionally I've always been a backend/infra engineer. In my spare + time I contribute to this wonderful community! + +* What would you name your most important contribution to Git? + + I would say my contributions to the documentation come out on top. + At the end of the day, Git is meant for human consumption. + So getting a bit more polish here and there for user-facing docs is + well worth the trouble, and I am most proud of my work in this area so + far. + + If I had more time, I would overhaul the documentation to make things + easier to understand. Truly, Git has a very simple conceptual model + (thanks to the brilliance of its original author). You just have to + understand that commits come from one or more other commits (sort of + like family trees). That's it! But sadly we have a reputation of + having absolutely terrible user-facing docs, so much so that it pushed + people away to Mercurial and other more friendly VCSs. We need to fix + that. + +* What are you doing on the Git project these days, and why? + + Last year I started trying to add unit tests to the (perhaps obscure) + `git interpret-trailers` command, but this effort has morphed into + "let's also overhaul the entire subsystem around how trailers are + handled, with the aim of creating a reusable C library around it" + [ [ref 1](https://lore.kernel.org/git/pull.1563.git.1691211879.gitgitgadget@gmail.com/) ] + [ [ref 2](https://lore.kernel.org/git/pull.1632.git.1704869487.gitgitgadget@gmail.com/) ]. + + I'm afraid I've bitten off more than I can chew, but I do have a + backlog of about 60 patches that I need to get sent up for review. Not + all at once, of course haha. Hopefully I can get these sent up and + merged over the coming months. The review process can be lengthy you + see, but for good reason --- we take time to try to make sure things + are right the first time. + +* 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? + + At the risk of being unoriginal, it would be libification (see + [Calvin Wan's interview](https://git.github.io/rev_news/2023/08/31/edition-102/#developer-spotlight-calvin-wan) + from edition 102). But to be more precise, it would be the complete + banning of "shelling out" which we do in many places (where Git + spawns another Git process to do something). Instead we could + (and should) be using libraries internally inside Git's own codebase. + I believe that once we can get Git to start treating itself + as a library, that external library consumption will soon follow. + + There are many others interested in this area as Git has a massive + footprint in our industry. I hope that the many large companies that + benefit from Git can grow their roster of Git contributors. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + `git checkout`. I believe `git switch` and `git restore` replaced the + need to have `git checkout`. I believe in the "there should be only + one way to do the right thing" camp when it comes to the CLI, so I don't + like how we have multiple commands with a lot of overlap. + + I say this even though personally I've been using Git for over 15 + years and have always used `git checkout` (even after the introduction + of `git {switch,restore}`). Simplicity matters! + +* What is your favorite Git-related tool/library, outside of + Git itself? + + [Tig](https://jonas.github.io/tig/). I use it all the time, every + day. It's so good that I basically never use `git log`, unless I'm + searching through it interactively with the pager. + + Every time I see someone proudly showing off their latest "git-log" + incantation (with all its bells and whistles), I think to myself "I + guess they've never heard of `tig`". + + Being an Emacs user, I tried to get into [Magit](https://magit.vc/) + but could not get used to the keybindings that conflicted with my + Vim-styled bindings. (Yes, I use [Evil](https://github.com/emacs-evil/evil) + mode via [Doom](https://github.com/doomemacs/doomemacs) Emacs if you're + into that sort of thing.) OTOH I get so much done with the basic + `git-*` commands and `tig` that I'm rather happy with my workflow. + +* Do you happen to have any memorable experience w.r.t. contributing to + the Git project? If yes, could you share it with us? + + Nine years ago, I contributed my first patch series. I was so proud of + this work that I wrote [a blog post](https://funloop.org/post/2014-09-09-my-first-contribution-to-git.html) + about it. + + The TL;DR of that post is that anyone can contribute to Git, and + really we are a welcoming community. Junio goes out of his way to + accommodate new contributors (I admire his patience), so please, feel + free to join us! + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + So my first contribution 9 years ago was via (the traditional) + `git send-email` command. These days there is this very neat service + called [GitGitGadget](https://gitgitgadget.github.io/) that allows + you to create pull requests on GitHub and does all the housekeeping + work of keeping mailing list discussions in sync (you'll get comments + on your PR which come from mailing list responses). Plus you can get + previews of your patch series (exactly how they'll look like on the + list) before you submit it, which is always nice. + + For local Git development, honestly I don't do anything special or + unusual. One window for Emacs, one window for (re)compiling Git and + running tests, and maybe one more for Tig. From Emacs I use [notmuch](https://wiki.archlinux.org/title/Notmuch) + to browse the mailing list emails (which I sync to Gmail with + [lieer](https://github.com/gauteh/lieer)). + + I use Org mode in Emacs heavily for organizing code snippets and ideas. + + Last but not least, I use [tmux](https://github.com/tmux/tmux/wiki) to organize terminal windows and + navigate quickly across them, even if I'm not using SSH. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + The hard part is figuring out which area you want to work on. Git has + a large codebase, so I recommend starting out with documentation + changes to familiarize yourself with the current state of things. + There's always a typo or grammofix hiding in there! + + Many of our manpages read like dictionaries, when they should read + more like user guides. Some manpages have helpful "EXAMPLES" sections + to show you how to actually use various options and commands, so if + you can think of additional examples, that would be most welcome. + Getting familiar with how things work with user-facing docs should + help you understand the intent behind the large C codebase we have. + + Try to make your contributions as small as possible, but make an + effort to write good commit messages. Copy the style of veterans like + Junio, Peff (Jeff King), Christian Couder, and others I am forgetting + (sorry!) who've been doing this for a long time. + + Once your change is submitted, nag people weekly to get things moving + (yes, we need prodding occasionally). But also don't get offended if + there are a lot of review comments for seemingly small things --- + we're just trying to maintain a certain level of quality. Git is used + by almost everyone in the software industry, so it's important for us + to keep a high bar for quality, that's all. + +* If there's one tip you would like to share with other Git + developers, what would it be? + + Junio has been our maintainer for nearly two decades. It's a tough job and + somehow he's kept going at it all this time. Still, let's do our best + to help make his job easier, because honestly we are truly lucky to + have someone of his caliber lead our project. + + More concretely, this means helping out with code reviews. If you're + not sure which ones to review, see the "What's Cooking" emails that + Junio sends out regularly to look for patches that need help from + reviewers. They are commented as "Needs review" or "Comments?", so + they're easy enough to spot. + + Cheers! + + +## Other News + + + +__Light reading__ + +* Julia Evans continues her series of blog posts about Git with + [How HEAD works in git](https://jvns.ca/blog/2024/03/08/how-head-works-in-git/) and + [The "current branch" in git](https://jvns.ca/blog/2024/03/22/the-current-branch-in-git/). + The first entry in this series of blog posts can be found + in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/). +* [Keeping repository maintainer information accurate](https://github.blog/2024-03-04-keeping-repository-maintainer-information-accurate/): + ensuring that the [CODEOWNERS file](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) + is up to date with the help of tools like [cleanowners](https://github.com/github/cleanowners). + By Zack Koppert on GitHub Blog. +* [De Programmatica Ipsum, Issue #66: Version Control - Twenty Years Is Nothing](https://deprogrammaticaipsum.com/twenty-years-is-nothing/) + by Adrian Kosmaczewski. +* [Git Worktrees and GitButler](https://blog.gitbutler.com/git-worktrees/): + How do Git worktrees help you work on more than one branch at the same time, + and how does that differ from virtual branches in GitButler? + Written by Scott Chacon on GitButler Blog. +* [Fixing up [a series of] Git [commits] with Autosquash](https://blog.gitbutler.com/git-autosquash/) + by Scott Chacon on GitButler Blog. +* [Advanced git commands every senior software developer needs to know](https://optimizedbyotto.com/post/advanced-git-commands/) + by Otto Kekäläinen on Optimized by Otto blog. +* [Five Ways to Be More Productive with Git](https://laravel-news.com/five-ways-to-be-more-productive-with-git) + by Paul Redmond on Laravel News blog. The blog post lists + a few useful Git aliases, setting up a commit template, using password manager for SSH keys + (that can be used for signing commits), making use of the GitHub CLI tool (`gh`), + and configuring `mergetool` and `difftool`. +* [Git: programmatic staging](https://choly.ca/post/git-programmatic-staging/) + (with the help of the [`expect`](https://linux.die.net/man/1/expect) tool, + or with [`grepdiff`](https://linux.die.net/man/1/grepdiff)) + by Ilia Choly on Choly's Blog. The author uses described technique + as a cleanup step after rewriting/refactoring code using automatic tools, + such as [Semgrep](https://semgrep.dev/), [ast-grep](https://ast-grep.github.io/), + LLMs (Large Language Models) such as ChatGPT, and one-off scripts. + * [Semgrep](https://semgrep.dev/) was mentioned in [Git Rev News Edition #75](https://git.github.io/rev_news/2021/05/27/edition-75/); + you can test it with [Semgrep Playground](https://semgrep.dev/playground/new). + * [Another article](https://choly.ca/post/semgrep-autofix-llm/) + by the same author mentions other similar tools, namely + [CodeQL](https://codeql.github.com/) (mentioned in passing + in [Git Rev News Edition #79](https://git.github.io/rev_news/2021/09/30/edition-79/)), + and [Comby](https://comby.dev/). It also talks about the newly created + [`semgrepx`](https://github.com/icholy/semgrepx) tool for rewriting `semgrep` matches + using externals tools (such as Datasette's [`llm`](https://llm.datasette.io/) CLI tool + and Python library). +* [Unleashing the Power of Git Bisect](https://dzone.com/articles/unleashing-the-power-of-git-bisect) + by Shai Almog on DZone (DevOps Zone). +* [Moving Code from One Repository to Another Using Git Patch](https://joelcolaco.hashnode.dev/moving-code-from-one-repository-to-another-using-git-patch) + by Joel Colaco on his blog - though a better solution would be to use + `git format-patch` and `git am` (or alternates and `git cherry-pick`). +* [Extremely Linear Git History](https://westling.dev/b/extremely-linear-git), + with first commit in a repo having a hash that starts with `0000000`, + the second commit is `0000001`, and so on; written by Gustav Westling + on his blog (2022). +* [Witty.rb - A very simple Ruby Script demonstrating how to parse a Git index file (`.git/index`)](https://gist.github.com/Chubek/1fa1c037d280dfc7952676cb4ee89e11). + Published as Gist by Chubak Bidpaa. +* [Dr. Git-Love or: How I Learned to Stop Worrying and Love the Rebase](https://escodebar.github.io/trainings/git/meetup/#/) + are HTML slides for Git training course by Pablo Vergés (escodebar). + +- [Toy/demo: using ChatGPT to summarize lengthy LKML threads (b4 integration)](https://lore.kernel.org/all/20240227-flawless-capybara-of-drama-e09653@lemur/t/#u) + thread on Linux kernel mailing list, started by Konstantin Ryabitsev. + + +__Easy watching__ + +* [So You Think You Know Git Part 2 - DevWorld 2024](https://www.youtube.com/watch?v=Md44rcw13k4) + by Scott Chacon on GitButler YouTube channel, continues the + [FOSDEM version](https://www.youtube.com/watch?v=aolI_Rz0ZqY) of the talk, + which was mentioned in the [previous Git Rev News](https://git.github.io/rev_news/2024/02/29/edition-108/). + [DevWorld Git Slides](https://blog.gitbutler.com/devworld-git-slides/) + are available on GitButler Blog. + + +__Git tools and sites__ + +* [extremely-linear](https://github.com/zegl/extremely-linear), also known as `git-linearize`, + is a tool to create commits with SHA-1 identifier beginning with `0000000` for the first commit, + `0000001` for the second, `0000002` for the third, and so on. This tool uses + [lucky_commit](https://github.com/not-an-aardvark/lucky-commit), + which inserts invisible whitespace characters at the end of the commit message + until it gets a SHA-1 (or SHA-256) hash with the desired prefix. + * Compare and contrast with [git-vain](https://git.anna.lgbt/anna/git-vain) + (mentioned in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/)) + and [git-vanity-sha](https://github.com/mattbaker/git-vanity-sha) + (mentioned in [Git Rev News Edition #39](https://git.github.io/rev_news/2018/05/16/edition-39/)), + tools to generate vanity hashes (for example to make the SHA-1 hash of HEAD begin with `c0ffee`). +* [Nosey Parker](https://github.com/praetorian-inc/noseyparker/) is a command-line program + that finds secrets and sensitive information in textual data and Git history. + Written in Rust, under Apache 2.0 license. +* [gitu](https://github.com/altsem/gitu) - a TUI Git client inspired by Magit. + Written in Rust, under MIT license. +* [Vim-Flog](https://github.com/rbong/vim-flog) is a powerful Git branch viewer for Vim. + Requires Neovim or Vim with Lua support. +* [gcd](https://github.com/davvid/gcd) - Git worktree navigator, + lets you quickly navigate to Git worktrees on your filesystem, + and to directories within your current worktree. + Written as a set of shell functions to be sourced into `~/.zshrc` or `~/.bashrc`. +* [grepdiff](https://pkg.go.dev/rsc.io/grepdiff) is a command-line tool that reads unified diffs + from the files passed as arguments (or standard input), and prints a reduced diff + containing only the hunks matching a regular expression. Written in Go. +* [Gitstr](https://github.com/fiatjaf/gitstr) is a tool to send and receive Git patches + over [Nostr][], using [NIP-34](https://github.com/nostr-protocol/nips/pull/997). + * Compare and contrast with [git-ssb](https://scuttlebot.io/apis/community/git-ssb.html) + (see [git-ssb-intro](https://github.com/hackergrrl/git-ssb-intro) guide): + decentralized Git repo hosting and issue tracking on Secure-ScuttleButt (SSB), + mentioned in [Git Rev News Edition #26](https://git.github.io/rev_news/2017/04/19/edition-26/) + and [#40](https://git.github.io/rev_news/2018/06/20/edition-40/). + +[Nostr]: https://nostr.com/ "A decentralized social network with a chance of working" + + +## Releases + ++ libgit2 [1.8.0](https://github.com/libgit2/libgit2/releases/tag/v1.8.0) ++ Gerrit Code Review [3.7.8](https://www.gerritcodereview.com/3.7.html#378), +[3.9.2](https://www.gerritcodereview.com/3.9.html#392) ++ GitHub Enterprise [3.12.1](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.1), +[3.11.7](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.7), +[3.10.9](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.9), +[3.9.12](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.12), +[3.8.17](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.17), +[3.12.0](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.0), +[3.11.6](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.6), +[3.10.8](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.8), +[3.9.11](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.11), +[3.8.16](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.16) ++ GitLab [16.10.1, 16.9.3, 16.8.5](https://about.gitlab.com/releases/2024/03/27/security-release-gitlab-16-10-1-released/), +[16.10](https://about.gitlab.com/releases/2024/03/21/gitlab-16-10-released/), +[16.9.2](https://about.gitlab.com/releases/2024/03/06/security-release-gitlab-16-9-2-released/) ++ GitKraken [9.13.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.12](https://desktop.github.com/release-notes/), +[3.3.11](https://desktop.github.com/release-notes/), +[3.3.10](https://desktop.github.com/release-notes/) ++ Tower for Windows [6.0](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) ([Release blog post](https://www.git-tower.com/blog/tower-windows-6/)) ++ Tower for Mac [10.5](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) ++ git-credential-azure [0.3.0](https://github.com/hickford/git-credential-azure/releases/tag/v0.3.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Linus Arver, Eric Sunshine, +Ghanshyam Thakkar, Kristoffer Haugsbakk, +Štěpán Němec, Junio Hamano and Bruno Brito. diff --git a/_posts/2024-04-30-edition-110.markdown b/_posts/2024-04-30-edition-110.markdown new file mode 100644 index 0000000000..4c9dbca6de --- /dev/null +++ b/_posts/2024-04-30-edition-110.markdown @@ -0,0 +1,309 @@ +--- +title: Git Rev News Edition 110 (April 30th, 2024) +layout: default +date: 2024-04-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 110 (April 30th, 2024) + +Welcome to the 110th 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 March and April 2024. + +## Discussions + +### General + +* [What's cooking in git.git (Mar 2024, #05; Tue, 19)](https://lore.kernel.org/git/xmqqil1iqi37.fsf@gitster.g/) + + In March, Junio Hamano, the Git maintainer, sent one of the usual + "What's cooking in git.git" emails that describe the current state + of the patch series that might be merged into the development + branches (mostly "master", "next", and "seen"). + + The patch series are listed in these emails along with some related + information in a custom format, including the following elements: + + - a title line, for example: + + > * bl/cherry-pick-empty (2024-03-11) 7 commits + + where `bl` are the initials of the author, and `cherry-pick-empty` + the series title, + + - a patch list, for example: + + > - cherry-pick: add `--empty` for more robust redundant commit handling + > - cherry-pick: enforce `--keep-redundant-commits` incompatibility + > - sequencer: do not require `allow_empty` for redundant commit options + > - sequencer: treat error reading `HEAD` as unborn branch + > - rebase: update `--empty=ask` to `--empty=stop` + > - docs: clean up `--empty` formatting in git-rebase (1) and git-am (1) + > - docs: address inaccurate `--empty` default with `--exec` + + - a description, for example: + + > "cherry-pick" told to keep redundant commits needs to be allowed to + > create empty commits to do its job, but it required the user to + > give the `--allow-empty` option, which was unnecessary. Its UI has + > also been tweaked a bit. + + - a status, for example: + + > Comments? + + - a source, for example: + + > source: <20240119060721.3734775-2-brianmlyles@gmail.com> + + Some of the above elements, like the description, are also + automatically used to create the release notes that Junio prepares + and sends when he creates a new release. + + Brian Lyles replied to Junio that the description of the patch + series used as an example above, which Brian had sent, was "a little + out-of-date". He suggested a different wording for it, and said that + he was going to send a version 4 of his patch series. + + Junio said that the wording suggestion for the description was + very much appreciated, and wondered if the project could adopt a + better workflow where contributors could write a short description + at the top of the cover letter of their patch series and if that + description could then be picked up automatically by some tools to appear + in Junio's "What's cooking in git.git" emails. + + Brian Lyles agreed that improving the process could be a + good idea. He mentioned a strategy used by other projects, namely + adding an entry in a "CHANGELOG.NEXT.md" file for each + important commit. At release time, all the entries in that + file would be moved into a standard "CHANGELOG.md" file. He then + showed how the entry in the "CHANGELOG.NEXT.md" file would look like + for his series as an example. + + Junio replied by summarizing the current process related to these + descriptions and pointing to the + ["Documentation/howto/maintain-git.adoc" file](https://github.com/git/git/blob/master/Documentation/howto/maintain-git.adoc), + which describes his workflow and says that maintaining these topic + descriptions is his responsibility as the project maintainer. He + then mentioned some downsides of giving that responsibility to the + patch series authors. + + One downside is that the description might be harder to read because + the authors "inevitably are biased by the importance of their own + work ;-)". Another one is that the description might not be as + consistent as when they are all written by the same person. Coming + up with some description is also "a good opportunity" for the + maintainer to find what is still unclear after reading the patches + and the cover letter. Junio agreed that "the distribution of burden is + certainly attractive" though. + + Brian replied that he thought the author should still write + something and that at least he was willing to do it. He also + suggested having guidelines, like for commit messages, to help + authors and reviewers standardize the style of these descriptions. + + In the meantime, in a separate email, Junio also pointed out that a + "CHANGELOG.NEXT.md" file would make merges more difficult compared + to having the description in the cover letter. + + To that Brian agreed, and proposed writing a patch to the + "Documentation/SubmittingPatches" file to document that the + description can be written in the cover letter. + + Junio replied by proposing a patch to that file himself. Brian + commented that the description might need "some specific heading, + phrase, or other structured text" to mark it appropriately, making + it easy to notice and extract. + + Dragan Simic joined the discussion saying that writing the + description should not be a strict requirement and then agreed with + Junio's patch. Max Gautier also chimed in, agreeing with Brian and + Dragan about using a format to mark the description. Dragan replied + that adding an example of such a formatted description in the patch + Junio suggested would be good. + + Junio replied to Brian that he preferred starting "with a + lightweight process that does not burden participants with too much + red tape", so something like "When the first paragraph of the + message looks like an entry in the Release Notes, it is used as + such", as he thought that the Release Notes style was "distinct + enough" as to "not require any further marking". + + As Junio's patch was then merged, it's now + [officially possible to write a short description](https://github.com/git/git/blob/v2.45.0-rc1/Documentation/SubmittingPatches#L462-L472) + in patches or cover letters. This description might then be used + as-is in the "What's cooking in git.git" emails and in the release + notes. + + + + + + + +## Other News + +__Various__ + +* [Highlights from Git 2.45](https://github.blog/2024-04-29-highlights-from-git-2-45/) + by Taylor Blau on GitHub Blog. +* [What’s new in Git 2.45.0?](https://about.gitlab.com/blog/2024/04/30/whats-new-in-git-2-45-0/) + by Patrick Steinhardt on GitLab Blog. +* Adam Johnson’s book “Boost Your Git DX” + [has been updated](https://adamj.eu/tech/2024/04/04/bygdx-update/) with ten + new pages of content. This book was mentioned in + [Git Rev News Edition #104](https://git.github.io/rev_news/2023/10/31/edition-104/). + +__Light reading__ + +* Julia Evans continues her series of blog posts about Git, preparing for a new Git zine, + with [Notes on git's error messages](https://jvns.ca/blog/2024/04/10/notes-on-git-error-messages/). + There are also [Some Git poll results](https://jvns.ca/blog/2024/03/28/git-poll-results/) + (which are, as admitted by the author, highly unscientific, and might not be representative). + The first entry in this series of blog posts can be found in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/), + and it continues since, edition after edition so far. +* [Modern Git Commands and Features You Should Be Using](https://martinheinz.dev/blog/109) + by Martin Heinz on his blog. The list includes `git switch`, `git restore`, + `git sparse-checkout`, `git worktree`, and (not new) `git bisect`. +* [Learn Git Fundamentals – A Handbook on Day-to-Day Development Tasks](https://www.freecodecamp.org/news/learn-git-basics/) + by Samyak Jain on freeCodeCamp. +* [Navigating the Stormy Waters of Git Merge Conflicts: A Guide for basic git conflicts](https://dev.to/kadea-academy/navigating-the-stormy-waters-of-git-merge-conflicts-a-complete-guide-38n9) + by Jomagene for KADEA ACADEMY on DEV\.to. +* [The guide to Git I never had.](https://glasskube.dev/guides/git/) + under Philip Miglinci's byline, as Glasskube's guide to Git + (also [on DEV\.to](https://dev.to/glasskube/the-guide-to-git-i-never-had-1450), + by Jake Page for Glasskube). +* [How to get somebody fired using Git](https://dev.to/mauroaccorinti/how-to-get-somebody-fired-using-git-31if) + (or: how to NOT use Git), by Mauro Accorinti on DEV\.to. +* [What Happens on GitLab When You do `git push`?](https://nanmu.me/en/posts/2022/what-happens-on-gitlab-when-you-do-git-push/) + by Li Zhennan, on the personal blog. +* [Radicle: peer-to-peer collaboration with Git](https://lwn.net/Articles/966869/), an + article by Lars Wirzenius on LWN\.net. + * [Radicle](https://radicle.xyz/) was first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/), then in [Edition #70](https://git.github.io/rev_news/2020/12/26/edition-70/). + There was also an [article about Radicle from The New Stack](https://thenewstack.io/radicle-a-decentralized-alternative-to-github-for-web3/) + in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/). + * Compare with [ForgeFed](https://notabug.org/peers/forgefed) (formerly GitPub), + a federation protocol for software forges, mentioned in [Git Rev News Edition #69](https://git.github.io/rev_news/2020/11/27/edition-69/). + * There is also [gitstr (`git str`)](https://github.com/fiatjaf/gitstr), a tool to send and receive Git patches + over [Nostr](https://nostr.com/), using [NIP-34](https://github.com/nostr-protocol/nips/pull/997) + (mentioned in [Git Rev News Edition #109](https://git.github.io/rev_news/2024/03/31/edition-109/)), + and [`git-ssb`](https://scuttlebot.io/apis/community/git-ssb.html) + (see the [git-ssb-intro](https://github.com/hackergrrl/git-ssb-intro) guide), a + decentralized Git repo hosting and issue tracking on [Secure-ScuttleButt (SSB)](https://www.scuttlebutt.nz/) + (mentioned in [Git Rev News Edition #26](https://git.github.io/rev_news/2017/04/19/edition-26/) + and [#40](https://git.github.io/rev_news/2018/06/20/edition-40/)). +* [Git as debugging tool](https://lucasoshiro.github.io/posts-en/2023-02-13-git-debug/) + by Lucas Seiki Oshiro on his GitHub Pages-powered personal blog (2023). + + +__Easy watching__ + +* [re:bass](https://www.youtube.com/watch?v=S9Do2p4PwtE) by Dylan Beattie [4:34]. + If Git was music, what would it sound like? + An original composition inspired by the Git version control system. + + +__Git tools and sites__ + +* [`git bisect-find`](https://gitlab.com/kevincox/git-bisect-find) is + a simple command to find where to start your bisection. Written in Rust. + * See also [Announcing `git bisect-find`](https://kevincox.ca/2024/04/19/git-bisect-find/) + by Kevin Cox on his blog. +* [`git-cz`](https://github.com/streamich/git-cz) is a command-line tool + to help you make semantic Git commits. Written in JavaScript for Node.js. + Can be installed standalone, or with [Commitizen](https://commitizen-tools.github.io/commitizen/) + (which was mentioned in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/)). + Has non-interactive mode; is configurable (for example turning off emoji). +* [`ydiff`](https://github.com/ymattw/ydiff) is a term based tool + to view _colored, incremental diff_ in a version controlled workspace + (supports Git, Mercurial, Perforce and Subversion so far) + or from stdin, with _side by side_ (similar to `diff -y`) and _auto pager_ support. + Written in Python. (Its [`cdiff`](https://github.com/amigrave/cdiff) fork appears to be unmaintained.) +* [`gws`](https://github.com/StreakyCobra/gws) is a text user interface colorful helper + to manage workspaces composed of Git repositories. Written in Bash. +* [Giftless](https://giftless.datopian.com/) ([GitHub repo](https://github.com/datopian/giftless)) + is a Python implementation of a [Git LFS](https://git-lfs.com/) Server. + It is designed with flexibility in mind, to allow pluggable storage backends, + transfer methods and authentication methods. +* [`gil`](https://github.com/chronoxor/gil) (git links tool) is a tool to manage + complex recursive repository dependencies with cross references and cycles. + This tool provides a solution to the _git recursive submodules dependency_ problem. + Written in Python. +* [`git subrepo`](https://github.com/ingydotnet/git-subrepo) "clones" an external Git repo + into a subdirectory of your repo. It is an alternative to `git submodule` and `git subtree`. + The subrepo history is _squashed_ into a single commit that contains the reference information. + Recommended as replacement for the (no longer maintained) [Git STree](https://deliciousinsights.github.io/git-stree/) + project. +* [`tomono`](https://github.com/hraban/tomono): Multi- to Monorepo Migration, + is a script that merges multiple independent tiny repositories into a single “[monorepo](https://monorepo.tools/)”. + Every original repo is moved into its own subdirectory, branches with the same name are all merged. + * Can be considered the reverse of [splitsh/lite](https://github.com/splitsh/lite) tool, whose goal is + to make splitting a monolithic repository to read-only standalone repositories easy and fast + (mentioned in [Git Rev News: Edition #16](https://git.github.io/rev_news/2016/06/15/edition-16/)). +* [`gitdm`](https://github.com/npalix/gitdm) (the "git data miner") + is the tool that Greg KH and Jonathan Corbet have used + to create statistics on where kernel patches come from. + Written in Python. Original at git://git.lwn.net/gitdm.git +* [`lolcommits`](https://github.com/lolcommits/lolcommits): Git-based selfies for software developers. + `lolcommits` takes a snapshot with your webcam every time you execute `git commit`, + and archives a lolcat style image with it (image with embedded caption). + Written in Ruby, requires a webcam and ImageMagick installed. + See also [Lolcommits from around the world!](https://github.com/lolcommits/lolcommits/wiki/Lolcommits-from-around-the-world%21) + page on the project Wiki. +* [Steve's Jujutsu Tutorial](https://steveklabnik.github.io/jujutsu-tutorial/introduction/introduction.html). + * [Jujutsu (`jj`)](https://github.com/martinvonz/jj) is a version control system + first mentioned in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/); + additionally, links to the [LWN.net article](https://lwn.net/Articles/958468/) + and the [Jujutsu: A Git-Compatible VCS](https://www.youtube.com/watch?v=bx_LGilOuE4) + talk about this version control system at Git Merge 2022 can be found in + [Git Rev News Edition #107](https://git.github.io/rev_news/2024/01/31/edition-107/). +* [Awesome Git](https://github.com/dictcp/awesome-git) + is a curated list of amazingly awesome Git tools, resources and shiny things. +* [Awesome Git Hooks](https://github.com/compscilauren/awesome-git-hooks) + is a curated list of easy-to-use Git hooks for automating tasks during Git workflows. + + +## Releases + ++ Git [2.45.0](https://public-inbox.org/git/xmqq8r0ww0sj.fsf@gitster.g/), +[2.45.0-rc1](https://public-inbox.org/git/xmqq4jbqzo3j.fsf@gitster.g/), +[2.45.0-rc0](https://public-inbox.org/git/xmqqcyqljmuu.fsf@gitster.g/) ++ Git for Windows [2.45.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.45.0.windows.1), +[2.45.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.45.0-rc1.windows.1), +[2.45.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.45.0-rc0.windows.1) ++ GitHub Enterprise [3.12.2](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.2), +[3.11.8](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.8), +[3.10.10](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.10), +[3.9.13](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.13) ++ GitLab [16.11.1, 16.10.4, 16.9.6](https://about.gitlab.com/releases/2024/04/24/patch-release-gitlab-16-11-1-released/), +[16.11](https://about.gitlab.com/releases/2024/04/18/gitlab-16-11-released/), +[16.10.3, 16.9.5, 16.8.7](https://about.gitlab.com/releases/2024/04/15/gitlab-16-10-3-released/), +[16.10.2, 16.9.4, 16.8.6](https://about.gitlab.com/releases/2024/04/10/patch-release-gitlab-16-10-2-released/) ++ Gerrit Code Review [3.8.5](https://www.gerritcodereview.com/3.8.html#385), +[3.9.3](https://www.gerritcodereview.com/3.9.html#393), +[3.9.4](https://www.gerritcodereview.com/3.9.html#394) ++ GitHub Desktop [3.3.14](https://desktop.github.com/release-notes/), +[3.3.13](https://desktop.github.com/release-notes/) ++ tig [2.5.9](https://github.com/jonas/tig/releases/tag/tig-2.5.9) ++ git-credential-oauth [0.11.2](https://github.com/hickford/git-credential-oauth/releases/tag/v0.11.2) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Junio Hamano, Štěpán Němec, Kristoffer Haugsbakk, +Dragan Simic and Adam Johnson. diff --git a/_posts/2024-05-31-edition-111.markdown b/_posts/2024-05-31-edition-111.markdown new file mode 100644 index 0000000000..887c4a6eeb --- /dev/null +++ b/_posts/2024-05-31-edition-111.markdown @@ -0,0 +1,346 @@ +--- +title: Git Rev News Edition 111 (May 31st, 2024) +layout: default +date: 2024-05-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 111 (May 31st, 2024) + +Welcome to the 111th 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 April and May 2024. + +## Discussions + +### General + +* [[GSoC] Welcoming our 2024 contributors and thanking our applicants](https://public-inbox.org/git/406aa31f-4ea0-496c-aeb6-443be86385c0@gmail.com/) + + The Git project was accepted in the + [Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/) + this year again, and 3 applicants were selected: + + - Jialuo She will work on the + ["Implement consistency check for refs" project](https://summerofcode.withgoogle.com/programs/2024/projects/ukm4PTEF) + mentored by Karthik Nayak and Patrick Steinhardt. He already + started posting on [his blog](https://luolibrary.com/categories/GSoC-2024/), + and will push his work to his [Git repo](https://github.com/shejialuo/git). + + - Ghanshyam Thakkar will work on the + ["Move existing tests to a unit testing framework" project](https://summerofcode.withgoogle.com/programs/2024/projects/e9C4rhrv) + mentored by Kaartic Sivaraam and Christian Couder. He already + started posting on [his blog](https://spectre10.github.io/posts/), + and will push his work to his [Git repo](https://github.com/spectre10/git). + + - Chandra Pratap will work on the + ["Move and improve reftable tests in the unit testing framework" project](https://summerofcode.withgoogle.com/programs/2024/projects/tlh611d7) + mentored by Patrick Steinhardt and Christian Couder. He already + started posting on [his blog](https://chand-ra.github.io/), + and will push his work to his [Git repo](https://github.com/Chand-ra/git). + + Congratulations to them, and thanks a lot to all the applicants who + worked on Git and submitted proposals! It was tough to choose from + multiple potential contributors, all of them good in their own + respect. + +* [Git Merge conference](https://public-inbox.org/git/Zj0JyL1b+g1G3zWx@nand.local/) and Contributor's Summit + + Taylor Blau from GitHub announced that Git Merge 2024 is happening + in-person on September 19th and 20th in Berlin. It is being co-hosted + by GitHub and [GitButler](https://gitbutler.com/). + + The talks are scheduled on September 19th and the birds of a feather + are scheduled on September 20th. Registration is yet to open. + + The announcement welcomes calls for proposals, ideas on the format, + topics for discussions, venue setup, and applications for financial + assistance. + +### Reviews + ++ [[PATCH 0/3] color: add support for 12-bit RGB colors](https://lore.kernel.org/git/20240429164849.78509-1-dev+git@drbeat.li/) + + Beat Bolli sent a patch series consisting of 3 patches to add 12 bit RGB + color support to the color parsing code. That code is used + especially when parsing configuration files, as + [a lot of configuration options](https://git-scm.com/docs/git-config#Documentation/git-config.txt-coloradvice) + allow users to customize how Git colorizes its output. + + Before Beat's patch series, the code supported the following: + - fixed strings, like `normal`, `blue`, `red`, etc, + - 256-color-modes from the terminal, like `[1;38;5;254;48;5;255m` , and + - 24-bit color values in the form `#RRGGBB`. + + With Beat's patch, it also supports 12-bit colors in the form + `#RGB`, where in both the 24-bit and 12-bit forms, `R`, `G` and `B` + are hexadecimal digits for the red, green and blue components of the + color respectively. + + The first patch in the series fixed a typo. The second patch added + tests for invalid non-hexadecimal characters in `#RRGGBB` + values. + + The last patch added support for the `#RGB` form and mentioned in + its commit message that such a shortened 12 bit form is already + supported in Cascading Style Sheets (CSS). When used in CSS, each of + the hexadecimal digits in this form is duplicated to convert the + color to 24 bits, and the same duplication is performed in Beat's + patch. For example `#f1b` specifies the same color as `#ff11bb`. + + Junio Hamano, the Git maintainer, replied to Beat's third patch + saying that it looked good. Junio noticed that a wrong `#0xFF0000` + value in a code comment was converted to the right `#FF0000` value + by removing `Ox`. He wondered if there were instances of the same + mistake in our documentation. Beat replied that it was the only + place he found such a mistake. + + Taylor Blau then reviewed the patch series and said it looked "very + nice". Jeff King, alias Peff, also reviewed Beat's series and + commented on the third patch. Looking at the tests that checked the + rejection of invalid values, Peff wondered what would happen if + values like "#1", "#12", "#1234" were passed. Junio replied to Peff + that such values would be worth covering in the tests but doing that + in a separate cleanup patch outside this series would be fine. + + Then Junio replied to himself and suggested adding such tests in the + second patch of the series which already added tests for invalid + values. Junio even sent a 'fixup!' patch to add these tests to the + second patch. Peff replied that this 'fixup!' patch looked good. + + Beat then sent a + [version 2 of his series](https://lore.kernel.org/git/20240502110331.6347-1-dev+git@drbeat.li/) + that incorporated Junio's patch. Both Junio and Peff approved of it, + so it was later merged into the 'master' branch. + + + +## Developer Spotlight: Beat Bolli + +* Who are you and what do you do? + + I'm a software engineer currently working in an Integration Engineer role + for the Swiss government. When I'm not coding, I read, ride any of my three + bikes or play the guitar or electric bass. + +* What would you name your most important contribution to Git? + + I'm more a drive-by contributor. There are no big issues that I work on. + For example, my very first commit was "just" a spelling correction. + + The biggest contribution in terms of the number of commits was a cleanup of + the test scripts that eliminated redundant processes in long pipelines. + + Other topics that come to mind are the strict ISO date format, the + "copy commit reference" menu item in [gitk](https://git-scm.com/docs/gitk), + and some cleanups to get a warning-free compile with `-pedantic`. + +* What are you doing on the Git project these days, and why? + + As explained in the previous answer, I mostly see small things that I try + to improve, like [recently adding the 12-bit RGB color format](#reviews). + +* 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? + + Honestly, I'm pretty content with the state of Git. I've been using Git since + 2009 and I guess I got used to its idiosyncrasies (but see the next question!). + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + There are too many different options and/or subcommands to remove things. + Compare `git remote remove`, `git branch (-d/-D)`, `git rm` (for files). + I understand that these are different situations but from time to time I + have to really think about which is the right syntax in a given case. + +* What is your favorite Git-related tool/library, outside of + Git itself? + + First, I'm a fan of the command line, so Git itself does over 80% of what + I need. Next up are [tig](https://jonas.github.io/tig/) and [vim-fugitive](https://github.com/tpope/vim-fugitive). + I also use a comprehensive set of Git-related shell aliases that improve + my efficiency. + +* Do you happen to have any memorable experience w.r.t. contributing to + the Git project? If yes, could you share it with us? + + Nothing out of the ordinary, but then I'm old-school and have no problems + with an email-based workflow. My first commits were accepted without much + fanfare, and this encouraged me to continue to submit things. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + I follow the mailing list on [lore.kernel.org](https://lore.kernel.org/git/), and + have also subscribed to the NNTP feed in Thunderbird. For submitting patches I + have configured a few send-email options, probably like everyone else who + contributes. I do most of my development on a Mac mini in [iTerm2](https://iterm2.com/) + and Vim. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + First, don't think you're not good enough. By following [SubmittingPatches](https://git-scm.com/docs/SubmittingPatches) + and the rest of the [beginner's documentation](https://git-scm.com/docs/MyFirstContribution), + everyone can contribute. I experience the "mood" on the mailing list as very + supportive and helpful. + +* If there's one tip you would like to share with other Git + developers, what would it be? + + Just a tiny pet peeve of mine: `sizeof` is not a function 😉 + + +## Other News + +__Various__ + ++ [Securing Git: Addressing 5 new vulnerabilities](https://github.blog/2024-05-14-securing-git-addressing-5-new-vulnerabilities/) + fixed in v2.45.1, by Johannes Schindelin on GitHub Blog. + The main theme of fixes in v2.45.1 is to improve the security of cloning Git repositories. + + +__Light reading__ + ++ [A beginner's guide to the Git reftable format](https://about.gitlab.com/blog/2024/05/30/a-beginners-guide-to-the-git-reftable-format/) + (available since the [release of Git 2.45.0](https://about.gitlab.com/blog/2024/04/30/whats-new-in-git-2-45-0/)). + Article by Patrick Steinhardt on GitLab Blog. ++ Julia Evans has just [published her new Git zine](https://jvns.ca/blog/2024/04/25/new-zine--how-git-works-/), + “[How Git Works](https://wizardzines.com/zines/git/)”. + She [counted](https://fosstodon.org/@b0rk@jvns.ca/112519150131306917) + that she apparently wrote 28,000 words of blog posts while writing the zine. + These posts were covered here, starting from [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/), + and continuing, edition after edition, until [the previous edition #110](https://git.github.io/rev_news/2024/04/30/edition-110/).
+ As a companion to this zine, there is a little [git cheat sheet](https://wizardzines.com/git-cheat-sheet.pdf) (PDF) freely available. + + Julia Evans had also published the “[Oh Shit, Git](https://wizardzines.com/zines/oh-shit-git/)” zine in 2018; + as she [describes](https://fosstodon.org/@b0rk@jvns.ca/112338598244430472): + “Oh Shit, Git” is about how to get out of Git messes, while + “How Git Works” explains why those messes happen in the first place. + + The [Oh Shit, Git!?!](http://ohshitgit.com/) website by Katie Sylor-Miller + was first mentioned in [Git Rev News Edition #19](https://git.github.io/rev_news/2016/09/14/edition-19/). ++ [Securing Git repositories with gittuf](https://lwn.net/Articles/972467/) + by Joe Brockmeier on LWN\.net is a report of a talk by Aditya Sirish A Yelgundhalli and Billy Lynch + at Open Source Summit North America (OSSNA). + The video of the talk [is available on YouTube](https://www.youtube.com/watch?v=eCSeIEdMbCw). + [Gittuf](https://gittuf.dev/) was mentioned + in [Git Rev News Edition #104](https://git.github.io/rev_news/2023/10/31/edition-104/). ++ [Clone arbitrary single Git commit](https://blog.hartwork.org/posts/clone-arbitrary-single-git-commit/) + by Sebastian Pipping on Hartwork Blog. Inspired by GitHub Action [`actions/checkout`](https://github.com/actions/checkout). ++ [Reverting File Changes in Git: A Comprehensive Guide](https://dev.to/mochafreddo/reverting-file-changes-in-git-a-comprehensive-guide-80i) + by Geoffrey Kim on DEV\.to. ++ [What is Git? GitHub beginner’s guide to version control](https://github.blog/2024-05-27-what-is-git-our-beginners-guide-to-version-control/) + by Kedasha Kerr on GitHub Blog. ++ [Signed Git commits with Sigstore, Gitsign and OpenID Connect (OIDC)](https://buildkite.com/blog/securing-your-software-supply-chain-signed-git-commits-with-oidc-and-sigstore) + by James Healy on Buildkite Blog. + [Sigstore](https://www.sigstore.dev/) and [Gitsign](https://github.com/sigstore/gitsign) + tools for keyless Git signing were both mentioned + in [Git Rev News Edition #91](https://git.github.io/rev_news/2022/09/30/edition-91/). ++ [Understanding the Stacked Pull Requests Workflow](https://www.git-tower.com/blog/stacked-prs/) by Bruno Brito on Tower's blog. + There have been various approaches to adding stacks to Git workflows: + + [Stacked Git](https://stacked-git.github.io/) (aka StGit) was mentioned in + [Git Rev News Edition #17](https://git.github.io/rev_news/2016/07/20/edition-17/), + [#21](https://git.github.io/rev_news/2016/11/16/edition-21/), + and [#74](https://git.github.io/rev_news/2021/04/30/edition-74/), + and finally presented as a tool in [#93](https://git.github.io/rev_news/2022/11/30/edition-93/). + + Stacked diffs were discussed in [Stacked Diffs Versus Pull Requests](https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/) + (mentioned in [Git Rev News Edition #44](https://git.github.io/rev_news/2018/10/24/edition-44/)) + and [Stacked Diffs (and why you should know about them)](https://newsletter.pragmaticengineer.com/p/stacked-diffs) (mentioned + in [#105](https://git.github.io/rev_news/2023/11/30/edition-105/)). + + [Working with stacked branches](https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/) + was mentioned in [Git Rev News Edition #93](https://git.github.io/rev_news/2022/11/30/edition-93/). ++ [How short can Git abbreviate?](https://blog.cuviper.com/2013/11/10/how-short-can-git-abbreviate/) + by Josh Stone on his WordPress-based blog (2013). + + +__Easy watching__ + ++ [Securing Git Repositories with Gittuf](https://www.youtube.com/watch?v=eCSeIEdMbCw) - + Aditya Sirish A Yelgundhalli, New York University & Billy Lynch, Chainguard. + A 30 minute long video on The Linux Foundation channel on YouTube. + + +__Git tools and sites__ + ++ [KSDB](https://lwn.net/ksdb/) is the LWN\.net kernel source database, a site + which can answer a wide range of questions about the Linux kernel's development history. ++ The [Kernel.org Transparency Log Monitor](https://tlog.linderud.dev/) + webpage is a monitor of the kernel.org transparency log for git-receive operations. + Among others, it tracks signed pushes (compare with [gittuf](https://gittuf.dev/)). + Runs [kernel.org-git-verifier](https://github.com/Foxboron/kernel.org-git-verifier). + + There is also the [Gitolite transparency log](https://korg.docs.kernel.org/gitolite/transparency-log.html), + with git-receive operations published at the [transparency-logs/gitolite/git](https://git.kernel.org/pub/scm/infra/transparency-logs/gitolite/git/) + repositories in [the public-inbox v2 format](https://public-inbox.org/public-inbox-v2-format.html). + [Gitolite](http://gitolite.com/gitolite/) was first mentioned in + [Git Rev News Edition #17](https://git.github.io/rev_news/2016/07/20/edition-17/) + and [#22](https://git.github.io/rev_news/2016/12/14/edition-22/). ++ [Sigstore Rekor](https://github.com/sigstore/rekor) is meant to + provide an immutable tamper resistant ledger of metadata + generated within a software project's supply chain. + It enables software maintainers and build systems to record and query + signed metadata. + Can be run as part of [Sigstore](https://sigstore.dev/) or on its own. ++ [Quickhook](https://github.com/dirk/quickhook/) is a Git hook runner designed for speed. + Written in Go. ++ [etckeeper](https://etckeeper.branchable.com/) is a collection of tools + to let `/etc` be stored in a Git repository, and use Git + to review or revert changes that were made to `/etc`. + Written as shell scripts (with some plugins in Python). ++ [Dangit, Git!?!](https://dangitgit.com/en) has the same contents, only without swears, + as the [Oh Shit, Git!?!](https://ohshitgit.com/) website + (first mentioned in [Git Rev News Edition #19](https://git.github.io/rev_news/2016/09/14/edition-19/)). + + +## Releases + ++ Git [2.45.1 and friends](https://public-inbox.org/git/xmqqv83g4937.fsf@gitster.g/) + (2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4) ++ Git for Windows [2.45.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.45.1.windows.1) ++ libgit2 [1.8.1](https://github.com/libgit2/libgit2/releases/tag/v1.8.1) ++ GitLab [17.0.1, 16.11.3, 16.10.6](https://about.gitlab.com/releases/2024/05/22/patch-release-gitlab-17-0-1-released/), +[17.0](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/), +[16.9.8](https://about.gitlab.com/releases/2024/05/09/gitlab-16-9-8-released/), +[16.11.2, 16.10.5, 16.9.7](https://about.gitlab.com/releases/2024/05/08/patch-release-gitlab-16-11-2-released/) ++ Gerrit Code Review [3.10.0](https://www.gerritcodereview.com/3.10.html#3100), +[3.7.9](https://www.gerritcodereview.com/3.7.html#379), +[3.8.6](https://www.gerritcodereview.com/3.8.html#386), +[3.9.5](https://www.gerritcodereview.com/3.9.html#395) ++ GitHub Enterprise [3.12.4](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.4), +[3.11.10](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.10), +[3.10.12](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.12), +[3.9.15](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.15), +[3.13.0](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.0), +[3.12.3](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.3), +[3.11.9](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.9), +[3.10.11](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.11), +[3.9.14](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.14) ++ GitKraken [10.0.1](https://help.gitkraken.com/gitkraken-client/current/), +[10.0.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.0](https://desktop.github.com/release-notes/), +[3.3.18](https://desktop.github.com/release-notes/), +[3.3.17](https://desktop.github.com/release-notes/), +[3.3.16](https://desktop.github.com/release-notes/), +[3.3.15](https://desktop.github.com/release-notes/) ++ TortoiseGit [2.16.0](https://tortoisegit.org/download/) ++ Git Cola [4.7.1](https://github.com/git-cola/git-cola/releases/tag/v4.7.1) ++ Garden [1.5.0](https://github.com/garden-rs/garden/releases/tag/v1.5.0) ++ Tower for Mac [11.0](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) ([blog post](https://www.git-tower.com/blog/tower-mac-11/)) ++ Tower for Windows [7.0](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) ++ tig [2.5.10](https://github.com/jonas/tig/releases/tag/tig-2.5.10) ++ git-credential-oauth [0.11.3](https://github.com/hickford/git-credential-oauth/releases/tag/v0.11.3) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Beat Bolli, Sven Strickroth, David Aguilar, +Bruno Brito and Štěpán Němec. diff --git a/_posts/2024-06-30-edition-112.markdown b/_posts/2024-06-30-edition-112.markdown new file mode 100644 index 0000000000..6e490ec0dd --- /dev/null +++ b/_posts/2024-06-30-edition-112.markdown @@ -0,0 +1,278 @@ +--- +title: Git Rev News Edition 112 (June 30th, 2024) +layout: default +date: 2024-06-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 112 (June 30th, 2024) + +Welcome to the 112th 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 May and June 2024. + +## Discussions + + + +### Reviews + +* [[RFC PATCH] docs: document upcoming breaking changes](https://lore.kernel.org/git/fc1a9fa03de7330f79dc56b0f2712834cb236b5a.1715070296.git.ps@pks.im/) + + Patrick Steinhardt sent an RFC patch to the mailing list that + created a new "UpcomingBreakingChanges.md" document. The goal of the + document was to inform users and developers of deprecations and + breaking changes, and to encourage discussion of the direction of + the project regarding these topics in advance. + + Patrick noted that the changes listed in the document, along with + links to mailing list threads where they had been discussed, were a + work in progress with controversial and missing items, and that he + didn't want to push for a Git 3.0 release with the listed changes + soon. + + The idea for that new document had been discussed previously + [in a thread about a patch series from Patrick](https://lore.kernel.org/git/ZjiL7vu5kCVwpsLd@tanuki/) + that introduced subcommands like `get`, `set`, etc, in `git config`. + In that thread, after Patrick asked if we wanted to introduce a + document to keep track of upcoming removals for a potential Git 3.0 + release, Junio Hamano, the Git maintainer, replied to Patrick that + in a few of his ["What's cooking" emails](https://lore.kernel.org/git/?q=s%3A%22What%27s+cooking+in+git.git%22) + before the Git 2.44.0 release, he had written: + + > It may not be a bad idea to reflect on what technical debt and UI + > warts we have accumulated so far to see if we have enough of them to + > start planning for a breaking Git 3.0 release (or, of course, keep + > incrementally improve the system, which is much more preferable -- + > continuity and stability is good). + + So Junio was happy that "somebody has bit it ;-)" and suggested a + number of topics that could be added to the document Patrick wanted + to create. This started a discussion about the possibility of + deprecating some features, such as the `restore`, `switch`, + `submodules` and `worktrees` subcommands. + + In the RFC patch to add the document, Patrick mentioned some of the + topics suggested by Junio, but not others that seemed controversial + in the previous discussion. + + Johannes Schindelin, alias Dscho, replied to Patrick's RFC patch + saying he loved it. Dscho also gave his opinion about the topics, + and suggested to deprecate or remove additional rarely used + features. + + Junio replied to Patrick's patch suggesting to add features that we + don't want to drop and why, and to mention that we deprecate but, + for backward compatibility, rarely remove old ways to do things. + Patrick agreed to Junio's suggestion and proposed a "superseded" + section for the features we don't want to drop. + + Dragan Simic, who had participated in the discussions of the preceding + `git config` thread, repeated that he didn't want to see any of + `git restore`, `git switch` or `git checkout` deprecated, which + Patrick agreed shouldn't be done. + + Phillip Wood, replying to Patrick's patch, asked if the document + should track the progress of some unfinished work, like the config + based hooks implementation. Patrick said he was planning on + creating a separate document for long running projects, projects + already discussed, and also small or micro projects, with the + additional intent to help newcomers looking for something to work on. + + Justin Tobler also replied to Patrick's patch suggesting adding the + removal of double dot and triple dot syntax (".." and "...") from + `git diff` to the document. This was discussed by Junio and Patrick + but, as it would need a lot more work, Patrick decided to not add it + to the document for now. + + Patrick then sent a + [version 2 of his patch](https://lore.kernel.org/git/2ef53ff98b12fe9373a15ec3a795235f040d9049.1715667067.git.ps@pks.im/) + adding a section about features "that are _not_ to be + deprecated" and proposing some further deprecations, while withdrawing + the `$GITDIR/hooks` directory deprecation proposal. + + Karthik Nayak replied to the patch version 2, listing a number of + commands not mentioned in the document that do similar things, which + might indicate that some of them could be deprecated too. Patrick, + Junio and Dragan discussed these commands, but decided that only + `git pickaxe`, which is an alias for `git blame`, could be removed + for now. + + So Patrick sent a + [version 3 of his patch](https://lore.kernel.org/git/84c01f1b0a2d24d7de912606f548623601c0d715.1716555034.git.ps@pks.im/), + which only added the removal of `git pickaxe`. + + Junio replied to this version 3 with a lot of comments to discuss + how each item was justified and how we could improve on justifying + items in general. Patrick then agreed on ways to improve the + document. + + Patrick sent a + [version 4](https://lore.kernel.org/git/cover.1717141598.git.ps@pks.im/) + where the single patch had been broken down into 4 patches. In the + process a lot of the proposed deprecations from the previous version + were removed and the document name was changed from + "UpcomingBreakingChanges.md" to "BreakingChanges.md" as some changes + listed in the "Superseded features that will not be deprecated" + section should not be considered upcoming. + + The goal was to introduce the document in a skeletal form in the + first patch and then add only one item to each of the three sections + in the following patches. This way each of the last 3 patches should + be an example of how other items should later be added to the + document. + + Junio, Patrick and Todd Zullinger then discussed relatively small + improvements to the form and content of the document. + + Patrick sent a + [version 5 of the patch series](https://lore.kernel.org/git/cover.1717402497.git.ps@pks.im/) + where the main change was that the document was converted to + AsciiDoc instead of Markdown and renamed from "BreakingChanges.md" + to "BreakingChanges.txt" for format compatibility with most other + documents in the codebase. + + Junio, Phillip Wood and Patrick discussed other small improvements, + which Patrick integrated into + [version 6 of the patch series](https://lore.kernel.org/git/cover.1717504292.git.ps@pks.im/). + + Junio then suggested a few more small improvements, which Patrick + finally integrated into + [version 7 of the patch series](https://lore.kernel.org/git/cover.1718345026.git.ps@pks.im/), + which was later merged into the 'master' branch. + + + + + +## Other News + + + +__Light reading__ + +* [BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days](https://graphite.dev/blog/bitkeeper-linux-story-of-git-creation) + by Nicholas Yan on Graphite Blog. + See also, among others, [GitHistory page in the archives of Git SCM Wiki](https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitHistory.html), + which was mentioned in [Git Rev News Edition #105](https://git.github.io/rev_news/2023/11/30/edition-105/), + and other links that were mentioned in that edition. +* [Git Workflows for API Technical Writers](https://bump.sh/blog/git-workflows-for-api-technical-writers) + by James Higginbotham on Bump\.sh. + Mentions [Bump.sh](https://bump.sh/), an API doc platform for tech writers and engineers, + at the end of the article. +* [What is Git? Our beginner’s guide to version control](https://github.blog/2024-05-27-what-is-git-our-beginners-guide-to-version-control/) and + [Top 12 Git commands every developer must know](https://github.blog/2024-06-10-top-12-git-commands-every-developer-must-know/) + by Kedasha Kerr on GitHub Blog. This blog post accompanies the + [GitHub for Beginners](https://youtube.com/playlist?list=PL0lo9MOBetEFcp4SCWinBdpml9B2U25-f&feature=shared) + series (YouTube playlist). +* [Stop Wasting Hours! Git Bisect: Your Ultimate Bug Hunting Tool](https://ionixjunior.dev/en/stop-wasting-hours-git-bisect-your-ultimate-bug-hunting-tool/) + by Ione Souza Junior on his blog; also available [on DEV.to](https://dev.to/ionixjunior/stop-wasting-hours-git-bisect-your-ultimate-bug-hunting-tool-4ebc) + as a part of [mastering-git series](https://dev.to/ionixjunior/series/26070). +* [The Magic of Git Stash: How It Saved My Day](https://dev.to/waqaryounis7564/the-magic-of-git-stash-how-it-saved-my-day-119k) + by waqaryounis7564 on DEV\.to. +* [Prevent Hidden Merge Conflicts](https://dev.to/shinigami92/prevent-hidden-merge-conflicts-2lem) + by Shinnigami on DEV\.to; but note that the described solutions might warrant some more thought + (linearizing history by requiring rebase instead of merge to integrate changes + versus requiring branch to be up to date before merging), and are not the only possible + solutions (for example: post-merge checks). +* [“Good Commit” vs “Your Commit”: How to Write a Perfect Git Commit Message](https://dev.to/safdarali/good-commit-vs-your-commit-how-to-write-a-perfect-git-commit-message-59ol) + by Safdar Ali on DEV\.to. + * Compare the [Conventional Commits](https://www.conventionalcommits.org/) specification, + first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/), + and [Gitmoji](https://gitmoji.dev/), first mentioned in [Git Rev News Edition #47](https://git.github.io/rev_news/2019/01/23/edition-47/). +* [Ten Things You Didn’t Know Git And GitHub Could Do](https://owenou.com/ten-things-you-didnt-know-git-and-github-could-do/) + by Owen Ou on Owen Ou's blog (2012). +* [Versioning FreeCAD files with git](https://blog.lambda.cx/posts/freecad-and-git/) + (FreeCAD files are zip archives containing text documents) by Dante Catalfamo on lambda.cx blog (2021). + + +  + +* [Programming in Unison](https://lwn.net/Articles/978955/) + by Daroc Alden on LWN\.net ([free subscriber link](https://lwn.net/SubscriberLink/978955/cd8dffc792b86313/)). + [Unison](https://www.unison-lang.org/) is an MIT-licensed programming language, + where programs are stored in an append-only, content-addressed database + (though still displayed to the user for editing as text, using the editor of their choice)... + just like information about project versions is stored in Git. + + + +__Git tools and sites__ + +* [setuptools-scm](https://github.com/pypa/setuptools_scm) + is a tool that extracts Python package versions from `git` or `hg` metadata + instead of declaring them as the version argument or in an SCM managed file. + Additionally, it provides setuptools with a list of files that are managed by the SCM + (i.e. it automatically adds all of the SCM-managed files to the sdist). + Unwanted files must be excluded via `MANIFEST.in`. + The preferred way to configure setuptools-scm is via `pyproject.toml`.
+ The [latest version](https://setuptools-scm.readthedocs.io/en/latest/) + and the [stable version documentation](https://setuptools-scm.readthedocs.io/en/stable/) + are available on Read the Docs. +* [`piku`](https://piku.github.io/), which was inspired by [`dokku`](https://dokku.com/), + allows you to do `git push` deployments to your own servers, no matter how small they are. + An open source PaaS (Platform as a Service) alternative to services such as Heroku. + Written in Python. +* [gitchangelog](https://github.com/vaab/gitchangelog) is a tool that + creates a changelog from git log history. Written in Python; + no longer actively developed (version 3.0.4 is from 2018). + * Compare with for example [git-cliff](https://git-cliff.org/) changelog generator, + mentioned in [Git Rev News Edition #108](https://git.github.io/rev_news/2024/02/29/edition-108/). +* [git-open-remote](https://github.com/masukomi/masuconfigs/blob/master/bin/git-scripts/git-open-remote) + is a shell script by [masukomi](https://masukomi.org) to open the web page(s) for the repo's remote(s). + With this script you can simply cd into a git repo and type `git open-remote`. + Requires [`open`](https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/open.1.html) + or [`xdg-open`](https://linux.die.net/man/1/xdg-open) + (aliased or linked to `open`) to open the web browser, + and [charm gum](https://github.com/charmbracelet/gum) + to implement the selection UI when the Git repo has more than one remote. +* [Git EOL Conversion Diagram](https://gist.github.com/DecimalTurn/3f99a3903366bf9fb2c1f513bd3c5a83) for checkout + as Gist providing an [SVG version](https://raw.githubusercontent.com/gist/DecimalTurn/3f99a3903366bf9fb2c1f513bd3c5a83/raw/d54d0e842c1f22e0b04d7a044dde1489993d87bf/Git-EOL-Conversion-Diagram.svg) + and an [editable version on Mindmup](https://app.mindmup.com/map/_free/2024/06/982eaeb032cf11ef93d0a9d7af4d6195), + by Martin Leduc (@DecimalTurn). + +## Releases + ++ Git [2.45.2 and friends to unbreak "git lfs" and others](https://public-inbox.org/git/xmqqr0dheuw5.fsf@gitster.g/) ++ Git for Windows [2.45.2(1)](https://github.com/git-for-windows/git/releases/tag/v2.45.2.windows.1) ++ GitHub Enterprise [3.13.0](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.0), +[3.12.5](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.5), +[3.11.11](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.11), +[3.10.13](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.13), +[3.9.16](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.16) ++ GitLab [17.1.1, 17.0.3, 16.11.5](https://about.gitlab.com/releases/2024/06/26/patch-release-gitlab-17-1-1-released/), +[17.1](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/), +[17.0.2, 16.11.4, 16.10.7](https://about.gitlab.com/releases/2024/06/12/patch-release-gitlab-17-0-2-released/) ++ GitKraken [10.0.2](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.2](https://desktop.github.com/release-notes/), +[3.4.1](https://desktop.github.com/release-notes/) ++ Tower for Mac 12.0 (BETA) — [Release blog post](https://www.git-tower.com/blog/tower-mac-12/) ++ Garden [1.7.0](https://github.com/garden-rs/garden/releases/tag/v1.7.0), +[1.6.0](https://github.com/garden-rs/garden/releases/tag/v1.6.0) ++ Git-Cola [4.8.0](https://github.com/git-cola/git-cola/releases/tag/v4.8.0) ++ git-credential-oauth [0.12.1](https://github.com/hickford/git-credential-oauth/releases/tag/v0.12.1), +[0.12.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.12.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Štěpán Němec, Bruno Brito, David Aguilar, +Brandon Pugh and Dragan Simic. diff --git a/_posts/2024-07-31-edition-113.markdown b/_posts/2024-07-31-edition-113.markdown new file mode 100644 index 0000000000..629b7a3192 --- /dev/null +++ b/_posts/2024-07-31-edition-113.markdown @@ -0,0 +1,435 @@ +--- +title: Git Rev News Edition 113 (July 31st, 2024) +layout: default +date: 2024-07-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 113 (July 31st, 2024) + +Welcome to the 113th 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 June and July 2024. + +## Discussions + + +### General + +* [[ANNOUNCE] Tickets available for Git Merge 2024](https://lore.kernel.org/git/ZpU0WwsrXCF8BC1f@nand.local/) + + Taylor Blau announced that [tickets for Git Merge 2024, Berlin, September 19th and 20th](https://git-merge.com) + are now on sale. People who would like to come but need financial + assistance with travel costs can contact the Git PLC or Scott + Chacon directly. + +* [[ANNOUNCE] Git Merge 2024 CFP deadline extended](https://lore.kernel.org/git/ZqkHxvDx7dlh0RX6@nand.local/) + + Taylor Blau announced that the Git Merge 2024 CFP (Call For + Proposals) limit has been extended by a week from August 1st to August 8th. + So there are a few more days left to propose talks. + +* [[ANNOUNCE] Berlin Git Meetup on August 14th, 6pm CEST](https://lore.kernel.org/git/ZqoQcuKz_ynYaBNM@tanuki/) + + Patrick Steinhardt announced that some Git developers are trying to + revive the Git user group in Berlin and will host their first + session together with GitButler soon. + + + +### Support + +* [[BUG] "git clean -df ." silently doesn't delete folders with stale .nfs* files](https://lore.kernel.org/git/ae862adb-1475-48e9-bd50-0c07dc42a520@rawbw.com/) + + Yuri reported that `git clean -df .`, which was supposed to delete a + directory and all its contents, didn't work when there were files + named '.nfsXXXXXXXXXXX' managed by NFS in that directory. He + expected that `git clean -df .` would warn or error out when it + cannot remove such a file, instead of ignoring the fact that it + could not remove the file and the containing directory and + terminating with a success exit code. + + Junio Hamano, the Git maintainer, replied to Yuri saying that it was + expected that directories that were not empty were not removed. + + Yuri replied that he expected the '.nfsXXXXXXXXXXX' files to be + removed as they were untracked, that is, neither added nor part of the repo, + and the command was expected to remove such untracked files. + + Junio replied that the '.nfsXXXXXXXXXXX' files were "a limitation" + of NFS that applications, including Git, couldn't and weren't + supposed to remove. He pointed to some documentation which explains + what these special NFS files are, and that they originate from an NFS + protocol based implementation strategy commonly known as "silly rename". + + Yuri replied that Git should still complain when it cannot remove + such files, or that there should be a verbosity option that should + make it complain in such cases. + + Randall S. Becker replied to Yuri that he tried to reproduce the + issue without using NFS and couldn't. So he asked Yuri if he could + share "a reproducible set of commands" and said that it was probably + caused by NFS. + + Junio replied to Randall and Yuri that removing a '.nfsXXXXXXXXXXX' + files under a real NFSv3 client would likely result in the file + being automatically resurrected, and that failure to remove a file + should indeed be reported as Git does when it cannot remove a + regular file. + + Yuri replied to Randall listing a series of instructions to + reproduce the issue. He agreed that Git reported failures when it + couldn't remove a file because of "permissions and special flags + reasons", but he repeated that it should also do it in the case of + such NFS files. + + Randall replied to Yuri saying he thought that Git didn't even see + the NFS files. He asked if a second `git clean -df .` removed the + NFS files and put new ones, with different names, in place. + + Yuri replied that it wasn't the case and there seemed to be a single + NFS file. + + Chris Torek then chimed into the discussion replying to Yuri. He + explained in details how "NFS silly renames" work, and listed some + cases which could result in NFS lying to Git by reporting that an + unlink(2) operation succeeded when in fact the file was renamed but + not deleted. In such a case Git could not report that it couldn't + remove a file. It could report that it couldn't remove the + containing directory though. + + Chris finished his explanations saying "Anyway, that's the OS view + of this mess. I leave the work on Git itself to others. :-)" + + Jeff King, alias Peff, replied to Yuri's email that contained a + series of instructions to reproduce the issue. He said he got the + following warning when trying to reproduce: + ``` + warning: failed to remove xx/.nfs0000000002c8197f00000002: Device or resource busy + ``` + + So Peff thought Git worked properly on his system and then + communicated details of the OS and NFS mount he used. + + Yuri replied by giving information about his system. He also said + that when using `rm -rf` to remove the NFS file, he got a "Device or + resource busy" error message, but not when using Git. + + Randall replied to Peff that doing a self-mount to reproduce as Peff + did was perhaps not the best, as the NFS client might be aware of + the self-mount and things might not behave the same as in a regular + mount. + + Yuri suggested using a virtual machine to avoid a self-mount. + + Gabor Gombas replied to Yuri reporting the results of his tests. He + got a "Directory not empty" or a "Device or resource busy" error + message when he used `git clean -dfx`, but he also got no error + message when using `git clean -df`. + + This led Yuri to reply that with `-dfx` Git indeed warns about NFS + files on his machine, but with `-df` it doesn't, because the NFS + files are in the ignore list. + + It is indeed expected that ignored files are not deleted and are + just ignored without the `-x` option. + + +## Developer Spotlight: Rubén Justo + +* Who are you and what do you do? + + My name is Rubén, and that's how it's spelled correctly. However, + some old friends call me Ruben because when we were kids changing + names was a sign of friendship. Changing the accent from "ben" to + "ru", makes the letter 'e' lose its tilde when writing my name. + + My $dayjob is not related to Git, but I use it quite often during the + workday. Using it sometimes gives me an itch that I often can't + resist trying to scratch. + +* What would you name your most important contribution to Git? + + I can't think of any worth mentioning. But I'll say something in the + other direction; contributing to Git has not only meant solving some + itches, but it has clearly made me improve my overall work style. + I'm grateful for that. + +* What are you doing on the Git project these days, and why? + + This can be read at any time: polishing up some itches that has come + up for me or a colleague. + + Lately, though, I find myself exploring more and more side issues + that arise during iterations of the changes I was originally + interested in. + +* 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'll say a feasible one: something _in Git_ that allows me to avoid + writing shortcuts like `@{-1}`, `@{1}`, `@{...` + + At least on my keyboard, it's a pain to type `@`, `{...}`. And I + tend to type those shortcuts a lot. + + Perhaps too easy for the experts and they'll have a lot of spare time + during the year? + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + I think that backwards compatibility is overrated most of the time. + It's usually a matter of getting on with it and time; sometimes a lot + of time, I admit. + + The steps being taken towards Git 3.0 seem very interesting to me + [[ref 1](https://public-inbox.org/git/xmqqa5l2y6aa.fsf_-_@gitster.g/)] + [[ref 2](https://public-inbox.org/git/cover.1718345026.git.ps@pks.im/)]. + Perhaps there is an opportunity to do some breaking changes. I don't + have any in mind, though. + + * What is your favorite Git-related tool/library, outside of + Git itself? + + Definitely: [`tig`](https://jonas.github.io/tig/). + +* Do you happen to have any memorable experience w.r.t. contributing + to the Git project? If yes, could you share it with us? + + Nope. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + To interact with the list, I mainly use [`lei`](https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started), + [`mutt`](http://www.mutt.org/) and [`thunderbird`](https://www.thunderbird.net/en-US/) + in a rather makeshift way. Maybe someday I'll finally configure + [`git send-email`](https://git-send-email.io/). + + In fact, more often than not, when I send a patch, I have the feeling + that someone is going to come along and say: "Come on, Rubén. That + user agent? Set up a decent environment to send this properly". + + To develop, I mainly use vanilla Vim. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + Perhaps I would say that writing and reading code are not the most + important skills in a project like Git. Empathy and the development + of effective arguments to convey ideas or intentions are much more + crucial. + + Realizing and internalizing that, is a solid starting point, I think. + +* If there's one tip you would like to share with other Git + developers, what would it be? + + Keep in mind that reviewing code is much harder than writing it, but + writing a good message for the commit is even harder. + + +## Other News + +__Various__ + ++ [Highlights from Git 2.46](https://github.blog/open-source/git/highlights-from-git-2-46/) + by Taylor Blau on GitHub Blog. Those include pseudo-merge reachability bitmaps, + subcommands in [git-config](https://git-scm.com/docs/git-config/2.46.0) (like `git config list`), + an enhanced credential helper protocol, and improving the still experimental reftable support. ++ [What’s new in Git 2.46.0?](https://about.gitlab.com/blog/2024/07/29/whats-new-in-git-2-46-0/) + by Justin Tobler on GitLab Blog. Highlights include tooling to migrate reference backends + (from files backend to reftables), symref update instructions for `git update-ref --stdin`, + `git config` interface improvements (mentioned in the previous article linked), and bundle URI fixes. ++ [Anyone can Access Deleted and Private Repository Data on GitHub](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github) + via Cross Fork Object Reference (CFOR) from another [public] fork. + Any code committed to a public repository may be accessible forever + as long as there is at least one public fork of that repository. + This is an intentional design decision by GitHub; see [the documentation](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility). + There is though a separate fork network for public and for private versions + of the same repository.
+ Posted on Truffle Security blog. ++ [Debian debate over tag2upload reaches compromise](https://lwn.net/Articles/978324/) + by Joe Brockmeier on LWN\.net. The [tag2upload service](https://salsa.debian.org/dgit-team/dgit/-/blob/master/TAG2UPLOAD-DESIGN.txt) + promises a streamlined way for Debian developers using Git to upload packages to + the [Debian Archive](https://wiki.debian.org/Services/Debian%20Archive). + + +__Light reading__ + ++ [A Git story: Not so fun this time](https://blog.brachiosoft.com/en/posts/git/) + on Brachiosoft Blog. The title refers to the ["Just for Fun"](https://www.amazon.com/Just-Fun-Story-Accidental-Revolutionary/dp/0066620732/) + book, the 2001 autobiography of Linux kernel creator Linus Torvalds, + and how the Git origin story wasn't so much fun, at least for Linus. + The article provides a list of references. Includes new material + not seen in earlier retellings of the Git history, like the ones linked in + [Git Rev News Edition #2](https://git.github.io/rev_news/2015/04/05/edition-2/) (on 10 years of Git), + [Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/), + [Edition #62](https://git.github.io/rev_news/2020/04/23/edition-62/) (on 15 years of Git), + [Edition #105](https://git.github.io/rev_news/2023/11/30/edition-105/) + and [Edition #112](https://git.github.io/rev_news/2024/06/30/edition-112/) + (among others). ++ [Why Facebook doesn’t use Git](https://graphite.dev/blog/why-facebook-doesnt-use-git) + by Greg Foster on Graphite Blog. + + See also [Scaling Mercurial at Facebook](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/), + mentioned in [Git Rev News Edition #24](https://git.github.io/rev_news/2017/02/22/edition-24/). ++ [Pull requests via git push](https://blog.sesse.net/blog/tech/2024-07-15-13-04_pull_requests_via_git_push.html) + and a specially crafted `pre-receive` hook (and `git-http-backend` configured + to allow anonymous push) that turns `git push` into series of patch emails. + (Though this approach has some limitations.) Written by Steinar H. Gunderson on his blog. + + See also [git-pr](https://pr.pico.sh/) in the "Git tools and sites" section. ++ [How I Use Git Worktrees](https://matklad.github.io/2024/07/25/git-worktrees.html) + by Alex Kladov (matklad) on his GitHub Pages-based blog. + TL;DR: consider using worktrees not as a replacement for branches, + but as a means to manage concurrency in your tasks (for example: view, work, review, fuzz, scratch). ++ [Git autocorrect needs more marketing](https://dev.to/cloudx/git-autocorrect-needs-more-marketing-20gg) + by Axel Navarro for Cloud(x); on DEV\.to. + + See also [thefuck](https://github.com/nvbn/thefuck), a command line application + which corrects your previous console command (for example Git command) + if you made an error (like typos in command name), and it _didn't_ do what you wanted; + the tool was first mentioned in + [Git Rev News Edition #101](https://git.github.io/rev_news/2023/07/31/edition-101/). ++ [commit messages are optional](https://schpet.com/note/git-commit-messages-are-optional) + by Peter Schilling in schpet’s notebook (though for some of the mentioned uses, + commits with empty commit messages are better replaced with `git commit --fixup`). ++ [Git-ifying SVN: How I Brought Modern Version Control to an Age-Old System](https://ionixjunior.dev/en/gitifying-svn-how-i-brought-modern-version-control-to-an-ageold-system/) + by Ione Souza Junior on his blog; also available [on DEV.to](https://dev.to/ionixjunior/git-ifying-svn-how-i-brought-modern-version-control-to-an-age-old-system-4o3e) + as a last part of the [mastering-git series](https://dev.to/ionixjunior/series/26070). + Another article from this series was mentioned in [Git Rev News Edition #112](https://git.github.io/rev_news/2024/06/30/edition-112/). ++ [Benchmarking the Modern Development Experience across Versioning Tools: S3, DVC, Git LFS, and XetHub](https://about.xethub.com/blog/benchmarking-the-modern-development-experience) + by Ann Huang on XetHub blog. + + [XetHub](https://about.xethub.com/) is a development platform for datasets and models, + which automatically versions and tracks assets across the Machine Learning stack + to guarantee reproducibility. Mentioned in passing in [Git Rev News Edition #95](https://git.github.io/rev_news/2023/01/31/edition-95/). + + The comparison does not include [DagsHub's Direct Data Access / Data Streaming](https://dagshub.com/docs/feature_guide/dagshub_storage/data_streaming/), + which was [announced](https://dagshub.com/blog/launching-data-streaming-and-upload/) in 2022. + [DagsHub](https://dagshub.com/), a web platform for storing, versioning and managing data (data hub), + was first mentioned in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/). ++ [The visualization and analysis of git commit statistics for IT team leaders.](https://dev.to/responsivecrocodile/the-visualization-and-analysis-of-git-commit-statistics-for-it-team-leaders-2pof) + by Aleksei Bakhirev (Responsive Crocodile) on DEV\.to. Uses the [Assayo](https://github.com/bakhirev/assayo) + tool written by the author for plots (see also the [assayo.online](https://assayo.online/) webpage).
+ Some personal thought: beware of [Goodhart's law](https://en.wikipedia.org/wiki/Goodhart%27s_law): + _"When a measure becomes a target, it ceases to be a good measure"_. + For examples from IT, see Joel on Software "[Measurement](https://www.joelonsoftware.com/2002/07/15/20020715/)" (2002). ++ [Reorient GitHub Pull Requests Around Changesets](https://mitchellh.com/writing/github-changesets) + from one giant mutable changeset, by Mitchell Hashimoto on his blog (2023). ++ [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) + (2008) by Tim Pope on tbaggery blog; it also explains some of the reasoning behind recommendations. + +  + ++ git good (My Hero Academia fanfiction, humor/horror) - Izuku's quirk is Git, + the version control software (some artistic license taken in order to make a good story). + By Unknownlight. Available [on Archive of Our Own](https://archiveofourown.org/works/55773742/chapters/141591955), + [on FanFiction.net](https://www.fanfiction.net/s/14369888/1/git-good) (not recommended by the author), + and [on SpaceBattles](https://forums.spacebattles.com/threads/git-good-my-hero-academia-izukus-quirk-is-git-the-version-control-software.1163142/).
+ Summary: + > Reality shattered like broken glass. The firmament that separated the real world from the eldritch beyond had broken. Two timelines had collided in the center of the street - an incongruous synthesis of two different chains of events. A building collapsed, and it did not. An explosion devastated the surroundings, and it did not. Screaming faces and laughs of joy overlapped each other as if viewed through a kaleidoscopic prism. + > + > The crowd looked on in horror and awe. Who was responsible for tearing apart the fabric of reality? + > + > Izuku groaned. _'Great, another merge conflict'_, he thought. _'What a pain'_. + + +__Easy watching__ + ++ [I was wrong about `git stash`...](https://www.youtube.com/watch?v=ntM7utSjeVU) + (or rather, how one can use `git worktree`), by Philomatics on YouTube [5:18]. + + +__Git tools and sites__ + ++ [pico/git-pr](https://pr.pico.sh/) (Patch Requests) is a new Git collaboration service, + where you send and retrieve patches not via email but via SSH to a `git-pr` server: + ```bash + # Contributor submits his/her changes: + git format-patch origin/main --stdout | ssh pr.pico.sh pr create test + # > Patch Request has been created (ID: 1) + + # Owner can apply those changes via patch request: + ssh pr.pico.sh pr print 1 | git am -3 + ``` + Can be self-hosted. Written in Go, MIT licensed. ++ [eza](https://github.com/eza-community/eza) is a modern replacement + for the venerable file-listing command-line program `ls`. It knows about symlinks, + extended attributes, and Git (like file status in Git repo, Git repo status, + or ignoring files mentioned in `.gitignore`). Written in Rust, MIT licensed. + See the [documentation](https://eza.rocks/). ++ [BlenderBIM](https://blenderbim.org/) is an add-on for detailed and + data-rich [OpenBIM](https://www.buildingsmart.org/about/openbim/) + (Building Information Modeling) with Blender. + BlenderBIM supports [tracking the development of your IFC files with Git](https://docs.blenderbim.org/users/git_support.html) + (Industry Foundation Classes, or IFC, is an international standard for BIM). + Note that merging requires the [ifcmerge](https://github.com/brunopostle/ifcmerge) + tool to be installed (`ifcmerge` is written in Perl and published under the GPLv3 license). ++ [_diff-pdf_](https://vslavik.github.io/diff-pdf/) is a tool for visually comparing two PDFs + which produces a PDF file with visually highlighted differences. + Note that [the repository](https://github.com/vslavik/diff-pdf) states that + the code is not being actively developed. Written in C++, GPLv2 licensed. + + See also [pdf-diff](https://github.com/JoshData/pdf-diff) in Python, CC0-1.0 licensed; + another [pdf-diff](https://github.com/serhack/pdf-diff) in Go, MIT licensed; + and [diff-pdf-visually](https://github.com/bgeron/diff-pdf-visually) in Python, + dual licensed under both MIT License and Apache License, Version 2.0 - with + a slightly different goal. ++ [vdm: A General-Purpose Versioned-Dependency Manager](https://github.com/opensourcecorp/vdm) + is an alternative to e.g. `git submodules` for managing arbitrary external dependencies. + Written in Go, MIT licensed. + + Contrast [Gil (git links) tool](https://github.com/chronoxor/gil) + to manage complex recursive repository dependencies with cross references and cycles, + mentioned in [Git Rev News Edition #110](https://git.github.io/rev_news/2024/04/30/edition-110/). ++ [Bit-Booster is an Offline Commit Graph Drawing Tool](https://bit-booster.com/graph.html), + using HTML and SVG, generating graphs by pasting the result of running + `git log --all --date-order --pretty="%h|%p|%d"` into a textarea. + + It is also an [add-on for Atlassian Bitbucket Server](https://bit-booster.com/graph.html). + + The webpage includes [comparison with other various commit graph add-ons](https://bit-booster.com/best.html) (2016). + +  + ++ [How To Rotate](https://howtorotate.com/) is an open-source collection + of API Key Rotation tutorials for different SaaS providers. ++ [Act](https://github.com/nektos/act) is a command line tool + to run your GitHub Actions locally, using the Docker Engine API. Written in Go. + Please look at the [`act` user guide](https://nektosact.com/) for more documentation. + + There is also [Act runner](https://gitea.com/gitea/act_runner), + a runner for Gitea based on the Gitea fork of `act`. + + +## Releases + ++ Git [2.46.0](https://public-inbox.org/git/xmqqzfq0i0qa.fsf@gitster.g/), +[2.46.0-rc2](https://public-inbox.org/git/xmqq7cdavgqa.fsf@gitster.g/), +[2.46.0-rc1](https://public-inbox.org/git/xmqqwmlivcdp.fsf@gitster.g/), +[2.46.0-rc0](https://public-inbox.org/git/xmqqjzhqmt22.fsf@gitster.g/) ++ Git for Windows [2.46.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.46.0.windows.1), +[2.46.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.46.0-rc2.windows.1), +[2.46.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.46.0-rc1.windows.1), +[2.46.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.46.0-rc0.windows.1) ++ GitLab [17.2.1, 17.1.3, 17.0.5](https://about.gitlab.com/releases/2024/07/24/patch-release-gitlab-17-2-1-released/), +[17.2](https://about.gitlab.com/releases/2024/07/18/gitlab-17-2-released/), +[17.1.2, 17.0.4, 16.11.6](https://about.gitlab.com/releases/2024/07/10/patch-release-gitlab-17-1-2-released/) ++ GitHub Enterprise [3.13.2](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.2), +[3.12.7](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.7), +[3.11.13](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.13), +[3.10.15](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.15), +[3.9.18](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.18) ++ GitKraken [10.1.1](https://help.gitkraken.com/gitkraken-client/current/), +[10.1.0](https://help.gitkraken.com/gitkraken-client/current/) ++ Garden [1.7.0](https://github.com/garden-rs/garden/releases/tag/v1.7.0) ++ Git Cola [4.8.1](https://github.com/git-cola/git-cola/releases/tag/v4.8.1) ++ git-credential-oauth [0.13.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.13.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Štěpán Němec and Rubén Justo. diff --git a/_posts/2024-08-31-edition-114.markdown b/_posts/2024-08-31-edition-114.markdown new file mode 100644 index 0000000000..8f81a8674a --- /dev/null +++ b/_posts/2024-08-31-edition-114.markdown @@ -0,0 +1,231 @@ +--- +title: Git Rev News Edition 114 (August 31st, 2024) +layout: default +date: 2024-08-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 114 (August 31st, 2024) + +Welcome to the 114th 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 July and August 2024. + +## Discussions + + + +### Reviews + +* [[PATCH] ReviewingGuidelines: encourage positive reviews more](https://lore.kernel.org/git/xmqqsevysdaa.fsf@gitster.g/) + + Junio Hamano, the Git maintainer, sent a patch to the mailing list + which updated the 'ReviewingGuidelines.txt' documentation with the + goal of encouraging positive reviews even more. + + The 'ReviewingGuidelines.txt' documentation was + [created a few years ago](https://lore.kernel.org/git/pull.1348.v2.git.1663614767058.gitgitgadget@gmail.com/) + by Victoria Dye to provide "consistent definitions for common + review terminology" and to give advice to reviewers, in a similar + way as the MyFirstContribution documentation gives advice to + contributors. + + The few paragraphs that Junio's patch added said that positive + reviews are highly encouraged, even when the author is a work + colleague. They show that people other than the author(s) of the + reviewed patches care about the issue that is addressed. + + When writing positive reviews, reviewers should tell why they + support the patches, and should show that they understand the issue + and how the patches address it. They are also encouraged to describe + how they understand complex parts of the patches. + + Junio's patch also adds a small paragraph saying that "uplifting + feedback goes a long way towards encouraging contributors to + participate more actively in the Git community." + + Eric Sunshine then replied to Junio pointing out a minor typo in his + patch. Patrick Steinhardt replied to Junio too. He said that he had + already guided some of his GitLab colleagues who review patches + and suggested them to do what Junio describes. + + Derrick Stolee, who prefers to be called Stolee, replied to Patrick + agreeing with him and saying that it also helps to not have internal + reviews for experienced contributors. He said that they used to have + internal reviews at Microsoft but it was overly cautious and "loses + the benefits of doing reviews in the open". + + Patrick replied to Stolee saying that GitLab also used to have an + internal review, but it recently became optional and recommended + only for people who are not yet familiar with the mailing list + workflow. + + Junio then sent + [a version 2](https://lore.kernel.org/git/xmqqle1pjwtt.fsf@gitster.g/) + of the patch fixing small typos. Patrick reviewed this version + and found it good, so it was later merged into the 'master' branch. + + + + + +## Other News + +__Various__ ++ [GitLab now supports SHA256 repositories](https://about.gitlab.com/blog/2024/08/19/gitlab-now-supports-sha256-repositories/) + by John Cai on GitLab Blog (in Bulletin Board category). ++ [Forgejo v8.0 is available](https://forgejo.org/2024-07-release-v8-0/). + + [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 mentioned in passing in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/), + as one of the forges working on implementing the [ForgeFed](https://forgefed.org/) + federation protocol for forge services. ++ Packt recently published the second edition of the “Mastering Git” book + by Jakub Narębski, one of the Git Rev News editors. + The book is available [on PacktPub](https://www.packtpub.com/en-us/product/mastering-git-9781835086070) + and [on Amazon](https://www.amazon.com/Mastering-Git-expert-level-proficiency-distributed-ebook/dp/B0D98BR1T7). + The first edition of the book was mentioned in [Git Rev News Edition #16](https://git.github.io/rev_news/2016/06/15/edition-16/); + you can find the interview with Jakub Narębski in [Edition #17](https://git.github.io/rev_news/2016/07/20/edition-17/). + +__Light reading__ ++ [Different ways to use `--patch` in Git](https://tekin.co.uk/2024/08/the-many-uses-for-git-patch) + by Tekin Süleyman on his blog. It describes selectively stashing changes, + selectively discarding changes, and selectively restoring changes. + This article expands on the + "[interactively stage changes with \-\-patch](https://tekin.co.uk/2017/03/git-tips-you-possibly-did-not-know-you-needed#3-interactively-stage-changes-with---patch)" advice + in [Git Tips you (Possibly) Didn't Know You Needed](https://tekin.co.uk/2017/03/git-tips-you-possibly-did-not-know-you-needed). ++ [Tracing the evolution of a Python function with git log](https://nerderati.com/tracing-the-evolution-of-a-python-function-with-git-log/) + by Joël Perras on his Nerderati blog. It shows a detailed example on using `git log -L` + (and the `diff=python` gitattribute) to diagnose a real-life bug that was ostensibly + caused by an upgrade to Authlib. + + This technique is also described in the + [See the History of a Method with `git log -L`](https://calebhearth.com/git-method-history) article, + mentioned in [Git Rev News Edition #105](https://git.github.io/rev_news/2023/11/30/edition-105/). ++ [Optimize your workflow with Git stash](https://developer.mozilla.org/en-US/blog/optimize-your-workflow-git-stash/) + by Toon Claes (from GitLab) at MDN Blog. ++ [Seriously, You Need to Learn Git](https://blog.derlin.ch/seriously-you-need-to-learn-git) + by Lucy Linder on her blog (also available [on DEV\.to](https://dev.to/derlin/seriously-you-need-to-learn-git-1n8j)). The article defines various levels of Git knowledge, + and explains how knowing Git might improve one's development process. ++ [Tips for creating merge commits](https://www.brandonpugh.com/blog/tips-for-creating-merge-commits/) + by Brandon Pugh on his blog. ++ [Back-dating Git commits based on file modification dates](https://til.simonwillison.net/git/backdate-git-commits) + by Simon Willison in his [TILs on Git](https://til.simonwillison.net/git) + (Today I’ve Learned). + + It was used by the author to create the [1991-WWW-NeXT-Implementation](https://github.com/simonw/1991-WWW-NeXT-Implementation) + repository out of [the archive](https://www.w3.org/History/1991-WWW-NeXT/Implementation/) + of Tim Berner-Lee's original code for the WorldWideWeb application for NeXT. + This endeavor was described in a short blog post, [1991-WWW-NeXT-Implementation on GitHub](https://simonwillison.net/2024/Aug/1/www-next-implementation-on-github/). ++ [Store Code Discussions in Git using Git Notes](https://wouterj.nl/2024/08/git-notes) + by Wouter de Jong on his blog. The article includes some code (in PHP) + that uses the GitHub API to fetch the pull request comments and store them + in notes (under the `github-comments` notes reference). ++ [Attaching notes to git branches](https://dev.to/pinotattari/attaching-notes-to-git-branches-503k) + by Riccardo Bernardini on DEV\.to. The article describes why this feature is useful + and how `git branch --edit-description` and `git notes` fall short; this led to + the creation of the [git-branchnotes](https://gitlab.com/mockturtle/git-branchnotes) tool. ++ [This developer tool is 40 years old: can it be improved?](https://stackoverflow.blog/2024/08/05/this-developer-tool-is-40-years-old-can-it-be-improved) + by Bill Harding (CEO at GitClear) on StackOverflow Blog. + The article describes how GitClear's "Commit Cruncher" diff algorithm works, + which was created with the goal of making code reviews easier. + Note that the Myers diff algorithm (created by Eugene Myers in his + [seminal work](http://www.xmailserver.org/diff2.pdf) in 1986) + is not the only one available in [`git diff`](https://git-scm.com/docs/git-diff): + there are also `minimal`, `patience` and `histogram` diff algorithms available + (via the `--diff-algorithm` option); + this is not stated in the article. ++ [How Different Are Different diff Algorithms in Git?](https://cs.paperswithcode.com/paper/how-different-are-different-diff-algorithms): + a paper with code by Yusuf Sulistyo Nugroho, Hideaki Hata, Kenichi Matsumoto + from 2019. ++ [Git Things: A grab bag of less frequently talked about git adjacent points](https://matklad.github.io/2023/12/31/git-things.html) + by Alex Kladov (matklad) on his GitHub Pages-based blog, from 2023. ++ [Unified Versus Split Diff](https://matklad.github.io/2023/10/23/unified-vs-split-diff.html): + a discussion what is better for code reviews (and what the author uses) + by Alex Kladov (matklad) on his GitHub Pages-based blog, from 2023. ++ [How Does Git Store Files?](https://blog.git-init.com/how-does-git-store-files/) + — from a conceptual point of view. An article by by Alexis Määttä Vinkler + on [The Pragmatic Git](https://blog.git-init.com/) blog, from 2023. + + + ++ [Code review antipatterns](https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/code-review-antipatterns/) + for the dark side developers, a joke article by Simon Tatham + (don’t do any of the things described in this article). + + + +__Git tools and sites__ ++ [The Pragmatic Git](https://blog.git-init.com/) blog; + note that some articles are paid members only. Powered by Ghost. ++ [Carapace-bin](https://github.com/carapace-sh/carapace-bin) provides argument completion + for multiple CLI commands ([full list](https://carapace-sh.github.io/carapace-bin/completers.html) + including Git, [git-extras](https://github.com/tj/git-extras), `gh` GitHub CLI, `glab` GitLab CLI, + `tea` Gitea CLI, etc.), and works across multiple POSIX and non-POSIX shells. + Details about the Git completion support can be found in issue [#99](https://github.com/carapace-sh/carapace-bin/issues/99). + Written in Go under the MIT license.
+ Carapace-bin is a part of the [Carapace](https://carapace.sh/) multi-shell completion library and binary. + A high-level overview of Carapace itself is available at . ++ [git-random](https://git-random.olets.dev/): quickly build random-content Git + graphs with a specified shape. + This is a tool that can work as an aid for learning and experimenting with Git. + Source code available [on GitHub](https://github.com/olets/git-random/). + Written as a single-file Bash script under a custom + CC BY-NC-SA 4.0 license with Hippocratic License v3 ethical requirements. + + The author mentions that this tool was inspired by seeing Lorna Jane Mitchell + use Matthew J. McCullough's [generaterandomchanges](https://github.com/matthewmccullough/scripts/blob/master/generaterandomchanges) + in her talk _"[Advanced Git for Developers](https://www.youtube.com/watch?v=duqBHik7nRo)"_ + at Laracon EU 2015. ++ [git-branchnotes](https://gitlab.com/mockturtle/git-branchnotes) is a command-line tool + (that can be run as a git external command) that allows you to add notes to a branch and manage them. + Written in Ruby. + ++ [w2vgrep - Semantic Grep](https://github.com/arunsupe/semantic-grep) + is a command-line tool, with the interface similar to that of `grep`, + that performs semantic searches on text input using word embeddings (word2vec). + It's designed to find semantically similar matches to the query, + going beyond simple string matching. Supports multiple languages. + Written in Go under the MIT license. ++ [Collective Code Construction Contract](https://rfc.zeromq.org/spec/42/) (C4) + is an evolution of the github.com [Fork + Pull Model](https://help.github.com/articles/about-pull-requests/), + aimed at providing an optimal collaboration model for free software projects. + + Compare with [Ship / Show / Ask: A modern branching strategy](https://martinfowler.com/articles/ship-show-ask.html) model, + mentioned in [Git Rev News #79](https://git.github.io/rev_news/2021/09/30/edition-79/). + +## Releases + ++ Gerrit Code Review [3.10.1](https://www.gerritcodereview.com/3.10.html#3101), +[3.8.8](https://www.gerritcodereview.com/3.8.html#388), +[3.9.6](https://www.gerritcodereview.com/3.9.html#396) ++ GitHub Enterprise [3.14.0](https://help.github.com/enterprise-server@3.14/admin/release-notes#3.14.0), +[3.13.3](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.3), +[3.12.8](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.8), +[3.11.14](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.14), +[3.10.16](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.16) ++ GitLab [17.3.1, 17.2.4, 17.1.6](https://about.gitlab.com/releases/2024/08/21/patch-release-gitlab-17-3-1-released/), +[17.3](https://about.gitlab.com/releases/2024/08/15/gitlab-17-3-released/), +[17.2.2, 17.1.4, 17.0.6](https://about.gitlab.com/releases/2024/08/07/patch-release-gitlab-17-2-2-released/) ++ GitKraken [10.2.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.3](https://desktop.github.com/release-notes/) ++ git-credential-oauth [0.13.2](https://github.com/hickford/git-credential-oauth/releases/tag/v0.13.2), +[0.13.1](https://github.com/hickford/git-credential-oauth/releases/tag/v0.13.1) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Štěpán Němec, Brandon Pugh, Ralf Steube +and Toon Claes. diff --git a/_posts/2024-09-30-edition-115.markdown b/_posts/2024-09-30-edition-115.markdown new file mode 100644 index 0000000000..4e4af1c8ba --- /dev/null +++ b/_posts/2024-09-30-edition-115.markdown @@ -0,0 +1,454 @@ +--- +title: Git Rev News Edition 115 (September 30th, 2024) +layout: default +date: 2024-09-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 115 (September 30th, 2024) + +Welcome to the 115th 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 2024. + +## Discussions + +### General + +* [Git Merge 2024 conference](https://git-merge.com/) and [Contributor's Summit 2024](https://lore.kernel.org/git/Zu2DmS30E0kKug2a@nand.local/) + + The Git Merge conference happened on + [September 19th and 20th](https://github.com/git/git-merge) in + Berlin, hosted by [GitButler](https://gitbutler.com/) and + [GitHub](https://github.com/). + + The first day consisted of + [talks](https://github.com/git/git-merge#day-one-talks) and an + afterparty in the evening sponsored by + [GerritForge](https://www.gerritforge.com/). + + On the [second day](https://github.com/git/git-merge?tab=readme-ov-file#day-two-unconference), + there was [the Contributor's Summit](https://lore.kernel.org/git/Zu2DmS30E0kKug2a@nand.local/) in parallel + with [breakout unconference sessions](https://github.com/git/git-merge/tree/main/breakouts). + +* [Git participated in GSoC (Google Summer of Code) 2024](https://summerofcode.withgoogle.com/programs/2024/organizations/git) + + All the contributors have successfully passed their final evaluation + and published a final report: + + - Jialuo She [worked](https://luolibrary.com/) on the + [Implement consistency check for refs](https://summerofcode.withgoogle.com/programs/2024/projects/ukm4PTEF) + project. He was mentored by Karthik Nayak and Patrick Steinhardt. The final + report can be found on + [his website](https://luolibrary.com/2024/08/25/GSoC-Final-Report/). + + - Chandra Pratap [worked](https://chand-ra.github.io/) on the + [Move and improve reftable tests in the unit testing framework](https://summerofcode.withgoogle.com/programs/2024/projects/tlh611d7) + project. He was mentored by Patrick Steinhardt and Christian Couder. The final + report can be found on + [his website](https://chand-ra.github.io/2024/08/24/GSoC-Final-Report.html). + + - Ghanshyam Thakkar [worked](https://spectre10.github.io/posts/) on the + [Move existing tests to a unit testing framework](https://summerofcode.withgoogle.com/programs/2024/projects/e9C4rhrv) + project. He was mentored by Christian Couder and Kaartic Sivaraam. The final + report can be found on [his website](https://spectre10.github.io/posts/gsoc_final_report/). + + Congratulations to the contributors and their mentors! + +* Git will [participate in the next Outreachy round](https://www.outreachy.org/communities/cfp/git/) + + Git applied to participate in the next + [Outreachy](https://www.outreachy.org/) round from December 2024 to + March 2025 and was accepted. + [Two projects](https://www.outreachy.org/apply/project-selection/#git) + are proposed: + + - "Convert unit tests to use the clar testing framework" which will + be mentored by Patrick Steinhardt and Phillip Wood. + + - "Finish adding a 'os-version' capability to Git protocol v2" + which will be mentored by Christian Couder. + + See this [Outreachy webpage](https://www.outreachy.org/docs/applicant/) + for more information about the application process for contributors. + +### Reviews + +* [[PATCH] tests: drop use of 'tee' that hides exit status](https://lore.kernel.org/git/xmqq4j7uhfvm.fsf@gitster.g/) + + Junio Hamano, the Git maintainer, sent a patch removing uses of the + `tee` command from test scripts. + [tee(1)](https://en.wikipedia.org/wiki/Tee_(command)) is a shell + command that duplicates its input to both its output and to one or + more files. The issue was that in some test scripts it was used + after a [pipe](https://en.wikipedia.org/wiki/Pipeline_(Unix)) to + directly duplicate the output of a Git command, so using a format + like: + + `git COMMAND OPTIONS... | tee FILE...` + + However, it's not a good idea to use a pipe after a Git command because + pipes discard the exit code of the command before them, so the + standard (Unix) shell behaviour is that the exit code of the whole + sequence is simply the exit code of the last command of a pipe sequence, + here `tee`. In Git tests though, we wouldn't want a test + to pass if the Git command fails when it should succeed. + + \[For shell intimates: there are ways to override this default behaviour, + such as [the `pipefail` option](https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_09_02), + or [named pipes](https://en.wikipedia.org/wiki/Named_pipe), but + there are a number of reasons, like shell portability and making + it easy to understand small parts of the code, why Git developers + try to avoid using those features in the Git codebase.\] + + As there was no reason to hide the exit code of the Git commands in + the tests that used `tee`, Junio's patch basically just replaced + `| tee` with a simple `>` + [redirection](https://en.wikipedia.org/wiki/Redirection_(computing)). + + Rubén Justo replied to Junio suggesting a wording improvement in the + commit message, but otherwise agreeing with the patch. + + Johannes Schindelin, alias Dscho, also replied to Junio saying that + having something that duplicates the output of the Git command to + standard output could still be useful for debugging, especially when + dealing with CI failures. He showed an implementation of a + `redirect_and_show()` helper function that could perhaps be used + instead of `tee`, but agreed that it might be overkill and hoped that + having more unit tests written in C could help. + + Jeff King, alias Peff, replied to Dscho saying that a better help + for debugging CI failures might be to have a way to automatically + save the state of the test directory, called + `trash directory.tXXXX-YYYY` where `tXXXX-YYYY` is related to the + name of the test script. + + Junio also replied to Dscho saying that a simple `cat FILE` + instruction could be added after the lines where `| tee` was + replaced with a redirection to make sure the Git command output + appeared on standard output. Junio also agreed with Peff that saving + the state of test directories would be best to debug CI failures. + + A version of Junio's patch taking into account the wording + improvement suggested by Rubén was eventually merged. + + + +## Developer Spotlight: Jialuo She + +_Editor's note: We're starting a new initiative in Git Rev News where + we interview recent GSoC/Outreachy students to get their reflections + on completing their projects. Feel free to share any thoughts or + feedback you might have!_ + +* Who are you and what do you do? + + My name is Jialuo She. I find it quite challenging to select an English + name for myself, so I decide to leave it as is. However, you can simply + call me "Luo(/lwɔː/)". I am currently employed at NVIDIA as a Tegra + System Architect. In this role, I am responsible for developing the + verification infrastructure for complex full-chip features, such as + CPU-GPU cache coherency. So my daily job is unrelated to Git. In my + spare time, I continue my GSoC work to + [implement consistency checks for refs](https://summerofcode.withgoogle.com/programs/2024/projects/ukm4PTEF). + +* How did you initially become interested in contributing to Git, + and what motivated you to choose it as your GSoC project? + + When I was a student, I read [the book "Pro Git"](https://git-scm.com/book/en/v2) + to learn how to use Git in my daily development process. One day, I + found [a tutorial](https://www.leshenko.net/p/ugit/) that teaches + how to write a mini Git step by step, and I really appreciated the + design of Git. + + As I was approaching my graduate school graduation, I hoped to use the + opportunity provided by GSoC to do something meaningful for the long + term. Since I felt that I had an understanding of Git's internal + principles, believing that my chances of being selected would be much + higher. When I saw the "Implement consistency check for refs" project, + I became very interested and resolutely chose Git. + +* How do you balance your contributions with other responsibilities + like work or school? + + As a newcomer, contributing to Git can be particularly time-consuming + due to unfamiliarity with the overall codebase. I would dedicate an + evening to responding to review feedback, which forces me to think + about how to make improvements, and then I would code over the weekend. + Of course, if there were urgent situations at work or life, I would have + to postpone my contributions to Git. I feel there's no need to think + about balancing because it happens naturally. + +* What was your biggest takeaway or learning from GSoC that you now + apply regularly in your work? + + After participating in GSoC, I begin to consider whether my commit + sequence is clear and understandable when writing code at work. I also + become more stringent with myself regarding commit messages, ensuring + they clearly explain the background, motivation, and implementation + details. + +* What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it? + + When building the ref consistency check infrastructure, I encountered + an exceptionally long review process that lasted about three months. + It was quite frustrating because there was no positive feedback compared + with other participants. Then I reflected on myself, wondering why I + was always comparing myself to others instead of focusing on what I was + doing. So, I adjusted my mindset. + +* Have you thought about mentoring new GSoC students? + + If I have the opportunity and time, I would definitely mentor GSoC + students. I am very grateful to my mentors, Patrick and Karthik, for + introducing me to the Git community and enabling me to continue + contributing after completing GSoC. I hope that one day I can also + ignite the passion in others. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + The write and read support for symlink symrefs. + +* What is your favorite Git-related tool/library, outside of Git + itself? + + I very much like the [GitLens tool](https://gitlens.amod.io/) when using + VSCode. By using this tool, I hardly use the bare `git blame` command. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + When reviewing patches, I will firstly use [`b4`](https://b4.docs.kernel.org/en/latest/) + or simply fetch the branch stored in Junio's tree, and then I will + see the diffs just in the VSCode. To reply to a patch, I download the + raw email and use [`mutt`](http://www.mutt.org/) to write contents. + When sending patches, I still use `mutt` to make the environment as + simple as possible to improve efficiency. + + I develop Git using VSCode and the [clangd](https://clangd.llvm.org/) + language server. I generate the `compile_commands.json` file using + `compiledb make`. I believe this is one of the best development + approaches available today, offering excellent code suggestions, + completions, and static analysis. + +* How do you envision your own involvement with Git or other open + source projects in the future? + + I hope to complete the implementation of all ref consistency checks. + Additionally, I aim to further familiarize myself with the Git codebase + related to refs, follow the development of the reftable backend, and + participate in more reviews. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + In my opinion, the barrier to starting contributions to Git is relatively + high because Git doesn't have something like "good first issue" labels. + Therefore, I believe the best approach is to participate in mentoring + programs or continue work from certain mentoring programs as a student. + +* Would you recommend other students or contributors to participate in + the GSoC, or other mentoring programs, working on Git? Why? Do you + have advice for them? + + I highly recommend that students integrate into the Git community + through mentoring programs. These programs provide basic ideas to help you + get started and contribute to Git. Working on Git is an amazing experience, + allowing you to be guided by many experienced contributors, improve your + code quality standards, and enhance your communication skills. + + As for advice to participants, I believe the most important thing is not to + think of the project merely as a resume booster. Instead, let your passion + shine through and stay at the community after mentoring programs. + + +## Other News + +__Various__ ++ [Radicle 1.0](https://radicle.xyz/2024/09/10/radicle-1.0.html).
+ Radicle is a peer-to-peer, local-first code collaboration stack built on Git. + [Radicle](https://radicle.xyz/) was first mentioned in + [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/), + then in [Edition #70](https://git.github.io/rev_news/2020/12/26/edition-70/), + [#86](https://git.github.io/rev_news/2022/04/30/edition-86/), + and [#110](https://git.github.io/rev_news/2024/04/30/edition-110/) - where one + can find similar and related tools. ++ [git-scm.com is now a static website](https://lore.kernel.org/all/ZvrNmsycmamx2dcR@nand.local/t/#m72b3c0f77102fe9964e77d6c10d9166485e13c0e) + by Johannes Schindelin on the Git mailing list.
+ Moving git.github.io, Git Developer Pages and Git Rev News' website + into git-scm.com is discussed in [GitHub issue #729](https://github.com/git/git.github.io/issues/729). + +__Light reading__ ++ [Why GitHub Actually Won](https://blog.gitbutler.com/why-github-actually-won/): + How GitHub _actually_ became the dominant force it is today, from one of its cofounders. + Written by Scott Chacon on GitButler Blog.
+ Nice companion to various articles on Git history, like the latest + [A Git story: Not so fun this time](https://git.github.io/rev_news/2024/07/31/edition-113/) + in [Git Rev News #113](https://git.github.io/rev_news/2024/07/31/edition-113/) - in #113 you + can also find links to other editions with links to other retellings of the Git history. ++ [Rethinking code reviews with stacked PRs](https://www.aviator.co/blog/rethinking-code-reviews-with-stacked-prs/#) + on Aviator blog by Ankit Jain (also available [on DEV\.to](https://dev.to/dphenomenal/rethinking-code-reviews-with-stacked-prs-3dih), + published by Ibrahim Salami. Aviator provides [`av`](https://github.com/aviator-co/av), a CLI tool + to help with managing stacked PRs on GitHub. + + Stacked Pull Requests, also under the name Stacked Diffs, + were most recently mentioned in + [Git Rev News Edition #111](https://git.github.io/rev_news/2024/05/31/edition-111/), + where you can find links to other editions with other articles, and to related tools. + + See also [Stacked PRs CLI Product Comparison (Public)](https://docs.google.com/spreadsheets/d/1riYPbdprf6E3QP1wX1BeASn2g8FKBgbJlrnKmwfU3YE/edit?gid=0#gid=0) + Google Sheet spreadsheet. + + Contrast [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html), + which strongly recommends patterns that are best suited to Continuous Integration, + first mentioned in [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/), + and [Ship / Show / Ask: A modern branching strategy](https://martinfowler.com/articles/ship-show-ask.html), + mentioned in [Edition #79](https://git.github.io/rev_news/2021/09/30/edition-79/). ++ [Git With Python HowTo: GitPython Tutorial And PyGit2 Tutorial](https://grimoire.carcano.ch/blog/git-with-python-howto-gitpython-tutorial-and-pygit2-tutorial/) + by Marco Antonio Carcano on his blog 'The grimoire of a modern Linux professional'. ++ [Beyond “Commit” and “Push”: 5 Advanced Git Features You Should Know](https://www.git-tower.com/blog/5-advanced-git-features) + by Bruno Brito on GitTower Blog. + Covers git-bisect, git-rerere, gitattributes, git-notes, and git-worktree. ++ [Mastering Tower (Windows Edition)](https://www.git-tower.com/blog/mastering-tower-windows) + and [Mastering Tower (Mac Edition)](https://www.git-tower.com/blog/mastering-tower/) + by Bruno Brito on GitTower Blog. Tower is a proprietary Git client for Mac and Windows, + with 30-day free trial. ++ [Git bisect run techniques](https://paperless.blog/git-bisect-run-techniques) + by Victor Engmark on paperless\.blog. ++ [Semantic Versioning with GitVersion (GitFlow)](https://blog.raulnq.com/semantic-versioning-with-gitversion-gitflow) + by Raul Naupari on his blog; Featured on daily\.dev, also available + [on DEV\.to](https://dev.to/raulnq/semantic-versioning-with-gitversion-gitflow-1gb4). ++ [Host your own Radicle seed node](https://edzz.de/posts/host-your-own-radicle-seed-node/) + by Eduard on Ed's Site. Also available [on DEV\.to](https://dev.to/viiik/how-to-host-your-own-radicle-node-contribute-to-decentralized-source-control-5cgm). ++ [Creating a Git commit: The Hard Way](https://avestura.dev/blog/creating-a-git-commit-the-hard-way) + (with low-level plumbing commands) by Aryan Ebrahimpour + on Avestura's Personal Website. ++ [My Git cheatsheet](https://write.as/pylapp/my-git-cheatsheet) - a list + of some useful commands, as a cheatsheet or a simple reminder to keep and share. + Written by Pierre-Yves Lapersonne on his French and English pylapp blog in the fediverse (write\.as). + + + + +__Git tools and sites__ ++ [b4](https://github.com/mricon/b4) is a tool created to make it easier + for project developers and maintainers to use a distributed development + workflow that relies on patches, e-mail and distribution lists for code + contributions and review (like those used in Linux kernel development). + This tool was first mentioned in [Git Rev News Edition #61](https://git.github.io/rev_news/2020/03/25/edition-61/); + you can find links to various articles and posts about this tool + in [Edition #61](https://git.github.io/rev_news/2020/03/25/edition-61/), + [#91](https://git.github.io/rev_news/2022/09/30/edition-91/), + [#95](https://git.github.io/rev_news/2023/01/31/edition-95/), + [#107](https://git.github.io/rev_news/2024/01/31/edition-107/) and + [#109](https://git.github.io/rev_news/2024/03/31/edition-109/). + Written in Python, under GPL-2.0 license. ++ [Phabricator.KDE.org](http://phabricator.kde.org/) is KDE's desktop environment task management system. + It was used for patch review and other functions in the past, but KDE has since transitioned to GitLab, + at . Bug tracking is done using . + Phabricator is still used for task tracking by KDE until this functionality is migrated to GitLab. + + [Phabricator](https://www.phacility.com/phabricator/) is/was a suite + of web-based development collaboration tools, which includes a code review tool called Differential, + a repository browser called Diffusion, a change monitoring tool called Herald, + a bug tracker called Maniphest, and a wiki called Phriction.
+ Phabricator is [no longer actively maintained](https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/) + by Phacility since June 1, 2021. This tool was mentioned + in [Git Rev News Edition #13](https://git.github.io/rev_news/2016/03/16/edition-13/). + Written in PHP, under Apache 2.0 license. + + [Phorge](https://we.phorge.it/) is a community-maintained fork of Phabricator, + public [since Sep 7, 2022](https://we.phorge.it/phame/post/view/1/going_public/). + It seems to be actively developed. ++ [nb-clean](https://github.com/srstevenson/nb-clean) cleans Jupyter notebooks + of cell execution counts, metadata, outputs, and (optionally) empty cells, + preparing them for committing to version control. + Written in Python, under short ISC license. ++ [av](https://github.com/aviator-co/av) (Aviator) is a command-line tool + that helps you manage your stacked PRs on GitHub. + Written in Go, under MIT license. ++ [Stacked PRs CLI Product Comparison (Public)](https://docs.google.com/spreadsheets/d/1riYPbdprf6E3QP1wX1BeASn2g8FKBgbJlrnKmwfU3YE/edit?gid=0#gid=0) + is a Google Sheet spreadsheet by Aviator, listing various stacked PR/stacked diff tools: + + [ghstack](https://github.com/ezyang/ghstack) in Python, + + [gh-stack](https://github.com/timothyandrew/gh-stack) in Rust - no longer developed, + + [git-branchless](https://github.com/arxanas/git-branchless) in Rust + (mentioned in [Git Rev News Edition #76](https://git.github.io/rev_news/2021/06/27/edition-76/), + [#90](https://git.github.io/rev_news/2022/08/31/edition-90/), + [#93](https://git.github.io/rev_news/2022/11/30/edition-93/), + [#98](https://git.github.io/rev_news/2023/04/30/edition-98/), + and [#106](https://git.github.io/rev_news/2023/12/31/edition-106/)), + + [git-branchstack](https://github.com/krobelus/git-branchstack) in Python, + + [git-chain](https://github.com/dashed/git-chain) in Rust, + + [git-machete](https://github.com/VirtusLab/git-machete) in Python + - also available as a [plugin](https://github.com/VirtusLab/git-machete-intellij-plugin) + for the IntelliJ Platform products, + + [git-ps-rs - Git Patch Stack](https://github.com/drewdeponte/git-ps-rs) in Rust, + + [git-series](https://github.com/git-series/git-series) in Rust + (first mentioned in [Git Rev News Edition #18](https://git.github.io/rev_news/2016/08/17/edition-18/), + with a link to the presentation in [#19](https://git.github.io/rev_news/2016/09/14/edition-19/)), + + [git-stack](https://github.com/gitext-rs/git-stack) in Rust, + + [graphite-desktop](https://github.com/withgraphite/graphite-desktop) + (formerly [graphite-cli](https://github.com/withgraphite/graphite-cli)) + in JavaScript/TypeScript - no longer actively developed, + + [Sapling SCM](https://github.com/facebook/sapling) Git-compatible source control system + by Facebook (mentioned in [Git Rev News Edition #93](https://git.github.io/rev_news/2022/11/30/edition-93/)), + + [spr](https://github.com/ejoffe/spr) - Stacked Pull Requests on GitHub, in Go, + + [Stacked Git (StGit)](https://stacked-git.github.io/) in Rust + (mentioned in Git Rev News Edition [#17](https://git.github.io/rev_news/2016/07/20/edition-17/), + [#21](https://git.github.io/rev_news/2016/11/16/edition-21/), + and [#74](https://git.github.io/rev_news/2021/04/30/edition-74/), + and finally presented as a tool in [#93](https://git.github.io/rev_news/2022/11/30/edition-93/)). ++ [degit](https://github.com/Rich-Harris/degit) is a CLI tool + that makes copies of Git repositories faster than ordinary `git clone`. + Supports GitHub, GitLab, Bitbucket, and Sourcehut (sr\.ht). + Written in JavaScript for Node.js, under MIT license. ++ [GitVersion](https://gitversion.net/) is a tool that generates + a [Semantic Version](https://semver.org/) number based on your Git history. + Available as Continuous Server pipeline, CLI tool, MSBuild task, and software library. + Written in C#, under MIT license. Works on Windows, Linux, and Mac. ++ [ugit: DIY Git in Python](https://www.leshenko.net/p/ugit/) is a tutorial on Git internals, + where you learn about how Git works on the inside by trying to implement + (micro) Git in Python. + + +## Releases + ++ Git [2.47.0-rc0](https://public-inbox.org/git/xmqqv7yijq33.fsf@gitster.g/), +[2.46.2](https://public-inbox.org/git/xmqqa5fyytg0.fsf@gitster.g/), +[2.46.1](https://public-inbox.org/git/xmqqikuytbxd.fsf@gitster.g/) ++ Git for Windows [2.47.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.47.0-rc0.windows.1), +[2.46.2(1)](https://github.com/git-for-windows/git/releases/tag/v2.46.2.windows.1), +[2.46.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.46.1.windows.1) ++ GitHub Enterprise [3.14.1](https://help.github.com/enterprise-server@3.14/admin/release-notes#3.14.1), +[3.13.4](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.4), +[3.12.9](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.9), +[3.11.15](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.15), +[3.10.17](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.17) ++ GitLab [16.10.10, 16.9.11, 16.8.10, 16.7.10, 16.6.10, 16.5.10, 16.4.7, 16.3.9, 16.2.11, 16.1.8, 16.0.10](https://about.gitlab.com/releases/2024/09/25/patch-release-gitlab-16-10-10-released/), +[17.4.1, 17.3.4, 17.2.8](https://about.gitlab.com/releases/2024/09/25/patch-release-gitlab-17-4-1-released/), +[17.4](https://about.gitlab.com/releases/2024/09/19/gitlab-17-4-released/), +[17.3.3, 17.2.7, 17.1.8, 17.0.8, 16.11.10](https://about.gitlab.com/releases/2024/09/17/patch-release-gitlab-17-3-3-released/), +[16.11.9](https://about.gitlab.com/releases/2024/09/11/gitlab-16-11-9-released/), +[17.0.7](https://about.gitlab.com/releases/2024/09/11/gitlab-17-0-7-released/), +[17.3.2, 17.2.5, 17.1.7](https://about.gitlab.com/releases/2024/09/11/patch-release-gitlab-17-3-2-released/) ++ GitKraken [10.3.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.5](https://desktop.github.com/release-notes/), +[3.4.4](https://desktop.github.com/release-notes/) ++ Garden [1.8.0](https://github.com/garden-rs/garden/releases/tag/v1.8.0) ++ Git Cola [4.8.2](https://github.com/git-cola/git-cola/releases/tag/v4.8.2) ++ GitButler [0.12.26](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.12.26), +[0.12.25](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.12.25) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Jialuo She, Josh Steadmon and Štěpán Němec. diff --git a/_posts/2024-10-31-edition-116.markdown b/_posts/2024-10-31-edition-116.markdown new file mode 100644 index 0000000000..b681baabaa --- /dev/null +++ b/_posts/2024-10-31-edition-116.markdown @@ -0,0 +1,406 @@ +--- +title: Git Rev News Edition 116 (October 31st, 2024) +layout: default +date: 2024-10-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 116 (October 31st, 2024) + +Welcome to the 116th 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 2024. + +## Discussions + + + + + +### Support + +* [fatal from `submodule status --recursive` when used with `grep -q`](https://lore.kernel.org/git/CAKDm0rNaHbzoiPg=DeuCoxzooNAsxw2BJfc0wg7fC_-=o9uJ7w@mail.gmail.com/) + + Matt Liberty reported that when he tried using + `git submodule status --recursive | grep -q "^+"` on a repo with + a submodule, he got an error message like "fatal: failed to recurse + into submodule XXX", where XXX is the name of the submodule. + + He expected no error message, no output and a 0 exit code from the + whole command line as it should have succeeded. He guessed that Git + didn't like that `grep` when used with `-q` exits immediately + (without printing anything) when there is a match. + + Phillip Wood replied to Matt saying he assumed that `grep`'s exit + broke the pipe between `git` and `grep`, so `git` received a + `SIGPIPE` signal which killed it. Phillip suggested consuming the + whole output from Git if the exit code from it was wanted. + + Matt replied to Phillip that he was interested in the exit code from + `grep`, not from `git`, and that Git shouldn't output any error when + its output is connected to a pipe that gets broken, in the same way + as the `yes` command, for example, doesn't output any error when + piped to `grep -q y`. + + Junio Hamano, the Git maintainer, also replied to Phillip's first + message that the error Git emitted in such a case wasn't useful to + the user. + + Matt replied to Junio that he thought no error at all should be + emitted as most Unix tools don't output any error. + + Then Phillip replied to Matt's first reply to him. He asked if all + Matt wanted was that `git submodule status` did not print any error + message when it receives a `SIGPIPE` signal. Matt replied that he + wanted both no error message and a 0 exit code from it. + + Junio replied to Matt that it was reasonable to ask for no error + message, but it should be OK if the exit code was related to the + `SIGPIPE` message that the Git command received and that killed + it. Junio used the example that even `yes` exited with code 130 when + killed using the Control-C keys on a terminal. + + The exit code associated with a signal is '128 + the signal number', + for example as the Control-C keys send a `SIGINT` signal, whose signal + number is 2, processes killed this way should exit with code '128 + 2', + so 130. + + Eric Sunshine replied to Junio that it wasn't clear how the exit + code from Git was important in the discussion as in the original + command line, Git appears before the pipe, so its exit code might be + lost. + + Matt replied to Eric that the exit code mattered if the `pipefail` + shell option was used. + + Phillip replied to Matt suggesting he remap the exit code + associated with `SIGPIPE`, which is 141 (128 + 13), to 0, if he was + using `pipefail` but still wanted a 0 exit code. Phillip also gave + an example shell function to help with that remapping, and sent + [a first version of a patch](https://lore.kernel.org/git/pull.1799.git.1726837642511.gitgitgadget@gmail.com/) + to fix the error message. + + Junio reviewed that patch and found that it was unnecessarily + including the "signal.h" system header. + + Phillip fixed that issue in + [version 2 of the patch](https://lore.kernel.org/git/pull.1799.v2.git.1726925150113.gitgitgadget@gmail.com/) + which was merged and part of Git v2.47.0. + + +## Developer Spotlight: Chandra Pratap + +_Editor's note: Just like in our previous edition, we return with another + GSoC retrospective interview in this issue. We hope the reflections shared + by GSoC students 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? + + Hey! I am Chandra Pratap (prefer going by Chand) and I am an + undergraduate student of Mathematics at SVNIT, Surat, India. I have + a passion for everything computing and like to solve leetcode-styled + problems in my free time or contribute to open-source software. + +* How did you initially become interested in contributing to Git, and + what motivated you to choose it as your GSoC project? + + C was the first programming language that I learnt, and I wanted to + try working on a non-trivial software project. I watched a YouTube + video on open source and that’s where I got the idea of looking for + open-source projects to contribute to. Git and VLC were the only + open-source C-written software that I was familiar with and used in + day-to-day life, so I decided to start contributing to Git out of the two. + By the time GSoC came around, Git was the only open-source + community that I was familiar with, so I decided to choose it as my + GSoC organization. + +* How do you feel your contribution has impacted the Git community + or the broader open-source ecosystem? + + [My project](https://summerofcode.withgoogle.com/programs/2024/projects/tlh611d7) + was about moving and improving reftable tests, so I think + my contributions made life somewhat easier for other Git hackers, + especially those who frequent the reftable sub-project. My project + didn’t really affect any user-facing aspect of Git, so I don’t think it had + a huge impact on the broader open-source ecosystem, besides the + fact that it gained another lifelong contributor. + +* Is there any aspect of Git that you now see differently after having + contributed to it? + + Everything, to be honest. Working on and with Git for the duration of + my project completely changed my mental model for the tool. Before + GSoC, Git was a clunky tool reserved for software development work + but post-Git, I know the most frequent commands like the back of my + hand, and I’ve already used Git to version control many of my non-software + files. I feel like I’ve learnt enough Git to last my entire career. + +* How do you balance your contributions with other responsibilities like + work or school? + + I had summer vacation for the entire duration of GSoC and no other work + commitments, so I had no problems finding time for my GSoC project. + +* Can you share how GSoC helped enhance your technical and non-technical + skills (like communication, project management, etc.)? + + In terms of technical skills, I think my C and Git skills saw the biggest jump. + I am a lot more comfortable working with those two tools than when I + was pre-GSoC. Besides that, I’m a lot less scared of the command line + now. In terms of non-technical skills, I believe I’ve gotten a lot better at + composing mails and communicating with other professionals. I’ve learnt + to write with the right amount of professionalism, so I don’t appear too + uptight or too lax, the right way to respond to constructive feedback, how + to time my schedule to fit with others’, especially those living in other + parts of the globe, and how to ask good questions. + +* What was your biggest takeaway or learning from GSoC that you now + apply regularly in your work? + + I’d say the biggest takeaway from GSoC for me was that it is normal for + everyone to face difficulties when trying to learn a new codebase, tool, etc, + or even a different part of the same codebase. It is important to persevere + and not be afraid of asking questions to achieve the desired results. Other + than that, I’ve learnt a lot about good practices in software development, + like appropriately splitting commits and writing good commit messages, + that I subconsciously incorporate in my work now. + +* What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it? + + The biggest challenge in contributing to Git was the initial phase of + getting involved. I remember starting out working on a small patch for + about 2 months with a lot of help from other contributors before it got + accepted into Git’s upstream. After a few initial contributions, I grew more + confident and could steadily find things to work on and produce + acceptable results. The key to overcoming this challenge was to be + persistent and patient, and not being afraid of asking silly questions. + +* Have you thought about mentoring new GSoC students? + + I’m not sure about being a full-on mentor, but I’d love to co-mentor + any future GSoC student(s) interested in working on the reftable + project. + +* 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? + + The [Git GUI](https://git-scm.com/docs/git-gui) tool. I believe that + would make Git far more accessible than it currently is and get it + incorporated in a lot more people’s day-to-day works. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + The packed-refs format for refs seems redundant to me now that + reftable is a core part of Git. + +* What is your favourite Git-related tool/library, outside of Git itself? + + [GitGitGadget](https://gitgitgadget.github.io/) was a lifesaver when + I had just started contributing to Git, so that is probably my favourite + Git related tool. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + I used Git’s `send-email` to send patches to the mailing list (especially + the `--compose` and `--annotate` flags) and Gmail’s online client to + convey non-patch mails. For developing Git, I used Vim as the editor + on an Ubuntu machine and Git as the version control software (duh). + +* How do you envision your own involvement with Git or other + open-source projects in the future? + + I plan on making small contributions to Git from time to time, since I + cannot find enough time for larger patches. Other than that, I’ll try to + volunteer as a Git mentor for future GSoC or Outreachy cohorts. + Regarding other open-source projects, I’ll try contributing to them when + I learn a new technology and want a real-world experience. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + Go through Git’s [‘My First Contribution tutorial’](https://git-scm.com/docs/MyFirstContribution) + for the initial setup and to get an idea of what’s it like + to work on Git. Then work on a few ‘microprojects’ ([more information on + the Git Developer's website](https://git.github.io/General-Microproject-Information/)) + to dip your toes in the Git Development community. From there, you + can figure out interesting stuff to work on by yourself. + +* Would you recommend other students or contributors to participate in + the GSoC, or other mentoring programs, working on Git? Why? Do you + have advice for them? + + Yes. I believe that Git is a tool that every working professional can find + useful regardless of whether they work in the software industry or not, + and working on Git through an open-source program is an excellent way + to get good at it in a short period of time. There’s also the added benefit + of joining a large and active community of amazingly experienced + developers who can teach you a lot about writing software, and the + software development workflow in general. + + I think the key to getting selected as a participant in GSoC or other + mentoring programs is getting involved as early as possible. The more + time you allow yourself to get familiar with Git’s codebase and + development workflow, the easier it becomes to find an apt project and + write a reasonable proposal for it. Also, the initial phase of contributions is + the most difficult part of getting involved with an open-source project, so it + is better to allow yourself ample time to tackle that initial hurdle. + + +## Other News + +__Various__ ++ [Highlights from Git 2.47](https://github.blog/open-source/git/highlights-from-git-2-47/) + by Taylor Blau on GitHub Blog. Includes features like incremental multi-pack indexes, + `%(is-base:)` atom for `git for-each-ref` (see also the [Brooke Kuhlmann article](https://alchemists.io/articles/git_for_each_ref), mentioned below), + the new “[Platform Support Policy](https://github.com/git/git/blob/v2.47.0/Documentation/technical/platform-support.txt)” document, + `git mergetool` directly supporting Visual Studio Code merge tool, and others. ++ [What's new in Git 2.47.0?](https://about.gitlab.com/blog/2024/10/07/whats-new-in-git-2-47-0/) + by Justin Tobler on GitLab Blog. Highlights include + `init.defaultRefFormat` configuration option that can be set to use `reftable` backend + (see [Beginner's guide to the Git reftable format](https://about.gitlab.com/blog/2024/05/30/a-beginners-guide-to-the-git-reftable-format/)), + `init.defaultObjectFormat` configuration option that can be set to `sha256`, + `git refs verify`, and others. ++ Tower is running a [Git GUIs User's Survey](https://gittower.typeform.com/git-survey) + for people who do not 100% of the time use Git in the terminal. + + +__Light reading__ ++ [How Typefully Uses Tower [Git GUI Client] to Conquer Social Media Publishing](https://www.git-tower.com/blog/how-typefully-uses-tower) + by Bruno Brito on Tower Blog. ++ [Moving all our Python code to a monorepo: pytendi](https://attendi.nl/moving-all-our-python-code-to-a-monorepo-pytendi/). ++ [Bruno — An API Client Using Git to Fight for Developer Experience](https://www.git-tower.com/blog/bruno-api-client-using-git/) + by Ryan Reynolds on Tower Blog. ++ [Using Git as Your Personal To-Do List](https://dev.to/munemprionto/using-git-as-your-personal-to-do-list-3kkd) + by Munem Prionto on DEV\.to - more as a way of learning Git by the way of managing + a TODO list, rather than for practical reasons. + + Contrast with [Using Git to Manage Todos](https://jezenthomas.com/2015/10/using-git-to-manage-todos/) + by Jezen Thomas (2015), mentioned in [Git Rev News Edition #9](https://git.github.io/rev_news/2015/11/11/edition-9/), + which is about using Git to help manage TODO or FIXME comments in the codebase + (assuming that for example your IDE does not have a plugin for managing TODOs). + + One can also consider using a CLI tool that stores data in plain text files + for managing TODOs, like [Taskwarrior](https://taskwarrior.org/). Plain text + files work well with Git. ++ [Git For Each Ref](https://alchemists.io/articles/git_for_each_ref) + by Brooke Kuhlmann in Alchemists Collective articles. + Learn how to use this command to make use of references + for information dumping, statistics, and much more. + Included in this article is use of the new `is-base` field name recently added in + [Git 2.47.0](https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.47.0.adoc). ++ [Searching for and navigating Git commits](https://alexharri.com/blog/searching-and-navigating-git-commits) + by Alex Harri on his blog. ++ [Why some of us like "interdiff" code review](https://gist.github.com/thoughtpolice/9c45287550a56b2047c6311fbadebed2) + by Austin Seipp (a Gist). Describes problems with the UI of multi-commit GitHub Pull Requests + for responding to reviewer comments by providing a new version of the patch series, + and how `git range-diff` and interactive rebase can help with this task. ++ [How I Review GitHub PRs](https://www.bitquabit.com/post/how-i-do-github-prs/) + by Benjamin Pollack on bitquabit. + + ++ [Python PGP proposal poses packaging puzzles](https://lwn.net/Articles/993787/) + by Joe Brockmeier on LWN\.net - [Sigstore](https://docs.sigstore.dev/) vs [OpenPGP](https://www.openpgp.org/). + Sigstore was mentioned in [Git Rev News Edition #91](https://git.github.io/rev_news/2022/09/30/edition-91/) + and [#111](https://git.github.io/rev_news/2024/05/31/edition-111/). ++ [A look at the aerc mail client](https://lwn.net/Articles/993498/) + by Joe Brockmeier on LWN\.net. + + + +__Scientific papers__ ++ Tsukasa Yagi, Shinpei Hayashi: _"Toward Interactive Optimization of Source Code Differences: + An Empirical Study of Its Performance"_, + [arXiv:2409.13590]((https://arxiv.org/abs/2409.13590)), + with dataset at (but no source code). + + It is based on a prior study: + Nugroho, et al.: _"How different are different diff algorithms in Git?: + Use --histogram for code changes"_ (2019), + + +__Git tools and sites__ ++ [Reviewing git contributions via email](https://git-am.io/) () + is a companion piece to [interactive guide on sending patches with git send-email](https://git-send-email.io/) + (); the latter was mentioned in + [Git Rev News Edition #50](https://git.github.io/rev_news/2019/04/26/edition-50/) + [#68](https://git.github.io/rev_news/2020/10/30/edition-68/), and + [#92](https://git.github.io/rev_news/2022/10/26/edition-92/). ++ ["Data Management" section of Awesome MLOps](https://github.com/kelvins/awesome-mlops#data-management) + also includes tools related to versioning data like + + [Dolt](https://github.com/dolthub/dolt) ([Git Rev News #62](https://git.github.io/rev_news/2020/04/23/edition-62/)), + + [DVC](https://dvc.org/) (first mentioned in [Git Rev News #42](https://git.github.io/rev_news/2018/08/22/edition-42/), + then in [#63](https://git.github.io/rev_news/2020/05/28/edition-63/), + [#64](https://git.github.io/rev_news/2020/06/25/edition-64/), + [#100](https://git.github.io/rev_news/2023/06/30/edition-100/), + [#107](https://git.github.io/rev_news/2024/01/31/edition-107/), and + [#113](https://git.github.io/rev_news/2024/07/31/edition-113/), + among others), + + [Dud](https://kevin-hanselman.github.io/dud/), improving on DVC, but with narrowed scope, + + [Intake](https://intake.readthedocs.io/) ([Git Rev News #96](https://git.github.io/rev_news/2023/02/28/edition-96/)), + + See also the discussion in issue #337 in the Intake repository: + [Data versioning/validation: Comparing Intake with DVC, Quilt and Great Expectations](https://github.com/intake/intake/issues/337) + + [lakeFS](https://lakefs.io/) ([Git Rev News #78](https://git.github.io/rev_news/2021/08/31/edition-78/)), + + [Quilt](https://www.quiltdata.com/) / [Quilt Data](https://www.quiltdata.com/) + ([Git Rev News #99](https://git.github.io/rev_news/2023/05/31/edition-99/)). ++ [git-task](https://github.com/jhspetersson/git-task) is + a local-first task manager/bug tracker that stores everything within your git repository, + and which can sync issues to/from GitHub or GitLab. + Written in Rust, under MIT license. ++ [Bruno](https://www.usebruno.com/) is a fast and Git-friendly open-source API client, + similar to Postman, Insomnia and similar tools. It stores collections directly + in a folder on your filesystem in a plain text markup language, Bru. + + Compare with [Simple Web Application Test (SWAT)](https://github.com/melezhik/swat), + web application oriented testing framework, with test plan stored as plain text files + in specially named directories. + +## Releases + ++ Git [2.47.0](https://public-inbox.org/git/xmqqa5fg9bsz.fsf@gitster.g/), +[2.47.0-rc1](https://public-inbox.org/git/xmqqploiphj3.fsf@gitster.g/) ++ Git for Windows [2.47.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.47.0.windows.2), +[2.47.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.47.0.windows.1), +[2.47.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.47.0-rc1.windows.1) ++ libgit2 [1.8.4](https://github.com/libgit2/libgit2/releases/tag/v1.8.4), +[1.8.3](https://github.com/libgit2/libgit2/releases/tag/v1.8.3) ++ GitLab [17.5.1, 17.4.3, 17.3.6](https://about.gitlab.com/releases/2024/10/23/patch-release-gitlab-17-5-1-released/), +[17.5](https://about.gitlab.com/releases/2024/10/17/gitlab-17-5-released/), +[17.4.2, 17.3.5, 17.2.9](https://about.gitlab.com/releases/2024/10/09/patch-release-gitlab-17-4-2-released/) ++ Gerrit Code Review [3.10.2](https://www.gerritcodereview.com/3.10.html#3102), +[3.8.9](https://www.gerritcodereview.com/3.8.html#389), +[3.9.7](https://www.gerritcodereview.com/3.9.html#397) ++ GitHub Enterprise [3.14.2](https://help.github.com/enterprise-server@3.14/admin/release-notes#3.14.2), +[3.13.5](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.5), +[3.12.10](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.10), +[3.11.16](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.16) ++ GitKraken [10.4.1](https://help.gitkraken.com/gitkraken-client/current/), +[10.4.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.8](https://desktop.github.com/release-notes/), +[3.4.7](https://desktop.github.com/release-notes/), +[3.4.6](https://desktop.github.com/release-notes/) ++ Garden [1.9.0](https://github.com/garden-rs/garden/releases/tag/v1.9.0), +[1.8.0](https://github.com/garden-rs/garden/releases/tag/v1.8.0) ++ git-credential-oauth [0.13.3](https://github.com/hickford/git-credential-oauth/releases/tag/v0.13.3) ++ GitButler [0.13.8](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.13.8), +[0.13.7](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.13.7), +[0.13.6](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.13.6) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Chandra Pratap, Brooke Kuhlmann, +Štěpán Němec and Brandon Pugh. diff --git a/_posts/2024-11-30-edition-117.markdown b/_posts/2024-11-30-edition-117.markdown new file mode 100644 index 0000000000..ffa294b1ba --- /dev/null +++ b/_posts/2024-11-30-edition-117.markdown @@ -0,0 +1,384 @@ +--- +title: Git Rev News Edition 117 (November 30th, 2024) +layout: default +date: 2024-11-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 117 (November 30th, 2024) + +Welcome to the 117th 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 2024. + +## Discussions + + + + + +### Support + ++ [Bug report: v2.47.0 cannot fetch version 1 pack indexes](https://lore.kernel.org/git/BA07EFA0-0793-420D-BED9-ACD7CEBE0112@townlong-yak.com/) + + Someone called 'fox' reported that when upgrading Git to v2.47.0 + from v2.46.2 or a previous version, cloning from their website, + which uses the old "dumb HTTP" protocol, stopped working. With + v2.47.0 there is an error message indicating that some index files + "differ in contents". + + Using `git bisect`, fox found the commit that introduced the + issue. That commit implemented a check that verified that the index + file downloaded from the remote was byte-for-byte identical with the + index file generated locally from the Git objects downloaded as part + of the clone. + + That check failed because the remote had an index in the version 1 + format, while the locally generated index was in a more recent + format. And fox wondered if this was intentional. + + Eric Sunshine replied to fox that he could reproduce the problem. + + Jeff King, alias Peff, also replied to fox saying that the breakage + was not intended. He thought that it was better to rely on the + locally generated index, but that there should be no guarantee for + it to be identical to the downloaded one. + + Peff proposed a draft patch that discarded the downloaded version + before generating an index, but said it was hacky and didn't check + that the content was the same. So he suggested a better solution. + + He then proposed an improved draft patch, which implemented the + better solution he had suggested by marking the downloaded index as + temporary and then discarding it after a new one is generated. + + Taylor Blau, who was the temporary Git maintainer while Junio + Hamano, the usual maintainer, had some time off, replied to Eric and + fox in the meantime confirming it was an unintentional breakage, and + saying he was going to look at Peff's patches. + + Taylor then discussed with Peff the first draft patch and agreed + with Peff that the solution implemented in the improved draft patch + was better. + + So Taylor reviewed Peff's improved draft patch. He made some + comments but found it good, and asked Peff to add a test and to + propose it as a regular patch. + + Peff replied to Taylor's comments, proposed a draft test, and said + he was going to work on a proper patch as well as some cleanups and + refactors in the dumb HTTP code. + + Taylor found Peff's draft test "beautifully written". + + Peff then sent + [a series made of 11 patches](https://lore.kernel.org/git/20241025064148.GA2110169@coredump.intra.peff.net/) + to fix the issue, clean up the dumb HTTP code and fix a couple of + other bugs or potential bugs he found in the process. + + Taylor reviewed the patch series and discussed a few technical + details with Peff. Overall he found the series good to go and + eventually merged it. + + +## Developer Spotlight: Ghanshyam Thakkar + +* Who are you and what do you do? + + I am Ghanshyam Thakkar. I was an undergrad student in Electronics + when I started contributing to Git. I am now a Software Engineer at a + startup. I sometimes contribute to open source projects in my free time, + and explore/learn new technologies. + +* How did you initially become interested in contributing to Git, + and what motivated you to choose it as your GSoC project? + + Before GSoC, I was quite familiar with the Linux ecosystem, and it had + been my primary OS for the majority of my college years. And during + those times I felt Git was the most impactful project enabling the vastly + collaborative Linux Desktop Ecosystem. So, I felt like contributing + to Git would be a great opportunity to learn and contribute to a + project that had been so crucial to my everyday workflow. + +* How do you feel your contribution has impacted the Git community + or the broader open source ecosystem? + + Before my GSoC project, I had contributed some small patches, which + could be considered as bug fix, general code cleanup, expanding test + coverage, etc. Some of which can be observed in user-space. But my GSoC + project was about migrating Git's test suite to a purely C-based + test framework, which was not user-facing, however, was a step in the + right direction for the project as a whole. + +* Is there any aspect of Git that you now see differently after + having contributed to it? + + The mailing list workflow. Although, I was skeptical about it at first + because I had never used mailing lists before, I now see it as a very + effective way to communicate and collaborate on a project of such + massive scale. Although, I still am not a big fan of the all or nothing + nature of the mailing lists. Subscribing to mails of a specific area + would have been great. Although, I do understand that it can + probably be done with filtering using a script. + +* How do you balance your contributions with other responsibilities + like work or school? + + When I was contributing to Git as part of GSoC, I was a student and I + also had summer vacation, so it was quite easy for me to balance my + contributions with my personal life. However, now that I am quite busy with my + $DAYJOB, I don't have much bandwidth to contribute to open + source in the short term. But I am planning to start contributing again + after some time. + +* Can you share how GSoC helped enhance your technical and + non-technical skills (like communication, project management, etc.)? + + I would say it helped me improve my technical communication skills immensely. + Going back and forth with the reviewers on the list, I learned quite a + bit about how to communicate effectively. Also, this was my first time + working in a C based project, so I learned some C hacks as well! + +* What was your biggest takeaway or learning from GSoC that you now + apply regularly in your work? + + Technical communication and effective code review. Also more effective + Git usage. + +* What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it? + + More than the technical challenges solving a problem, I would say it was + more challenging finding the relevant work to do, as there is no + official issue tracker. I would search for #leftoverbits on the mailing + list and #TODOs in the codebase to find things to do. However, + most of them seemed quite out of reach in terms of difficulty. However, + I attempted them anyway and learned a lot in the process. The mailing + list folks were quite helpful in guiding me in the right direction. + +* Have you thought about mentoring new GSoC students? + + Yes, although I don't have the bandwidth to become a primary mentor, + I would love to be a co-mentor. + +* 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? + + Honestly, I find Git to be quite mature and complete. I can't + think of anything, off the top of my head, that I would like + people to work on for a full year. + +* What upcoming features or changes in Git are you particularly + excited about? + + Rust adoption. + +* What is your favorite Git-related tool/library, outside of Git + itself? + + I quite frequently find myself using [`lazygit`](https://github.com/jesseduffield/lazygit) + on the command line for some quick and dirty Git operations. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + I use [aerc](https://aerc-mail.org/) and `send-email`/`format-patch` + for email interactions. And for development, I use [Neovim](https://neovim.io/) + and [clangd LSP](https://gist.github.com/Strus/042a92a00070a943053006bf46912ae9) + with the `GENERATE_COMPILATION_DATABASE` build flag. + +* How do you envision your own involvement with Git or other open + source projects in the future? + + I think I will continue to be a part of the open source community in some + way or the other. My perspective towards open source has always been + very positive and I would like to continue contributing to it. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + I would suggest to start from reading the docs, particularly + [MyFirstContribution](https://git-scm.com/docs/MyFirstContribution) + and [SubmittingPatches](https://git-scm.com/docs/SubmittingPatches). + And then start with some [#leftoverbits](https://lore.kernel.org/git/?q=%23leftoverbits) + or if you are particularly interested in a specific area, you can + even reach out to people working on those areas to ask for guidance. + +* Would you recommend other students or contributors to participate in + the GSoC, or other mentoring programs, working on Git? Why? Do you + have advice for them? + + Absolutely! GSoC is a great opportunity to learn and contribute to open + source projects. It is a great way to learn how a project of such + massive scale is managed and developed. + + +## Other News + +__Light reading__ + ++ [The Bus Factor](https://mclare.blog/posts/the-bus-factor/) + by Maryanne Wachter (also known as <mclare> or m-clare) on her blog + (with visualizations built with Observable), and + [The github plugin my coworkers asked me not to write.](https://scannedinavian.com/the-github-plugin-my-coworkers-asked-me-not-to-write.html) + by Shae Erisson on Shae Erisson's Blog. + + The _bus factor_ is a measurement of the risk resulting from information and capabilities + not being shared among team members, derived from the phrase "in case they get hit by a bus". + It is also known as the bus problem, truck factor, bus/truck number or circus factor. + The "bus factor" is the minimum number of team members that have to suddenly disappear + from a project before the project stalls due to lack of knowledgeable or competent personnel. + (From [Wikipedia](https://en.wikipedia.org/wiki/Bus_factor)). + + Based on the ["A Novel Approach for Estimating Truck Factors"](https://arxiv.org/abs/1604.06766) + paper from 2016 by Guilherme Avelino, Leonardo Passos, Andre Hora, and Marco Tulio Valente, + with many citations since. + Original implementation available at . ++ [How we shrunk our Javascript monorepo git size by 94%](https://www.jonathancreamer.com/how-we-shrunk-our-git-repo-size-by-94-percent/) + Mentions using the [git-sizer](https://github.com/github/git-sizer) tool + which was mentioned in passing in [Git Rev News Edition #37](https://git.github.io/rev_news/2018/03/21/edition-37/). + The work described in the article also led to adding the `--path-walk` option to `git repack` + and the `pack.usePathWalk` config option to Git, + and to the new experimental [`git survey`](https://github.com/microsoft/git/pull/667) command + (that for now is present in Microsoft's fork of Git), ++ [Deleted your fork. Is it gone? Not really…](https://ygreky.com/2024/07/deleted-your-fork-is-it-gone-not-really/) + by Marta Rybczynska on Ygreky Blog. Provides some recommendations for best practices + when using public forges. + + References [Anyone can Access Deleted and Private Repository Data on GitHub](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github) + blog post by Truffle Security, mentioned in [Git Rev News Edition #113](https://git.github.io/rev_news/2024/07/31/edition-113/). + + See also [Demystifying GitHub Private Forks - The Hidden Danger of Cached View](https://blog.gitguardian.com/demystifying-github-cached-views-the-hidden-danger/) + by Guillaume Valadon on GitGuardian Blog. ++ [How I configure my Git identities](https://www.benji.dog/articles/git-config/) + with the help of `git config` features: `includeIf` with `gitdir:` and `hasconfig:`, + complex `~/.ssh/config` setups (and the use of `insteadOf`, where needed). + Written by Benji Encalada Mora on their blog + (with a comment of "This may be overkill, but it works on my machine"). ++ [When to rewrite Git history?](https://drewdeponte.com/blog/when-to-rewrite-git-history/) + (beside "Don't rewrite history once it is shared."). Written by Drew De Ponte on his blog. ++ [[The Ultimate Guide to] Git Commit Creation](https://drewdeponte.com/blog/git-commit-creation/) + by Drew De Ponte on his blog. ++ [How to Use Git Stash to Efficiently Manage Your Code](https://www.freecodecamp.org/news/how-to-use-git-stash-to-manage-code) + by Okoro Emmanuel Nzube on freeCodeCamp. ++ [Finding when a bug was fixed with git bisect](https://jvns.ca/til/finding-when-a-bug-was-fixed-with-git-bisect/) + in Julia Evans [TILs](https://jvns.ca/til/) (Today I Learned). + + Julia Evans has written a series of articles on Git, which were referenced in + Git Rev News from [Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/) + to [#111](https://git.github.io/rev_news/2024/05/31/edition-111/). + + She has also published two [zines](https://wizardzines.com/) about Git: + _[Oh shit, git!](https://wizardzines.com/zines/oh-shit-git/)_ and + _[How Git Works](https://wizardzines.com/zines/git/)_ ++ [Quick tip: Ignore commits in Git blame using a file](https://marijkeluttekes.dev/blog/articles/2024/11/17/quick-tip-ignore-commits-in-git-blame-using-a-file/) + (recommended name is `.git-blame-ignore-revs`) + by Marijke Luttekes on her blog. ++ [4 reasons you should use Git for productivity, even if you aren't a developer](https://www.xda-developers.com/reasons-should-use-git-productivity/) + by Adam Conway on XDA Developers blog. + + + ++ [Doomed Keys and Hidden Threats: The Scariest Secrets in Your Repositories](https://blog.gitguardian.com/scary-secrets-2024/) + by Gaetan Ferry and + [The Extent of Hardcoded Secrets: From Development to Production](https://blog.gitguardian.com/the-extent-of-hardcoded-secrets-from-development-to-production/) + by Guillaume Valadon on GitGuardian Blog. + + + + +__Git tools and sites__ + ++ [GitFourchette](https://gitfourchette.org/) - The comfortable Git UI for Linux. + Under development; you can currently install it [with AppImage or from source](https://github.com/jorio/gitfourchette/releases). + Written in Python, using the Qt UI (via PyQt6/PySide6) and pygit2. Under GPLv3 license. ++ [Changesets](https://github.com/changesets/changesets) is a tool + to manage versioning and changelogs with a focus on multi-package repositories (monorepos). + Written in TypeScript, under MIT license. + + For an explanation of the "monorepo" concept see + [What is a Monorepo?](https://monorepo.tools/#what-is-a-monorepo) + on monorepo.tools (this site was mentioned first in + [Git Rev News Edition #84](https://git.github.io/rev_news/2022/02/28/edition-84/)). ++ [Beachball](https://microsoft.github.io/beachball/): The Sunniest Semantic Version Bumper. + Tool for automating npm publishing. + Written in TypeScript, under MIT license. ++ [git-sizer](https://github.com/github/git-sizer) is a tool that computes various size metrics + for a Git repository, flagging those that might cause problems. + Written in Go, under MIT license. + + This tool was mentioned in passing in + [Git Rev News Edition #37](https://git.github.io/rev_news/2018/03/21/edition-37/). ++ [git-remote-s3](https://github.com/awslabs/git-remote-s3) is a library + that enables you to use Amazon S3 as a git remote and as an LFS server.
+ It provides an implementation of a [git remote-helper](https://github.com/awslabs/git-remote-s3) + to use S3 (Amazon Simple Storage Service) as a serverless Git server, and + of the [git-lfs custom transfer](https://github.com/git-lfs/git-lfs/blob/main/docs/custom-transfers.md) + to enable pushing LFS managed files to the same S3 bucket used as remote. + Written in Python, under Apache 2.0 license. ++ [PatchScope](https://github.com/ncusi/PatchScope) is a tool that + annotates files and lines of diffs (patches) with their purpose and type, + and performs statistical analysis on diffs and on the generated annotation data. + It also includes a web app, displaying various data visualizations. + Written in Python, under MIT license. + + Its README includes a [list of similar tools and sites](https://github.com/ncusi/PatchScope/blob/main/README.md#related-projects), + many of which were mentioned here on Git Rev News. ++ [Mergiraf](https://mergiraf.org/) is a syntax-aware [git merge driver](https://git-scm.com/docs/gitattributes#_performing_a_three_way_merge) + (and a `mergiraf` command line tool that helps solving merge conflicts) + for a growing collection of programming languages and file formats. + Adding a new language to Mergiraf is done in a declarative way. + Written in Rust, under GPLv3 license. + + The author recommends using Mergiraf 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/). ++ [Diffdiff.net](https://diffdiff.net/) (formerly diff.so) is a web application + that provides a fast, [private](https://diffdiff.net/privacy) way to compare two pieces of text + in a "split diff"/"side diff" view, side by side with highlighting the text that is different + from the text on the other side. + + + ++ [DiffLens](https://www.difflens.com/) - The Developer's Diff Tool. + Provides language-aware semantic diffs for GitHub Pull Requests, + adding them as a comment to the pull request. + Available as a [GitHub app](https://github.com/marketplace/difflens) + or a [VS Code Extension](https://marketplace.visualstudio.com/items?itemName=DiffLens.difflens). + Proprietary tool, with 14 days free trial and [demo](https://www.difflensapp.com/difflensDemo2_849ca26f9ee09faa084cbdcdc90b6f90f8ce8495). + See above for possible alternatives. + + +## Releases + ++ Git [2.47.1](https://public-inbox.org/git/xmqq5xob6coo.fsf@gitster.g/) ++ Git for Windows [2.47.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.47.1.windows.1) ++ libgit2 [1.8.4](https://github.com/libgit2/libgit2/releases/tag/v1.8.4) ++ Gerrit Code Review [3.10.3](https://www.gerritcodereview.com/3.10.html#3103), +[3.8.10](https://www.gerritcodereview.com/3.8.html#3810), +[3.9.8](https://www.gerritcodereview.com/3.9.html#398) ++ GitHub Enterprise [3.15.0](https://help.github.com/enterprise-server@3.15/admin/release-notes#3.15.0) ++ GitLab [17.6.1](https://about.gitlab.com/releases/2024/11/26/patch-release-gitlab-17-6-1-released/), +[17.6](https://about.gitlab.com/releases/2024/11/21/gitlab-17-6-released/), +[17.5.2](https://about.gitlab.com/releases/2024/11/13/patch-release-gitlab-17-5-2-released/) ++ GitKraken [10.5.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.9](https://desktop.github.com/release-notes/) ++ Sourcetree [4.2.10](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.10.html), +[4.2.9](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.9.html) ++ Garden [1.9.1](https://github.com/garden-rs/garden/releases/tag/v1.9.1) ++ Git Cola [4.9.0](https://github.com/git-cola/git-cola/releases/tag/v4.9.0) ++ git-credential-oauth [0.13.4](https://github.com/hickford/git-credential-oauth/releases/tag/v0.13.4) ++ GitButler [0.14.0](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.0), +[0.13.17](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.13.17) ++ Tower for Windows [8.0](https://www.git-tower.com/release-notes/windows?show_tab=release-notes), [8.1](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) ([Release blog post](https://www.git-tower.com/blog/tower-windows-8/)) ++ Tower for Mac [12.3](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Ghanshyam Thakkar, Johannes Schindelin, +Štěpán Němec, Bruno Brito and Toon Claes. diff --git a/_posts/2024-12-31-edition-118.markdown b/_posts/2024-12-31-edition-118.markdown new file mode 100644 index 0000000000..b7deb451ab --- /dev/null +++ b/_posts/2024-12-31-edition-118.markdown @@ -0,0 +1,425 @@ +--- +title: Git Rev News Edition 118 (December 31st, 2024) +layout: default +date: 2024-12-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 118 (December 31st, 2024) + +Welcome to the 118th 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 November and December 2024. + +## Discussions + +### General + +- Git participates in [Outreachy's December 2024 to March 2025 round](https://www.outreachy.org/alums/2024-12/): + + - Seyi Kuforiji is working on the "Convert unit tests to use the + [clar testing framework](https://github.com/clar-test)" project. He is mentored by Patrick + Steinhardt and Phillip Wood and posting updates [on his gitlab.io blog](https://seyi-kuforiji-902b48.gitlab.io/posts/index.html) + while his work is on [his GitHub repository](https://github.com/Seyi007/git). + + - Usman Akinyemi is working on the "Finish adding an 'os-version' + capability to Git protocol v2" project. He is mentored by + Christian Couder and posting updates [on his hashnode.dev blog](https://uniqueusman.hashnode.dev/) + while his work is on [his GitLab repository](https://gitlab.com/Unique-Usman/git/-/branches). + + Congratulations to Usman and Seyi for being selected! + + Thanks to GitHub for funding these two Outreachy internships! + + Many thanks also to the other contributors who applied and worked on + micro-projects, but couldn’t be selected! We hope to continue to see + you in the community! + + + +### Support + ++ [`./configure` fails to link test program due to missing dependencies](https://lore.kernel.org/git/GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com/) + + Last September Henrik Holst reported an issue when trying to compile + Git 2.44.0 with HTTPS/curl support on [LFS](https://www.linuxfromscratch.org/) 12.1. The `configure` script + failed to detect libcurl's dependencies properly when trying to link + statically. + + The issue occurred because the `configure` script only used the + `-lcurl` build flag without running `pkg-config --libs libcurl` to + add build flags for dependencies like `zstd` that libcurl + needs. Henrik found that manually setting the LDFLAGS environment + variable to include build flags for all dependencies (like `-lcurl + -lssl -lcrypto -lzstd -lbrotlidec -lz`) allowed the build to + succeed. This sparked a broader discussion about Git's build system + situation. + + Looking at `configure.ac`, Junio Hamano, the Git maintainer, noted + that `pkg-config` isn't used at all, instead `curl-config --libs` is + used to detect curl's flags. Even though the `configure` script was + added early in the history of the Git project, Junio said it was an + afterthought and nobody has considered "upgrading" from + `curl-config` to `pkg-config` for dependency detection. + + In fact, our own Jakub Narębski + [initially added the `configure` script](https://lore.kernel.org/git/200607030156.50455.jnareb@gmail.com/) + back in 2006 to make it much easier to create the RPM spec file for Git. + Creating `*.spec` files is especially easy when the + compilation follows traditional `configure && make && make install` + steps. + + brian m. carlson replied to Junio that users shouldn't statically + link libcurl or OpenSSL at all, as this creates security issues. + With static linking, security updates to these libraries would + require recompiling Git to take effect. In contrast, dynamic linking + allows security updates to be applied as soon as a new Git process + is spawned. + + Patrick Steinhardt replied to Junio suggesting it might be time to + reconsider Git's three build systems + ([GNU Make](https://www.gnu.org/software/make/), + [Autoconf](https://www.gnu.org/software/autoconf/), and + [CMake](https://cmake.org/)). He proposed potentially dropping + Autoconf and making CMake officially supported, or switching to + [Meson](https://mesonbuild.com/) as an alternative. + + CMake was [added more recently in 2020](https://lore.kernel.org/git/pull.614.git.1587700897.gitgitgadget@gmail.com/) + by Sibi Siddharthan as the third build system with the main goal of + improving the build experience for developers on Windows. + + Soon after Patrick's reply, the Git Contributors' Summit took place, + and the + ["Modern Build System" topic](https://lore.kernel.org/git/Zu2E3vIcTzywWOx3@nand.local/) + was discussed there. Patrick Steinhardt raised concerns about + maintaining three different build systems while others were + concerned about having good platform support and good Windows + developer experience. This led to an extensive discussion about + the merits of different build systems in the thread started by + Henrik. + + Eli Schwartz, the Meson maintainer, made a detailed case for + preferring Meson over CMake, citing various CMake pain points and + limitations. Phillip Wood agreed with Patrick about getting rid of + Autoconf, but raised the importance of Visual Studio integration, + since CMake was originally added to improve the Windows developer + experience. Johannes Schindelin, alias Dscho, emphasized that + CMake's deep Visual Studio integration was crucial for Windows + developers and cautioned against switching to alternatives that + would make the Windows experience worse. It appeared that Visual + Studio has Meson support via plugins though, which alleviated some + concerns. + + Paul Smith, the GNU Make maintainer, noted that requiring additional + build tools like Meson, which are not yet often used and require + some other dependencies, like Python3 for Meson, adds friction, + though he acknowledged that for Git specifically this may be less of + a concern given its existing dependencies. + + Junio seemed to agree that adding support for a fourth build system + would be worth it if it would allow the project to drop all other + three build systems eventually. He said the new build system would + have "to be something available widely and easy to learn". + + Patrick came up later in October with a + [21 patch long RFC series](https://lore.kernel.org/git/cover.1727881164.git.ps@pks.im/) + to add support for the Meson build system with the goal of + eventually replacing the current three build systems. + + There were a number of iterations on that series. Among the many + comments, Taylor Blau asked about the eventual goals of the series + and plans for CMake support. He noted that CMake support in contrib/ + was in an awkward position, neither fully supported nor properly + maintained out-of-tree. He was concerned about having to maintain + three build systems simultaneously during any transition period. + + David Aguilar expressed concerns about Python being a dependency + through Meson. Eli replied that [muon](https://github.com/muon-build/muon), + a C99 implementation of Meson, + could be used instead and demonstrated it working with Git's build. + + Jeff King, alias Peff, asked about reliability for bisecting and + whether out-of-source builds would work correctly when moving + between commits. He also requested better documentation of common + developer workflows with Meson compared to Make. + + Junio discussed the need to maintain build system compatibility + during any transition period. He noted that many of the Makefile + options were added over time for good reasons and dropping support + for them would need careful consideration. + + A number of other developers participated in the reviews. Ramsay + Jones tested the patches on various platforms including + Cygwin. Phillip Wood reviewed CMake-related changes and provided + technical feedback. Johannes Sixt commented on changes to the + gitk-git subtree. Eric Sunshine provided technical feedback. Your + own Christian Couder provided feedback on the documentation. + + Over the iterations, Patrick updated the series to improve + documentation, fix conflicts with in-flight patches, and address the + various technical concerns raised during review. + + Eventually + [version 11 of the patch series](https://lore.kernel.org/git/20241206-pks-meson-v11-0-525ed4792b88@pks.im/) + was merged and will be part of Git v2.48.0 that should be released + in the next few weeks. It should be a properly supported modern + build system that can be faster and more easily configurable than + the three existing ones, which will hopefully get deprecated over + time. + + The merged patch series especially adds + [some documentation](https://lore.kernel.org/git/20241206-pks-meson-v11-24-525ed4792b88@pks.im/#Z31meson.build) + (via comments in [`meson.build`](https://git.kernel.org/pub/scm/git/git.git/tree/meson.build)) + to help build Git with Meson and + [a build system comparison](https://lore.kernel.org/git/20241206-pks-meson-v11-23-525ed4792b88@pks.im/#Z31Documentation:technical:build-systems.txt) + (in [`Documentation/technical/build-systems.txt`](https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/technical/build-systems.adoc)) + that might be interesting to read. + + + + +## Other News + +__Various__ + ++ [Git 2.48-rc0 Released With git-fsck Warning Over "Curiously Formatted" Ref Contents](https://www.phoronix.com/news/Git-2.48-rc0) + by Michael Larabel on Phoronix. ++ [Git Merge 2024 Talks are Up (on YouTube)](https://blog.gitbutler.com/git-merge-2024-talks/) + by Scott Chacon on GitButler Blog. The article includes a quick summary + of each of the talks. ++ [Forgejo makes a full break from Gitea](https://lwn.net/Articles/963095/) + by Joe Brockmeier on LWN\.net (from February 23, 2024). + + [Gitea](https://about.gitea.com/), which is Go-based software forge, a fork of [Gogs](https://gogs.io/), + was first mentioned in [Git Rev News Edition #23](https://git.github.io/rev_news/2017/01/25/edition-23/);
+ [Forgejo](https://forgejo.org/), which started as a "soft" fork of Gitea, + was first mentioned in passing in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/), + and again in [Edition #114](https://git.github.io/rev_news/2024/08/31/edition-114/). ++ [EMERALDWHALE exploits vulnerable Git configuration files](https://www.developer-tech.com/news/emeraldwhale-exploits-vulnerable-git-configuration-files/) + by Ryan Daws on Developer Tech News, about a global operation known as EMERALDWHALE, + which has stolen over 15000 cloud service credentials by exploiting exposed Git configuration files + (via misconfigured web services, which were exposing the `.git` directories of private repositories). ++ [Abusing Git branch names to compromise a PyPI package](https://lwn.net/Articles/1001215/) + (caused by a project automatically processing pull requests with a flawed script), + short post by daroc on LWN\.net. + + +__Light reading__ + ++ [NonStop discussion around adding Rust to Git](https://lwn.net/Articles/998115/) + by Daroc Alden on LWN\.net. The Git project discussed the prospect in January 2024, + and then again at the Git Contributors' Summit in September 2024. + + The Git Contributors' Summit 2024 was mentioned in + [Git Rev News Edition #115](https://git.github.io/rev_news/2024/09/30/edition-115/), + with links to notes as posts to the Git mailing list (also available in read-only Google Docs) + and a repo with notes from the breakout unconference sessions. ++ [Vigilante Justice on GitHub: GitHub Graffiti](https://trufflesecurity.com/blog/vigilante-justice-on-github) + by Dylan Ayrey on The Dig (Truffle Security Co. blog), 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) - + which is [only] possible because of spammer attempts to leverage GitHub issues for phishing, + on a repo one has push access to. ++ [Facing the Git commit-ID collision catastrophe](https://lwn.net/Articles/1001526/) + (in Linux kernel repository) by Jonathan Corbet on LWN\.net, + about the concern that, given the growth of the kernel repository, soon 12 digits will not be enough; + on the other hand, commits only make up about 1/8 of the total objects in the repository, + and abbreviated hashes should be accompanied by the short-form version of the changelog + (`--format=reference`). ++ [Optimizing Your Repository for Speed and Efficiency](https://dev.to/this-is-learning/optimizing-your-repository-for-speed-and-efficiency-5co2) and + [Using Git Maintenance in GitHub Actions: Optimize Your Repositories Automatically](https://dev.to/this-is-learning/using-git-maintenance-in-github-actions-optimize-your-repositories-automatically-39ka) + posts by Emanuele Bartolesi for [This is Learning on DEV\.to](https://dev.to/this-is-learning) constitute the 2 part series + [Streamline Your Workflow with the Git Maintenance Command](https://dev.to/kasuken/series/29808). + + The [`git maintenance`](https://git-scm.com/docs/git-maintenance) command + was mentioned in [Git Tips 2: Some Subtle New Things](https://blog.gitbutler.com/git-tips-2-new-stuff-in-git/) + article on GitButler Blog by Scott Chacon, which in turn was mentioned in + [Git Rev News Edition #108](https://git.github.io/rev_news/2024/02/29/edition-108/). ++ [Demystifying git submodules](https://www.cyberdemon.org/2024/03/20/submodules.html) + by Dmitry Mazin on his blog. ++ [Fearless Rebasing](https://blog.gitbutler.com/fearless-rebasing/) by Scott Chacon on GitButler Blog + is about "first class" conflict support in GitButler, based on the Jujutsu concept of + "[first class conflicts](https://martinvonz.github.io/jj/latest/conflicts/)". + + The article does not mention the built-in (but optional) [git rerere](https://git-scm.com/docs/git-rerere) + mechanism of reusing recorded resolutions of conflicting merges + (described for example in [Git Tools - Rerere](https://git-scm.com/book/en/v2/Git-Tools-Rerere) + section in "Pro Git" 2nd Edition), that can help when rebasing repeatedly. + + In order to reduce the pain of resolving merge conflicts, + and allow a merge or a rebase to be saved, tested, interrupted, published, + and collaborated on while it is in progress, one can also use + [git-imerge](https://github.com/mhagger/git-imerge) tool + (see also [git-imerge: A Practical Introduction](https://softwareswirl.blogspot.com/2013/05/git-imerge-practical-introduction.html) article).
+ `git-imerge` was first mentioned in passing in [Git Rev News Edition #17](https://git.github.io/rev_news/2016/07/20/edition-17/), + while Edition #34 includes [Developer Spotlight: Michael Haggerty](https://git.github.io/rev_news/2017/12/20/edition-34/#developer-spotlight-michael-haggerty), + an interview with the author of this tool. + + [Jujutsu (`jj`)](https://jj-vcs.github.io/jj/), a Git-compatible version control system, + written in Rust, was first mentioned in + [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [Stacked Branches with GitButler](https://blog.gitbutler.com/stacked-branches-with-gitbutler/) + by Scott Chacon on the GitButler Blog. + With the 0.14 release, GitButler can now manage dependent branches that are stacked, + including managing stacked GitHub PRs (Pull Requests). + + 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. ++ [~~Enforcing~~ Git Branch Naming Standards: ~~Tools and~~ Tips for Developers](https://dev.to/oj_redifined/enforcing-git-branch-naming-standards-tools-and-tips-for-developers-1p27) + by Ojay on DEV\.to (despite the title, the article does not include any technical way of + helping to enforce or even remind of branch naming conventions). ++ [9 ways to manage large creative projects with version control tools](https://www.xda-developers.com/manage-large-creative-projects-with-version-control-tools/) + by Ruby Helyer on XDA Developers. Mentions CI/CD, Git LFS, commit message and file naming conventions. ++ Adam Ruka posted a series of articles on working with the Git source control system: + 1. [GitFlow considered harmful](https://www.endoflineblog.com/gitflow-considered-harmful) (2015) + 2. [Follow-up to 'GitFlow considered harmful'](https://www.endoflineblog.com/follow-up-to-gitflow-considered-harmful) (2015) + 3. [OneFlow – a Git branching model and workflow](https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow) (2017) + 4. [Implementing OneFlow on GitHub, BitBucket and GitLab](https://www.endoflineblog.com/implementing-oneflow-on-github-bitbucket-and-gitlab) (2021) + + [GitFlow: A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/) + was a blog post by Vincent Driessen from 2010, with a note of reflection from 2020; + the original author now suggests adopting a much simpler workflow (like + [GitHub flow](https://guides.github.com/introduction/flow/)) if the team is doing + continuous delivery of software, and using GitFlow only when necessary, + for explicitly versioned software - with multiple versions of it in the wild to be supported.
+ See also [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) + by Martin Fowler, mentioned in [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/). + + + + +__Git tools and sites__ + ++ [bus-factor-explorer](https://github.com/JetBrains-Research/bus-factor-explorer) + by JetBrains Research is a web app for exploring the Bus Factor of GitHub projects + by analyzing the commit history. Preferably run as a Docker image. + The repository includes evaluation results for 935 popular repositories on GitHub. + There is also a short video about the tool on YouTube: . + Written in Kotlin (with evaluation done with Jupyter notebooks), under MIT license. + + See [The Bus Factor](https://mclare.blog/posts/the-bus-factor/) and + [The github plugin my coworkers asked me not to write](https://scannedinavian.com/the-github-plugin-my-coworkers-asked-me-not-to-write.html) + articles mentioned in [Git Rev News Edition #117](https://git.github.io/rev_news/2024/11/30/edition-117/) + (the previous edition), together with accompanying links. ++ [Anonymous GitHub](https://anonymous.4open.science/) is a service + that allows you to anonymize your GitHub repository for double-blind scientific reviews + (of scientific articles where source code is to be made available for open science reasons). + Several anonymization options are available to ensure that you do not break the double anonymization, + such as removing links, images or specific terms. + The goal is to make is as easy as possible for the reviewer to explore and review the repository. ++ [Git.News](https://git.news/) is a website which provides an infinite newsfeed of + trending repositories from GitHub, HackerNews & Reddit + (which you can then filter by programming language). ++ [Octobox](https://octobox.io/) is a service to help manage GitHub notifications. + Includes an optional GitHub app to add live information on issue, PR, CI status, labels, authors, etc. + Octobox is free for open source projects and the use of basic notifications is free for private projects. ++ [Filestash](https://www.filestash.app/) is a Dropbox-like enterprise-grade file manager, + connecting your storage with your identity provider and authorisations. + It adds a web interface to storage solutions like S3 buckets, SFTP/FTPS servers, Git repositories, etc. + Self-hosted deployment is free; it can be done using a Docker image. + Written in Go and JavaScript, under AGPLv3 license. + Demo available at , + source code at . ++ [DistGit (Distribution Git)](https://github.com/release-engineering/dist-git) + is Git with additional data storage, designed to hold content of source RPMs + (Linux distribution packages). Written in Python, under MIT license, + but with scripts/httpd/upload.cgi under GPLv1, + and the dist-git-client subdirectory under GPLv2+. ++ [wikmd](https://linbreux.github.io/wikmd/) is a file-based wiki, with + documents written in Markdown, which uses Git for version control. + It is possible to connect Wikmd with an online repo. + Written in Python, under MIT license. ++ [Mycorrhiza Wiki](https://mycorrhiza.wiki/) is a free and open-source wiki engine, + with data stored as simple files, and changes [stored in Git](https://mycorrhiza.wiki/hypha/git). + It uses [Mycomarkup](https://mycorrhiza.wiki/hypha/mycomarkup), a custom-made markup language, + with support for transcluding units of contents. + Written in Go, under AGPLv3 license. ++ [Gitit](https://github.com/jgm/gitit) is a wiki engine written in Haskell, + that uses [Happstack](http://happstack.com/) (HAppS) for the web server + and [pandoc](http://pandoc.org/) for markup processing (with extended Markdown format as default). + Pages and uploaded files are stored in a Git, darcs, or Mercurial repository + and may be modified through the wiki's web interface. + Under GPLv2 license. ++ [Xandikos](https://www.xandikos.org/) is a lightweight CardDAV/CalDAV server + that keeps history and backups in a Git repository. + It allows to share calendars (events, todo items, journal entries) via CalDAV + and contacts (vCard) via CardDAV. + Written in Python using Dulwich, Jinja2, icalendar, and defusedxml, + licensed under GPLv3+. ++ [Opengist](https://github.com/thomiceli/opengist) is a self-hosted pastebin powered by Git, + similar to [GitHub Gist](https://gist.github.com/). + Demo available at . + Written in Go, under AGPLv3 license. ++ [rgit](https://github.com/w4/rgit) is a gitweb/cgit-like fast web frontend for Git repositories. + You can see it in action at . + Written in Rust using Axum, gitoxide, Askama and RocksDB. + Under WTFPL license + (which is not on the list of [OSI approved Licenses](https://opensource.org/licenses), + but is on the list of [licenses that meet Debian Free Software Guidelines](https://wiki.debian.org/DFSGLicenses#DO_WHAT_THE_FUCK_YOU_WANT_TO_PUBLIC_LICENSE)). ++ [klaus](https://github.com/jonashaag/klaus) is a simple, easy-to-set-up Git web viewer. + Supports syntax highlighting, Markdown + RestructuredText (reST) rendering support, + and code navigation using Exuberant ctags. Can be installed as Docker image or via `pip`. + You can see its demo at . + Written in Python, under an unnamed custom permissive license. ++ [git-activity](https://git-activity.olets.dev/) is a tool + to record your Git activity across multiple (or all) repos, + and read it optionally filtered by date, + activity type (e.g. commit, branch creation, etc.) regex pattern, + repo name regex pattern, branch name regex pattern, commit message regex pattern, + and/or commit SHA (first seven characters) regex pattern. + Useful for retroactively filling out a time sheet (or correcting a time sheet), + finding that time you solved a problem similar to the one you're working on now, etc. + The log is stored in a plain text file. Source code [on GitHub](https://github.com/olets/git-activity). + Written as Bash shell script using AWK, licensed under (custom) + CC BY-NC-SA 4.0 with Hippocratic License v3 ethical requirements. ++ [git-branches-script](https://github.com/conorsheppard/git-branches-script) + is a convenience script that prints a menu of recent Git branches + and allows you to switch to a new branch by selecting its corresponding number. + Written as Bash shell script, no license provided. + + +## Releases + ++ Git [2.48.0-rc1](https://public-inbox.org/git/xmqqjzbhxeho.fsf@gitster.g/), +[2.48.0-rc0](https://public-inbox.org/git/xmqqfrmn4hr9.fsf@gitster.g/) ++ Git for Windows [2.48.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.48.0-rc1.windows.1), +[2.48.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.48.0-rc0.windows.1) ++ libgit2 [1.9.0](https://github.com/libgit2/libgit2/releases/tag/v1.9.0) ++ GitHub Enterprise [3.15.1](https://help.github.com/enterprise-server@3.15/admin/release-notes#3.15.1), +[3.14.6](https://help.github.com/enterprise-server@3.14/admin/release-notes#3.14.6), +[3.13.9](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.9), +[3.12.13](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.13), +[3.11.19](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.19), +[3.15.0](https://help.github.com/enterprise-server@3.15/admin/release-notes#3.15.0), +[3.14.5](https://help.github.com/enterprise-server@3.14/admin/release-notes#3.14.5), +[3.13.8](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.8), +[3.12.12](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.12), +[3.11.18](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.18) ++ GitLab [17.7](https://about.gitlab.com/releases/2024/12/19/gitlab-17-7-released/), +[17.6.2, 17.5.4, 17.4.6](https://about.gitlab.com/releases/2024/12/11/patch-release-gitlab-17-6-2-released/) ++ Gerrit Code Review [3.11.0](https://www.gerritcodereview.com/3.11.html#3110) ++ GitKraken [10.6.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.12](https://desktop.github.com/release-notes/), +[3.4.11](https://desktop.github.com/release-notes/), +[3.4.10](https://desktop.github.com/release-notes/) ++ Garden [1.10.0](https://github.com/garden-rs/garden/releases/tag/v1.10.0) ++ Git Cola [4.10.1](https://github.com/git-cola/git-cola/releases/tag/v4.10.1), +[4.10.0](https://github.com/git-cola/git-cola/releases/tag/v4.10.0) ++ GitButler [0.14.4](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.4), +[0.14.3](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.3) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Štěpán Němec. diff --git a/_posts/2025-01-31-edition-119.markdown b/_posts/2025-01-31-edition-119.markdown new file mode 100644 index 0000000000..3e38e4eaaf --- /dev/null +++ b/_posts/2025-01-31-edition-119.markdown @@ -0,0 +1,287 @@ +--- +title: Git Rev News Edition 119 (January 31st, 2025) +layout: default +date: 2025-01-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 119 (January 31st, 2025) + +Welcome to the 119th 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 December 2024 and January 2025. + +## Discussions + + + + + + +### Support + ++ [git support for "xattrs" (extended filesystem attributes)?](https://lore.kernel.org/git/5b4c09a9-64bb-e672-e604-120563fc1ad6@das-werkstatt.com/) + + Peter B. asked on the Git mailing list if there was a way to store + [extended attributes (xattrs)](https://en.wikipedia.org/wiki/Extended_file_attributes) + in Git. His use case was professional archival collection and he + needed bit-proof preservation of all xattrs, even larger ones. + + Junio Hamano, the Git maintainer, replied that Git only tracks + "contents, pathnames where these contents are stored, and the + executable bit". + + Jeff King, alias Peff, also replied to Peter confirming that Git, + like most other version control systems, doesn't store most + metadata, but pointing to other tools, + [etckeeper](https://etckeeper.branchable.com/) and + [metastore](https://github.com/przemoc/metastore), that can help + with storing them in a separate file and restoring them on checkout. + + Junio agreed with Peff that Git is extensible that way. + + brian m. carlson replied to Peter mentioning other + possibilities. One is to use the `.gitattributes` files to store a + few xattrs with values that are "well stored as text", and then + `git ls-attr` and a `post-checkout` + [hook](https://git-scm.com/book/ms/v2/Customizing-Git-Git-Hooks) + to restore them. + + Another possibility is to use + [mtree](https://linux.die.net/man/8/mtree) utilities to store or + restore metadata from or into mtree files. brian especially pointed + to [go-mtree](https://github.com/vbatts/go-mtree) which supports + xattrs. As `mtree` is an extensible key-value format, brian uses it + to store the install location of his + [dotfiles](https://en.wikipedia.org/wiki/Hidden_file_and_hidden_directory). + + Peter replied to brian thanking everyone for the suggestions and + saying he would especially take a look at `mtree` and + `metastore`. He thanked brian again in the following message, + saying that `go-mtree` looked very promising and that he was going + to look at `post-checkout` hooks. + +## Developer Spotlight: Justin Tobler + +* Who are you and what do you do? + + My name is Justin Tobler and I am a relatively new contributor to the + Git project with my first contributions being made this last year. I + work at GitLab and these days spend my time integrating Git into + GitLab's data access layer as well as upstreaming Git fixes/features. + +* What would you name your most important contribution to Git? + + Most of my contributions thus far have been relatively minor bug fixes, + but [one bug I found](https://public-inbox.org/git/pull.1683.git.1709669025722.gitgitgadget@gmail.com/) + particularly interesting was with the table compaction algorithm in the + new reftable reference backend. There was a theoretical scenario where + certain Git operations could be performed and new tables written, but + table compaction would never occur. This was found when tests on certain + platforms started failing because of file descriptor limits being exceeded. + +* What are you doing on the Git project these days, and why? + + One topic I'm currently working on is introducing a way to + [generate batches of specific blob diffs](https://public-inbox.org/git/20241213042312.2890841-1-jltobler@gmail.com/). + This is not particularly useful for users, but for Git servers + it's a nice feature. + + I still have much to learn about the project so I also enjoy looking + into the inflight topics that pop on the mailing list. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + I don't have anything specific in mind, but it would probably be along + the lines of changes to make the Git CLI more consistent across its + various commands. + +* What is your favorite Git-related tool/library, outside of + Git itself? + + For my Git-related workflow, outside of GitLab, I primarily use the Git + CLI for everything. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + For interacting with the mailing list my workflow primarily consists of + using [`neomutt`](https://neomutt.org/guide/gettingstarted.html) + and `git send-email`, but I have also recently been + exploring [`b4`](https://github.com/mricon/b4). + + For development, I use [`neovim`](https://neovim.io) as my editor with + an assortment of plugins. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + If you are unfamiliar with the mailing workflow, [GitGitGadget](https://gitgitgadget.github.io/) + can help handle formatting patches and sending them off to the mailing + list. My first couple of patch series used this tool and I found it + useful to get started without having to be super familiar with + `git format-patch` and `git send-email`. Other than that, I also + find it very helpful to observe how other contributors submit + patches and interact on the mailing list. + +* If there's one tip you would like to share with other Git + developers, what would it be? + + I appreciate when the authors of a patch series provide as much + background as possible to the change being made. Reading incoming patch + series is a great way to learn about the project and it is very helpful + when the required context overhead is minimized. + + +## Other News + +__Various__ + +* [Highlights from Git 2.48](https://github.blog/open-source/git/highlights-from-git-2-48/) + by Taylor Blau on GitHub Blog, about + faster SHA-1 computations for checksums, adding option `--remerge-diff` to the `git range-diff` command, + memory-leak-free tests, introducing the Meson build system, and more. +* [What’s new in Git 2.48.0?](https://about.gitlab.com/blog/2025/01/10/whats-new-in-git-2-48-0/) + by Christian Couder on GitLab Blog, about + the Meson build system, Git becoming memory-leak-free, improved bundle URI checks, + adding reference consistency checks, more performant 'reftables' implementation, + support for reflogs in `git-refs migrate` (to migrate to 'reftables'), + the 'ref-filter' subsystem optimizations, and more. +* [Git security vulnerabilities announced](https://github.blog/open-source/git/git-security-vulnerabilities-announced-5/) + by Taylor Blau on GitHub Blog: + [CVE-2024-50349](https://nvd.nist.gov/vuln/detail/CVE-2024-50349) (ANSI escape sequences in hostname and prompt for interactive credentials) and + [CVE-2024-52006](https://nvd.nist.gov/vuln/detail/CVE-2024-52006) (specially-crafted repository URL and credential helpers). + * See also [Clone2Leak: Your Git Credentials Belong To Us](https://flatt.tech/research/posts/clone2leak-your-git-credentials-belong-to-us/) + by RyotaK (@ryotkak), a security engineer at GMO Flatt Security Inc. +* Adam Johnson’s book “Boost Your Git DX” + [has been updated](https://adamj.eu/tech/2025/01/28/bygdx-second-update/) + with 28 new pages of content. This book was first mentioned in + [Git Rev News Edition #104](https://git.github.io/rev_news/2023/10/31/edition-104/). + + +__Light reading__ + +* [Off-the-shelf governance models for small FOSS projects?](https://antonin.delpeuch.eu/posts/off-the-shelf-governance-models-for-small-foss-projects/) + by Antonin Delpeuch, about an idea for `GOVERNANCE.md` file template or generator, + as another recommended addition to `README.md`, `LICENSE`, and Code of Conduct. + Mergiraf's [`GOVERNANCE.md`](https://codeberg.org/mergiraf/mergiraf/src/branch/main/GOVERNANCE.md) + is his example - the goal here is to make it clear for project users + what one can do if there is an issue/bug, or if one wants to add a new feature to a project. +* [Re: DCO](https://inbox.sourceware.org/gdb/Z5esfoH+wMxmDyRP@ebb.org/) + by Bradley M. Kuhn of Software Freedom Conservancy on GDB Development mailing list (via GDB public-inbox instance), + about the considerations when adopting the Developer Certificate of Origin for a project (similarly to the Linux kernel and Git). +* [The many names of commit 55039832f98c](https://lwn.net/Articles/1005222/) + by Jonathan Corbet on LWN\.net, about difficulties finding the commit in mainline kernel repository + that corresponds to the specific commit/patch sent to the stable-update mailing list, + in the presence of DRM community's wide use of cherry-picking + (without something like "change ID" that is used by Gerrit). +* [The slow death of TuxFamily](https://lwn.net/Articles/1004988/), a French free-software-hosting service, + by Joe Brockmeier on LWN\.net. +* [A Retrospective on the Source Code Control System](https://www.mrochkind.com/mrochkind/docs/SCCSretro2.pdf) + by Marc J. Rochkind (PDF). +* [Considerations for making a tree view component (in a web Git UI) accessible](https://github.blog/engineering/user-experience/considerations-for-making-a-tree-view-component-accessible/) + by Eric Bailey on GitHub Blog. +* [Commit subject case in Git history](https://benknoble.github.io/blog/2025/01/04/git-subject-case/) + analysis by D. Ben Knoble, as a blog post on his Junk Drawer site. +* [Colliding with the SHA prefix of Linux's initial Git commit](https://people.kernel.org/kees/colliding-with-the-sha-prefix-of-linuxs-initial-git-commit) + Or, how to break all the tools that parse the “Fixes:” tag, + by Kees Cook on people\.kernel\.org. Note that the 12-character prefix collision + was generated with the help of the [lucky-commit](https://github.com/not-an-aardvark/lucky-commit) project; + this tool was mentioned in [Git Rev News Edition #109](https://git.github.io/rev_news/2024/03/31/edition-109/). + * See also [Facing the Git commit-ID collision catastrophe](https://lwn.net/Articles/1001526/) + by Jonathan Corbet on LWN\.net, mentioned in [the previous edition](https://git.github.io/rev_news/2024/12/31/edition-118/). +* [How to set up your ~~own Git server~~ Gitea instance at home for your personal projects](https://www.xda-developers.com/set-up-your-own-git-server-at-home/) + by Ty Sherback on XDA Developers. + * [Gitea](https://about.gitea.com/), a Go-based software forge (fork of [Gogs](https://gogs.io/)), + was first mentioned in [Git Rev News Edition #23](https://git.github.io/rev_news/2017/01/25/edition-23/). + There is also [Forgejo](https://forgejo.org/), a fork of Gitea, + mentioned in [Git Rev News Edition #114](https://git.github.io/rev_news/2024/08/31/edition-114/). +* [Is there a way to split the git history of a file or combine the histories of two files without a merge commit?](https://devblogs.microsoft.com/oldnewthing/20241218-00/?p=110655), + a short exploration by Raymond Chen on The Old New Thing, part of Microsoft Dev Blogs. + * Some of the other blog posts referenced in the above-mentioned exploration also made their appearance in Git Rev News: + [Mundane git tricks: Combining two files into one while preserving line history](https://devblogs.microsoft.com/oldnewthing/20190514-00/?p=102493) + was mentioned in [Edition #51](https://git.github.io/rev_news/2019/05/22/edition-51/). + [How do I split a file into two while preserving git line history?](https://devblogs.microsoft.com/oldnewthing/20190916-00/?p=102892) + was not present, but the related + [How to split off an older copy of a file while preserving git line history](https://devblogs.microsoft.com/oldnewthing/20230728-00/?p=108498) + appeared in [Edition #104](https://git.github.io/rev_news/2023/10/31/edition-104/). +* [Edit commit message with git reword (`git commit --fixup:reword=`)](https://www.brandonpugh.com/til/git/edit-commit-message-with-reword/) + in Brandon Pugh's TILs: Today I learned... (2024). +* [How I use git worktrees](https://notes.billmill.org/blog/2024/03/How_I_use_git_worktrees.html) + (with the help of custom [worktree](https://github.com/llimllib/personal_code/blob/daab9eb1/homedir/.local/bin/worktree#L1) script) + by Bill Mill on their blog (2024). + * See also [How I Use Git Worktrees](https://matklad.github.io/2024/07/25/git-worktrees.html) + by Alex Kladov (matklad) on his GitHub Pages-based blog, + mentioned in [Git Rev News Edition #113](https://git.github.io/rev_news/2024/07/31/edition-113/). +* [Git Trailers](https://alchemists.io/articles/git_trailers) by Brooke Kuhlmann + was mentioned in [Git Rev News Edition #108](https://git.github.io/rev_news/2024/02/29/edition-108/), + but was since then updated. + + + +__Git tools and sites__ + +* [Project Harmony (Harmony Agreements)](https://www.harmonyagreements.org/) + is a community-centered group focused on _contributor agreements_ + for free and open source software (FOSS). +* [todo-md](https://codeberg.org/lig/todo-md) is a pre-commit hook written in Bash + that automatically maintains a `TODO.md` file in your repository. + It collects `TODO:` comments from your code and organizes them into a Markdown file, + making it easy to track tasks and improvements. + Under MIT license. +* [Yek](https://github.com/bodo-run/yek) (يک) is a fast Rust based tool + to serialize (selected) text-based files in a repository or directory + into a single file meant for LLM consumption. Mentions similar projects. + Under MIT license. + + +## Releases + ++ Git [2.48.1 and friends (security releases)](https://public-inbox.org/git/xmqq5xmh46oc.fsf@gitster.g/), +[2.48.0](https://public-inbox.org/git/xmqqplku7cvm.fsf@gitster.g/), +[2.48.0-rc2](https://public-inbox.org/git/xmqqbjwjyalr.fsf@gitster.g/) ++ Git for Windows [2.47.1(2) (security release)](https://github.com/git-for-windows/git/releases/tag/v2.47.1.windows.2), +[2.48.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.48.0-rc2.windows.1) ++ GitLab [17.8.1, 17.7.3, 17.6.4](https://about.gitlab.com/releases/2025/01/22/patch-release-gitlab-17-8-1-released/), +[17.8](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/), +[17.7.2](https://about.gitlab.com/releases/2025/01/15/gitlab-17-7-2-released/), +[17.7.1, 17.6.3, 17.5.5](https://about.gitlab.com/releases/2025/01/08/patch-release-gitlab-17-7-1-released/) ++ Gerrit Code Review [3.10.4](https://www.gerritcodereview.com/3.10.html#3104), +[3.11.1](https://www.gerritcodereview.com/3.11.html#3111), +[3.9.9](https://www.gerritcodereview.com/3.9.html#399) ++ GitHub Enterprise [3.15.2](https://help.github.com/enterprise-server@3.15/admin/release-notes#3.15.2), +[3.14.7](https://help.github.com/enterprise-server@3.14/admin/release-notes#3.14.7), +[3.13.10](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.10), +[3.12.14](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.14) ++ GitKraken [10.6.3](https://help.gitkraken.com/gitkraken-client/current/), +[10.6.2](https://help.gitkraken.com/gitkraken-client/current/), +[10.6.1](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.15](https://desktop.github.com/release-notes/), +[3.4.14](https://desktop.github.com/release-notes/), +[3.4.13](https://desktop.github.com/release-notes/) ++ Garden [2.0.0](https://github.com/garden-rs/garden/releases/tag/v2.0.0), +[1.10.1](https://github.com/garden-rs/garden/releases/tag/v1.10.1) ++ Git Cola [4.11.0](https://github.com/git-cola/git-cola/releases/tag/v4.11.0) ++ GitButler [0.14.6](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.6), +[0.14.5](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.5) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Justin Tobler, D. Ben Knoble, +Brandon Pugh, Štěpán Němec and Adam Johnson. diff --git a/_posts/2025-02-28-edition-120.markdown b/_posts/2025-02-28-edition-120.markdown new file mode 100644 index 0000000000..8ad9194cd9 --- /dev/null +++ b/_posts/2025-02-28-edition-120.markdown @@ -0,0 +1,349 @@ +--- +title: Git Rev News Edition 120 (February 28th, 2025) +layout: default +date: 2025-02-28 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 120 (February 28th, 2025) + +Welcome to the 120th 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 January and February 2025. + +## Discussions + + + +### Reviews + ++ [[PATCH] worktree: detect from secondary worktree if main worktree is bare](https://lore.kernel.org/git/pull.1829.git.1731653548549.gitgitgadget@gmail.com/) + + Last November, Olga Pilipenco sent a patch to the mailing list + addressing an issue she had encountered while working with multiple + [worktrees](https://git-scm.com/docs/git-worktree). + + Git worktrees allow developers to check out multiple branches from + the same repository simultaneously, each in its own working + directory. Unlike creating separate clones, worktrees share the same + object database and references, saving disk space and avoiding the + need to push and fetch between copies of the repository. They can be + very useful when working on multiple features in parallel or when + needing to make a quick fix while in the middle of other development + work. + + The issue happened when a repository had a main worktree that was + bare with `core.bare = true` in `config.worktree`. After creation of a new + secondary worktree, from that secondary worktree's point-of-view + the main worktree appeared as non-bare. This prevented users from + checking out or working with the default branch of the main worktree + (typically "main" or "master") in the secondary worktree. + + When `extensions.worktreeConfig` is enabled, each worktree has its + own configuration settings in a `config.worktree` file that can + override repository-wide settings in the common `config` file. This + allows different worktrees to have different configurations, but it + also means that settings from one worktree aren't automatically + visible to commands running in another worktree. + + Olga found that when inside the secondary worktree, the main + worktree's configuration wasn't initialized, and her patch fixed + that by loading the main worktree's `config.worktree` file only when + required. + + Unfortunately Olga's email fell through the cracks, receiving no + response. But last January she sent a + [version 2](https://lore.kernel.org/git/pull.1829.v2.git.1737063335673.gitgitgadget@gmail.com/) + of her patch. There was no code change compared to the first + version, but she added people in "Cc:", and she had rebased the + patch on top of the "maint" branch. + + This time Eric Sunshine replied. He acknowledged that this was a + real problem and noted that it had been documented in a "NEEDSWORK" + comment added in 2019 to the code which now got patched. He then + attempted to rewrite the commit message of the patch in a way that + was "more idiomatic" to the project and that added more details to + help understand the problem. + + The suggested commit message especially mentioned that when + `extensions.worktreeConfig` is true, commands run in a secondary + worktree only consulted `$commondir/config` and + `$commondir/worktrees//config.worktree`. Thus they never saw + that the main worktree's `core.bare` setting was true in + `$commondir/config.worktree`. + + Eric also suggested removing some parts of Olga's commit message + that talked about other solutions she had considered, or + repeated in which circumstances the problem appeared. Finally, there + were a number of small comments on the code part of the patch. + + Olga replied to Eric saying that the commit message he proposed was + "so much better" than the original one. She agreed with most of + Eric's suggestions and answered the few questions he asked. + + Eric replied explaining some technical details and making a few more + suggestions. + + Junio Hamano, the Git maintainer, then replied to Eric thanking him + "for an easy-to-read review" and thanking Olga for working on this + issue. + + Eric and Olga further discussed technical improvements to the + patch. In the course of that discussion, Eric explained the + historical context related to using the "bare main worktree" + expression: + + > It's a historic "accident" that when worktree support was designed, + > the idea of linking worktrees to a bare repository was not considered. + > Support for using worktrees with a bare repository was added later. + > However, by that time, the term "main worktree" was already well + > established, with the very unfortunate result that even when there is + > no actual "main worktree" but only a bare repository with "linked + > worktrees" hanging off it, the repository itself is usually referred + > to as the "bare main worktree", which is an obvious misnomer; the + > repository is just a repository (i.e. the object database and other + > meta-information) and there is no actual main worktree. + + Olga then sent a + [version 3](https://lore.kernel.org/git/pull.1829.v3.git.1738346881907.gitgitgadget@gmail.com/) + of her patch. It used the commit message suggested by Eric, and + implemented his suggestions. + + Junio reviewed this new version of the patch and had a single + question about the code that decided when it was necessary to read + the main worktree's `config.worktree` file. Olga and Junio further + discussed how to make it clearer what that code was doing, and + eventually agreed on adding a four line long comment on top of it. + + Olga then sent a + [version 4](https://lore.kernel.org/git/pull.1829.v4.git.1738737014194.gitgitgadget@gmail.com/) + of her patch which only added that four line long comment. + + The patch was later merged into the 'master' branch, so + version 2.49 of Git, which should be released in a few weeks, will + finally resolve a long-standing issue and significantly enhance the + usability of Git worktrees for developers working with bare + repositories. + + + + +## Community Spotlight: Chris Torek + +_[Chris Torek](https://stackoverflow.com/users/1256452/torek) has been a prolific +contributor to the Git topic on Stack Overflow. This edition features an interview +with him. This is a continuation of our initiative to interview community contributors +outside of our mailing list. Our first interview was [with VonC in edition 106](https://git.github.io/rev_news/2023/12/31/edition-106/#community-spotlight-vonc)_. + + +* **Who are you and what do you do?** + + "Who am I" is way too complicated! 🙂 What I do ... well, I'm now + retired, and you'd think that would give me more time to answer things + like this. + + I used to do a lot of embedded systems programming, and a lot of + internal company education at times (about programming languages, + various hardware functions and limitations, software tools, and such). + That's what led me to [answering Stack Overflow questions](https://stackoverflow.com/users/1256452/torek?tab=summary). + +* **What would you name your most important contribution to Git?** + + I haven't put much into Git itself. I fixed a minor issue with + case-insensitive rename once, and something that was annoying me about + `git diff` applied to merge commits [[ref](https://public-inbox.org/git/pull.804.v4.git.git.1591978801.gitgitgadget@gmail.com/)]. + +* **What was your motivation behind answering questions about Git on + Stack Overflow?** + + Here, well, I got roped into explaining Git to a group that was moving + from Mercurial. I found existing descriptions to be lacking. + Eventually that particular job went away but the question-answering + persisted, until I got sufficiently annoyed at Stack Overflow itself + (for various reasons) to take a break that continues to this day. + +* **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'm not entirely sure. There are a few big issues today, such as + dealing with OS irregularities (the fact that Windows can't name a + file `aux.h` for instance is a trivial example of the overall problem; + very long file names, case and UTF-8 encoding sensitivities are + another example of the same underlying issue); the ongoing + [transition from SHA-1 to SHA-256](https://git-scm.com/docs/hash-function-transition) + (which works now but there's no cross-compatibility); a number + of minor but sometimes important niggles with merging; support + for extremely large code bases, including submodules and other + ideas (Microsoft's Git VFS). I have no ideas for *how* to + achieve this but a better way to "see" history would, + I think, be a huge improvement. + + One other thing that might be particularly good is an equivalent of + [Mercurial's `evolve` extension](https://www.mercurial-scm.org/doc/evolution/). + But even Mercurial's was never mainstreamed; this is very hard to + get right (whatever "right" means). + +* **If you could remove something from Git without worrying about backwards + compatibility, what would it be?** + + I'm not convinced anything needs to be _removed_, but it would + simplify things a lot if we didn't need SHA-1 compatibility, if + SHA-256 magically just worked and everything were converted over. (And + looking at [VonC's reply](https://git.github.io/rev_news/2023/12/31/edition-106/#community-spotlight-vonc) + I agree that `switch`+`restore` is a much better + split than the old `checkout`.) And, although people like it for + convenience, it might be OK if we all had to use separate + `fetch`-then-(whatever is needed) steps: see below. + +* **What is your favorite Git-related tool/library, outside of Git itself?** + + I don't think I have one. I've used [gitk](https://git-scm.com/docs/gitk) + for history browsing, and if it were somehow improved (see the list of + items above) it might be particularly useful. + +* **What is one of your most favourite features of Git?** + + Speed. Having used the previous generations of version control (and + waited, and waited...), there's nothing quite like doing an update and + having it take only seconds. The distributed nature is also pretty + crucial, though it has its pluses and minuses. + +* **Could you brief a bit about one of your most memorable experiences with Git?** + + Hah, the most memorable one was probably one of the worst, back in the + days of Git 1.5 or so. Back then, an initial `git pull` wasn't always + careful about a pre-populated working tree. I had it destroy a week's + worth of code once. Ever since then I've separated pull into fetch + followed by merge-or-rebase. This is long since fixed, but it's + instructive to new users to know that `pull` is really two separate + steps. When I started, I didn't know that: the tutorial I read just + said to run `git pull`. + +* **What is your advice for people who want to start using Git? Where + and how should they start?** + + I'm not entirely fond of any of the introductions I've seen. I started + on a book once (between jobs) but stalled out when I went to work for + another startup. One of these days I plan to get back to it. + +* **There's a common conception that "Git is confusing". What are your + thoughts about the same?** + + There *are* confusing parts, but they are inherent to the issues that + occur with distributed repositories and independent development. The + only way to really understand this is to get a good grounding—hence + the idea of writing a book. + +* **If there’s one tip you would like to share with other Git + developers, what would it be?** + + For *developers* in particular, they should probably have a look at + what surprises Git users. If something didn't work the way someone + expected it to, why? Was it an incorrect expectation (it probably was) + and if so, why did the user *have* that expectation in the first + place? + + +## Other News + +__Various__ + +- The Git project has been accepted as a [Mentor Organization](https://summerofcode.withgoogle.com/programs/2025/organizations/git) + for Google Summer of Code (GSoC) 2025. We can still add project ideas to our + [idea page](https://git.github.io/SoC-2025-Ideas/), and volunteers to (co-)mentor + are still welcome. Feel free to join the discussion in the [corresponding thread](http://public-inbox.org/git/6C29409D-691B-471F-B08C-83E14D35EE13@gmail.com/T/#mb087c1b0ed06fcbd56d4ffa320efbeb42fd4983f). + Also, feel free to spread the word about Git’s participation. ++ [GitHub - Repositories – Updated insight views (General Availability)](https://github.blog/changelog/2025-02-25-repositories-updated-insight-views-general-availability/) + in GitHub Changelog. + + +__Light reading__ + ++ [Why was Git Autocorrect too fast for Formula One drivers?](https://blog.gitbutler.com/why-is-git-autocorrect-too-fast-for-formula-one-drivers/) + Why did Git's autocorrect wait 0.1s before executing a mistyped command? + Post by Scott Chacon on GitButler Blog. ++ [How Core Git Developers Configure Git](https://blog.gitbutler.com/how-git-core-devs-configure-git/) + by Scott Chacon on GitButler Blog. + + See also [Popular `git config` options](https://jvns.ca/blog/2024/02/16/popular-git-config-options/) + by Julia Evans on her blog, which was mentioned in [Git Rev News Edition #108](https://git.github.io/rev_news/2024/02/29/edition-108/). ++ [How to do patch-based review with `git range-diff`](https://blog.gitbutler.com/interdiff-review-with-git-range-diff/) + by Scott Chacon on GitButler Blog. ++ [Markdown's Big Brother: Say Hello to AsciiDoc](https://www.git-tower.com/blog/asciidoc-quick-guide) + by Marvin Blome on Git-Tower Blog. + + Another similar file format for textual data and technical documentation + is [reStructuredText](https://docutils.sourceforge.io/rst.html) (RST, ReST, or reST). + It is used, among others, by the Python programming language community, + and is part of the Docutils project of the Python Doc-SIG. ++ [Understanding the Trunk-Based Development Workflow](https://www.git-tower.com/blog/trunk-based-development) + by Bruno Brito on Git-Tower Blog (2024). + + See also the site, + first mentioned in [Git Rev News Edition #24](https://git.github.io/rev_news/2017/02/22/edition-24/). ++ [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) + with `includeIf`, a short post by Matteo Pampana on Medium\.com. ++ [Why Some Source Code Files Shouldn’t Be Managed via Git-Based Version Control](https://www.itsecurityguru.org/2025/01/27/why-some-source-code-files-shouldnt-be-managed-via-git-based-version-control/) + on IT Security Guru. ++ [Git Stash Without the Branch Name](https://www.brandonpugh.com/blog/git-stash-without-the-branch-name/) + post by Brandon Pugh. ++ [Microsoft Engineers Highlight Git Repository Bloat Flaw](https://devops.com/microsoft-engineers-highlight-git-repository-bloat-flaw/) + by Adrian Bridgwater on DevOps\.com blog (2024). + + + + +__Git tools and sites__ + ++ [JJ (Jujutsu) Cheat Sheet](https://justinpombrio.net/2025/02/11/jj-cheat-sheet.html) + by Justin Pombrio. + + [Jujutsu (`jj`)](https://jj-vcs.github.io/jj/), a Git-compatible version control system, + written in Rust, was first mentioned in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [Beej's Guide to Git](https://beej.us/guide/bggit/). ++ [Gookme](https://lmaxence.github.io/gookme/) is a simple and easy-to-use, + yet powerful and language agnostic Git hook manager for [monorepos](https://monorepo.tools/). + Successor of Mookme. Written in Go, under MIT license. + + +## Releases + ++ Git [2.49.0-rc0](https://public-inbox.org/git/xmqqzfi8bljk.fsf@gitster.g/) ++ Git for Windows [2.49.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.49.0-rc0.windows.1), +[2.48.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.48.1.windows.1) ++ GitHub Enterprise [3.16.0](https://help.github.com/enterprise-server@3.16/admin/release-notes#3.16.0), +[3.15.3](https://help.github.com/enterprise-server@3.15/admin/release-notes#3.15.3), +[3.14.8](https://help.github.com/enterprise-server@3.14/admin/release-notes#3.14.8), +[3.13.11](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.11), +[3.12.15](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.15) ++ GitLab [17.9.1, 17.8.4, 17.7.6](https://about.gitlab.com/releases/2025/02/26/patch-release-gitlab-17-9-1-released/), +[17.9](https://about.gitlab.com/releases/2025/02/20/gitlab-17-9-released/), +[17.8.2, 17.7.4, 17.6.5](https://about.gitlab.com/releases/2025/02/12/patch-release-gitlab-17-8-2-released/) ++ GitKraken [10.7.0](https://help.gitkraken.com/gitkraken-client/current/), +[10.6.3](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.17](https://desktop.github.com/release-notes/), +[3.4.16](https://desktop.github.com/release-notes/) ++ Sourcetree [4.2.11](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.11.html) ++ tig [2.5.12](https://github.com/jonas/tig/releases/tag/tig-2.5.12), +[2.5.11](https://github.com/jonas/tig/releases/tag/tig-2.5.11) ++ Garden [2.1.0](https://github.com/garden-rs/garden/releases/tag/v2.1.0) ++ Git Cola [4.12.0](https://github.com/git-cola/git-cola/releases/tag/v4.12.0) ++ GitButler [0.14.8](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.8), +[0.14.7](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.7) ++ Tower for Mac [12.5, 12.5.1, 12.5.2](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) — [Release blog post](https://www.git-tower.com/blog/tower-mac-125/) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Chris Torek, Štěpán Němec, Bruno Brito +and Brandon Pugh. diff --git a/_posts/2025-03-31-edition-121.markdown b/_posts/2025-03-31-edition-121.markdown new file mode 100644 index 0000000000..ce754e0639 --- /dev/null +++ b/_posts/2025-03-31-edition-121.markdown @@ -0,0 +1,461 @@ +--- +title: Git Rev News Edition 121 (March 31st, 2025) +layout: default +date: 2025-03-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 121 (March 31st, 2025) + +Welcome to the 121st 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 February and March 2025. + +## Discussions + +### General + +* [10 years of Git Rev News](https://git.github.io/rev_news/archive/) + + Git Rev News started 10 years ago with + [edition 1 published on March 25, 2015](https://git.github.io/rev_news/2015/03/25/edition-1/), + and then one edition per month. + + To celebrate, let's look at some stats that we have gathered about + these first 120 editions. + + + First we would like to thank all those who helped us so far. + + This includes those who helped with ideas, links, PRs, small + corrections, letting us know about a Git related software release, + and even sometimes full articles without being part of our editor + team. Here is the top 12 along with the number of editions they + helped us with, according to our "Credits" section, and the number + of commits they contributed: + + - Johannes Schindelin: 29 editions and 71 commits + - Bruno Brito: 25 editions and 36 commits + - Luca Milanesio: 19 editions and 23 commits + - Štěpán Němec: 18 editions and 22 commits + - Junio Hamano: 13 editions and 22 commits + - Philip Oakley: 10 editions and 10 commits + - Elijah Newren: 10 editions and 9 commits + - Andrew Ardill: 8 editions and 15 commits + - David Pursehouse: 8 editions and 12 commits + - Jeff King: 8 editions and 5 commits + - Matthieu Moy: 6 editions and 14 commits + - Lars Schneider: 6 editions and 14 commits + + In total, more than 125 people helped this way. + + Former members of the editor team helped a lot, too: + + - Thomas Ferris Nicolaisen: 33 editions and 135 commits + - Gabriel Alcaras: 22 editions and 7 commits + - Nicola Paolucci: 16 editions and 5 commits + + A small number of people have also helped us by contributing to + [our scripts](https://github.com/chriscool/getreleases/) to + automate parts of the edition and publication process: + + - Gabriel Alcaras: 9 commits + - David Aguilar: 3 commits + - Mirth Hickford: 2 commits + + + A number of people helped by accepting to be interviewed in our + "Developer Spotlight" or "Community Spotlight" sections. Thanks to + them, too: + + - Total interviews: 72 + - Unique interviewees: 70 + - Repeat interviews: 2 (David Aguilar and Eric Sunshine have been interviewed twice) + - Developer interviews: 70 + - Community interviews: 2 + + + Most of the long articles are in a "Discussions" section and in + one of its subsections: "General", "Reviews" or "Support". Here + are some related stats: + + Total over all the editions: + + - Discussions articles: 254 + - General articles: 106 + - Reviews articles: 79 + - Support articles: 69 + + Average per edition: + + - Discussions: 2.12 + - General: 0.88 + - Reviews: 0.66 + - Support: 0.57 + + Text Statistics: + + - Total words: 100,434 + - Total lines: 14,090 + - Total paragraphs: 3,097 + + Average per article: + + - Words: 395.4 + - Lines: 55.5 + - Paragraphs: 12.2 + + Total words per section: + + - General: 29,220 words + - Reviews: 35,912 words + - Support: 35,302 words + + + Among those long articles, 16 articles were written by people + outside the editor team. Big thanks to them! The top 3 is: + + - Junio Hamano: 4 + - Matthieu Moy: 3 + - Jacob Keller: 2 + + The following people wrote one article each: + + Andrew Ardill, Elijah Newren, Eric S. Raymond, Eric Sunshine, + Jiang Xin, Lars Schneider. + + One article was also written collaboratively by the following + students: + + François Beutin, Jordan De Gea, William Duclot, Samuel Groot, + Erwan Mathonière, Antoine Queru, Simon Rabourg and Tom Russello. + + These articles were mostly written towards the first years of Git + Rev News: + + - 2015: 8 articles + - 2016: 2 articles + - 2018: 2 articles + - 2019: 1 article + - 2020: 3 articles + + + There were 2298 entries in the "Other News" section, + which gathers links to various news, articles, sites, tools, + and sometimes media about Git (or related to Git). + + Those entries include: + + - 1090 entries in "Light reading" over 114 editions + with 1777 links; around 13.76% of entries mention previous editions. + - 691 entries in "Git tools and sites" over 118 editions + with 1270 links; around 11.72% of entries mention previous editions. + - 411 entries in "Various" over 110 editions + with 635 links; around 7.06% of entries mention previous editions. + - 20 entries in "Events" over 12 editions + with 39 links + - 15 entries in "Easy watching" over 12 editions + with 31 links; of those, 3 entries mention previous editions. + + There were quite a few one-off names of sub-lists, like + "Slightly heavier reading", "April Fool's", "Listening and watching". + The template with standardized names was not present in the 1st edition, + but was created later. + + +* [Git participated in the December 2024 Outreachy round](https://www.outreachy.org/alums/2024-12/) + + All the Outreachy interns have successfully completed their + internship: + + - Seyi Kuforiji worked on the "Convert unit tests to use the clar + testing framework" project, mentored by Patrick Steinhardt and + Phillip Wood. See + [his completion email](https://lore.kernel.org/git/CAGedMtcLRjr0GVNYmUU_tacrA0aRvOCYFGyOy0FACTBL=X3cwA@mail.gmail.com/) + and + [his retrospect blog post](https://seyi-kuforiji-902b48.gitlab.io/posts/a-retrospect-on-new-test-conversions). + + - Usman Akinyemi worked on the "Finish adding a 'os-version' + capability to Git protocol v2" project, mentored by Christian + Couder. See + [his completion blog post](https://uniqueusman.hashnode.dev/my-outreachy-internship-experience-at-git). + + + + + +## Developer Spotlight: Peter Krefting + +* **Who are you and what do you do?** + + My name is Peter Krefting and I am a software engineer. Hailing from Sweden, + I moved to Norway for my first job, at Opera Software, mostly working on + internals such as Unicode support and internal libraries. I ended up staying + in Norway and am currently working for a small company providing monitoring + equipment for digital TV. + +* **What are you doing on the Git project these days, and why?** + + My answers to these two are the same, I am the maintainer of the + [Swedish translation of Git](https://github.com/git-l10n/git-po/blob/master/po/sv.po). + I like having software running in my own language, and sometimes + you have to take matters in your own hands. + +* **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 think [`git gui`](https://git-scm.com/docs/git-gui) and + [`gitk`](https://git-scm.com/docs/gitk) could need some extra love, + these are my daily drivers, in addition to the command line. + +* **Is there something that developers could do to ease the life of + translators?** + + My main gripe is using library function names as verbs, + like `cannot fsync`. That's hard to read even in the original + language, even for a C developer like myself. + +* **What is your favorite Git-related tool/library, outside of + Git itself?** + + I like simple and clean interfaces, so using [cgit](https://wiki.archlinux.org/title/Cgit) + to visualize history on a web server is very nice. + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I mostly just read the mailing list, and only a small percentage of the + posts to it; the localization is handled through [GitHub pull requests](https://github.com/git-l10n/git-po/pulls?q=is%3Apr), + so that's where that work happens. The few patches I have sent to the + mailing list have been very manual, using `git format-patch` and + the [Alpine mail client](https://alpineapp.email/). + +* **What is your advice for people who want to start Git development? + Where and how should they start?** + + Find some small part you want to improve, and work on that. Git is a + fairly complex piece of software, implemented in several different + languages, making it hard to get an overview. I most definitely do not have that, + even after having read (and translated) most of the user-visible strings. + + +## Other News + +__Various__ + ++ [What's new in Git 2.49.0?](https://about.gitlab.com/blog/2025/03/14/whats-new-in-git-2-49-0/) + by Toon Claes on GitLab Blog. This blog post mentions, among other things, + improved performance thanks to zlib-ng, a new name-hashing algorithm, and git-backfill. ++ [Highlights from Git 2.49](https://github.blog/open-source/git/highlights-from-git-2-49/) + by Taylor Blau on GitHub Blog. Mentioned items include faster packing with name-hash v2, + backfilling historical blobs in partial clones, building Git with zlib-ng, + and the libgit-sys and libgit Rust crates. + + +__Light reading__ + ++ [Going down the rabbit hole of Git's new bundle-uri](https://blog.gitbutler.com/going-down-the-rabbit-hole-of-gits-new-bundle-uri/) + by Scott Chacon on GitButler blog.
+ The [`bundle-uri`](https://git-scm.com/docs/bundle-uri) was mentioned in passing in [Git Rev News Edition #95](https://git.github.io/rev_news/2023/01/31/edition-95/) + (in _"Developer Spotlight"_) and in [Edition #104](https://git.github.io/rev_news/2023/10/31/edition-104/) + (in _"Git tools and sites"_, when mentioning [git-bundle-server](https://github.com/git-ecosystem/git-bundle-server)). ++ [No Longer My Favorite Git Commit](https://mtlynch.io/no-longer-my-favorite-git-commit/) + by Michael Lynch on his blog, talks about how one could _improve_ the commit message + described in David Thompson's [“My favourite Git commit”](https://dhwthompson.com/2019/my-favourite-git-commit) - which + was mentioned in [Git Rev News Edition #57](https://git.github.io/rev_news/2019/11/20/edition-57/) + and [#108](https://git.github.io/rev_news/2024/02/29/edition-108/). + + The article mentions the [How to Write Useful Commit Messages](https://refactoringenglish.com/chapters/commit-messages/) + guide by Michael Lynch, one of the sample chapters for his prospective book, + _"Refactoring English: Effective writing for software developers"_. + + Another post by Michael Lynch, [How to Make Your Code Reviewer Fall in Love with You](https://mtlynch.io/code-review-love/), + was mentioned in [Git Rev News Edition #70](https://git.github.io/rev_news/2020/12/26/edition-70/). ++ [19000 curl commits](https://daniel.haxx.se/blog/2025/03/14/19000-curl-commits/) + by Daniel Stenberg on his blog, presenting some statistics about those commits. ++ [Why fastDOOM is fast](https://fabiensanglard.net/fastdoom/index.html) + by Fabien Sanglard, examines FastDOOM performance evolution over time, + doing some nice Git archeology. ++ [Personal Agency With Git Time Logging](https://doocot.sh/blog/2025/03/28/time-tracking-with-git) + by Doug Bridgens on doocot blog. The `commit-msg` and `pre-push` hooks from + [git-time-hooks](https://github.com/thisdougb/git-time-hooks) are used to measure time spans + from creating a new branch to merging that branch. ++ [git bisect …](https://theweeklychallenge.org/blog/git-bisect/) + by Mohammad Sajid Anwar (MANWAR) on The Weekly Challenge blog. + The blog post shows how to use `git bisect` on a detailed example (in Perl). ++ [Python monorepo with uv and pex](https://chrismati.cz/posts/uv-pex-monorepo/) + by Christoph Pröschel on his blog. The article discusses the benefits of a + lightweight solution built with regular Python tooling + over, for example, the [Pants](https://www.pantsbuild.org/) build tool, + because it was easier to justify its adoption for the rest of the team. + + You can find a definition of "monorepo" and a list of various tools on the [Monorepo.tools](https://monorepo.tools/) site, + which was first mentioned in [Git Rev News Edition #84](https://git.github.io/rev_news/2022/02/28/edition-84/). ++ [Gerrit Code Review: A How-To Guide for new users!](https://gitenterprise.me/2025/03/10/gerrit-code-review-a-how-to-guide-for-new-users/) + by Daniele Sassoli on GerritForge Blog. See also: + + [How GitHub taught the world code review the wrong way](https://medium.com/@danielesassoli/how-github-taught-the-world-code-reviews-the-wrong-way-f840a072f5be) + by Daniele Sassoli (2024) on his Medium-based blog. + + [Pull requests / Collaborate with pull requests / Getting started / Helping others review your changes](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/helping-others-review-your-changes) + on GitHub Docs. ++ [TIL: Hugo's GitInfo](https://blog.erethon.com/log/2025-03-03-hugo-git-info/) + by Dionysis Grigoropoulos, about the [GitInfo](https://gohugo.io/methods/page/gitinfo/) method + of [Hugo](https://gohugo.io/), the static site generator + in Go. The method returns Git information related to the + last commit of the given page. ++ [GitHub meets GitLab](https://theweeklychallenge.org/blog/github-meets-gitlab/) + by Mohammad Sajid Anwar (MANWAR) on The Weekly Challenge blog, + about the terminology differences between GitHub and GitLab + (part of the learning process to pick up GitLab). ++ [Comparing Git Mirror Options](https://www.lloydatkinson.net/posts/2025/comparing-git-mirror-options/): + by Lloyd Atkinson on his blog. + The tools considered include gitweb, cgit, and Forgejo; + the last option (Forgejo) was ultimately selected. ++ [Migrating git.adyxax.org from gitolite and cgit to Forgejo](https://www.adyxax.org/blog/2025/03/25/migrating-git.adyxax.org-from-gitolite-and-cgit-to-forgejo/): + How I am deploying [Forgejo](https://forgejo.org/) with [Ansible](https://www.ansible.com/). + By Julien (Adyxax) Dessaux on his blog. ++ [Learn Git through Gamification – A Visual Guide to Key Version Control Concepts](https://www.freecodecamp.org/news/learn-git-through-gamification) + by Jacob Stopak on freeCodeCamp. ++ [4 reasons you need to run a Git server on your NAS (even if you're not a developer)](https://www.xda-developers.com/reasons-run-git-server-nas/) + by Adam Conway on XDA Developers. ++ [Manage DNS Records with GitHub Actions and DNSControl](https://runtimeterror.dev/manage-dns-records-github-actions-dnscontrol) + by John Wq on [runtimeerror] blog. ++ [WSL SSH agent and Git](https://www.patriktrefil.com/posts/wsl_ssh_agent_and_git/) + by Patrik Trefil (2024) on his blog. + This article describes how you can avoid the hassle of copying and pasting your SSH passphrase + every time you want to connect to a machine via ssh. ++ [Accessing git Servers Over Another Port When 22 is Blocked and Cloning Hangs Waiting for Connection](https://jdsalaro.com/howto/fix-git-hang-connection-blocked-port-22-github-gitlab-bitbucket/) + by Jayson Salazar Rodriguez (2024) on his site. ++ [Automatic Versioning with Xcode and Git](https://blog.reiterate.app/software/2024/07/09/automatic-versioning-with-xcode-and-git/) + by Rat Troupe on Reiterations blog (2024). ++ [Version controlling Jenkins config](https://scripter.co/version-controlling-jenkins-config) + by Kaushal Modi (2022) on A Scripter's Notes; + mentions `jenkins-plugin-cli` from [Plugin Installation Manager Tool for Jenkins](https://github.com/jenkinsci/plugin-installation-manager-tool). + + Compare [How to use the Jenkins Git Plugin: Tips and tricks](https://www.theserverside.com/video/Tips-and-tricks-on-how-to-use-Jenkins-Git-Plugin) + by Cameron McKenzie from [Git Rev News Edition #44](https://git.github.io/rev_news/2018/10/24/edition-44/), + about [Git | Jenkins Plugin](https://plugins.jenkins.io/git/). ++ [Using Git Delta with Magit](https://scripter.co/using-git-delta-with-magit/) + by Kaushal Modi (2022) on A Scripter's Notes. + + [Delta](https://github.com/dandavison/delta) is a highly configurable command line utility + that makes the Git diffs look better, while also syntax-highlighting the code in the diffs. + First mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/). + + [Magit](https://magit.vc/) is a popular Emacs interface to Git, + first mentioned (in passing) in [Git Rev News Edition #6](https://git.github.io/rev_news/2015/08/05/edition-6/). ++ [How to Proxy Git Connections: using socat to ...Git... through a corporate firewall](https://bryanbrattlof.com/how-to-proxy-git-connections/) + by Bryan Brattlof (2022) on his blog. ++ [Git aliases supporting main and master: How to make your aliases agnostic to the default branch](https://phili.pe/posts/git-aliases-supporting-main-and-master/) + by Philipe Fatio (2022) on his blog. ++ [Keeping ‘live‘ dotfiles in a Git repo](https://probablerobot.net/2021/05/keeping-'live'-dotfiles-in-a-git-repo/) + by creating a repository directory named `.dotfiles/` rather than `.git/` via the `--git-dir` Git wrapper option. + From (2021). ++ [On mainline merges and fast forwards](https://vcscompare.blogspot.com/2008/06/on-mainline-merges-and-fast-forwards.html) + by aoeuo (2008) on the Blogger-based DVCS Comparison blog. + Compares Bazaar with Git and Mercurial. + ++ [GPLv2 is not impressed by git](https://www.thomas-huehn.com/gplv2-is-not-impressed-by-git/) + by Thomas Huehn on his Bear-powered blog, a short musing about the following phrase from the license: + > You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. ++ [I found commit 0](https://programming.dev/post/27187038) + (or rather a commit whose SHA-1 identifier begins with 0000000), + by Kissaki on the programming\.dev Lemmy instance.
+ [Lemmy](https://join-lemmy.org/docs/index.html) is a self-hosted, federated social link aggregation and discussion forum, + somewhat similar to Reddit. + + Note that there are tools like [git-vain](https://git.anna.lgbt/anna/git-vain) + and [git-vanity-sha](https://github.com/mattbaker/git-vanity-sha), + most recently listed in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/), + which can be used to make the SHA-1 hash of a commit start with a specific pattern, like `000000`, + by manipulating the commit date or message. + + +__Easy watching__ + ++ [What Git Clone REALLY Does (and why it matters)](https://www.youtube.com/watch?v=zigbUJHBsL4) + on The Modern Coder YouTube channel, 3:16 minutes long. + It's made by @JackLot who created the [LearnGit.io](https://learngit.io) resource, + which site was mentioned in [Git Rev News Edition #108](https://git.github.io/rev_news/2024/02/29/edition-108/). ++ [Git Interview Part 1: Easy | Ep. 8 Bits and Booze](https://www.youtube.com/watch?v=SdSllNeQuVc) [29:09] and
+ [Git Interview Part 2: Hard | Ep. 9 Bits and Booze](https://www.youtube.com/watch?v=FbW9wlve8sI) [17:45]
+ on the GitButler YouTube channel. Join Nico as he (mock) interviews Scott [Chacon] about Git. + + +__Git tools and sites__ + ++ [git-who](https://github.com/sinclairtarget/git-who) is a command-line tool for finding + the people responsible for entire components or subsystems in a codebase. + You can think of `git-who` as a sort of `git blame` but for file trees rather than individual files. + Written in Go under MIT license. ++ [chrondb](https://chrondb.moclojer.com/) ([repo](https://github.com/moclojer/chrondb)) + is a chronological key/value database, + where storing data is based on database-shaped `git` (core) architecture and Lucene for indexing. + Written in Clojure, uses MIT license. ++ [Calendar.txt](https://terokarvinen.com/2021/calendar-txt/) is a solution + to keep your calendar in a plain text file. + One of its advantages is that it is versionable: because it's plain text, you can keep it in Git. + You can also easily take diffs of calendar files, as it's one day one line. + + See also [Todo.txt](http://todotxt.org/) to keep your TODO list in a plain text file, + and tools like [Taskwarrior](https://taskwarrior.org/) and + [Plain Text Accounting (PTA)](https://plaintextaccounting.org/). ++ [YSK there are open-source (gamified) tutorials to learn git](https://programming.dev/post/26285997) + provides a list of some tutorials and interactive learning tools, including: + + [Oh My Git!](https://ohmygit.org/), an open source game about learning Git, + first mentioned in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/). + + [Learn Git Branching](http://learngitbranching.js.org/), visual and interactive way to learn Git on the web, + first mentioned in [Git Rev News Edition #30](https://git.github.io/rev_news/2017/08/16/edition-30/). + + [Git Gud: Master Git Through Play](https://www.gitmastery.me/), a modern website + to learn Git commands and concepts through an interactive game. + + [Git+ Coach](https://github.com/vishal2376/git-coach), a free education app + designed to help users learn Git and its commands. Written in Kotlin, for Android. + + [Git-it](https://github.com/jlord/git-it-electron) is a desktop (Mac, Windows and Linux) Electron app + that teaches you how to use Git and GitHub on the command line. + First mentioned in [Git Rev News Edition #7](https://git.github.io/rev_news/2015/09/09/edition-7/). ++ [BeanHub](https://beanhub.io/) is a modern accounting book app + based on the most popular open source version control system Git + and the text-based double entry accounting book software [Beancount](https://beancount.github.io/docs/index.html). + [Mostly open-sourced](https://beanhub.io/open-source/). See also the following posts by Fang-Pen Lin: + + [My Beancount books are 95% automatic after 3 years](https://fangpenlin.com/posts/2024/12/30/my-beancount-books-are-95-percent-automatic/). + + [How BeanHub works part 1: the danger of processing Beancount data with sandbox](https://beanhub.io/blog/2024/04/23/how-beanhub-works-part1-sandboxing/). + + [How BeanHub works part 2: large-scale auditable Git repository system based on container layers](https://beanhub.io/blog/2024/06/26/how-beanhub-works-part2-layer-based-git-repos/). + + +## Releases + ++ Git [2.49.0](https://public-inbox.org/git/xmqqfrjfilc8.fsf@gitster.g/), +[2.49.0-rc2](https://public-inbox.org/git/xmqq34fk958s.fsf@gitster.g/), +[2.49.0-rc1](https://public-inbox.org/git/xmqqjz94r8p0.fsf@gitster.g/) ++ Git for Windows [2.49.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.49.0.windows.1), +[2.49.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.49.0-rc2.windows.1), +[2.49.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.49.0-rc1.windows.1) ++ Gerrit Code Review [3.10.5](https://www.gerritcodereview.com/3.10.html#3105), +[3.11.2](https://www.gerritcodereview.com/3.11.html#3112), +[3.9.10](https://www.gerritcodereview.com/3.9.html#3910) ++ GitLab [17.10.1, 17.9.3, 17.8.6](https://about.gitlab.com/releases/2025/03/26/patch-release-gitlab-17-10-1-released/), +[17.10](https://about.gitlab.com/releases/2025/03/20/gitlab-17-10-released/), +[17.9.2, 17.8.5, 17.7.7](https://about.gitlab.com/releases/2025/03/12/patch-release-gitlab-17-9-2-released/) ++ GitHub Enterprise [3.16.1](https://help.github.com/enterprise-server@3.16/admin/release-notes#3.16.1), +[3.15.5](https://help.github.com/enterprise-server@3.15/admin/release-notes#3.15.5), +[3.14.10](https://help.github.com/enterprise-server@3.14/admin/release-notes#3.14.10), +[3.13.13](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.13), +[3.12.17](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.17), +[3.16.0](https://help.github.com/enterprise-server@3.16/admin/release-notes#3.16.0), +[3.15.4](https://help.github.com/enterprise-server@3.15/admin/release-notes#3.15.4), +[3.14.9](https://help.github.com/enterprise-server@3.14/admin/release-notes#3.14.9), +[3.13.12](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.12), +[3.12.16](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.16) ++ GitKraken [11.0.0](https://help.gitkraken.com/gitkraken-client/current/), +[10.8.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.18](https://desktop.github.com/release-notes/) ++ GitButler [0.14.14](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.14), +[0.14.13](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.13) ++ git-credential-azure [0.3.1](https://github.com/hickford/git-credential-azure/releases/tag/v0.3.1) ++ git-credential-oauth [0.15.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.15.0) ++ Tower for Mac [12.6](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) ++ Tower for Windows [9.0](https://www.git-tower.com/release-notes/windows) ([Release blog post](https://www.git-tower.com/blog/tower-windows-9/)) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Peter Krefting, Bruno Brito, +Daniele Sassoli, Toon Claes and Štěpán Němec. diff --git a/_posts/2025-04-30-edition-122.markdown b/_posts/2025-04-30-edition-122.markdown new file mode 100644 index 0000000000..98ace10847 --- /dev/null +++ b/_posts/2025-04-30-edition-122.markdown @@ -0,0 +1,756 @@ +--- +title: Git Rev News Edition 122 (April 30th, 2025) +layout: default +date: 2025-04-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 122 (April 30th, 2025) + +Welcome to the 122nd 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 March and April 2025. + +## Discussions + +### General + +* [Let's celebrate Git's 20th anniversary this coming Monday!](https://lore.kernel.org/git/89757bec-4d7e-1d90-5697-44651c6128df@gmx.de/) + + Johannes Schindelin (alias Dscho) posted on the mailing list that + the oldest Git commit was performed on April 7th, 2005. So Monday + April 7th, 2025 was the 20th anniversary of Git! + + To celebrate this event, Dscho created + [a channel on Git's Discord, called `#20th-anniversary`](https://discord.gg/UcjvsNQR) + where everyone is welcome, especially to talk about their encounter + with Git. + +* [[ANNOUNCE] Git Merge 2025, September 29-30, San Francisco, CA](https://lore.kernel.org/git/Z+L3Mt58n18KUNzs@nand.local/) + + Taylor Blau announced a new [Git Merge 2025](https://git-merge.com) + conference on September 29-30 at GitHub HQ in San Francisco along + with a Contributor's Summit on September 30. + + Registration and a Call for Proposals, which closes on May 13th, are + open. Requests for financial assistance with travel costs can be + sent to the Git PLC at . + +* [Patch (apply) vs. Pull](https://lore.kernel.org/git/1119284365.3926.15.camel@localhost.localdomain/) + + To celebrate Git's 20th anniversary in our own way let's talk about + a discussion on the Git mailing list that happened nearly 20 years + ago. + + On June 20, 2005, Darrin Thompson sent an email about a discrepancy + he was perceiving between his mental model of how Git worked and a + common practice he observed on mailing lists. + + He understood that on one hand Git was about people duplicating + locally the remote history they were interested in, which provided + common points in history that enabled "intelligent merging", while + on the other hand mailing lists were filled with emailed patches. + + He asked how the patches were created and handled to ensure they + could be properly dealt with by the receivers and those who would + later pull from those initial receivers. + + He was basically trying to reconcile the patch-based workflow on + mailing lists with Git's design, especially its merging philosophy + based on a common history. + + Junio Hamano, who would later become the Git maintainer, then + replied to Darrin acknowledging that emailed patches were essentially + "out of band" communications. Merges could still work if the same + patch had been applied independently. Even if that wasn't ideal, it + was "manageable". + + Junio then described his workflow, which consisted of regularly + pulling from Linus, discarding his HEAD, using Linus' HEAD instead, + and reapplying onto it some patches that Linus had rejected but he + still considered good. Then he would work on new changes and commit + them on top. + + Darrin, questioning this approach, asked for ways to manage patches + as a series of commits, and wondered if that would still allow + cherry-picking patches. + + Then Daniel Barkalow and Catalin Marinas chimed in + to talk about [StGit (Stacked Git)](https://stacked-git.github.io/) + which helps manage Git commits as a stack of patches. Catalin + Marinas was the creator of StGit, which seems to still be developed + these days as there was a 2.5.0 release in January 2025. + + Daniel suggested integrating functionality similar to StGit into Git + to help with applying patches and bridging the gap between the + patch-based workflow and Git's commit-based model in general, even + though he thought that commits were "fundamentally resistant to + cherry-picking". + + Catalin over the course of the discussion provided specific details + about how StGit could address Junio's workflow. For example, StGit + would automatically detect when a patch was already merged upstream + and warn the user. It could also handle conflicts during the + reapplication process using `diff3`. + + Catalin also mentioned that StGit would soon support pulling changes + from a remote tree along with patch series information, making it + easier to apply patches from different branches. + + Meanwhile, Linus also replied to the email where Junio described his + workflow, proposing "a different kind of merge logic" to automate + some of the steps, as individual developers often want to move their + work forward to the current tip, instead of merging it. The new + script would "try to re-base all the local commits from the common + parent onwards on top of the new remote head". + + Linus showed some steps that the script would perform, some of them + using a new `git-cherry-pick` script that "basically takes an old + commit ID, and tries to re-apply it as a patch (with author data and + commit messages, of course) on top of the current head". + + Then Linus, Junio and Daniel discussed how to implement this. One + problem appeared to be how to automatically detect patches that had + already been merged even where there were small changes, like typo + fixes or whitespace changes, in the patches. + + Daniel suggested that authors could give an ID that would be + preserved across various later modifications to each of their + patches. Linus didn't like this idea because he thought that they + could be useful for specific projects but should be tracked outside + of Git. Inside Git, he thought they could create confusion as it + wouldn't be clear if a patch has been modified or not. + + Daniel then asked Linus if he actually modified patches before + applying them. Linus replied that he very often did modify them and + that he absolutely didn't want to apply them first and then modify + them as he didn't want "crap" in his code. He further elaborated + that his `git-apply` tool was strict and refused to apply patches + with any 'fuzz' (mismatched context lines), only allowing patches + that matched exactly, potentially after adjusting for line number + offsets. He said: + + "So I want things to be cleaned up before they hit the tree, rather + than have a really dirty history. A dirty history just makes it + harder to read, and I don't believe in a second that it's 'closer to + reality' like some people claim." + + "I don't believe anybody wants to see the 'true' history. If they + did, we'd be logging keystrokes, and sending all of that + around. Nope, people want (and need, in order to be able to follow + it) an 'idealized' history." + + Martin Langhoff also contributed to the discussion, noting that + rebasing and replaying local history was an approach he had used + successfully with [Arch](https://en.wikipedia.org/wiki/GNU_arch). He + suggested that the rebasing process should be restartable after + encountering a failed cherry-pick, and proposed adding features like + a "skip list" for patches already merged upstream and a `--stop-at` + option to handle batches of commits incrementally. + + Daniel and Linus continued to discuss practical ways to identify and + manage patches across repositories. Linus proposed hashing the + actual changes in a patch, ignoring line numbers and whitespace, + rather than relying on explicit IDs or commit metadata. He + implemented this idea in the form of a `git-patch-id` and tested it + on the Linux kernel repository where it found 15 duplicate patches + in the kernel history and processed around 2788 patches in under a + minute with no false positives. + + Junio replied with a series of three patches to the email where + Linus had suggested some steps that the script to re-base all the + local commits would perform. The cover letter of his series was + named "Rebasing for 'individual developer' usage". + + The first patch added a `-m` flag to the `git-commit-script` which + allowed committing using the commit message and author information + from an existing commit. + + The second patch implemented a new `git-cherry` script to find + commits that are in the current branch but not in another branch, so + it can help find commits that haven't been merged upstream. + + The third patch implemented a new `git-rebase-script` that used the + functionality from the two previous patches to actually implement + rebasing. + + + + + +## Community interview + +_Editor note: For Git's 20th anniversary, we are doing an exclusive collaborative +community interview and curating answers of various community members. Also, +there's a [short Q&A](#short-qa-with-our-maintainer-junio-c-hamano) with our +zealous, inclusive and tireless maintainer that follows below._ + + +- **What's your favorite Git trick or workflow that you wish more people + knew about?** + + [_Thalia Rose_][thalia]: For rebase-heavy workflows, `git range-diff` is incredibly + useful. To compare against upstream, use `git range-diff @{u}...@`, + and to compare against the previous HEAD, use `git range-diff @{1}...@`. + + [_Lucas Seiki Oshiro_][seiki]: Everything related to code archaeology + (`git grep`, `git log -S/-G`, `git log -L` and `git bisect`). Those are + my primary debugging tools and every time I explained them to other + people they find them mind-blowing and useful. + And they also started loving it :-) + + [_Elijah Newren_][elijah]: [`range-diff`][range-diff]. The ideas behind + it ought to be the basis for code review, IMO. Commits should be the + unit of review (including commit messages as a fundamental and primary + thing to be reviewed), and a series of commits should be the unit of + merging. I dislike most code review tools, because they get one or + both of those things wrong. Getting both of those things right naturally + leads to `range-diff` or something like it being a very important part + of the workflow, at a minimum for detecting which commits in a series + are unmodified and which have been updated and need to be further reviewed. + + +- **What was your worst Git disaster, and how did you recover from it?** + + [_Thalia Rose_][thalia]: When I was first starting with Git, I wanted to make a repo + to preserve my first coding project when I was twelve, a bunch of VBS scripts. + I had assumed that Git maintained file modification timestamps, so I deleted + the originals because they were now redundant. I now no longer know exactly + when I wrote them and have been careful about timestamps ever since. + + [_Luca Milanesio_][luca]: I suspect to be one of the worst offenders :-) [ [ref](https://www.infoq.com/news/2013/11/use-the-force) ] + + Thankfully I was using Gerrit Code Review and the replication plugin: + the refs were not lost but just rewind and we could reset all the + correct SHA1s for all of them. + + [_Lucas Seiki Oshiro_][seiki]: I don't remember something that I did, + but I remember a simple and curious disaster: our deploy workflows + stopped working, only leaving a message like "cannot fetch + ambiguous reference `master`". I decided to investigate what happened + and I found out that someone by mistake (I don't know how) created a + tag called `master` and pushed it to GitHub. By the time we used the + `master` branch for deploy, and the workflows didn't know if they + should use the `master` branch or tag. GitHub didn't have a feature + for deleting tags through the web interface, so we thought + "what should we do?". + + The solution was to run `git push origin :refs/tags/master`. Simple, + but not obvious. A classic case where it only required a screw to be + turned, but all the hard work was to find which screw should be turned. + + [_Elijah Newren_][elijah]: + My worst Git-related disaster wasn't with Git directly but with our + Git hosting software we used at a prior job, Gerrit. 'twas a + "startup" that was still forming good practices. We had both a + production and a staging instance. The staging instance was seeded + with a copy of production data so we could do scale testing...but that + seeding process was a multi-step manual thing; it hadn't been + automated. One step was, as best I recall, "drop database gerrit", + followed by loading the production copy of the mysql database (this + was long before [NoteDB][notedb] arrived). And as many readers + probably have guessed by now, I was on the wrong host one day when + I ran that command. + + The actual git repositories were still intact, but the review metadata + was toast. Luckily, we had a backup from about 7 hours earlier, so we + could recover the older review metadata and with some hackery fix the + mysql metadata mismatch with the newer repository contents. And since + Gerrit emailed folks comments from reviews as they were posted, we + could tell people to look at their emails for the pieces we couldn't + recover. + + It was a really long night trying to fix things. Some folks told me + they thought I was going to throw up just looking at me. But I + learned how wonderful it was to be at a company with blameless + post-mortems, and I appreciated the many folks who reached out to tell + me stories of mistakes they had made. They were more interested in + whether we learned our lesson and put processes into place to prevent + repeats, and I definitely did both. + + I did, of course, also get some good-natured ribbing, such as people + saying I got to play the part of little Bobby Tables once (see + [this xkcd comic][bobby-tables] if you don't know that reference). + I kindly reminded them that I didn't drop a table -- I dropped the whole + database (plus, it wasn't injection, it was just running a command in + the wrong location). Also, one of my colleagues helpfully modified + the prompt on production to be red and bold, "This is PROD Gerrit", + and the prompt on staging to be green, "This is staging Gerrit; it's + okay to drop database here!" The prompts ended up not mattering since + I automated the process, and made sure the process just error'ed out + if run on prod instead of staging. But the prompt persisted for many + years anyway, because I thought it was a hilarious way to poke fun at + my blunder. + + +- **If you could go back in time and change one design decision in Git, + what would it be?** + + [_Luca Milanesio_][luca]: Use SHA-256 straight away, as it was + published 24 years ago and already existed at the time Git was designed. + + [_Lucas Seiki Oshiro_][seiki]: Perhaps writing a more abstract CLI. After + studying Git a little more deeper it makes sense for me, but I would group + the functionality into more high-level subcommands and would make the flags + and options more consistent across the subcommands. + + For example, Docker CLI have all the image operations under + `docker image` and all the network operations under `docker network`. + If I want to delete an image, I use `docker image rm`, if I want to + delete a network, I use `docker network rm`, and so on. I would make + Git CLI work based on that idea, for example: + + - `git branch add my_branch` + - `git branch delete my_branch` + - `git branch list` + - `git remote add my_remote ...` + - `git remote delete my_remote` + - `git remote list` + - `git tag add my_tag` + - `git tag delete my_tag` + - `git tag list` + + With some shorter alias, just like Docker has `docker rmi` and + `docker rm`. + + [_Elijah Newren_][elijah]: The index. For a few reasons. + + 1. Performance. + 1. The index is pervasive throughout the codebase, and while it works + great for small repositories, it means that many operations are O(size + of repository) instead of O(size of changes). [sparse indices][sparse-index] + help, but the code has to be carefully audited for sparse indices to + work with each codepath, and even then there tends to be a fallback of + just-load-everything-anyway because the data structure doesn't lend + nicely to just expanding a little more. + + 2. An under-appreciated aspect of the performance improvements that + came from our new merge strategy, [`merge-ort`][merge-ort], were due + to dispensing with the index as the primary data structure. The index + had two problems: + 1. first of all it meant loading every path in the repository, + which would have prevented ort's optimization to avoid recursing into + subtrees when unnecessary (an optimization that often made merges e.g. + 50x faster). Sparse indices didn't exist back then, but even if they + had we would have had to complicate them significantly in order to + have their sparseness be determined by renames and the intersection of + modified paths on the two sides of history instead of having + sparseness determined by user-defined path rules; I think that'd have + been much more complicated than just dispensing with the index as the + data structure, but we didn't even have sparse indices back then + anyway. + + 2. Second, the use of the index as done in the old merge strategy, + `merge-recursive`, resulted in O(N^2) behavior since entries (including + conflicted higher order stages) had to be inserted in sorted order. + Deleting entries didn't have the same O(N^2) problem due to some + tricks to queue the deletion for later, but attempting to do the same + for insertions was far from straightforward and I believe would have + required making some other data structure primary and then forming the + index at the end. (Note that the primary data structure used, whatever + it is, cannot just have a list of things to insert, it also needs to + be checked for various properties intermingled with insertions...and + those sometimes relied on the fact that the index was sorted for quick + lookups.)

+ (Note that a tree-structured index rather than a linear index would + resolve these problems. But retrofitting the entire codebase is + probably never going to happen...) + + 2. Cognitive Complexity.
The funny thing is, although I say this, + I use the index all the time. I use `git add -p` a lot. I very much + need to slice and dice my changes into different commits, and tend to + have dirty changes that I don't want pushed.

+ But slicing and dicing before things are committed, as opposed to + being able to slice and dice after, is a choice that adds a lot of + complexity to the user interface and does so even for users who aren't + interested in slicing and dicing commits. We don't have a + sufficiently flexible set of tooling for slicing and dicing commits + after-the-fact within git to switch to a post-commit-slice-and-dice + workflow even today, but I suspect that some of the ideas from [JJ][jujutsu] + would or could be much better than the methods I use today in git to + slice and dice commits. + + +- **Which Git feature or improvement over the past 20 years do you think + had the biggest impact on your workflow?** + + [_Lucas Seiki Oshiro_][seiki]: Sorry, but I can't answer. I am from a + generation that started programming when Git was already the de facto + VCS so I can't compare a world that has it with a world that doesn't have. + + [_Elijah Newren_][elijah]: Speed. + + Being able to instantly switch branches (in smaller repos, sure, but + CVS and SVN couldn't pull it off even in small repos) was a game + changer. + + +- **What Git problem that existed 10 years ago has been most + successfully solved?** + + [_Lucas Seiki Oshiro_][seiki]: Sorry again, but 10 years ago I was only + starting to use Git and when I started to use more complex features they + already were there. + + [_Elijah Newren_][elijah]: Merging and rebasing with lots of renames + (and generally merging without a worktree or index). I'm obviously + a bit biased on this point, but that doesn't mean I'm wrong. ;-) + It used to be awful and works great now. + + Relatedly, merging without a worktree or index was problematic; you + had to either use an alternative merge strategy with limited + capabilities, or use something other than git (e.g. [libgit2][libgit2]). + But now git handles it well with its default merge strategy. + + +- **Which Git commands or workflows do you think are still misunderstood + or underutilized today?** + + [_Lucas Seiki Oshiro_][seiki]: I think [squash merges][squash-merge] and + [submodules][submodule] are really misunderstood, yet they are the opposite + of being underutilized. Sadly I saw several people using them in daily basis, + based on the wrong idea of what they are and then using them incorrectly. + + + What I think is underutilized is the full power of commits being + a good source of documentation and good resource for, again, performing + code archaeology that may help understanding what the code does and + debugging it. Several developers treat the commits as just checkpoints. + + [_Elijah Newren_][elijah]: `range-diff` is very under-utilized, but I + already discussed that above. + + +- **What's one Git based project, tool, or extension you think deserves + more recognition from the community?** + + [_Lucas Seiki Oshiro_][seiki]: Perhaps it would be better to leave this + question for other less known tools. But if you want an answer, I think: + + - [Delta](https://github.com/dandavison/delta) is a really cool tool + for formatting the diff-related outputs; + + - [Kworkflow](https://kworkflow.org/) is a powerful tool for + contributing to the Linux kernel source code (I should also + try it for contributing to the Git source code); + + - Merge drivers in general. `diff3` works in most cases but it is + only based on pure diffs, without performing deeper operations based + on the file format they are merging. + + +- **What Git feature or capability surprised you most when you first + discovered it?** + + [_Lucas Seiki Oshiro_][seiki]: As you may have noticed, I'm really + a fan of Git archaeology :-), so I would say all that I mentioned + in the first answer (i.e., `git grep`, `git log -S/-G`, `git log -L` + and `git bisect`). But my favorite is still [bisect][bisect]. + It's an egg of Columbus and everyone that I have shown it to + was equally amazed by it! + + +- **What's your boldest prediction about how version control might look + in another 20 years?** + + [_Lucas Seiki Oshiro_][seiki]: I still see Git as the dominant VCS + in the future, but I think more Git-based VCSs (like [Jujutsu][jujutsu] + will arise. Just like we have today programming languages built on top + of the stack of the other languages (e.g. Clojure, Kotlin and Scala on + JVM, TypeScript on JS), networking protocols written on top of other + protocols (e.g. QUIC on UDP, gRPC on HTTP) and so on. + + The Git core is simple, flexible, transparent and powerful and there's + still room for people using it directly in several creative ways. Once + I saw [a project using it as a backend for a NoSQL database][git-backend-nosql], + who knows how many use cases we still have for it. + + [_Elijah Newren_][elijah]: I'm more interested in what storms might be + brewing along that path, and what we might be able to do to avoid them. + In particular, some questions and observations in that area: + + * With monorepos growing ever larger, do we have hard-to-workaround-or-fix + design decisions that pose scaling challenges? e.g. + * the index data structure + * per-directory .gitignore files, per-directory .gitattribute files, etc. + * ...or do the prominent Git forges have hard-to-workaround-or-fix + design decisions that'll give Git a reputation for not scaling? e.g. + * making refs/pull/NNN/merge a public ref and excessively + implicitly updating it + * Will we face a crisis of interest? e.g. + * `git` is currently written in C. Even if that's not a liability + already, coupled with "decades" I think it is. Young developers + probably don't want to learn C, and older ones who already know C + may worry about C becoming a Fortran or Cobol. + * Companies employing Git developers think "git already won" and + redeploy those engineers on other problems + * Will the combination of issues above result in folks who want improvements + deciding their best bet is not improving Git but in creating/funding + an alternative? Will that snowball? + +
+ To me, the entry of new projects like [JJ][jujutsu] and [sapling][sapling] + suggest the above are real concerns already rather than just theoretical. + Both projects have compelling things that git lacks. I like the friendly + competition, and the JJ and sapling developers are awesome to talk to + at Git Merge conferences. But there is a risk that this friendly + competition mirrors that of Git and Mercurial from years past, and + that Git at some future point down the road ends up on the other side + of that history and gets largely displaced by the alternatives. I'd + rather not see that happen, but I sometimes wonder if we're taking + enough measures to avoid marching towards such an outcome. + + +[thalia]: https://discord.com/channels/1042895022950994071/1361310935427584213/1361316878819131452 +[luca]: https://public-inbox.org/git/04A328E9-1146-4D4A-84E7-456FFEB66A5A@gmail.com/ +[seiki]: https://public-inbox.org/git/AE27429C-97B1-4226-8F30-5B635A050498@gmail.com/ +[elijah]: https://public-inbox.org/git/CABPp-BH2yH4iJ28Bo7Q=uryu68LLk7a0Tvb2SzAbAiHK8QpRug@mail.gmail.com/ +[squash-merge]: https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---squash +[submodule]: https://git-scm.com/docs/git-submodule +[bisect]: https://git-scm.com/docs/git-bisect +[range-diff]: https://git-scm.com/docs/git-range-diff +[sparse-index]: https://git-scm.com/docs/sparse-index +[merge-ort]: https://git-scm.com/docs/merge-strategies#Documentation/merge-strategies.txt-ort +[jujutsu]: https://github.com/jj-vcs/jj?tab=readme-ov-file#introduction +[git-backend-nosql]: https://www.kenneth-truyers.net/2016/10/13/git-nosql-database +[notedb]: https://www.gerritcodereview.com/notedb.html +[bobby-tables]: https://xkcd.com/327/ +[libgit2]: https://libgit2.org/ +[sapling]: https://sapling-scm.com/ + + +### Short Q&A with our maintainer, Junio C Hamano + +- **Looking back over ~20 years of maintaining Git, what has been the + most surprising or unexpected evolution in the project — technically + or community-wise?** + + Technically, one of the things I found surprising is how many lines + from Linus's original version still survive in today's codebase. The + [initial version of Git](https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290) + was 1244 lines spread across 11 files, which is miniscule compared + to 300+ thousands of lines in 4600+ files in v2.49.0, but it is not + fair to say Linus's original genius is less than 0.3% of what we have. + If you try running `git blame` in reverse, you'll see that about 10% + of lines we have in our tree came from the original version Linus + released 20 years ago. You can check out a + [little script called "Linus"](https://git.kernel.org/pub/scm/git/git.git/tree/Linus?h=todo) + out of my "todo" branch and run it to see for yourself. + + Community-wise, there weren't many things that surprised me. I + expected a bit more developers who are interested in the core part of + system to stick around, say for more than 10 years, and I hoped that + some of them would be from younger generations who have never seen any + version control system other than Git, but how many among the active + contributors we see on the list every week fall into that category? We + have long-timers who are respected in the community, but we want to + grow that pool by say 5 every year or so, some of them ready to stick + around for another 10 years. In [a recent interview](https://github.blog/open-source/git/git-turns-20-a-qa-with-linus-torvalds/), + Linus said he wanted somebody with good taste who sticks around, and + I do believe it is essential to have a sufficient number of long-timers + who can guide new folks into the community. + + So that is a bit of surprise that makes me a little sad, but at the + same time, I think what is happening is that a development community + of an extremely popular and successful system that is mature with + friendly atmosphere has attracted many aspiring new folks, they + scratch their own itches and have fun, but then they find more + interesting things to do and go back to be happy end-users, which is + totally expected and natural thing. + +- **What are your thoughts about AI-assisted development tools in the + context of Git? Do you see a place for Git itself to become more + "intelligent"?** + + I've kept saying that + + is one of the most important design discussion in the early days of + Git. In that article, Linus outlines how his "ideal" SCM tool would + let you follow the history of a single function in today's codebase + backwards, notice that at certain revision the function appeared, but + the tool finds five functions disappeared in the same revision, all + looking very similar to the function we are interested in that was + added there, and the tool can explain that the commit consolidated + duplicated reimplementations done in various subdirectories into a + single common function and adjusted the existing callers of them to + the SCM user (if you want to learn more details, go to the original + and read it twice, I'll wait). + + We can do `git log -S` repeatedly to drill + down the history to find the revision that introduced that new + (possibly consolidated) function. In fact, the `-S` feature + was invented exactly for the purpose of serving as the first step of + Linus's "ideal" SCM tool described in the article. But "finding + similar existing (and possibly getting lost) code in the same or + possibly nearby revisions" have been nebulous. I do not think anybody + in the Git circle tried it yet. I wonder, after 20 years, perhaps we + can feed a project's codebase to LLMs and let them figure out such a + fact? + +- **What's your boldest prediction about how version control might look in + another 20 years?** + + I do not even foresee what software development in 20 years would look + like. I am not an insight kind of person. + +- **What advice would you give to someone who might one day step into your + role as Git maintainer?** + + Be original. I didn't aim to duplicate the style Linus ran his tree + during the first four months of the project. My successor does not + have to duplicate my style of running the project, either. Having said + that, personally I would like to see more distribution of + responsibility. The maintainer may play a role of the final arbiter, + but it would be great if we can come up with a mechanism to allow list + participants to bear more of the burden of picking and choosing good + direction to go, deciding if a particular change is worth doing or + are there better ways to do the same thing, etc. I've been trying to + nudge the list discussions in that direction for the past few years, + but without much success, I think. + + +## Other News + +__Various__ + +* [Git turns 20: A Q&A with Linus Torvalds](https://github.blog/open-source/git/git-turns-20-a-qa-with-linus-torvalds/) + by Taylor Blau on GitHub blog. +* [Celebrating Git's 20th anniversary with creator Linus Torvalds](https://about.gitlab.com/blog/2025/04/07/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/) + by Patrick Steinhardt on GitLab blog. +* [Linus Torvalds built Git in 10 days - and never imagined it would last 20 years](https://www.zdnet.com/article/linus-torvalds-built-git-in-10-days-and-never-imagined-it-would-last-20-years/) + by Steven Vaughan-Nichols on ZDNet. +* [20 years of Git. Still weird, still wonderful.](https://blog.gitbutler.com/20-years-of-git/) + by Scott Chacon on Butler's Log (GitButler). +* [Journey through Git's 20-year history](https://about.gitlab.com/blog/2025/04/14/journey-through-gits-20-year-history/) + by Patrick Steinhardt on GitLab blog. +* [GitHub MCP Server is now available in public preview](https://github.blog/changelog/2025-04-04-github-mcp-server-public-preview/). + [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction) + is an AI tool calling standard that gives LLMs (Large Language Models) + a standardized way to call functions, look up data, and interact with the world. + + +__Light reading__ + +* [Verifying tricky git rebases with git range-diff](https://andrewlock.net/verifiying-tricky-git-rebases-with-range-diffs/) + by Andrew Lock on his .NET Escapades blog. +* [Mirroring my git repositories](https://dustri.org/b/mirroring-my-git-repositories.html) + using [cgit](https://git.zx2c4.com/cgit/about/) for the interface and nginx as a web server. + By Julien (jvoisin) Voisin on their blog. +* [Mirroring my Repositories from GitHub to GitLab](https://cleberg.net/blog/git-mirror.html), + including both public and private repositories on GitLab Free tier. + By Christian Cleberg on his blog. +* [Documentation as Code with AsciiDoctor, GitLab CI, and GitLab Pages](https://jensknipper.de/blog/gitlab-ci-pages-asciidoc-documentation-as-code/) + by Jens Knipper on his personal blog. +* [Afraid to Git](https://dammit.nl/afraid-to-git.html): + a rant by Michiel Scholten on his dammIT blog, explaining how misbehaving AI scrapers + cause him not to put his Gitea instance (his Git server) on the Internet, + and force others - like [Linux' kernel.org](https://git.kernel.org/) - to use tools like [Anubis](https://github.com/TecharoHQ/anubis). +* [Fedora change aims for 99% package reproducibility](https://lwn.net/Articles/1014979/) + by Joe Brockmeier on LWN\.net. +* [How to Exclude Commits from Git Blame](https://www.git-tower.com/blog/how-to-exclude-commits-from-git-blame) by Bruno Brito on Tower's blog. + + +__Easy watching__ + +* [Two decades of Git: A conversation with creator Linus Torvalds](https://www.youtube.com/watch?v=sCr_gb8rdEI) + video interview (YouTube, 41:49). + + +__Git tools and sites__ + +* [Devlands](https://devlands.com/) is the game that creates immersive experience + to help learning Git. Created by Jacob Stopak, the author of the [Git-Sim](https://github.com/initialcommit-com/git-sim) + tool to visualize Git commands directly in your own repo, which was first mentioned + in [Git Rev News Edition #95](https://git.github.io/rev_news/2023/01/31/edition-95/). + Described in [I struggled with Git, so I'm making a game to spare others the pain](https://initialcommit.com/blog/im-making-a-git-game) + article on Initial Commit Blog. +* [Git Game Show](https://justinpaulson.github.io/git_game_show/) is a text interface app + that transforms your project's Git commit history into a live, multiplayer trivia game. + One user hosts a session, other players join remotely, and the system rotates + through rounds of different question-based "mini-games," awarding points + and declaring a final winner. +* [dgit](https://manpages.debian.org/testing/dgit/dgit.1.en.html) is a tool that + allows you to treat the Debian archive as if it was a Git repository. + Conversely, it allows Debian to publish the source of its packages as Git branches, + in a format which is directly useable by ordinary people. + * Note that GitHub's Spokes system that stores multiple distributed copies + of Git repositories was once called DGit. See the [Stretching Spokes](https://github.blog/engineering/infrastructure/stretching-spokes/) + article by Michael Haggerty on GitHub Blog mentioned in + [Git Rev News Edition #14](https://git.github.io/rev_news/2016/04/20/edition-14/). +* [Mega](https://github.com/web3infra-foundation/mega) + is an unofficial open source implementation of Google Piper (a proprietary, massive, + centralized version control system that Google uses internally to manage their vast codebase). + It is a monorepo & monolithic codebase management system that supports Git. + More information can be found in [Why Google Stores Billions of Lines of Code in a Single Repository](https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext). + Written in Rust and TypeScript. +* [Oshit aka Oshiro's git](https://github.com/lucasoshiro/oshit): VCS written in Haskell + that tries to be compatible with Git. This is not safe to use, + and is only meant for learning how Git works and how hard it is. +* [codeowner-filter](https://kertal.github.io/codeowner-filter/) is a simple web tool + that solves the problem of finding just the files your team owns based + on the contents of [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) file. + It will generate search filters for VSCode, scope configuration for IDEA IDEs, and a list. +* [CodeOwners Filter](https://github.com/akowalska622/codeowners-filter) is a Visual Studio Code extension + that gives you a visual representation of the CODEOWNERS file + and helps you generate glob include patterns for any code owner. +* [rebuilderd](https://github.com/kpcyrd/rebuilderd) + is a tool that monitors the package repository + of a Linux distribution and uses rebuilder backends + like archlinux-repro to verify the provided binary packages + can be reproduced from the given source code. + Written in Rust, under GPL license. +* [reproduce](https://github.com/vltpkg/reproduce) is an open-source tool + designed to independently verify whether a published npm package + can be faithfully rebuilt from its declared source. + It is described in the [Reproducibility vs. Provenance: Trusting the JavaScript Supply Chain](https://blog.vlt.sh/blog/reproducibility) + blog post by Darcy Clarke. +* [Graft](https://graft.rs/) is an open-source transactional storage engine + designed for efficient data synchronization at the edge. + It is described in the [Stop syncing everything](https://sqlsync.dev/posts/stop-syncing-everything/) + article by Carl Sverre, his [Storing small things in big places](https://www.youtube.com/watch?v=eRsD8uSAi0s1) + Vancouver Systems talk (video on YouTube, 55:04), and his + [Building a serverless database replica with Carl Sverre](https://www.youtube.com/watch?v=dJurdmhPLH411) + High Performance SQLite talk (video on YouTube, 1:10:19). + Written in Rust. + + +## Releases + ++ GitHub Enterprise [3.16.2](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.2), +[3.15.6](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.6), +[3.14.11](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.11), +[3.13.14](https://docs.github.com/enterprise-server@3.13/admin/release-notes#3.13.14) ++ GitLab [17.11.1, 17.10.5, 17.9.7](https://about.gitlab.com/releases/2025/04/23/patch-release-gitlab-17-11-1-released/), +[17.11](https://about.gitlab.com/releases/2025/04/17/gitlab-17-11-released/), +[17.10.4, 17.9.6, 17.8.7](https://about.gitlab.com/releases/2025/04/09/patch-release-gitlab-17-10-4-released/), +[17.10.3](https://about.gitlab.com/releases/2025/04/02/gitlab-17-10-3-released/), +[17.9.5](https://about.gitlab.com/releases/2025/04/02/gitlab-17-9-5-released/) ++ Gerrit Code Review [3.12.0-rc0](https://www.gerritcodereview.com/3.12.html#3120), +[3.12.0-rc1](https://www.gerritcodereview.com/3.12.html#3120), +[3.12.0-rc2](https://www.gerritcodereview.com/3.12.html#3120), +[3.12.0-rc3](https://www.gerritcodereview.com/3.12.html#3120), +[3.12.0-rc4](https://www.gerritcodereview.com/3.12.html#3120) ++ GitHub Desktop [3.4.19](https://desktop.github.com/release-notes/) ++ GitButler [0.14.19](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.19), +[0.14.18](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.18) ++ Tower for Mac [13.0 (BETA)](https://www.git-tower.com/beta) ([Release blog post](https://www.git-tower.com/blog/tower-mac-13/)) + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Junio Hamano, Lucas Seiki Oshiro, +Luca Milanesio, Thalia Rose, Elijah Newren, +Toon Claes, Lee Reilly, Bruno Brito and Štěpán Němec. diff --git a/_posts/2025-05-31-edition-123.markdown b/_posts/2025-05-31-edition-123.markdown new file mode 100644 index 0000000000..96e3cd14cc --- /dev/null +++ b/_posts/2025-05-31-edition-123.markdown @@ -0,0 +1,268 @@ +--- +title: Git Rev News Edition 123 (May 31st, 2025) +layout: default +date: 2025-05-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 123 (May 31st, 2025) + +Welcome to the 123rd 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 April and May 2025. + +## Discussions + +### General + +* [[GSoC] Welcoming our 2025 contributors and thanking our applicants](https://lore.kernel.org/git/A2C60325-F96A-49FC-8910-035BFC209EB5@gmail.com/) + + The Git project was accepted in the + [Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/) + this year again, and 3 applicants were selected: + + - Meet Soni will work on + [the "Consolidate ref-related functionality into git-refs" project](https://summerofcode.withgoogle.com/programs/2025/projects/xVrT5e2q) + mentored by Patrick Steinhardt and Jialuo She. See Meet's + [blog](https://inosmeet.github.io/posts/) and + [repository](https://github.com/inosmeet/git) for more. + + - Lucas Seiki Oshiro will work on + [the "Machine-Readable Repository Information Query Tool" project](https://summerofcode.withgoogle.com/programs/2025/projects/fGgMYHwl) + mentored by Karthik Nayak and Patrick + Steinhardt. See Lucas's [blog](https://lucasoshiro.github.io/en/) + and [repository](https://github.com/lucasoshiro/git) for more. + + - Ayush Chandekar will work on + [the "Refactoring in order to reduce Git’s global state" project](https://summerofcode.withgoogle.com/programs/2025/projects/no7dVMeG) + mentored by Christian Couder and Ghanshyam Thakkar. See Ayush's + [blog](https://ayu-ch.github.io/archive.html) and + [repository](https://github.com/ayu-ch/git) for more. + +### Reviews + +* [[PATCH] git: add `--no-hooks` global option](https://lore.kernel.org/git/pull.1899.git.1743719888430.gitgitgadget@gmail.com/) + + Derrick Stolee, who prefers to be called just Stolee, sent a patch + to the mailing list that added a new `--no-hooks` global option and + an equivalent `GIT_HOOKS` environment variable to Git. The goal was + to allow users to disable all Git hooks during command execution. + + This could be useful for expert users who would want to bypass + pre-commit hooks when they have poor performance or perform useless + checks. + + Switching between enabled and disabled hooks and other workarounds, + like setting `core.hooksPath` to a "bogus path", did not look + convenient and very safe. + + brian m. carlson, who spell their name using only lowercase letters, + replied to Stolee acknowledging the need for this functionality as + some Jenkins users already set `core.hooksPath` to `/dev/null` for + security reasons. They warned that disabling hooks could break + [Git LFS](https://git-lfs.com/) in a way that is "less noticeable + and detectable" than the current `/dev/null` approach. + + They agreed that certain hooks like pre-commit hooks should be + optional, for example to make it easy to commit some + work-in-progress that doesn't meet standards, but saw fewer reasons + to bypass hooks that could be important for repository integrity. + + Stolee agreed that some hooks are important for integrity, but said + his intention was on the side of optional hooks. + + Phillip Wood also replied to Stolee's initial email noting that + there is already `git commit --no-verify` which bypasses the + pre-commit and commit-msg hooks. He argued that hooks so slow that + users want to bypass them are self-defeating and that the solution + should be to fix the hook's performance rather than make it easier + to skip. About setting `core.hooksPath` to `/dev/null`, he asked why + it could be unsafe. In general he said he wasn't convinced that + `--no-hooks` was a good idea, and later asked for "a clearer + motivation" to better understand its usefulness. + + Stolee agreed that setting `core.hooksPath` to `/dev/null` was safe, + and said he had forgotten that could be used instead of a bogus + path. + + Junio Hamano, the Git maintainer, then replied to Phillip thanking + him for pushing back on the idea, and saying that there should be a + "compelling reason" to justify a change. + + Also instead of implementing options to disable hooks or + configuration in some user facing "porcelain" commands, Junio + advocated for cleaning up and refactoring these commands into new + stable "plumbing" commands designed to be easily used in scripts. + + In the meantime, Lucas Seiki Oshiro replied to Phillip. Lucas had + noticed that using `/dev/null` to disable hooks wasn't mentioned in + the documentation of `core.hooksPath`, even though it was tested in a + test script. He asked if Stolee's patch should therefore be turned + into a documentation patch. + + brian agreed with Lucas that documenting how to disable hooks was a + good idea even if the `--no-hooks` option wasn't implemented. + + D. Ben Knoble also replied to Stolee's initial patch. He supported + the addition of the `--no-hooks` option, sharing his own + frustrations with poorly performing or difficult-to-manage hooks. He + described how a tool re-enables hooks after every `npm install` + leading him to overuse `--no-verify`, which he considered a worse + situation. He believed there should be a safe and sane way to + disable optional client-side hooks and felt that a `--no-hooks` + option would be useful, potentially encouraging better practices + like moving certain checks to server-side hooks. + + Stolee then replied to Junio thanking him for deciding about this + and saying he would follow up with a version 2 of his patch that + would only document that setting `core.hooksPath` to `/dev/null` was + the supported mechanism to disable hooks. + + In [the version 2 of his patch](https://lore.kernel.org/git/pull.1899.v2.git.1744818135435.gitgitgadget@gmail.com/), + Stolee just updated the documentation of the `core.hooksPath` + configuration option, adding the following small paragraph: + + > You can also disable all hooks entirely by setting `core.hooksPath` + > to `/dev/null`. This is usually only advisable for expert users and + > on a per-command basis using configuration parameters of the form + > `git -c core.hooksPath=/dev/null ...`. + + Lucas replied to that new patch. He suggested rewording the + documentation to focus on non-expert users rather than + experts. Stolee disagreed, explaining he intentionally targeted + expert users as a "there be dragons here" warning about the risks of + disabling hooks. + + brian supported Stolee's approach, agreeing that this feature should + be presented as expert-only due to the potential for data loss (like + missing Git LFS uploads). He appreciated Stolee's gracious pivot + from code changes to documentation. + + Junio also thanked Stolee for gracefully changing direction and + ensuring no loose ends were left after abandoning the original + approach. + + + + + +## Other News + + + + +__Light reading__ + ++ [What I've learned from jj (Jujutsu)](https://zerowidth.com/2025/what-ive-learned-from-jj/) + by Nathan Witmer on zerowidth positive lookahead blog.
+ [Jujutsu](https://jj-vcs.github.io/) (`jj`) is an experimental Git-compatible DVCS, + first mentioned in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [Git aliases](https://heitorpb.github.io/bla/git-aliases/) + by Heitor de Bittencourt on Heitor's Log blog, + which includes comparison with shell aliases, + and is only missing the trick to set `git` completion for the `!` alias. ++ [Pushing a whole stack of branches with a single Git command](https://andrewlock.net/pushing-a-whole-stack-of-branches-with-a-single-git-command/) + (with the help of git aliases) + by Andrew Lock on .NET Escapades. ++ [Tally All Git Trailers in a Repository](https://calebhearth.com/tally-git-trailers.page), + with a list of interesting and useful trailers _(with many links)_, + by Caleb Hearth on his blog. ++ [You can use Git to version control your notes, and here’s how I do it](https://www.xda-developers.com/you-can-use-git-to-version-control-your-notes/) + by Ayush Pande on XDA Developers + (with Joplin as an example of a note-taking application one can use with Git). ++ [A Short Guide on Git for Vibe Coders](https://anfalmushtaq.com/articles/a-short-guide-on-git-for-vibe-coders) + by Anfal Mushtaq on his blog. ++ [Version Control To The Max](https://hackaday.com/2025/05/14/version-control-to-the-max/) + by Al Williams on Hackaday, + about backing up the entire development environment + (with QEMU or VirtualBox or VMWare). ++ [Converting a Git repo from tabs to spaces](https://eev.ee/blog/2016/06/04/converting-a-git-repo-from-tabs-to-spaces/) + with the help of the "filter" gitattribute and the `expand` tool (part of the _coreutils_), + by Eevee on Fuzzy Notepad blog (2016). ++ [How the GitHub CLI can now enable triangular workflows](https://github.blog/open-source/git/how-the-github-cli-can-now-enable-triangular-workflows/) + by Tyler McGoffin on GitHub Blog. ++ [Using `git-upload-pack` for a simpler CI integration](https://blog.screenshotbot.io/2025/05/09/using-git-upload-pack-for-a-simpler-ci-integration/), + on how Screenshotbot can now extract commit graph data from remote repositories + (assuming one has SSH access to their Git repositories), + by Arnold Noronha on Screenshotbot Blog. ++ [Fixing SSH Conflicts: Using a Separate SSH Key for GitHub](https://dev.to/hastycodea/fixing-ssh-conflicts-using-a-separate-ssh-key-for-github-4in1) + by Hastycode Andreh on DEV\.to. + One trick to add is the possible use of `url..insteadOf`. ++ [The reductionist theory or rethinking of .gitignore bloat](https://dev.to/iegik/the-reductionist-theory-or-rethinking-of-gitignore-bloat-4gfo) + by Arturs Jansons on DEV\.to. + Mentions [gitignore.io](https://www.gitignore.io/), + first mentioned in passing in [Git Rev News Edition #6](https://git.github.io/rev_news/2015/08/05/edition-6/), + then linked to (with new final URL) in [Git Rev News Edition #94](https://git.github.io/rev_news/2022/12/31/edition-94/), + and [github/gitignore](https://github.com/github/gitignore) - which was + first mentioned in passing in [Git Rev News Edition #21](https://git.github.io/rev_news/2016/11/16/edition-21/), + then also linked to in [Edition #94](https://git.github.io/rev_news/2022/12/31/edition-94/), + + + + +__Git tools and sites__ + ++ [A modern theme for cgit](https://yingtongli.me/blog/2025/05/16/cgit.html) + by Lee Yingtong Li on Inane Observations blog. + The source code for this themed fork of [cgit](https://git.zx2c4.com/cgit/tree/README) + is available at . + Under GPL v2 license. ++ [AutoGit-o-Matic](https://github.com/FPGArtktic/AutoGit-o-Matic) is a Bash script + that automates Git operations across multiple repositories. It helps you + pull or fetch updates from multiple repositories with a single command + (with dry-run capability), + scans directories for Git repositories automatically, + logs operations in both TXT and JSON formats, + and is configurable via an INI file. + Under GPL-3.0 license. ++ [StatsCat](https://github.com/z1cheng/statscat) is a CLI tool + to get per-author and per-directory statistics of all your Git repositories. + Written in Go, under MIT license. + + +## Releases + ++ Git [2.50.0-rc0](https://public-inbox.org/git/xmqqzfewsml1.fsf@gitster.g/) ++ GitLab [18.0.1, 17.11.3, 17.10.7](https://about.gitlab.com/releases/2025/05/21/patch-release-gitlab-18-0-1-released/), +[18.0](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/), +[17.11.2, 17.10.6, 17.9.8](https://about.gitlab.com/releases/2025/05/07/patch-release-gitlab-17-11-2-released/) ++ Gerrit Code Review [3.10.6](https://www.gerritcodereview.com/3.10.html#3106), +[3.11.3](https://www.gerritcodereview.com/3.11.html#3113), +[3.12.0-rc5](https://www.gerritcodereview.com/3.12.html#3120), +[3.12.0-rc6](https://www.gerritcodereview.com/3.12.html#3120), +[3.12.0](https://www.gerritcodereview.com/3.12.html#3120), +[3.9.11](https://www.gerritcodereview.com/3.9.html#3911) ++ GitHub Enterprise [3.16.3](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.3), +[3.15.7](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.7), +[3.14.12](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.12), +[3.13.15](https://docs.github.com/enterprise-server@3.13/admin/release-notes#3.13.15), +[3.17.0](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.0) ++ GitKraken [11.1.1](https://help.gitkraken.com/gitkraken-client/current/), +[11.1.0](https://help.gitkraken.com/gitkraken-client/current/), +[11.0.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.20](https://desktop.github.com/release-notes/) ++ Garden [2.2.0](https://github.com/garden-rs/garden/releases/tag/v2.2.0) ++ Git Cola [4.13.0](https://github.com/git-cola/git-cola/releases/tag/v4.13.0) ++ GitButler [0.14.26](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.26), +[0.14.25](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.25) ++ git-credential-oauth [0.15.1](https://github.com/hickford/git-credential-oauth/releases/tag/v0.15.1) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <>. diff --git a/_posts/2025-06-30-edition-124.markdown b/_posts/2025-06-30-edition-124.markdown new file mode 100644 index 0000000000..3c89f84733 --- /dev/null +++ b/_posts/2025-06-30-edition-124.markdown @@ -0,0 +1,690 @@ +--- +title: Git Rev News Edition 124 (June 30th, 2025) +layout: default +date: 2025-06-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 124 (June 30th, 2025) + +Welcome to the 124th 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 May and June 2025. + +## Discussions + + + + + +### Support + +* [[BUG] `git stash` incorrectly showing submodule branch instead of superproject branch](https://lore.kernel.org/git/TO1PPF29324B4CE6D3518208073452C3C51CD97A@TO1PPF29324B4CE.CANPRD01.PROD.OUTLOOK.COM/) + + Stuart MacDonald sent a bug report to the mailing list. The report + described a workflow where people worked on a UI project that + included a hardware SDK as a submodule. Both the UI project (the + "superproject") and the SDK project (the submodule) had their own + branches. + + When using `git stash` on a bug fix branch on the superproject, + while the submodule was on a feature branch, it appeared that the + command `git stash list` output a message, like: + + `stash@{0}: On feature_sdk_foo: debugging` + + indicating the stash had been created on the submodule's branch + instead of the superproject's branch. The branch `feature_sdk_foo` + didn't even exist in the superproject. + + Stuart mentioned he thought this used to work correctly around 2021, + though he wasn't 100% certain. + + K Jayatheerth replied to Stuart confirming the bug happened on + different OSes, showing minimal steps to reproduce it, and saying it + was "one of the most interesting Git bugs" he had seen in a while. + + Jayatheerth came back later with + [a patch](https://lore.kernel.org/git/20250512164001.62065-1-jayatheerthkulkarni2005@gmail.com/) + that fixed the bug. It appeared that the branch name was obtained + via the `refs_resolve_ref_unsafe()` function, which returns a + pointer to a static buffer, but that static buffer was overwritten. + To fix this, the patch copied the branch name instead of pointing to + the static buffer. + + Stuart thanked Jayatheerth even though he couldn't rebuild Git with + the patch. + + Junio Hamano, the Git maintainer, replied to the patch with small + suggestions, while Eric Sunshine noted that the change should also + be accompanied by a new test. + + Jayatheerth replied to Eric and Junio saying he would fix the small + issues and add tests, which he later did in + [an updated patch](https://lore.kernel.org/git/20250608063537.233243-1-jayatheerthkulkarni2005@gmail.com/). + + René Scharfe reviewed the updated patch and suggested a number of + improvements to the code and the test. + + Jayatheerth then sent + [a v2 of his patch](https://lore.kernel.org/git/20250608144542.275836-1-jayatheerthkulkarni2005@gmail.com/) + which addressed René's comments. Junio reviewed it and suggested + further improvements. + + [The v3 patch from Jayatheerth](https://lore.kernel.org/git/20250611014204.24994-1-jayatheerthkulkarni2005@gmail.com/) + addressed Junio's comments and was merged. + +## Community Spotlight: Luca Milanesio + +_Luca Milanesio is a long standing contributor to both JGit and Gerrit +Code Review, an open-source veteran who's been accelerating Application +Lifecycle workflows for 30+ years—from founding GerritHub.io to pioneering +AI-powered repository optimization research._ + +_This is a continuation of our initiative to interview community +contributors outside of our mailing list. Our previous interviews +were with [VonC in edition 106][vonc] and [Chris Torek in edition 120][torek]._ + +- **Who are you and what do you do?** + + My name is Luca Milanesio, and I am the CEO of GerritForge Inc., + a company I founded 6 years ago, which is fully dedicated to the + development and support of Git and the Gerrit Code Review ecosystem + for medium and large enterprises around the globe. + + I am a passionate Open-Source contributor, and I have helped many + projects grow over my 30+ years of software development career, + including Jenkins, JGit, GitBlit, Swagger/Open-API, Kibana, Avro, + and Gerrit Code Review. + + I am a maintainer and release manager of Gerrit Code Review, a + member of its Engineering Steering Committee, and committer of the + JGit project. + + I introduced GerritHub.io 11 years ago, a free Gerrit Code Review + service for all public and private projects on GitHub. It has over + 50k subscribers and is currently used by over 300 organisations and + open-source projects worldwide. + + My latest work is research about using AI, specifically reinforcement + learning, to dynamically understand and learn how Git repository metrics + evolve and execute actions to improve their performance by up to 100x. + The research has been selected for the 50th edition of the [IEEE/ACM + International Conference on Software Engineering in Ottawa (CA)][3]. + +- **What would you name your most important contribution to the Git ecosystem?** + + I have introduced a multi-site replication plugin between the Git + repositories managed by JGit and Gerrit Code Review [[ref][1]]. + + Google introduced the multi-site replication concept in JGit from + the very beginning in 2012, [with the introduction of DFS][2], a + multi-site distributed storage mechanism for Git. Although DFS was + a completely abstract interface layer that could have been + implemented on top of any distributed storage, in practice, it was + effectively implemented and used only by Google in its internal + implementation of JGit. + + In the meantime, the rest of the Open-Source community was left with + the traditional filesystem-based implementation and its extensions + to work effectively and efficiently with a shared filesystem (e.g., NFS). + I started using the NFS implementation of JGit on GerritHub.io and + contributed many patches and improvements over the years. Still, I + was soon hit with all the quirks and limitations of the NFS protocol + in trying to mock the “illusion” of a POSIX filesystem over a network + protocol, including locking, stale file handles, and caching + inconsistencies. After working for 4 years on the NFS implementation + of JGit on GerritHub.io on a shared filesystem, I forked the + [high-availability plugin project][4] and started the + [multi-site project][1], which has now entered its 6th year of adoption. + + Thanks to the multi-site support, anyone worldwide can use Git + replication across Gerrit primary nodes without fearing a + split-brain disaster, as it [historically happened years ago][5] + on a large-scale Git service. + +- **With over 30 years in software development, how have you seen version + control systems evolve, and what makes Git stand out in this evolution?** +` + I started using RCS on my Unix box for tracking the local version of files + and avoiding bad surprises, and since then I’ve seen so many so-called + revolutions of the version control that promised “the moon” but ended up + creating yet another commercial silo. To name a few, consider + [Rational ClearCase][clearcase] and [Perforce][perforce], and the legacy + they have made for the software industry. + + In my experience, version control is the foundation of any Software + Development Life Cycle (SDLC for short) and should always be thought of + as an evolving technology: I don’t believe that Git is here to stay + forever as-is, even though it would be difficult to imagine an + Open-Source project starting today not using Git as version control. + + But if you roll back to the year 2000, you could have swapped Microsoft + with VA Software and Git with Subversion, and asked the same question: + _`“What version control and hosting site should a new Open-Source project + use?”_ I believe the answer would differ significantly from the one you + have today [[ref][6]]. + + What makes Git different from its predecessors is its adoption in + large Open-Source projects unlikely to be discontinued any time soon, + such as Linux and the Android OS project. With the advent of IoT and + the extensive adoption of Android OS everywhere, from appliances to + aerospace and automotive, Git version control has become responsible + for powering the SDLC of most devices we use daily. + + A second factor that has brought Git to the world stage as the future + of VCS is its ability to abstract from any vendor bias and be truly + driven by only its user base: software developers. Git was invented + by Linus Torvalds because he needed it, not because a company X wanted + to disrupt the market of the existing version control system Y to + achieve goal Z. + + A third factor is the growth of other Git-compatible version control + systems, such as [JJ (aka Jujutsu)][7]. Git is, first of all, a data + format for versioned directories and BLOBs and a protocol on how this + data can be safely transferred between peers: no implementation-specific + quirks, no vendor lock-ins, no silos, just data and protocol. + This has led other developers, like [Martin Von Zweigbergk][martinvonz] + (Senior Software Engineer @Google), to create version control systems + on top of it, assuring interoperability with the existing code and + innovation simultaneously. + + This is unprecedented and unique in the history of VCSs I have seen + in my whole 30+ career as a Software Developer. Do I believe that + Git will continue to exist in its current form in 25 years from + now? No, I believe it will be very different in the future, but + its foundations will remain the same, and I see many more + evolutions similar to Martin’s JJ project. + +- **You've been working on comparing Git reftable implementations + with JGit alternatives. Could you walk us through what motivated + this research and preview any interesting findings you've + discovered?** + + Being the Gerrit Code Review release manager comes with many + responsibilities, including verifying that whatever we release + is production-ready and always better than what has ever been + released. That also includes, first and foremost, the Git + performance, following Shawn Pearce’s (Gerrit Code Review + project founder, R.I.P.) mantra, “performance is a feature.” + + We have been working in Q1 of 2025 to release and certify + [Gerrit v3.12][gerrit-3.12], which includes the latest and + greatest of JGit’s implementation of reftable, which was + available since 2019 but not used in Gerrit because of the + lack of support from the C Git project. Some parts of Gerrit + use the “C Git” implementation for some scripting side + and replication; therefore, a Git repository with reftable + would not have been compatible with Gerrit until Git v2.45, + which was [released last year][8]. + + In February 2024, at the time of the release of reftable + support in Git v2.45, I was busy with my AI research work + for [optimising Git performance][3], and I immediately + thought that it was the right time to put JGit and C Git + implementation of reftable in the arena and see how they + interoperate and perform during heavy workload. + + The first finding was that reftable has an entirely different + philosophy from any other ref storage used before by Git. + Loose refs and packed refs are both based on the concept of + file-level locking and caching. Both C Git and JGit ensure + that every update is atomic by carefully creating and releasing + ref-level or packed-refs-level lock files and using atomic + filesystem updates to ensure that the concurrency of reads + and updates does not impact the normal functionality of + in-flight operations. JGit has a “wait for lock” mechanism + where the in-flight operation would wait for the lock file + to be released before acquiring the resource, with an exponential + backoff mechanism on packed-refs, whilst C Git just fails the + operation with a lock failure. + + Reftable is different because it is designed to be highly + scalable and performant, compared to loose refs or packed-refs. + To prioritise performance and low latency, reftable decides + to give up thread safety and locking altogether, relying on an + optimistic locking pattern. In a nutshell, whilst packed-refs + blocks the file and waits until it is released, reftable allows + multiple users to access the same data on disk and refer + directly without locking. The operation is always safe because, + unlike packed-refs and loose-refs, the reftable files are always + immutable and therefore safe to be shared concurrently without + any locks. + + What’s the catch? The concurrent updates of the same refs by + two different threads or processes will want to update the + list of reftables simultaneously. Whoever manages to perform + the update is gaining the “logical lock” and will cause any + other concurrent threads or processes to fail the whole + transaction they may have prepared. + + Why is this different from loose-refs and packed-refs? The + client interaction and compensation behaviour with a reftable + needs to be substantially different: if with loose-refs or + packed-refs the client was retrying the operation, or just + waiting in case of JGit, with reftable the client should + abort the whole logical operation, destroy the current + snapshot of the reftable read in memory, and restart the + whole transaction from scratch. + + The issue here is that reftable is simply configured + as a storage format for the refs, and the higher layers + are currently unprepared to manage the difference in + behaviour. This is currently causing trouble in the + JGit world, with [some initial issues reported][9] at the + API level, like the lack of “auto-refresh” and even more + problematic [stability problems reported on Gerrit Code Review][10] + when using reftable from concurrent threads. + + The $1M question about reftable is, *"Is it ready for mainstream + use in production?”* My answer is obviously a bold yes, but with + a very important caveat: whoever is using reftable should be aware + of what it is and how it should be used, and cannot be simply used + blindly, assuming that it works exactly as a loose-ref or + packed-refs. Reftable is ready, Git and Gerrit Code Review aren’t + ready yet to leverage it, and I am sure they will soon be adjusted + to get the best use of it. + +- **What's your approach to load testing Git repositories \- which + tools work best, what key metrics should organizations monitor, + and what are some interesting findings from your research in + this area?** + + At GerritForge, we’ve been investing a lot of time and effort + in testing and improving the performance of Git repositories, + as demonstrated by the recent research paper published on the + use of AI to improve repository performance 100x times. + + Over the years, we have developed much experience, successfully + using the [Gatling framework][11] and extending it to support + the [Git protocol over HTTPS and SSH][12]. The use of Gatling + is great because it allows us to create very comprehensive + scenarios using a DSL (domain-specific language), which is + high-level and can replicate real-life user behaviour. + Replicating real-life traffic is paramount when testing a Git + repository performance because it allows creating future volumes + in terms of length of delta-chains, number and distribution of + refs, and number of packfiles / loose objects, that reflect the + project lifecycle. + + Another key aspect of generating a workload against a Git repository + is scaling up the clients and making their requests parametric enough + to avoid different requests locking each other. With Gatling, you + have the concept of “user sessions” where different logical users + can have dynamic variables used in the Git requests that can be used + for making the operation independent (e.g., branch name fragments, + or tags) and avoiding them from failing or ending up in a deadlock. + + As part of [our research work][3], I managed to recreate 10 years + of Git traffic generated by hundreds of users and execute it in + just 12 hours, thanks to Gatling and the Git-Gatling plugin. + + An interesting finding from the research and experiments is that + over 95% of the CPU time is spent in serving git-upload-pack + commands (not really a surprise though), of which 90% of it is + spent in [the “search-for-reuse” phase][13]. + + A second interesting finding is that the presence of a bitmap, + single or multi-pack, is not a guarantee of fast and effective + Git operations: the quality of the bitmap also matters a lot. + A bad bitmap could be so detrimental that removing it could + make the Git repository much faster, which may sound + counterintuitive. + +- **Based on your testing, what improvements do you think are most + needed in Git's core implementation?** + + I believe that the Git GC process needs a full revamp: the way + it is designed today isn’t suitable for large repositories. I + have presented a simple “role play” demo of what could happen + to a large mono-repo when you are trying to resolve a production + slowdown [running a Git GC][14]: in my imaginary scenario, a + large team of developers is pushing a lot of changes to get the + latest features through on their product’s mono-repo, not unlike + what happens when a large developer conference is approaching + and company ABC wants to launch a new version of their product DEF. + The operation raises the main metrics of the repository and makes + the “search-for-reuse” phase explode, causing the complete blockage + of the CI/CD pipeline. The Git SCM Manager knows what to do … and + runs a Git GC, causing even more damage than the original problem. + + I believe Git GC needs to be redesigned from the ground up. + Instead of being a simple sequence of operations, it needs to be + much more intelligent and adaptive to perform the right operation + at the right time. This could also be *“do nothing”* as the CPU + load is too high or the volatility of the repository is diverging. + +- **How do you see the relationship between Git and JGit evolving + in the future?** + + I believe Git and JGit have a wonderful symbiosis of ideas and + code: many popular features in JGit ended up innovating and + inspiring similar implementations in Git (e.g., bitmap, + ref-table, just to name a couple). Also, the other way around + is happening, with the implementation of MIDX in JGit recently + merged, thanks to the collaboration of GerritForge and Google. + + I like Git because it makes the language absolutely irrelevant + to the implementation: extending Git doesn’t mean you have to + write C code, and you can always start a brand new Git functionality + in a language XYZ in the future. Git is all about data and protocol + specification, not language, code, or operating system. + + I believe that should remain the case, and I am looking forward to + new languages implementing and innovating on Git, like the recent + [Gitoxide project][15], a pure-native implementation in Rust. + +- **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 may repeat myself, but I would redesign the Git GC command from + the ground up. + +- **If you could remove something from Git without worrying about + backwards compatibility, what would it be?** + + Well, I would get rid of SHA-1 altogether immediately, forget + about the legacy, and force everyone to use SHA-256 … but + change requires time. + +- **What is one of your most favourite features of Git?** + + I thank all the Git developers every single day for the + interactive rebase. I use it as my bread and butter every + morning. + +- **What is your favorite Git-related tool/library, outside of Git itself?** + + I am shamelessly admitting that I love Git command line and + I do not feel I need anything else as a tool or library to + interact with it. Many people find it confusing, and I agree + that some syntax could be misleading. Nevertheless, it is worth + using it, proposing changes, and improving how it works and is + perceived by the developers. + + A tool that requires other tools is a symptom of a problem. + +- **Could you brief a bit about one of your most memorable experience + with Git?** + + As you haven’t mentioned if the experience should be positive or + negative, I always mention the world-stage attention I got from + force-pushing hundreds of Git repositories on the Jenkins CI + organisation [over 12 years ago][16]. It was bad and good at + the same time, because despite the panic caused in hundreds of + Jenkins CI projects, it demonstrated that force pushing isn’t + a destructive operation, and all the BLOBs were easily recovered, + and the refs pointed again to the expected SHA1. + + Also, my unfortunate mistake highlighted the resilience of the + Git repository model, where there isn’t a “single source of truth” + and GitHub’s repository is just “one of the peer repositories” + around the globe. You can always recover from any type of damage + with Git, at least from what I’ve seen in my 15 years of + contributing and using it with real-life large-scale repositories + and customers. + +- **What is your advice for people who want to start using Git? + Where and how should they start?** + + This could have been a valid question 15 years ago, when Git was + still “quite recent” and not widely adopted yet. Nowadays, Git is + taught at school and universities and has become the de facto + standard of any Open-Source project around the globe. I was also + pleasantly surprised to learn that my 10-year-old son was + introduced to Git by his Computer Science teacher at primary school. + +- **There's a common conception that "Git is confusing". What are your + thoughts about the same?** + + I believe the most confusing part of Git is the working copy and the + staging area. That’s the reason why [JJ][7] gets rid of it altogether + and introduces the concept of “unnamed” commit. That’s genius from + Martin Von Zweigbergk, if you think about it: you just stage files + because you’d like to create a commit. So the stage is the + “next commit you’re about to write”, therefore the unnamed commit. + +- **If there’s one tip you would like to share with other users of Git, + what would it be?** + + Never use an IDE to manage your Git repository and commits: always + stay in control of what happens and learn something every day by using + the Git command line. + +- **If there’s one tip you would like to share with other Git developers, + what would it be?** + + I am not currently contributing to C Git, so my tip would be more for + JGit developers instead. I would love to see more end-to-end JGit + features and protocols testing using tools like [Gatling][11] + and the [Git-Gatling plugin][12]. + +- **Anything else that you'd like to share with us?** + + In the future, I’d like to see Git become just one standard feature + of each operating system: anyone should version a file on their + system, regardless of whether that file is source code, a document, + a video, or a drawing. Maybe it is not a random event that the father + of Linux is also the creator of the Git version control system, + isn’t it? + + Thanks for allowing me to share my experience with Git and my history + of being a JGit contributor and committer. + +[vonc]: https://git.github.io/rev_news/2023/12/31/edition-106/#community-spotlight-vonc +[torek]: https://git.github.io/rev_news/2025/02/28/edition-120/#community-spotlight-chris-torek +[clearcase]: https://en.wikipedia.org/wiki/IBM_DevOps_Code_ClearCase +[perforce]: https://www.perforce.com/ +[martinvonz]: https://github.com/martinvonz +[gerrit-3.12]: https://www.gerritcodereview.com/3.12.html +[1]: https://gerrit.googlesource.com/plugins/multi-site/+/refs/heads/master/DESIGN.md +[2]: https://review.gerrithub.io/c/eclipse-jgit/jgit/+/3930 +[3]: https://conf.researchr.org/home/icse-2025 +[4]: https://gerrit.googlesource.com/plugins/high-availability +[5]: https://github.blog/news-insights/company-news/oct21-post-incident-analysis/ +[6]: https://en.wikipedia.org/wiki/SourceForge +[7]: https://jj-vcs.github.io/jj/latest/ +[8]: https://github.com/git/git/blob/master/Documentation/RelNotes/2.45.0.adoc +[9]: https://github.com/eclipse-jgit/jgit/issues/102 +[10]: https://github.com/eclipse-jgit/jgit/issues/130 +[11]: https://gatling.io/ +[12]: https://docs.gatling.io/reference/script/third-parties/ +[13]: https://github.com/eclipse-jgit/jgit/blob/46d0d1b40b147e4282043a6c404947166c71be93/org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/pack/PackWriter.java#L1452 +[14]: https://youtu.be/xhxrGxvChU0?t=395 +[15]: https://github.com/GitoxideLabs/gitoxide +[16]: https://www.infoq.com/news/2013/11/use-the-force/ + + +## Other News + +__Various__ ++ The Git Merge 2025 [speaker list](https://git-merge.com/#speakers) + and [schedule](https://git-merge.com/#schedule) have been announced. + It will be held on September 29 - 30, 2025, in San Francisco, CA, USA. ++ [[ANNOUNCE] Git v2.50.0](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u) + by Junio C Hamano on the Git mailing list. ++ [Highlights from Git 2.50](https://github.blog/open-source/git/highlights-from-git-2-50/) + by Taylor Blau on GitHub Blog.
+ Mentions + improvements for multiple cruft packs, including `git repack --combine-cruft-below-size` + (and improvements to its `--max-cruft-size` option), + incremental multi-pack reachability bitmaps (highly experimental), + the "ort" merge strategy replacing the "recursive" strategy entirely, + various `git cat-file` improvements, `git maintenance` new tricks, and more. ++ [What’s new in Git 2.50.0?](https://about.gitlab.com/blog/what-s-new-in-git-2-50-0/) + by Justin Tobler on GitLab Blog.
+ Mentions the + new [git-diff-pairs(1)](https://git-scm.com/docs/git-diff-pairs) command + which accepts "raw" formatted filepair info (from e.g. `git diff-tree`) + as input on stdin to determine exactly which patches to output, + batched reference updates with [git-update-ref(1)](https://git-scm.com/docs/git-update-ref) + and its new `--batch-updates` option + (which allows the updates to proceed even when one or more reference updates fails), + the new `--filter` option for [git-cat-file(1)](https://git-scm.com/docs/git-cat-file), + improved performance when generating bundles with [git-bundle(1)](https://git-scm.com/docs/git-bundle) + (used by GitLab to generate repository backups + and also as part of the [bundle-URI](https://git-scm.com/docs/bundle-uri) mechanism), + and better bundle URI unbundling. + + +__Light reading__ ++ [How to Install Gitea (with SQLite3 and HTTPS!) on a VPS](https://www.git-tower.com/blog/how-to-install-gitea) + by Bruno Brito on Tower Blog. ++ [Reduce the load on GitLab Gitaly with bundle URI](https://about.gitlab.com/blog/reduce-the-load-on-gitlab-gitaly-with-bundle-uri/). + Discover what the bundle URI Git feature is, how it is integrated into Gitaly, + configuration best practices, and how GitLab users can benefit from it. + GitLab Blog post writen by Olivier Campeau. ++ [How we decreased GitLab repo backup times from 48 hours to 41 minutes](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/) + by Karthik Nayak and Manuel Kraft on GitLab Blog. + Describes how the GitLab team tracked a performance bottleneck in `git bundle create` + to a 15-year-old Git function and fixed it. ++ [Working with stacked branches in git (part 2)](https://andrewlock.net/working-with-stacked-branches-in-git-part-2/) + by Andrew Lock on his blog, \.NET Escapades, continues where + [Working with stacked branches](https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/) + (mentioned in [Git Rev News Edition #93](https://git.github.io/rev_news/2022/11/30/edition-93/)) left off. ++ [Git: please stop squash merging!](https://lucasoshiro.github.io/posts-en/2024-04-08-please_dont_squash/) + and [Git: the danger of squash merging submodules](https://lucasoshiro.github.io/posts-en/2024-06-27-squash-submodule/) + by Lucas Seiki Oshiro on his GitHub Pages-powered personal blog. + + The first of those blog posts mentions + [Squash commits considered harmful](https://dev.to/wesen/squash-commits-considered-harmful-ob1) by Manuel Odendahl and + [Squash merges are evil](https://medium.com/bananatag-engineering-blog/squash-merges-are-evil-171f55139c51) by L. Holanda. + + See the [Combining branches](https://wizardzines.com/comics/combining-branches/) + comic by Julia Evans (@b0rk) for an explanation about the differences between merge, rebase, and squash merge. ++ [Cleaning up gone branches](https://haacked.com/archive/2025/04/17/git-gone/) + by Phil Haack on his You've Been Haacked blog. + Describes how to delete all the branches that have been merged into the default branch, + even if the project uses Squash and Merge when merging PRs + (also known as squash merge). ++ [Part 7: Office Migration from Source Depot to Git, or how I learned to love DevEx](https://danielsada.tech/blog/carreer-part-7-how-office-moved-to-git-and-i-loved-devex/) + by Daniel Sada on his personal blog + (part of his [My career so far](https://danielsada.tech/series/my-career-so-far/) series). + + Nicely complements [Microsoft’s Performance Contributions to Git in 2017](https://devblogs.microsoft.com/devops/microsofts-performance-contributions-to-git-in-2017/) + by Derrick Stolee on Microsoft Dev Blogs, mentioned in + [Git Rev News Edition #40](https://git.github.io/rev_news/2018/06/20/edition-40/), + and other posts at . ++ [Git Branch Manager: a manager for git branches](https://daveschumaker.net/git-branch-manager-a-manager-for-git-branches/) + by Dave Schumaker on his blog, + describes how he created the [Git Branch Manager](https://github.com/daveschumaker/gbm) + tool by "vibe coding" with Claude Code. The 'P.S.' part just kills it... ++ [no more gitmojis](https://kjelsrud.dev/blog/no-more-gitmojis/) + on Sids' blog; moving from [gitmojis](https://gitmoji.dev/) + to just using [conventional commits](https://conventionalcommits.org/). + + [Gitmoji](https://gitmoji.dev/) was first mentioned in [Git Rev News Edition #47](https://git.github.io/rev_news/2019/01/23/edition-47/), + though then under a [different URL](https://gitmoji.carloscuesta.me/) + (which now redirects to the current one). + + The similar [Emoji-Log](https://github.com/ahmadawais/Emoji-Log) commit log messages standard + was mentioned in [Git Rev News Edition #101](https://git.github.io/rev_news/2023/07/31/edition-101/). + + 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. ++ [`git diff --ignore-all-space` makes code review way easier](https://garrit.xyz/posts/2025-06-11-git-diff-ignore-all-space-makes-code-reviews-way-easier) + by Garrit Franke on Garrit's Notes blog; + a TIL (Today I've Learned) style post. ++ [Per-project git commit templates](https://tylercipriani.com/blog/2025/05/21/git-commits/) + by Tyler Cipriani on his blog. + Mentions in passing different commit guidelines used by various projects, like + [Conventional Commits](https://www.conventionalcommits.org/), + [Gitmoji](https://gitmoji.dev/), + [Problem/Solution format](https://zeromq.org/how-to-contribute/#write-good-commit-messages) used by ZeroMQ, and + [Acked-by:, Cc:, and Co-developed-by: trailers](https://docs.kernel.org/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by) + used by Linux kernel developers. ++ [The history of change-packing tools at Microsoft (so far)](https://devblogs.microsoft.com/oldnewthing/20180122-00/) + by Raymond Chen on Microsoft Dev Blogs: The Old New Thing (2018).
+ Change-packing is a way to save a whole changeset or commit to a single file, + to be able to save changes without committing them (like `git stash`), + or to get another developer’s opinion on code you’ve written (_buddy build_), etc. ++ [GIF: The Git Interchange Format](https://willhbr.net/2025/06/16/gif-the-git-interchange-format/) + by Will Richardson on his blog, + about how to cram a whole git repo (with history) into an animated GIF. + + + +__Scientific papers__ ++ Shane McIntosh, Luca Milanesio, Antonio Barone, Jacek Centkowski, Marcin Czech, Fabio Ponciroli: + _"Using Reinforcement Learning to Sustain the Performance of Version Control Repositories"_, + ICSE 2025: 47th International Conference on Software Engineering, + (preprint). ++ Jakub Narębski, Mikołaj Fejzer, Krzysztof Stencel, Piotr Przymus: + _"PatchScope - A Modular Tool for Annotating and Analyzing Contributions"_, + ISSTA 2025: 34th ACM SIGSOFT International Symposium on Software Testing and Analysis, + [DOI:10.1145/3713081.3731727](https://dl.acm.org/doi/10.1145/3713081.3731727) (short paper, free access). + + [PatchScope](https://github.com/ncusi/PatchScope) was first mentioned in + [Git Rev News Edition #117](https://git.github.io/rev_news/2024/11/30/edition-117/). + +__Git tools and sites__ ++ [GetHooky](https://ezpieco.github.io/GetHooky/) is a simple git hook manager for everyone. + Inspired by [Husky](https://typicode.github.io/husky/), + but a CLI tool, thus works for every stack. + Written in Go, under MIT license. + + [Husky](https://github.com/typicode/husky), a Git hook management tool, was first mentioned in + [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/); + you can find links to other articles talking about it in + [#87](https://git.github.io/rev_news/2022/05/26/edition-87/), + [#89](https://git.github.io/rev_news/2022/07/31/edition-89/), and + [#102](https://git.github.io/rev_news/2023/08/31/edition-102/). ++ [Git Branch Manager](https://github.com/daveschumaker/gbm) is + a terminal-based (TUI) Git branch management tool + that provides an interactive interface for managing Git branches, + with rich visual feedback and advanced features. + Written in Python (with the help of Claude Code), under MIT license. ++ [Gittyup](https://github.com/Murmele/Gittyup) is a graphical Git client + designed to help you understand and manage your source code history. + Written in C++ using Qt, under MIT license. + It is a continuation of the [GitAhead](https://github.com/gitahead/gitahead) client, + mentioned in [Git Rev News Edition #59](https://git.github.io/rev_news/2020/01/22/edition-59/). ++ [Conventional Changelog](https://github.com/conventional-changelog/conventional-changelog) + is an npm tool to generate changelogs and release notes + from a project's commit messages and metadata. + Written in TypeScript and JavaScript, under ISC license. + First mentioned in [Git Rev News Edition #81](https://git.github.io/rev_news/2021/11/29/edition-81/). + + +## Releases + ++ Git [2.50.0](https://public-inbox.org/git/xmqq1prj1umb.fsf@gitster.g/), +[2.50.0-rc2](https://public-inbox.org/git/xmqqfrg8surr.fsf@gitster.g/), +[2.50.0-rc1](https://public-inbox.org/git/xmqqsekgn4gk.fsf@gitster.g/) ++ Git for Windows [2.50.0.windows.1](https://github.com/git-for-windows/git/releases/tag/v2.50.0.windows.1), +[2.50.0-rc2.windows.1 (pre-release)](https://github.com/git-for-windows/git/releases/tag/v2.50.0-rc2.windows.1), +[2.50.0-rc1.windows.1 (pre-release)](https://github.com/git-for-windows/git/releases/tag/v2.50.0-rc1.windows.1), +[2.50.0-rc0.windows.1 (pre-release)](https://github.com/git-for-windows/git/releases/tag/v2.50.0-rc0.windows.1) ++ libgit2 [1.9.1](https://github.com/libgit2/libgit2/releases/tag/v1.9.1) ++ GitLab [18.1.1, 18.0.3, 17.11.5](https://about.gitlab.com/releases/2025/06/25/patch-release-gitlab-18-1-1-released/), +[18.1](https://about.gitlab.com/releases/2025/06/19/gitlab-18-1-released/), +[18.0.2, 17.11.4, 17.10.8](https://about.gitlab.com/releases/2025/06/11/patch-release-gitlab-18-0-2-released/) ++ GitHub Enterprise [3.17.1](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.1), +[3.16.4](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.4), +[3.15.8](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.8), +[3.14.13](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.13), +[3.13.16](https://docs.github.com/enterprise-server@3.13/admin/release-notes#3.13.16), +[3.17.0](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.0) ++ GitKraken [11.2.0](https://help.gitkraken.com/gitkraken-client/current/), +[11.1.1](https://help.gitkraken.com/gitkraken-client/current/), +[11.1.0](https://help.gitkraken.com/gitkraken-client/current/), +[11.0.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.5.0](https://desktop.github.com/release-notes/), +[3.4.21](https://desktop.github.com/release-notes/) ++ GitButler [0.14.35](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.35), +[0.14.34](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.34) ++ Tower for Mac [13](https://www.git-tower.com/release-notes/mac) - [Release Blog Post](https://www.git-tower.com/blog/posts/tower-mac-13) / [YouTube video](https://youtu.be/2hjLn9mq9fY) ++ Tower for Windows [9.1](https://www.git-tower.com/beta/windows) (Beta) - [Release Blog Post](https://www.git-tower.com/blog/posts/tower-windows-91) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Luca Milanesio, Bruno Brito, +Lee Reilly and Štěpán Němec. diff --git a/_posts/2025-07-31-edition-125.markdown b/_posts/2025-07-31-edition-125.markdown new file mode 100644 index 0000000000..063e936ee8 --- /dev/null +++ b/_posts/2025-07-31-edition-125.markdown @@ -0,0 +1,645 @@ +--- +title: Git Rev News Edition 125 (July 31st, 2025) +layout: default +date: 2025-07-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 125 (July 31st, 2025) + +Welcome to the 125th 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 June and July 2025. + +## Discussions + + +### General + +* 20 years ago: [Meet the new maintainer..](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/) + + On July 26 2005, so 20 years ago, Linus Torvalds announced on + the mailing list that Junio Hamano accepted the maintainership of + the Git project and that Junio "was the obvious choice". Linus said + he wasn't dropping Git but he just preferred working on it as a + contributor. + + Junio replied with an [A note from the new GIT maintainer](https://lore.kernel.org/git/7vmzo8ss2l.fsf@assigned-by-dhcp.cox.net/) + email where he acknowledged his new role as Git maintainer, thanked + the community for their support and collaboration, and promised to + take a more careful and deliberate approach in shepherding the + project. He also said he would post his own patches to the mailing + list for review before including them in the repository, and + encouraged community feedback. + +* [[ANNOUNCE] Git Mini Summit at Open Source Summit Europe, Amsterdam, August 28th](https://lore.kernel.org/git/aGwHt9HCd86hVuKh@pks.im/) + + Patrick Steinhardt announced a Git Mini Summit co-located with the + [Open Source Summit Europe](https://events.linuxfoundation.org/open-source-summit-europe/) + in Amsterdam on August 28th 2025. + + There will be lightning talks and some time for people to + connect. Proposals for the lightning talks should be sent to + Patrick, while the possibility to have remote talks is still + investigated. + + [Registration is open](https://events.linuxfoundation.org/open-source-summit-europe/features/co-located-events/#git-mini-summit-2025) + for both the Git Mini Summit only and for the Open Source Summit Europe including the Git Mini Summit. + + +### Reviews + +* [[PATCH v4 0/3] send-email: add oauth2 support and fix outlook breaking threads](https://lore.kernel.org/git/PN3PR01MB9597A83D537E3AE96144227EB8BA2@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM/) + + Last April, Aditya Garg sent a patch series containing three main + changes to `git send-email`. He mentioned that he was sending the + email series using the very patches he was proposing, via Outlook. + + The first patch was a rebased version of + [an earlier patch by Julian Swagemakers](https://lore.kernel.org/git/20250125190131.48717-1-julian@swagemakers.org/) + adding support for OAuth2 authentication, which started to be + required by Microsoft. Julian's patch unfortunately had been waiting + for review for over a year before Aditya picked it up. + + The second patch fixed thread breaking caused by Outlook's + proprietary Message-ID handling. + + The final patch added a new option for generating passwords, such as + OAuth2 tokens, via an external script. + + Junio Hamano, the Git maintainer, reviewed the three patches saying + he liked the commit messages, documentation and code comments even + though he suggested a few small style improvements to the code + style plus a number of grammar and formatting changes to the + documentation. + + He also asked for reviews from others as he said he was not familiar + with the `Authen::SASL` library. + + Aditya replied to Junio's review acknowledging the need for more + reviews and saying that OAuth2 was a significant and more secure + technology. He then took the initiative to Cc Greg Kroah-Hartman, + who wrote a precursor of `git send-email` for the Linux kernel. + + M Hickford also replied to Aditya expressing enthusiasm for the work + but wondering why the v4 version of the patch series was sent in a + new email thread rather than as a reply to the previous version. + + brian m. carlson commented on the second patch saying that replacing + message IDs like Outlook does is technically allowed by + standards. They raised concerns about hardcoding only two Outlook + server hostnames, and suggested adding configuration options for + Message-ID generation modes. + + Julian Swagemakers then pointed out that the goal of the third patch + could already be achieved using Git's existing custom credential + helper mechanism. Aditya confirmed this worked and said he was + unaware of this feature, which led to the decision to drop the third + patch. Recognizing that the existing feature was poorly + discoverable, the discussion led to improvements in Git's + documentation, adding clearer examples of using credential helpers + for OAuth2 tokens. + + Erik Huelsmann, the maintainer of the `Authen::SASL` Perl module, + joined the conversation after Aditya emailed him directly + referencing a GitHub issue about the lack of OAuth2 support in + `Authen::SASL`. In that issue Erik had + [commented that he would be happy to support XOAUTH2](https://github.com/gbarr/perl-authen-sasl/issues/18#issuecomment-2453040190), + but needed a patch and a way to test it. + + Aditya and Julian then worked together, with guidance from Erik, to + add the necessary XOAUTH2 and OAUTHBEARER support directly into + `Authen::SASL`. Shortly after, a new version of the `Authen::SASL` + module was officially released with this new functionality. This + successful collaboration meant the first patch in the series, which + was a workaround for the missing library support, was no longer + needed and was subsequently dropped. Instead, the new version of + `Authen::SASL` started to benefit all Perl users. + + Greg Kroah-Hartman echoed what brian had suggested about using a + configurable solution in the second patch. Greg noted that the + initial approach would not cover company-hosted Outlook servers. Yao + Zi also contributed to this discussion, noting that Tencent's mail + service had similar issues, further reinforcing the need for a + flexible solution beyond just hardcoding specific server names. + + That suggestion was then refined by Junio Hamano, who proposed a + concrete implementation for the new option by providing an example + patch. The final `--[no-]outlook-id-fix` option auto-detects known + Outlook servers but allows manual override for other deployments. + + After several iterations on its name and behavior, with Eric + Sunshine helping refine the user-facing documentation, Aditya + submitted a final, simplified patch series (v6). It now contained + only the single, refined patch to fix Outlook thread breaking, with + the other two patches having been made obsolete by the + `Authen::SASL` library update and the use of existing Git features. + + Aditya's patch was merged and released as part of Git v2.50.0. + + + +## Developer Spotlight: Usman Akinyemi + +_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 Outreachy 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’m Usman Akinyemi, a final-year CS and AI student, and an open-source + contributor passionate about Linux, distributed systems, and developer + tools. I’ve contributed to core projects like Git, systemd, LLVM, and + LibreOffice. During [my Outreachy internship](https://uniqueusman.hashnode.dev/my-outreachy-internship-experience-at-git), + I improved Git’s v2 protocol by adding OS-level metadata for better + diagnostics and security. + + Currently, I’m a [Google Summer of Code contributor](https://summerofcode.withgoogle.com/programs/2025/projects/wBCitF8F) + building a containerized pipeline for medical imaging using Kaapana, + Kubernetes and Airflow. I am also currently working on creating a + new subtype for RISC-V assembly instructions through the + Linux Foundation’s LFX program. + + Outside code, I mentor new contributors, volunteer with DesignIT and + LEAD and CODE to teach digital skills, and organize a tech webinar for + Nigerian students. I’ll be [speaking at Git Merge 2025](https://git-merge.com/#usman-akinyemi), + sharing insights from my open-source journey. I believe in the power of + community, collaboration, and curiosity to build a career that crosses + borders. + +* **How did you initially become interested in contributing to Git, + and what motivated you to choose it as your Outreachy project?** + + Though I have been contributing to other projects before applying for + Outreachy (Dec 2024), I was just a user of the Git project. When it + comes to the Outreachy contribution period when I had to pick a + project, I picked both Git and LibreOffice. I picked Git as it is a + project I use every time, also the thought of contributing to a + project used by almost all the developers in the whole world was + definitely a dream coming true. To also maximize my getting selected + for Outreachy, I picked Git because it is written in C, + which many other participants are always scared to pick (going for the + hard thing). The story did not end there as I got selected for both + LibreOffice and Git and I had to choose one as my Outreachy projects. + It was a hard decision but I picked it mainly because the Git + community is a community where it is so easy to communicate with other + team members, and it is a community where I clearly know who is who and + what they do in the community. Also Git is more well recognised. + +* **How do you feel your contribution has impacted the Git community + or the broader open source ecosystem?** + + [My contribution](https://lore.kernel.org/git/20250215155130.1756934-1-usmanakinyemi202@gmail.com/) + makes a fundamental improvement to the Git v2 protocol by enabling + Git clients to share their operating system information via the user + agent string. This helps platforms like GitHub, GitLab, and others + gain visibility into which OS environments are interacting + with their servers. It significantly improves debugging, security + auditing, and telemetry, helping maintainers understand usage patterns + and tailor support or upgrade strategies accordingly. Since this + change is part of the core Git client, it means it is used by all Git + users. I’m proud to have contributed something with such + wide-reaching, foundational impact. + +* **Is there any aspect of Git that you now see differently after + having contributed to it?** + + Before contributing to Git, I saw it as a complex tool that "just + works". Although I knew Git was different from GitHub, I struggled to + clearly differentiate between the two. But after contributing, I could + clearly differentiate between the two and I now see Git as a carefully + designed software project with a strong emphasis on performance, + cross-platform compatibility, and community-driven development. + + I’ve come to appreciate the level of thought and care that goes into + every change, from writing clean patches and commit messages to + engaging in technical discussions and defending your design decisions. + + Contributing to Git isn’t also about hierarchical review; instead, + it’s a collaborative process where every contributor is expected to + take full ownership of their patches, understand the problem they are + trying to fix, the solution and explain their rationale clearly by + writing clean patches, commit messages and engaging in technical + discussions and defending your design decisions. In fact, there have + been moments when some of my contributions led to insights even long + time contributors hadn’t considered, including Junio Hamano. That + boosted my confidence not just in contributing to Git, but to other + software projects as well, i.e., I can get my patches accepted anywhere, + I just need to convince others that it actually solves a problem. + +* **How do you balance your contributions with other responsibilities + like work or school?** + + Seriously, it has not been easy, most of my contributions to all + open source projects have always been during college. But, I have sort + of made contributions to open source as one important aspect of my + life and also as a way to learn new technologies and also practice + whatever new skills I learnt. Contributing to projects millions of + people use is also definitely rewarding and satisfying. + +* **Can you share how Outreachy helped enhance your technical and + non-technical skills (like communication, project management, etc.)?** + + Technically, I have been able to improve my C programming and bash + scripting skills. Also reading and understanding very large codebases + like Git. Of course now I can call myself an expert in using Git as a + tool itself. + + To contribute to Git, you must be able to communicate well, as all the + Git workflows happen remotely and over mailing lists. Most of the time + in the Git community it is not about the correctness of your code -- it + is about how well you can communicate your rationale to the community + before your patches can be accepted. So, over time, as a Git + contributor, my communication skills in a technical environment have + really improved. + + I have also learnt to write clean code, organize my changes into well + formatted patches, and write clear commit messages. + +* **What was your biggest takeaway or learning from Outreachy that + you now apply regularly in your work?** + + I’d say my biggest takeaway from Outreachy is learning how to write + clear, structured commit messages. Git commits, like those in the + Linux kernel, follow a thoughtful format: describe the current state, + the problem, and the fix. From reading most of the commit messages in + Git, you would have understood and been able to visualize what the changes + will look like. It also makes it easy to track the changes to other + prerequisite commits. I have been using the Git commit messages format + in other projects and I really love it. + +* **What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it?** + + I think the challenge which I initially faced is sending patches to + Git, not really a big challenge though as I was able to make my first + patch in a few days after joining the community. And the reason is + that Git does not use GitHub or GitLab, something someone would have + thought they will be using. Git uses a mailing list just like the + Linux kernel. While writing this, I remember that I had a challenge + retrieving patches from the mailing list as my project depended on some + patches that were sent by my mentor previously. I had to use `git am`, + something I never used before. Help from my mentor really helped, + as well as reading through the "[Hacking Git](https://git.github.io/Hacking-Git/)" + page. + +* **Have you thought about mentoring new GSoC / Outreachy students?** + + Yeah, I am planning to put in as a mentor for the coming Outreachy + period and hopefully for GSoC also. I will be starting as a co-mentor + though. + +* **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?** + + Smile, I will definitely say the Rustication of some parts of Git + which has been going on currently, I think one that has already been + integrated to Git is [libgit-rs](https://lore.kernel.org/git/cover.1738187176.git.steadmon@google.com/). + Rust seems to be a language that focuses more on safety/security, + and safety/security is very important in Git. I am also a Rustacean + so I should be able to help hopefully if that happens. + +* **If you could remove something from Git without worrying about + backwards compatibility, what would it be?** + + I really do not have anything in mind for now. + +* **What upcoming features or changes in Git are you particularly + excited about?** + + I think it is one of the [GSoC projects by Lucas](https://summerofcode.withgoogle.com/programs/2025/projects/fGgMYHwl). + I have been passively following the project. It is about introducing + a new Git sub-command (currently intended to be called `git repo-info`) + that will centralize data currently retrieved by `git rev-parse` in a + JSON format. + +* **What is your favorite Git-related tool/library, outside of Git + itself?** + + I think it's both GitHub and GitLab -- if I have to choose one, I will say GitHub. + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I started with [GitGitGadget](https://gitgitgadget.github.io/) initially + just to get my patches to the mailing list faster but, along the line + I switched to `git send-email` and really, it is more flexible and easy + to use than I thought of it. For my machine, I basically use Arch Linux + and Neovim as my text editor. + +* **How do you envision your own involvement with Git or other open + source projects in the future?** + + As I said earlier, open source has really been part of my life and it + has really helped me a lot in improving my skills, meeting new people + and even making some few bucks through internships. After my + internship at Outreachy, I did send patches to the Git community and I + planned to keep doing that. After Outreachy, I have contributed to a + few other projects like RISC-V and OSIPI (through GSoC). I currently + mentor people who want to start their open source journey, and I plan + to do more of it. I planned to keep contributing to open source + projects and hopefully get a job in open source. + +* **What is your advice for people who want to start Git development? + Where and how should they start?** + + I have been in many open source projects and see how their workflows + are, I will definitely say Git is one of the easiest and most + interesting projects to contribute to. The community members are + really supportive. Seriously, it is one of the best open source + communities I have been to. The best place to start is going through + the "[Hacking Git](https://git.github.io/Hacking-Git/)" page. It has + all the information on how to start contributing and you can make + your first contribution to Git. You should generally start with a + microproject which aims to introduce you to the Git contribution + workflow. Everything can be found above. Making your first contribution + to Git is actually very much easier than you might have thought. + Also, do not be scared to ask for help, Git developers are always ready to render help. + +* **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?** + + Definitely, Outreachy and GSoC are very much interesting mentoring + programs to start your open source journey. They both really make it + easy to start contributing to open source. You get assigned to mentors + who are experts in open source and the organization. It is a way to get + skills you will never be able to get in your classroom and skills + needed to thrive and excel in the software engineering world. Apart + from skills, it is a way to have proof of work before graduation and + also gain global recognition. As I have said, Git is a well known and + recognized software project in the whole world, contributing to it is + an achievement on its own. + + _Shout session_ + + I would like to shout out to all Git contributors, you are doing a + great job! I would also like to shout out to my Outreachy mentor + Christian Couder, he was really supportive during my Outreachy + program! Thanks to the Git Rev teams also! + + +## Other News + +__Various__ + ++ [[LWN.net] A set of Git security-fix releases](https://lwn.net/Articles/1029182/) + by Jonathan Corbet on LWN\.net, and
+ [Multiple vulnerabilities fixed in Git](https://www.openwall.com/lists/oss-security/2025/07/08/4) + by Taylor Blau on oss-security mailing list. ++ [[ANNOUNCE] Git v2.50.1 and friends](https://public-inbox.org/git/xmqqzfdevcov.fsf@gitster.g/t/#u) + by Junio C Hamano on the Git mailing list. ++ [Launchpad](https://launchpad.net/) is [phasing out Bazaar code hosting](https://discourse.ubuntu.com/t/phasing-out-bazaar-code-hosting/62189). + This post provides a link to the [Migrate a Repository From Bazaar to Git](https://jugmac00.github.io/blog/migrate-a-repository-from-bazaar-to-git/) article. + + +__Light reading__ + ++ [Artisanal Handcrafted Git Repositories](https://drew.silcock.dev/blog/artisanal-git/) + by Drew Silcock on drew's dev blog. + This article talks about how to handmake your Git repositories without using `git` commands. + You might also learn a bit more about how Git works under the hood during the process. ++ [How to use git worktree effectively with Python projects](https://www.andreagrandi.it/posts/how-to-use-git-worktree-effectively-with-python-projects/) + (with the help of a simple [git-add-worktree.sh](https://gist.github.com/andreagrandi/542b438bf0017d93aff2b640037e3ce1) Bash script) + by Andrea Grandi on his blog. ++ [Managing Multiple Claude Code Sessions Without Worktrees](https://blog.gitbutler.com/parallel-claude-code/) + by Scott Chacon on Butler's Log (GitButler Blog). + With [Claude Code](https://www.anthropic.com/claude-code)'s new [lifecycle hooks](https://docs.anthropic.com/en/docs/claude-code/hooks), + [GitButler](https://gitbutler.com/) Git client auto-sorts simultaneous AI coding into separate branches, + without manual [use of `git worktree`](https://www.anthropic.com/engineering/claude-code-best-practices#c-use-git-worktrees). + With this feature you can write three features, and get three clean branches. ++ [wtp: A Better Git Worktree CLI Tool](https://dev.to/satococoa/wtp-a-better-git-worktree-cli-tool-4i8l) + by Satoshi Ebisawa on DEV\.to. + The [wtp](https://github.com/satococoa/wtp) tool was created to make + working with multiple tasks in parallel using [Claude Code](https://www.anthropic.com/claude-code) + easier than with `git worktree`. ++ [Automated repo maintenance via GitHub Copilot coding agent](https://blog.pamelafox.org/2025/07/automated-repo-maintenance-with-github.html) + by Pamela Fox on her Blogger-based blog. ++ [Git Worktrees: Git Done Right](https://www.nickyt.co/blog/git-worktrees-git-done-right-2p7f/) + by Nick Taylor on Just Some Dev blog (and also [on DEV\.to](https://dev.to/nickytonline/git-worktrees-git-done-right-2p7f)). ++ [I Lost My Git Stash, So I Built a Tool (VS Code Extension) to Share It](https://dev.to/karandeepsingh7070/i-lost-my-git-stash-so-i-built-a-tool-to-share-it-27bn) + by Karandeep Singh on DEV\.to. ++ [Git: share a full repository as a file with `git fast-export`](https://adamj.eu/tech/2025/07/15/git-share-fast-export/) + by Adam Johnson on his blog + (for some reason the post does not mention the alternative of using + [`git bundle`](https://git-scm.com/docs/git-bundle)). + + Adam Johnson is the author of "[Boost Your Git DX](https://adamchainz.gumroad.com/l/bygdx)" book, + first mentioned in [Git Rev News Edition #104](https://git.github.io/rev_news/2023/10/31/edition-104/), + then its updates in [#110](https://git.github.io/rev_news/2024/04/30/edition-110/) + and [#119](https://git.github.io/rev_news/2025/01/31/edition-119/). ++ [Conventional Commits makes me sad](https://srazkvt.codeberg.page/posts/2025-07-06-conventional-commits-makes-me-sad.html) + by Sarah Mathey on her Codeberg Pages powered Sarah's Website blog.
+ 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/). ++ [Git experts should try Jujutsu](https://pksunkara.com/thoughts/git-experts-should-try-jujutsu/) + by Pavan Sunkara on his personal blog.
+ [Jujutsu (`jj`)](https://github.com/martinvonz/jj) is a version control system + first mentioned in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [Jujutsu For Busy Devs](https://maddie.wtf/posts/2025-07-21-jujutsu-for-busy-devs) and + by Madeleine Mortensen on her personal blog. ++ [Using Radicle CI for Development](https://radicle.xyz/2025/07/23/using-radicle-ci-for-development) + by Lars Wirzenius on Radicle Blog.
+ [Radicle](https://radicle.xyz/) is the distributed git hosting system, + first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/). ++ [Cutting GitHub out of the loop](https://www.circusscientist.com/2025/07/23/cutting-github-out-of-the-loop/) + (by deploying to a VPS with Git and SSH). + Written by tomjuggler on The Circus Scientist Site. ++ [Super Easy* 2-Stage Git Deployment](https://ratfactor.com/cards/super-easy-2-stage-git-deployment) + by Dave Gauer on Dave's Virtual Box of Cards. ++ [Guest Post: How I Scanned all of GitHub’s “Oops Commits” for Leaked Secrets](https://trufflesecurity.com/blog/guest-post-how-i-scanned-all-of-github-s-oops-commits-for-leaked-secrets) + by Sharon Brizinov on The Dig, the Truffle Security blog. ++ [Top 17 Essential Git Tools for Enhanced Developer Productivity](https://dev.to/vaib/top-17-essential-git-tools-for-enhanced-developer-productivity-7f3) + by vAlber on DEV\.to. + + + + +__Git tools and sites__ + ++ [DiffX - Next-Generation Extensible Diff Format](https://diffx.org/): + describes problem with Unified Diff format, and proposes as a solution + a new file format specification for Extensible Diffs, + fully backwards-compatible with existing tools, + while also being future-proof and remaining human-readable. ++ [git-phoenix](https://github.com/yaitskov/git-phoenix) is a command line tool + that does repository recovery after accidental removal or file system failure, + using [photorec](https://www.cgsecurity.org/wiki/PhotoRec) (or similar tool). + Written in Haskell, under 3-clause BSD license. ++ [wtp (Worktree Plus)](https://github.com/satococoa/wtp) is a Git worktree management tool + that extends git's worktree functionality with + automated setup, branch tracking, and project-specific hooks. + Written in Go, under the MIT license. ++ [GitNifty](https://gitnifty.js.org/index.html) is a robust and promise-based Git utility for Node.js, + offering developers smart, automation-ready commands for common Git operations. + Created for building CLI tools, automation scripts, or custom Git workflows. + Written in TypeScript, and released under the Apache License. ++ [difit](https://github.com/yoshiko-pg/difit) is a CLI tool + that lets you view and review local git diffs with a GitHub-style viewer + (in a browser). Written in TypeScript, under MIT license.
+ See [difit: Preview GitHub-like diffs locally before you push](https://dev.to/unhappychoice/difit-preview-github-like-diffs-locally-before-you-push-37gc) + by Yuji Ueki on DEV\.to. ++ [Flint](https://flintable.com/docs/flint/) is a Git-integrated code formatter + that lets each developer work in their preferred style locally, + while maintaining a consistent style remotely. + By automatically applying “local” and “remote” formatting passes during pull and push operations, + Flint prevents formatting noise in commits and code reviews. + It is currently in _alpha_ and is available exclusively on npm. + Written in Bash, under MIT license. ++ [DotProj](https://dotproj.ac-jr.com/) is a developer-centric CLI tool + designed to manage project-specific configuration files with Git versioning. + It helps keep your development environment settings organized, versioned, and synchronized + across multiple machines and projects. + DotProj uses Git commands (commit, push, pull, clone) making it intuitive for developers. + Written as a Bash shell script, under MIT license. ++ [git-remote-sqlite](https://github.com/chrislloyd/git-remote-sqlite) + is a [Git protocol helper](https://git-scm.com/docs/gitremote-helpers) + that helps you store a Git repository in a SQLite database. + Written in Zig, under MIT license. ++ [Backlog.md](https://backlog.md/) is a tool that turns any folder with a Git repo + into a self-contained project board, powered by plain Markdown files + and a zero-config CLI. Written in TypeScript, under MIT license. AI ready. ++ [git-resolve.sh](https://elixir.bootlin.com/linux/v6.16-rc3/source/scripts/git-resolve.sh) + is a Bash script that resolves a short git commit ID to its full SHA-1 hash, + which is particularly useful for fixing references in commit messages. + Under GPL-2.0 license. ++ [GitHub Trends](https://www.githubtrends.io/) is a service that + uses the GitHub API to bring you insightful metrics on your contributions, + broken by repository and language. ++ [DeepWiki](https://deepwiki.com/): AI-generated docs for any repo. + This service turns any public GitHub repo into up-to-date documentation you can talk to + (see for example [DeepWiki: git/git](https://deepwiki.com/git/git). + DeepWiki is the free public version of [Devin Wiki](https://docs.devin.ai/work-with-devin/devin-wiki) and [Devin Search](https://docs.devin.ai/work-with-devin/devin-search).
+ There are a few similar projects, like + [Open Source DeepWiki](https://github.com/AsyncFuncAI/deepwiki-open) and + [OpenDeepWiki](https://github.com/AIDotNet/OpenDeepWiki). ++ [GitHub Repository Maintenance Agent](https://github.com/pamelafox/github-repo-maintainer-agent/) + is an AI-powered agent for triaging failed [Dependabot](https://docs.github.com/en/code-security/getting-started/dependabot-quickstart-guide) pull requests + across one's GitHub repositories. The agent uses [Pydantic AI](https://ai.pydantic.dev/) + for LLM-based decisions and the GitHub API for repository, PR, and issue management. + Written in Python, under MIT license. ++ [tangled](https://tangled.sh/) is a new social-enabled git collaboration platform + built on the [AT Protocol](https://atproto.com/) (that powers the Bluesky social network). + Written in Go, under MIT license; note that it is in alpha stage of development.
+ Compare with: + + [Radicle](https://radicle.xyz/), a peer-to-peer, local-first code collaboration stack built on Git + (first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/)). + + [ForgeFed](https://forgefed.org/) (formerly GitPub), a federation protocol for software forges + (first mentioned in [Git Rev News Edition #69](https://git.github.io/rev_news/2020/11/27/edition-69/)). + + [`git-ssb`](https://scuttlebot.io/apis/community/git-ssb.html) + (see the [git-ssb-intro](https://github.com/hackergrrl/git-ssb-intro) guide), a + decentralized Git repo hosting and issue tracking on [Secure-ScuttleButt (SSB)](https://www.scuttlebutt.nz/) + (first mentioned in [Git Rev News Edition #26](https://git.github.io/rev_news/2017/04/19/edition-26/). + + [gitstr (`git str`)](https://github.com/fiatjaf/gitstr), + 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/)). ++ [Git With Me](https://sr.ht/~meejah/git-withme/) is a tool for + peer-to-peer, encrypted, ephemeral Git collaboration. + `git withme` provides a way for a single host to invite numerous peers + with short, one-time secure codes. The peers connect directly via + [Dilated Magic Wormhole channels](https://meejah.ca/blog/fow-wormhole-forward), + allowing collaborators to `git clone git://localhost/`. ++ [Radicle Desktop](https://desktop.radicle.xyz/) is a desktop application + that lets you interact with [Radicle](https://radicle.xyz/), + a peer-to-peer code collaboration and publishing stack. + Written in TypeScript for Node.js and Rust, using the Tauri framework. + Under GPLv3 license. ++ [GitBug: Git Learning Simulator](https://github.com/dvig14/gitbug) + is a CLI app that teaches Git through hands-on bug fixing. + It uses a realistic merge conflict scenario with visual feedback at every step. + The goal of the app is to help you learn by doing, not just reading. + Written in Python, under MIT license, in early stage (alpha).
+ Compare with: + + [Learn Git Branching](https://learngitbranching.js.org/), + mentioned first in [Git Rev News Edition #30](https://git.github.io/rev_news/2017/08/16/edition-30/). + + [Git Gud](https://nic-hartley.github.io/git-gud/), a visual web-based Git simulator, + meant to help understand Git better, announced by its author Nic Hartley in + [Git Gud at git](https://dev.to/nichartley/git-gud-at-git-5d9k). + First mentioned in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/). + + [Git Gud](https://github.com/benthayer/git-gud), a command line game + designed to help you learn how to use the Git version control system. + Written in Python by Ben Thayer. First mentioned in + [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/). + + [Oh My Git!](https://ohmygit.org/), an open source game about learning Git, + written using the Godot game engine ([source](https://github.com/git-learning-game/oh-my-git)). + There was a lightning talk about this game at FOSDEM 2021: + [Building a Git learning game: A playful approach to version control](https://fosdem.org/2021/schedule/event/git_learning_game/). + First mentioned in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/). + + [Git-Sim](https://github.com/initialcommit-com/git-sim) tool (written in Python) + to visually simulate Git operations in your own repos with a single terminal command. + Described in [Git-Sim: Visually Simulate Git Operations In Your Own Repos](https://initialcommit.com/blog/git-sim) + (mentioned in [Git Rev News Edition #95](https://git.github.io/rev_news/2023/01/31/edition-95/)) + and [Git-Sim 3 Month Dev Update: Community Response, New Features, & The Future](https://initialcommit.com/blog/git-sim-3-month-dev-update) + (mentioned in [Edition #98](https://git.github.io/rev_news/2023/04/30/edition-98/)). + + [Visualize Git](http://git-school.github.io/visualizing-git/) web app + that illustrates what's going on under the hood when you use common Git operations, + first mentioned in [Git Rev News Edition #107](https://git.github.io/rev_news/2024/01/31/edition-107/). + + [Devlands](https://devlands.com/), which is the game that creates + immersive experience to help learning Git. + First mentioned in [Git Rev News Edition #122](https://git.github.io/rev_news/2025/04/30/edition-122/). ++ [Ferriby](https://github.com/dawedawe/ferriby) is a CLI game + where you try to keep Ferrises alive and happy + by feeding them commits in your repositories. + Written in Rust, under MIT license. ++ [Pride Versioning](https://pridever.org/), + a [joking take](https://mastodon.online/@nikitonsky/113691789641950263) + on [Semantic Versioning (SemVer)](https://semver.org/). + + +## Releases + ++ Git [2.50.1 and friends](https://lore.kernel.org/git/xmqq5xg2wrd1.fsf@gitster.g/) ++ Git for Windows [2.50.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.50.1.windows.1), +[2.50.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.50.0.windows.2), +[2.49.1](https://github.com/git-for-windows/git/releases/tag/v2.49.1.windows.1) ++ GitHub Enterprise [3.17.4](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.4), +[3.16.7](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.7), +[3.15.11](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.11), +[3.14.16](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.16), +[3.17.3](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.3), +[3.16.6](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.6), +[3.15.10](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.10), +[3.14.15](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.15), +[3.17.2](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.2), +[3.16.5](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.5), +[3.15.9](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.9), +[3.14.14](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.14) ++ GitLab [18.2.1, 18.1.3, 18.0.5](https://about.gitlab.com/releases/2025/07/23/patch-release-gitlab-18-2-1-released/), +[18.2](https://about.gitlab.com/releases/2025/07/17/gitlab-18-2-released/), +[18.1.2, 18.0.4, 17.11.6](https://about.gitlab.com/releases/2025/07/09/patch-release-gitlab-18-1-2-released/) ++ Gerrit Code Review [3.10.7](https://www.gerritcodereview.com/3.10.html#3107), +[3.11.4](https://www.gerritcodereview.com/3.11.html#3114), +[3.12.1](https://www.gerritcodereview.com/3.12.html#3121) ++ GitKraken [11.2.1](https://help.gitkraken.com/gitkraken-client/current/), +[11.2.0](https://help.gitkraken.com/gitkraken-client/current/), +[11.1.1](https://help.gitkraken.com/gitkraken-client/current/), +[11.1.0](https://help.gitkraken.com/gitkraken-client/current/), +[11.0.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.5.2](https://desktop.github.com/release-notes/), +[3.5.1](https://desktop.github.com/release-notes/) ++ Sourcetree [4.2.13](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.13.html) ++ GitButler [0.15.8](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.15.8), +[0.15.7](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.15.7) ++ Sublime Merge [Build 2110](https://www.sublimemerge.com/download) ++ Tower for Mac [13.1](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) ++ Tower for Windows [9.1](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) - [YT video](https://youtu.be/4pNRUz0bNIU) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Usman Akinyemi, brian m. carlson, Aditya Garg, +Erik-B. Ernst, Bruno Brito and Štěpán Němec. diff --git a/_posts/2025-08-31-edition-126.markdown b/_posts/2025-08-31-edition-126.markdown new file mode 100644 index 0000000000..bb1f32be1d --- /dev/null +++ b/_posts/2025-08-31-edition-126.markdown @@ -0,0 +1,648 @@ +--- +title: Git Rev News Edition 126 (August 31st, 2025) +layout: default +date: 2025-08-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 126 (August 31st, 2025) + +Welcome to the 126th 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 July and August 2025. + +## Discussions + + + + + + +### Support + +* [[BUG] `git pull` ignores `pull.autostash=true` configuration when used with `--git-dir` and `--work-tree` flags on a bare repository](https://lore.kernel.org/git/010001980c1ee007-2797fc86-fdf3-46e9-bec9-f8da2c9ebb8d-000000@email.amazonses.com/) + + Bryan Lee posted a bug report about the `pull.autostash` + configuration variable being ignored in a repository used to manage + his dotfiles. + + He expected his unstaged changes to be automatically stashed before + a pull when that configuration variable is set to `true`. Instead, + the command failed with an error message telling him to "Please + commit or stash them". So he thought Git ignored the autostash + configuration completely due to the setup, which consisted of a bare + repository and a separate work tree accessed through the following + alias: + + `$ alias dot='git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME'` + + Lidong Yan replied to Bryan admitting that he wasn't sure why the + autostash feature would be ignored when using the `--git-dir` and + `--work-tree` flags. He suggested setting `rebase.autostash` instead + of `pull.autostash` to `true` though. + + Bryan Lee thanked Lidong saying that `pull.autostash` was not a Git + configuration option and that `rebase.autostash` did work for + rebase operations. But he raised the issue that Git silently accepts + invalid configuration keys without any warning, which can cause + users to waste a lot of time debugging. + + Lidong replied with a suggestion to add a `git config verify` + subcommand. But Junio Hamano, the Git maintainer, chimed in + expressing doubts about such a command, as Git cannot distinguish + between a typo of a known variable and a legitimate custom variable + that a user or a third-party tool might be using. Lidong elaborated + that such a command could work by having Git maintain an internal + registry of all valid keys, which could also be extended by users + and tools for their own custom configurations. + + Johannes Sixt suggested that instead of building a complex + verification system, it would be easier to fix the origin of the + misconception that `pull.autostash` was the correct configuration. + + Junio replied to Johannes that having `git pull` pay attention to + `rebase.autostash` was at least a documentation failure, if not a + bug. He argued that users have different expectations for a + relatively safe local rebase compared to a pull from a remote, which + could be riskier. Also it didn't make sense for `git pull` to + respect `rebase.autostash` but not `merge.autostash`. + + Ben Knoble then chimed in with a counter-argument to Junio. He + reasoned that since a `git pull` that rebases is conceptually a + fetch followed by a rebase, it would be "far more inconsistent" if + it didn't honor the rebase configuration. Breaking that expectation + would be unnatural for users taught to think of pull in that + way. Following this logic, he also supported the idea that a merging + pull should respect `merge.autostash`. + + Then Junio wondered if introducing a new, dedicated `pull.autostash` + variable would be a good idea. But soon Lidong came up with + [a patch](https://lore.kernel.org/git/20250717030732.75106-1-yldhome2d2@gmail.com/) + to actually add this configuration variable. + + Eric Sunshine reviewed the patch and left a number of suggestions to + improve it in many ways. After some discussions with Lidong and + Junio, Lidong posted + [a version 2 of the patch](https://lore.kernel.org/git/20250720124334.12045-1-yldhome2d2@gmail.com/). + + This new version implemented a number of improvements based on the + discussion. Some tests were added. The logic was updated to fall + back to either `rebase.autostash` or `merge.autostash` depending on + whether the pull performed a rebase or a merge. The order of + precedence was also clarified: `pull.autostash` now overrides the + more general `rebase.autostash` and `merge.autostash` + settings. Finally, the documentation was updated with more precise + explanations. + + This feature was released recently as part of Git v2.51.0. + +## Developer Spotlight: Seyi Kuforiji + +_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 Outreachy 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?** + + My name is Seyi Kuforiji, and I’m an Outreachy alum who worked on + [modernizing Git’s unit testing platform](https://seyi-kuforiji-902b48.gitlab.io/posts/week-1-Introduce-yourself) + by converting its homegrown unit test framework to use [Clar](https://github.com/clar-test/clar). + I studied geography at the University of Lagos, but my curiosity + and passion for computers and software drove me to start learning + Python and Git immediately after graduating. + + Since then, I’ve enjoyed exploring different areas of IT, from + software engineering to data science and DevOps, because I genuinely + love learning and experimenting with new tools. I also earned a + certification in Health Data Science and Precision Medicine from + Stanford University, which reflects my commitment to leveraging + technology to improve lives. Participating in Outreachy through Git + demonstrated to me the impact of open-source collaboration, and it has + strengthened my passion for developing solutions that give back to the + community. + + Outside of work, I’m usually diving into something new. Right now, the + [Linux graphics stack](https://lwn.net/Articles/955376/) has caught my + attention, but when I decide to give my brain a break from tech, I play + chess or watch sports. + +* **How did you initially become interested in contributing to Git, + and what motivated you to choose it as your Outreachy project?** + + Git was one of the first tools I ever learned years ago. At first, I + didn’t really understand it; I only knew a few commands like + `git clone`, `git add .`, and `git commit -m ""`, and I was + living life with just those. I remember during my 12-month software + engineering bootcamp, I helped some of my colleagues with Git because + I had this so-called “prior knowledge”, and for a while, I was treated + like a genius, at least until they caught up! + + So when I saw Git on the list of Outreachy projects, I knew right away + that this was where I needed to be: to deepen my understanding of the + tool and maybe level up from “genius” to something closer to expert + wizardry. These days, some say I’m a wizard, others say I’m a maestro, + but I’m just a humble guy who enjoys learning and sharing knowledge. + +* **How do you feel your contribution has impacted the Git community + or the broader open source ecosystem?** + + My contribution to Git, which was modernizing its homegrown unit + testing framework to use Clar, has helped improve Git’s testing + capabilities by making the tests more maintainable, easier to + understand, and easier to extend to cover more edge cases in the + future. Clar brings additional benefits such as clearer test + reporting, a more structured way to organize tests, and improved + readability, which makes the testing process more approachable for new + contributors. While this was primarily an internal-facing improvement, + I believe it plays an important role in maintaining the reliability of + Git’s functions and operations. A stronger testing framework makes it + easier for both new and experienced contributors to work with the + codebase confidently, which in turn strengthens Git for the millions + of people who rely on it every day. + +* **Is there any aspect of Git that you now see differently after + having contributed to it?** + + Like I said earlier, I started out only knowing a handful of Git + commands to do basic operations. My biggest takeaway since + contributing to Git has been discovering the full power of its + interactive rebase. I always saw rebase on cheat sheets but never + really experienced its capabilities until I worked more deeply with + Git. The best way I can describe it is that it feels like a time + machine: I make changes and commits, Git captures those states in + time, and with interactive rebase, I can go back, rewrite history, and + improve it as if it were the first time. + + I still find it so cool that in my text editor, I can see files I had + already deleted in later commits come back to life during a rebase. It + completely changed how I view Git, not just as a version control + system, but as a powerful storytelling tool for code. + +* **How do you balance your contributions with other responsibilities + like work or school?** + + I usually create a schedule with a clear timeframe dedicated to + working on the Git project. For example, during Outreachy, I set aside + specific blocks of time each day, treating it almost like a regular + job. This helped me stay consistent, avoid distractions, and make + steady progress. + + I’ve learned that balancing open-source contributions with other + responsibilities is all about structure and prioritization. By + planning my week ahead, I can make sure that my work, personal life, + and contributions don’t clash. Of course, I also try to stay flexible; + 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 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 + this experience. I now feel much more confident working in a large and + complex codebase, and I’ve built the mindset to take on hard problems + without shying away. This confidence is what’s encouraging me to dive + deeper into the Linux kernel, where I’ve been learning and + experimenting with the graphics stack and GPU drivers. My knowledge of + Git itself has also grown significantly, particularly with the + interactive rebase functionality, which has completely changed how I + think about version control and history management. + + On the non-technical side, I grew a lot in communication and project + management. I learned how to break down tasks into smaller, achievable + goals, track progress against deadlines, and ask for help effectively + when I was stuck. Collaborating with mentors and the wider Git + community also taught me the importance of giving clear updates in + blog posts and writing thoughtful commit messages. + + Overall, the experience didn’t just make me a better programmer; it + made me more disciplined, collaborative, and confident in working on + real-world projects. + +* **What was your biggest takeaway or learning from Outreachy that + you now apply regularly in your work?** + + My biggest takeaway from Outreachy is the balance between + understanding deeply and taking action. My mentor encouraged me to not + just know how things work but also to dig into why they work. At the + same time, I learned that it’s easy to get stuck in the learning + phase, waiting until you feel "ready." During my first few weeks, I + hesitated too much. What really helped me was realizing that you don’t + need to know everything before you start; you just need enough to + begin, and the rest comes as you build and iterate. That shift has + stayed with me and is something I now apply regularly in my life. + +* **What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it?** + + One of the biggest challenges I faced was understanding the Git + codebase. Git is a very large and complex project with many + interconnected parts, and even though my task was limited to the unit + testing section, I also needed to understand the underlying + functionality being tested. At first, it felt daunting, but I overcame + this by burning the midnight candle, digging deeper, and committing + myself to continuous learning. Bit by bit, things started to make + sense. What really helped was breaking down the complexity into + smaller pieces and focusing on one area at a time, while also asking + lots of questions and referring back to documentation. + +* **Have you thought about mentoring new GSoC / Outreachy students?** + + Yes, I hope to mentor future Outreachy interns if the opportunity arises. + +* **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?** + + A first-class graphical interface officially maintained by the Git + project, for those who prefer using an app instead of the command + line. + +* **What upcoming features or changes in Git are you particularly + excited about?** + + I’ve been reading recent discussions on the Git mailing list about how + Git might evolve in the age of AI, particularly around enabling + integrations with AI agents. The idea of extending Git’s capabilities + so that AI tools can better understand, interact with, and even + automate certain workflows is quite exciting. For example, AI-assisted + code reviews, intelligent merge conflict resolution, or automated + repository maintenance could become more seamless if Git had + standardized ways for agents to plug into its internals. + +* **What is your favorite Git-related tool/library, outside of Git + itself?** + + GitHub and GitLab. + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I mostly work from the command line. For sending contributions, I use + `git format-patch` and `git send-email`, since I’m more comfortable with + CLI tools. + +* **How do you envision your own involvement with Git or other open + source projects in the future?** + + I intend to remain active in the Git community for many years by + making steady contributions. At the moment, I’m still learning and + exploring the project to identify areas where I can improve and add + value. Over time, I hope to grow into a consistent contributor and + take on more responsibility within the project. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + For anyone starting Git development, I’d recommend a few key + resources. The "[Hacking Git](https://git.github.io/Hacking-Git/)” + guide is definitely a go-to resource for understanding how the + project is structured and how to navigate the codebase. + The [MyFirstContribution](https://git-scm.com/docs/MyFirstContribution) + page is also very helpful for learning how to get started with making + changes. Beyond that, the general Git documentation is valuable for + building a solid foundation. Starting small, asking questions, and + getting familiar with these resources can make the process much + smoother. + +* **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?** + + 100% yes. Programs like GSoC and Outreachy give you the unique + opportunity to learn directly from some of the smartest and most + experienced contributors in the Git community. Having a mentor to + guide you through real contributions accelerates your learning, helps + you build confidence and good practices early on. I’d absolutely + recommend it. My advice would be: come with curiosity, patience, and + the willingness to learn. Don’t worry if you don’t understand + everything at first. Ask questions, read the documentation, and engage + with the community. The mentorship and the experience you gain are + invaluable. + + +## Other News + +__Various__ + ++ [What’s new in Git 2.51.0?](https://about.gitlab.com/blog/what-s-new-in-git-2-51-0/) + by Karthik Nayak on GitLab Blog. It describes performance optimizations + for `git push` and `git fetch` (most significant when using the "reftable" + backend for references), further plans for Git 3.0 (which can be + found in the [BreakingChanges document](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/BreakingChanges.adoc)), semi-removal of `git whatchanged` + (still available with `--i-still-use-this` flag), and marking + `git switch` and `git restore` as no longer experimental, + adding a new `--start-after` flag for `git for-each-ref` (that can be + combined with the `--count` flag to support pagination), etc. ++ [Highlights from Git 2.51](https://github.blog/open-source/git/highlights-from-git-2-51/) + by Taylor Blau on GitHub Blog. It describes cruft-free multi-pack indexes + (which currently require setting a new `repack.MIDXMustContainCruft` config option), + smaller packs with a "path walk" method of collecting objects when repacking + (which you can try out with the new `--path-walk` command-line option), + a variant of the internal stash representation that can be used for stash interchange + (with new `export` and `import` commands for `git stash`), etc. ++ [Xet is now the default storage option for new users and organizations](https://huggingface.co/changelog/xet-default-for-new-users) + at [Hugging Face](https://huggingface.co/), switching from [Git LFS](https://git-lfs.com/). + This includes moving existing repositories from LFS to Xet. + To get the most out of Xet storage [read the usage instructions in the Hub docs](https://huggingface.co/docs/hub/en/storage-backends#using-xet-storage). + Note that Xet remains backward compatible with legacy clients optimized for Git LFS. + + [XetHub](https://xethub.com/) was first mentioned in passing in + [Git Rev News #95](https://git.github.io/rev_news/2023/01/31/edition-95/), + and its [benchmark by XetHub against S3, DVC, and Git LFS](https://about.xethub.com/blog/benchmarking-the-modern-development-experience) + was mentioned in [Git Rev News Edition #113](https://git.github.io/rev_news/2024/07/31/edition-113/). + + Compare with [DagsHub launching Direct Data Access in 2022](https://dagshub.com/blog/launching-data-streaming-and-upload/). + [DagsHub](https://dagshub.com/) was first mentioned in + [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/), + then in [#85](https://git.github.io/rev_news/2022/03/31/edition-85/), + [#96](https://git.github.io/rev_news/2023/02/28/edition-96/), + [#107](https://git.github.io/rev_news/2024/01/31/edition-107/), and + [#113](https://git.github.io/rev_news/2024/07/31/edition-113/). + + +__Light reading__ + ++ [The future of large files in Git is Git](https://tylercipriani.com/blog/2025/08/15/git-lfs/) + by Tyler Cipriani on his blog. It describes how one can use + partial clone today (and large object promisors in the future, + which are work in progress) instead of using [Git LFS](https://git-lfs.com/) + or similar solutions like [git-annex](https://git-annex.branchable.com/) + (or no longer actively developed solutions like git-media and git-fat) + or [DVC](https://dvc.org/) (Data Version Control). ++ [Code Review Can Be Better](https://tigerbeetle.com/blog/2025-08-04-code-review-can-be-better/) + (than GitHub's default code review process) + by matklad (Alex Kladov) on the TigerBeetle blog.
+ Mentions their [`git-review`](https://github.com/tigerbeetle/tigerbeetle/pull/2732) + work-in-progress tool, and also the + + [Fossil](https://fossil-scm.org/) version control system with built-in project management + (first mentioned in [Git Rev News Edition #11](https://git.github.io/rev_news/2016/01/13/edition-11/)), the + + [NoteDb](https://gerrit-review.googlesource.com/Documentation/note-db.html) backend + for [Gerrit](https://www.gerritcodereview.com/) - which allows storing review state in Git, + (NoteDb was first mentioned in [Git Rev News Edition #40](https://git.github.io/rev_news/2018/06/20/edition-40/)), the + + [git-bug](https://github.com/git-bug/git-bug) tool that uses Git to store information about issues / bugs + (first mentioned in [Git Rev News Edition #43](https://git.github.io/rev_news/2018/09/19/edition-43/)), the + + [git-appraise](https://github.com/google/git-appraise) tool that uses Git to store information about reviews + (first mentioned in [Git Rev News Edition #11](https://git.github.io/rev_news/2016/01/13/edition-11/)), the + + [prr](https://doc.dxuuu.xyz/prr/index.html) ('pull request review') tool that brings mailing list style code reviews to GitHub PRs + (mentioned in [Git Rev News Edition #90](https://git.github.io/rev_news/2022/08/31/edition-90/)), the + + [git-pr](https://pr.pico.sh/) project that leverages Git native features to replace the entire pull request workflow, + (mentioned in [Git Rev News Edition #113](https://git.github.io/rev_news/2024/07/31/edition-113/)), and the + + [How Jane Street Does Code Review](https://www.janestreet.com/tech-talks/janestreet-code-review/) + article by Ian Henry on Jane Street Tech Talks site. ++ [Jujutsu + Radicle = ❤️](https://radicle.xyz/2025/08/14/jujutsu-with-radicle) + by fintohaps on Radicle Blog, describing how the author uses Jujutsu in tandem with Radicle. + + [Jujutsu (`jj`)](https://jj-vcs.github.io/jj/) is a Git-compatible version control system + written in Rust, and was first mentioned in + [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). + + [Radicle](https://radicle.xyz/), a peer-to-peer, local-first code collaboration stack built on Git, + was first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/). ++ [introducing spindle](https://blog.tangled.sh/ci) by Anirudh & Akshay on Tangled blog; + spindle is Tangled’s new CI runner built atop Nix and the AT Protocol. + + [Tangled.sh](https://blog.tangled.sh/intro) is a new social-enabled Git collaboration platform + built on top of the AT Protocol (which is behind [BlueSky](https://bsky.app/) + microblogging federated social media service). + First mentioned in [the previous edition of Git Rev News](https://git.github.io/rev_news/2025/07/31/edition-125/). + + Compare the [Using Radicle CI for Development](https://radicle.xyz/2025/07/23/using-radicle-ci-for-development) + article by Lars Wirzenius, also mentioned in [Git Rev News #125](https://git.github.io/rev_news/2025/07/31/edition-125/). + [Radicle](https://radicle.xyz/) is another distributed Git hosting system, + first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/). ++ [How we used Radicle with GitHub Actions](https://radicle.xyz/2025/05/30/radicle-with-github-actions): + Quick guide to trying Radicle without dropping GitHub or whatever CI you’re using. + Published by rudolfs (Rūdolfs Ošiņš) on Radicle Blog. ++ [Archive Legacy GitHub Repos with Subtree](https://dev.to/tonymet/archive-legacy-github-repos-with-subtree-1dj3) + by Tony Metzidis on DEV\.to, about how to use `git subtree` to consolidate + hundreds of legacy experimental repos into an archive, + preserving all of the commit history. ++ [I'll think twice before using Github Actions again](https://ninkovic.dev/blog/2025/think-twice-before-using-github-actions) + by Nemanja Ninković on their blog. ++ [Git without a forge](https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/) + by Simon Tatham on his quasiblog, describing how to interact with a bare Git repo, + and explaining why he personally does not use any of the Git forges. ++ [How I Cleaned Up My Git History Like a Boss (a.k.a. Fixing Wrong Author Emails)](https://dev.to/emrahg/how-i-cleaned-up-my-git-history-like-a-boss-aka-fixing-wrong-author-emails-19lb) + by Emrah G. on DEV\.to. The solution uses the (deprecated) `git filter-branch` tool; + the recommended replacement is [`git filter-repo`](https://github.com/newren/git-filter-repo). + Also, you can correct the _visible_ e-mail with the [`.mailmap`](https://git-scm.com/docs/gitmailmap) file + (changing what Git shows, without having to rewrite history). ++ [Revolutionizing Git Workflows: The MCP Git Commit Generator](https://www.bampouris.eu/blog/mcp-git-commit-generator/) + by Theoklitos Bampouris on his blog (and also [on DEV\.to](https://dev.to/theoklitosbam7/revolutionizing-git-workflows-the-mcp-git-commit-generator-530m)), + about using Agentic AI and an LLM chatbot, + leveraging the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction). + The generated commit message will follow [Conventional Commits](https://www.conventionalcommits.org/) conventions.
+ Note: please read the proposed commit message before accepting it, + especially for more complex changes. While AI agents can take information + from changes and from an issue tracker, they cannot write whys of the change; + they cannot access your thoughts. + + [Git Rev News Edition #97](https://git.github.io/rev_news/2023/03/31/edition-97/) + lists a few other tools that use the GPT-3 / ChatGPT Large Language Model (LLM) + to help write commit messages. ++ [Better git status](https://purpleidea.com/blog/2025/08/04/better-git-status/) + by James (@purpleidea) on his blog. He uses `git alias` which examines + the terminal width, and then `git status --column=nodense` if the terminal is wide enough. ++ [Some Pretty Cool Git Tools To Save Your Sanity](https://fev.al/posts/git-tools/) + by Charles Féval on his blog. + Mentions `git revise` for splitting pull requests (PRs), + and custom `git backup`, `git reparent`, `git split`, `git move-branch`, and `git bookmark` commands. ++ [Using Git worktrees for development](https://blog.kulman.sk/git-worktree/) + by Igor Kulman on his blog. ++ [Curing A Case Of Git-UX](https://oppi.li/posts/curing_a_case_of_git-UX/) + by Akshay on their blog; describes how one can improve git worktree UX + with the help of [fzf](https://github.com/junegunn/fzf) + (or [skim](https://github.com/lotabout/skim) or [fzy](https://github.com/jhawthorn/fzy)), + and shell functions. + + 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/). ++ [Making my GitHub heatmap widget](https://leanrada.com/notes/github-heatmap-widget/) by + Lean Rada on their blog. The created tool partially scrapes and reformats HTML input, + but is constructed in such way that it could consume JSON from GitHub API instead. ++ [TryHackMe - Git Happens](https://jacen.moe/blog/20250805-tryhackme-git-happens/) + by Jacen Sekai on his blog, about [Git Happens](https://tryhackme.com/room/githappens): + an easy-ranked box on [TryHackMe](https://tryhackme.com/), website for + hands-on cyber security training through real-world scenarios. ++ [The Ingredients of a Productive Monorepo](https://blog.swgillespie.me/posts/monorepo-ingredients/) + by Sean Gillespie on his blog. + + You can find a definition of "monorepo" and a list of various tools on the [Monorepo.tools](https://monorepo.tools/) site, + which was first mentioned in [Git Rev News Edition #84](https://git.github.io/rev_news/2022/02/28/edition-84/). ++ [Git Branching Explained: Base, Topic, and Parent Branches](https://www.git-tower.com/blog/base-topic-parent-branches) + by Bruno Brito on Tower Blog. ++ [Git and jujutsu: in miniature](https://lottia.net/notes/0013-git-jujutsu-miniature.html) + by Charlotte (lottia) on her blog (2024). ++ [Git Interactive Rebase TODO Order is Wrong](https://salferrarello.com/git-interactive-rebase-order-is-wrong/) + by Sal Ferrarello on his blog (2019), stating a personal preference for stack-like order, + with latest commits appearing on the top.
+ The author even wrote a Vim plugin, + [Interactive Rebase Reverse Vim](https://github.com/salcode/vim-interactive-rebase-reverse), + to reverse the order of the commits in an interactive `git rebase`. ++ [Every line of code is always documented](https://mislav.net/2014/02/hidden-documentation/) + by Mislav Marohnić on his blog (2014). The article describes how to + extract information about a code snippet from project history using `git blame`, + 'pickaxe' search with `git log -S`, and a + [git-churn](https://github.com/garybernhardt/dotfiles/blob/f0c0ff92209e5aed4fa3ef6faf056eb9944a8f12/bin/git-churn) script, + and how to stay on the right side of history + (among others, to be able to use this technique effectively). + + + + +__Git tools and sites__ + ++ [WRKFLW](https://github.com/bahdotsh/wrkflw) is a command-line tool + for validating and executing GitHub Actions workflows locally, + without requiring a full GitHub environment. + It helps developers test their workflows directly on their machines + before pushing changes to GitHub. + Written in Rust, under MIT license. + + Compare with the [Act](https://github.com/nektos/act) command line tool + to run your GitHub Actions locally, using the Docker Engine API. + Written in Go, under MIT license. + Mentioned in [Git Rev News Edition #113](https://git.github.io/rev_news/2024/07/31/edition-113/). ++ [Setup DVC Action](https://github.com/marketplace/actions/setup-dvc-data-version-control) + by Iterative is a JavaScript action that can be used as a step in GitHub Actions.
+ [DVC](https://dvc.org) (Data Version Control) was first mentioned + in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/) + and many times since (most recently in [Edition #116](https://git.github.io/rev_news/2024/10/31/edition-116/)). ++ [Lappverk](https://codeberg.org/natkr/lappverk/) is a tool for modifying other people's software. + It works by keeping a series of `.patch` files as its source of truth + (like [quilt](https://savannah.nongnu.org/projects/quilt)), + but using temporary Git repositories as an interface to modify the patches, + rather than implementing its own version control system from scratch. + Written in Rust, under Apache 2.0 License. + Started out as Patchable internal tool.
+ You might also be interested in reading the announcement blog post: + [Modifying Other People's Software](https://natkr.com/2025-08-14-modifying-other-peoples-software/) + by Natalie Klestrup Röijezon (natkr) on natkr's ramblings. + + Compare [patchwork](http://jk.ozlabs.org/projects/patchwork/) - a web-based patch tracking system + designed to facilitate contribution and management of contributions to an open-source project, + first mentioned in [Git Rev News Edition #20](https://git.github.io/rev_news/2016/10/19/edition-20/). + + Compare [Stacked Git (StGit)](https://stacked-git.github.io/), + an application for managing Git commits as a stack of patches, + first mentioned in [Git Rev News Edition #17](https://git.github.io/rev_news/2016/07/20/edition-17/). + + Compare [B4 Tools](https://github.com/mricon/b4), a helper utility + to work with patches made available via a [public-inbox](https://public-inbox.org/README.html) archive like [lore.kernel.org](https://lore.kernel.org/). + This tool is written to make it easier to participate in patch-based workflows, + like those used in the Linux kernel development. + First mentioned in [Git Rev News Edition #61](https://git.github.io/rev_news/2020/03/25/edition-61/). ++ [patch-hub](https://github.com/kworkflow/patch-hub/tree/unstable) is a TUI tool + that streamlines the interaction of Linux developers + with patches archived on [lore.kernel.org](https://lore.kernel.org/). + Written in Rust, under GPL 2.0 license.
+ It is a spin-off of [kw](https://github.com/kworkflow/kworkflow), + a tool for helping Linux kernel developers in everyday tasks + (which is written in shell, and is under GPL 2.0 license). ++ [GitGenius](https://selvaneyas.github.io/gitgenius) is a smart and simple CLI tool + that explains Git errors in plain English and helps you fix them quickly. + Written in Python, under MIT license. + + See also [thefuck](https://github.com/nvbn/thefuck), a command line application + which corrects your previous console command (for example Git command) + if you made an error (like typos in command name), and it _didn't_ do what you wanted; + the tool was first mentioned in [Git Rev News Edition #101](https://git.github.io/rev_news/2023/07/31/edition-101/). + + Compare the [Oh Shit, Git!?!](http://ohshitgit.com/) / [Dangit, Git!?!](https://dangitgit.com/) + website by Katie Sylor-Miller, + first mentioned in [Git Rev News Edition #19](https://git.github.io/rev_news/2016/09/14/edition-19/). ++ [GIT.WTF!?!](https://git.wtf/) is a website with articles in which you can + find solutions to your Git problems, + along with tips & tricks to improve your Git workflows. ++ [GITHUB2FORGEJO](https://github.com/PatNei/GITHUB2FORGEJO) + is a Bash script for migrating all repositories from a GitHub user account + to a specified Forgejo instance. It supports mirroring or one-time cloning + and includes a cleanup feature for removing repositories on Forgejo + that no longer exist on GitHub. + Under GPL 3.0 license.
+ Based on [GitHub2Forgejo](https://github.com/RGBCube/GitHub2Forgejo) + Nushell script, also under GPL 3.0 license. + + [Forgejo](https://forgejo.org/) is a self-hosted lightweight software forge, + which started as a “soft” fork of Gitea (itself a fork of Gogs), + and was first mentioned in passing in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/). ++ [git-revise](https://git-revise.readthedocs.io/) is a Git subcommand and Python library + for efficiently updating, splitting, and rearranging commits. + Under MIT License.
+ The [Introducing git-revise](https://mystor.github.io/git-revise.html) + blog post was mentioned in [Git Rev News Edition #54](https://git.github.io/rev_news/2019/08/21/edition-54/). ++ [git-tools](https://github.com/cfe84/git-tools) is a set of additional Git commands + to "help you make crazy stuff in a very unsafe way". + Includes `git backup`, `git move-branch`, `git reparent` (similar to `git rebase --onto`), + `git split`, `git bookmark`, `git newbranch`, and `git get`. + Written in Go, under GPL 2.0 license. ++ [git-fetch-file](https://github.com/andrewmcwattersandco/git-fetch-file) is a utility + for importing specific files from other Git repositories into your own project, + while keeping a manifest (`.git-remote-files`) that remembers where they came from + and what commit they belong to. + Written in Python, under GPL 2.0 license. ++ [git-word-blame](https://framagit.org/mdamien/git-word-blame) + is a tool that shows word-by-word authors of a file, creating TSV and HTML files. + Written in Python, under GPL 3.0 license. + The README includes links to a few alternative tools in the "See also" section. ++ [`gguser`](https://github.com/withshubh/gguser) is a CLI tool + to easily switch between different Git user profiles. + It simplifies managing multiple GitHub or GitLab accounts + by allowing users to switch between profiles effortlessly. + Written in JavaScript for Node.js (npm), under Apache 2.0 License. ++ [GitLabForm](https://gitlabform.github.io/gitlabform/) is a specialized configuration-as-code tool + for GitLab's application settings, groups, projects, and more, + using hierarchical configuration written in YAML. + Written in Python, under MIT license.
+ See the [GitlabForm for Gitlab repository automation](https://www.mikestreety.co.uk/blog/gitlabform-for-gitlab-repository-automation/) + blog post by Mike Street on his blog. ++ [`gmap`](https://github.com/seeyebe/gmap) is a fast command-line tool + (with terminal interface) to explore Git activity - heatmaps, churn, authorship, and more. + It helps you understand your Git repository at a glance - not just what changed, + but when, how much, and by whom. + Written in Rust, under MIT license. ++ [Ayllu](https://ayllu-forge.org/) is a code forge optimized for single instance deployments. + It is still a work in progress. Written in Rust, under AGPL license. ++ [DiffMem](https://github.com/Growth-Kinetics/DiffMem) is a lightweight, + Git-based memory backend designed for AI agents and conversational systems. + It uses Markdown files for human-readable storage, + Git for tracking temporal evolution through differentials, + and an in-memory BM25 index for fast, explainable retrieval. + This project is a proof-of-concept (PoC). + Written in Python, no license (!). + + +## Releases + ++ Git [2.51.0](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/), +[2.51.0-rc2](https://lore.kernel.org/git/xmqqh5ybcfwt.fsf@gitster.g/), +[2.51.0-rc1](https://lore.kernel.org/git/xmqqikizoybn.fsf@gitster.g/), +[2.51.0-rc0](https://lore.kernel.org/git/xmqqms8f5889.fsf@gitster.g/) ++ Git for Windows [v2.51.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.0.windows.1), +[v2.51.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.0-rc2.windows.1), +[v2.51.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.0-rc1.windows.1), +[v2.51.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.0-rc0.windows.1) ++ GitLab [18.3.1, 18.2.5, 18.1.5](https://about.gitlab.com/releases/2025/08/27/patch-release-gitlab-18-3-1-released/), +[18.3](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/), +[18.2.4](https://about.gitlab.com/releases/2025/08/18/gitlab-18-2-4-released/), +[17.11.7](https://about.gitlab.com/releases/2025/08/15/gitlab-17-11-7-released/), +[18.2.2, 18.1.4, 18.0.6](https://about.gitlab.com/releases/2025/08/13/patch-release-gitlab-18-2-2-released/) ++ Gerrit Code Review [3.10.8](https://www.gerritcodereview.com/3.10.html#3108), +[3.11.5](https://www.gerritcodereview.com/3.11.html#3115), +[3.12.2](https://www.gerritcodereview.com/3.12.html#3122) ++ GitHub Enterprise [3.17.5](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.5), +[3.16.8](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.8), +[3.15.12](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.12), +[3.14.17](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.17) ++ GitKraken [11.3.0](https://help.gitkraken.com/gitkraken-client/current/) ++ Git Cola [4.14.0](https://github.com/git-cola/git-cola/releases/tag/v4.14.0) ++ GitButler [0.15.16](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.15.16), +[0.15.15](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.15.15) ++ Sublime Merge [Build 2112](https://www.sublimemerge.com/download) ++ Tower for Mac [14](https://www.git-tower.com/blog/tower-mac-14) ([YouTube video](https://youtu.be/WYhtxBAzOB0)) ++ Kinetic Merge [1.9.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.9.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Štěpán Němec, Gerard Murphy, +Seyi Kuforiji and Bruno Brito. diff --git a/_posts/2025-09-30-edition-127.markdown b/_posts/2025-09-30-edition-127.markdown new file mode 100644 index 0000000000..bf5ec5474c --- /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 0000000000..40be28f553 --- /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/_posts/2025-11-30-edition-129.markdown b/_posts/2025-11-30-edition-129.markdown new file mode 100644 index 0000000000..404db4a3c1 --- /dev/null +++ b/_posts/2025-11-30-edition-129.markdown @@ -0,0 +1,605 @@ +--- +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 contrary, 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 in the success or failure of the + command, but also in the end result of applying the patch. Was that + end result similar to the result of `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 though it looked + like `git cherry-pick` worked as expected, that still seemed a + strange behavior. + + 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 understand 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(CTF) + 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 about that feature's 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; they are what makes the world as it is today, + and carrying that forward I want to contribute in a way which makes + software 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, + a new subcommand for the 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 the `git last-modified` command for tree-level blame information, + advanced repository maintenance strategies for `git maintenance`, + new subcommands added to `git refs`, the experimental `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/). + That edition also includes 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 accidentally 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 the low-level `git update-index --chmod=+x ` "plumbing" command + first, instead of the corresponding 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 the "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`, `git commit --fixup`, and `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 and 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 the repository name from your Git remote, + auto-detects the 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 this class was added", + or "search_commits(query="authentication login changes", limit=5)". + Uses Microsoft's all-MiniLM-L6-v2 embedding 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 piping `git diff` output into it (`git diff | dunk` or `git diff | dunk | less -R`). + In 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 `git 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 a [`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 a 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 does a few other things. + There is a 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 point 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 the Latent Dirichlet Allocation (LDA) method. + There is also a [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 a GraphQL API. + Josh is distributed via [Docker Hub](https://hub.docker.com/r/joshproject/josh-proxy), + and you can start it with the 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 high score 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 (that is, 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 Ayush Chandekar, Štěpán Němec, +Bruno Brito and D. Ben Knoble. diff --git a/css/main.css b/css/main.css index f46e43f435..07ab16a9c3 100644 --- a/css/main.css +++ b/css/main.css @@ -35,16 +35,33 @@ body { -webkit-box-flex: 1; -webkit-flex: 1; -ms-flex: 1; - flex: 1; max-width: 700px; } .navbar { float: left; + position: -webkit-sticky; + position: sticky; + top: 0; text-align: left; + height: fit-content; width: 15em; padding: 2em; - padding-right: 0; +} + +.navbar > ul { + margin: 0; + list-style: none; + position: relative; + line-height: 0; +} + +.navbar > ul > li { + margin: .5rem 0; +} + +.navbar > ul > li.active { + font-weight: bold; } #menuLinkBar { @@ -64,6 +81,7 @@ body { display: -ms-flexbox; display: flex; margin: 0 auto; + width: 100%; justify-content: center; } @@ -80,6 +98,7 @@ body { -webkit-order: 2; -ms-flex-order: 2; order: 2; + padding: 1em; } .navbar { width: auto; @@ -87,6 +106,7 @@ body { -webkit-order:3; -ms-flex-order:3; order:3; + padding: 1em; } #menuLinkBar { display: block; @@ -795,10 +815,10 @@ pre { -moz-border-radius: 3px; -ms-border-radius: 3px; -o-border-radius: 3px; + white-space: pre-wrap; border-radius: 3px; display: block; padding: 10px 15px 13px 15px; - margin: 0 3em 1em 3em; background-color: #fff; border: solid 1px #efeee6; line-height: 18px; @@ -2015,7 +2035,7 @@ th, td { } img { - max-width: 100%; + max-width: 50%; } /* Table of contents */ @@ -2062,3 +2082,30 @@ img { padding-left: 2em; text-indent: -2em; } + +@media screen and (min-width: 800px) { + img[alt$=">"] { + float: right; + } + + /* + * Below styles could be useful when we position + * images to left / center. They're commented now + * since we don't use images in our site much. + * + * Ref: https://stackoverflow.com/a/39614958/5614968 + */ + /* + img[alt$="<"] { + float: left; + } + + img[alt$="><"] { + display: block; + max-width: 100%; + height: auto; + margin: auto; + float: none!important; + } + */ +} diff --git a/rev_news/drafts/edition-130.md b/rev_news/drafts/edition-130.md new file mode 100644 index 0000000000..860f707eaf --- /dev/null +++ b/rev_news/drafts/edition-130.md @@ -0,0 +1,60 @@ +--- +title: Git Rev News Edition 130 (December 31st, 2025) +layout: default +date: 2025-12-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 130 (December 31st, 2025) + +Welcome to the 130th 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 November and December 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/script/script.js b/script/script.js new file mode 100644 index 0000000000..4e0dfb012a --- /dev/null +++ b/script/script.js @@ -0,0 +1,9 @@ +const NAVBAR_LI_ELEMENTS = document.getElementById('navbar').firstElementChild.children; // Access all the
  • in side navigation + +// check for a match with the
  • element and SITE_URL, then make it active +Array.from(NAVBAR_LI_ELEMENTS).forEach((liElement) => { + if (liElement.firstElementChild.href == location.href) { + liElement.classList.add('active'); + return; + } +}) \ No newline at end of file