diff --git a/GSoC-Participants.md b/GSoC-Participants.md index 275c46c2b..df82c0b85 100644 --- a/GSoC-Participants.md +++ b/GSoC-Participants.md @@ -8,6 +8,17 @@ to Git via GSoC. +### 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/) ] diff --git a/General-Application-Information.md b/General-Application-Information.md index 69a7d27bc..7a2402b95 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) @@ -130,6 +132,110 @@ 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. @@ -247,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 75e467370..c98caeab8 100644 --- a/General-Microproject-Information.md +++ b/General-Microproject-Information.md @@ -39,18 +39,17 @@ 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 +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 @@ -62,7 +61,7 @@ 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`. @@ -75,7 +74,7 @@ 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. @@ -98,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 @@ -106,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 @@ -140,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. @@ -173,7 +175,7 @@ rewriting a small amount of code, your patch should change only "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: ". @@ -186,7 +188,7 @@ of them. 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](http://public-inbox.org/git/) are your friends) what +[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 @@ -210,6 +212,15 @@ 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. +## 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 @@ -372,11 +383,8 @@ tell us about your skills, interests, experience, background, etc. Feel free to tell us what you want about yourself if you wish though. -### Specify the mentoring program in the subject - -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 @@ -483,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 diff --git a/Hacking-Git.md b/Hacking-Git.md index 9b9677733..c8e9fef2b 100644 --- a/Hacking-Git.md +++ b/Hacking-Git.md @@ -18,7 +18,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 @@ -36,7 +38,7 @@ suggest improvements. Thanks! * ["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) @@ -54,7 +56,7 @@ 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 @@ -62,9 +64,9 @@ suggest improvements. Thanks! * [Sending patches by email with git](https://flusp.ime.usp.br/git/sending-patches-by-email-with-git/) is Matheus' git send-email tutorial. -* [lore.kernel.org/git](https://lore.kernel.org/git/) is our prefered mailing list archive. +* [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 behing lore.kernel.org. +* [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. @@ -80,7 +82,7 @@ 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. @@ -100,13 +102,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) diff --git a/Mentoring-Program-Guide.md b/Mentoring-Program-Guide.md index 89176a0c1..52d2b4796 100644 --- a/Mentoring-Program-Guide.md +++ b/Mentoring-Program-Guide.md @@ -444,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) diff --git a/Outreachy-21-Microprojects.md b/Outreachy-21-Microprojects.md index 2c9762fdc..cffa96590 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/SoC-2014-Microprojects.md b/SoC-2014-Microprojects.md index dceeccf26..f735a8a30 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 8d558eca0..2248169e8 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 b8df3a6ed..de0a0a729 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 9d66a0c6d..c5044c32c 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 3d3bebda5..54c5184b1 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 a0b349c9f..ef4a09b3e 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 7b4adf734..8a33938ff 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 94315b9c3..da3b6c8f3 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 80ef93c4d..9bec90f90 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 f2e94aba4..ce6d43cd6 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 1d1fc3f82..9a69ccb00 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 8e3bc62e9..90a0ab1cb 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-2023-Ideas.md b/SoC-2023-Ideas.md index 4c7cf5dac..582cfcd75 100644 --- a/SoC-2023-Ideas.md +++ b/SoC-2023-Ideas.md @@ -77,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 index 579a76042..041eba592 100644 --- a/SoC-2024-Ideas.md +++ b/SoC-2024-Ideas.md @@ -1,6 +1,7 @@ --- layout: default title: SoC 2024 Ideas +navbar: false --- ![git logo >](https://git-scm.com/images/logos/downloads/Git-Logo-2Color.svg) @@ -54,7 +55,7 @@ the reftable ones. - - - - - + - Expected Project Size: 175 hours or 350 hours @@ -76,7 +77,7 @@ the new framework. See: - this discussion - - + - - Expected Project Size: 175 hours or 350 hours diff --git a/SoC-2024-Microprojects.md b/SoC-2024-Microprojects.md index b0765bebd..c832f49f3 100644 --- a/SoC-2024-Microprojects.md +++ b/SoC-2024-Microprojects.md @@ -1,6 +1,7 @@ --- layout: default title: SoC 2024 Applicant Microprojects +navbar: false --- ## Introduction diff --git a/SoC-2025-Ideas.md b/SoC-2025-Ideas.md new file mode 100644 index 000000000..fac121ab4 --- /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 000000000..d382dbf69 --- /dev/null +++ b/SoC-2025-Microprojects.md @@ -0,0 +1,214 @@ +--- +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 + +### Fix Sign Comparison Warnings in Git's Codebase + +Help improve Git's code quality by fixing sign comparison warnings in files that +currently disable these warnings. The goal is to remove instances of +`DISABLE_SIGN_COMPARE_WARNINGS` macro and fix the underlying issues properly. + +#### Steps to Complete +1. Find a C source file that contains `#define DISABLE_SIGN_COMPARE_WARNINGS` +2. Remove this #define +3. Build Git with `DEVELOPER=1` to enable compiler warnings. The `DEVLEOPER` + can be specified in your `config.mak` or as follows + + ```sh + make DEVELOPER=1 -j4 + ``` + +4. Fix all `-Wsign-compare` warnings that appear for that file: + - Pay attention to comparisons between signed and unsigned integers + - Modify variable types or add appropriate casts as needed + - Ensure the fixes don't change the code's behavior + +#### Notes +- Each file should be handled in a separate patch +- Follow Git's commit message conventions +- Test your changes thoroughly +- This is part of an ongoing effort to enable `-Wsign-compare` globally + +#### Related Patches +For context on why this is a crucial improvement to Git's codebase, checkout +[this e-mail](https://public-inbox.org/git/20241206-pks-sign-compare-v4-0-0344c6dfb219@pks.im/) +by Patrick Steinhardt. + + +### 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/_posts/2015-04-15-edition-2.markdown b/_posts/2015-04-15-edition-2.markdown index 5fe035801..9ce60b992 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 f5d494ec2..3a81e2797 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 bea80587f..29965bb76 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 da15b2d14..9024c85aa 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 539f49864..d9de76ea4 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 858af32c5..6e0439d34 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 0839f8f34..e3c3292ad 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 d5ff0ecb3..a61170cb6 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 7c1285572..8f2bdf66a 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 1121afbb7..c74e9aac1 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 c8a065204..a62b4aed3 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 4b61c9ea9..86ee31687 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 846184d86..2ec0779e3 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 298083b16..080eb06e4 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 ee4c0a919..acff8d432 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 3b5ba0ede..4b59ec333 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 bee7863d5..8289698a5 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 a58d63ada..194bf450b 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 860ae0e4d..0c6e7870a 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 543c5451b..a06aecaef 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 6b23618c5..a1c955e74 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. + + + +### 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 000000000..ffa294b1b --- /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 000000000..b7deb451a --- /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 000000000..3e38e4eaa --- /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 000000000..8ad9194cd --- /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 000000000..ce754e063 --- /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 000000000..98ace1084 --- /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/rev_news/drafts/edition-116.md b/rev_news/drafts/edition-123.md similarity index 74% rename from rev_news/drafts/edition-116.md rename to rev_news/drafts/edition-123.md index 4dce659e6..ee42dedcd 100644 --- a/rev_news/drafts/edition-116.md +++ b/rev_news/drafts/edition-123.md @@ -1,19 +1,19 @@ --- -title: Git Rev News Edition 116 (October 31st, 2024) +title: Git Rev News Edition 123 (May 31st, 2025) layout: default -date: 2024-10-31 12:06:51 +0100 +date: 2025-05-31 12:06:51 +0100 author: chriscool categories: [news] navbar: false --- -## Git Rev News: Edition 116 (October 31st, 2024) +## Git Rev News: Edition 123 (May 31st, 2025) -Welcome to the 116th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +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 September 2024 and October 2024. +This edition covers what happened during the months of April 2025 and May 2025. ## Discussions