diff --git a/.gitignore b/.gitignore index 29949d465..eb676c0ab 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,3 @@ /_site /Gemfile.lock +/vendor diff --git a/Gemfile b/Gemfile index a7bf33a1b..3cc8ef00a 100644 --- a/Gemfile +++ b/Gemfile @@ -2,3 +2,7 @@ source 'https://rubygems.org' # Because https://help.github.com/articles/using-jekyll-with-pages/ gem 'github-pages', group: :jekyll_plugins + +# gem "webrick", "~> 1.7" # N.B. we may not want to fix this Gemfile to Ruby 3 +gem "webrick" +gem 'jekyll-redirect-from' \ No newline at end of file diff --git a/README.md b/README.md deleted file mode 120000 index 555cdc1cb..000000000 --- a/README.md +++ /dev/null @@ -1 +0,0 @@ -_includes/README.md \ No newline at end of file diff --git a/README.md b/README.md new file mode 100644 index 000000000..99d880180 --- /dev/null +++ b/README.md @@ -0,0 +1,46 @@ +## Git Developer Pages + +- This is a website for information on Git development. If you stumbled into this by mistake, you may want: + - Information on running Git and links to download the latest version from [HERE](https://git-scm.com/) + - Wiki that has historically contained developer information from [HERE](https://git.wiki.kernel.org/index.php/Main_Page) + +- These pages are intended to collect information useful to Git developers. This is also the web home of: + - the [Hacking Git](https://git.github.io/Hacking-Git/) page, + - the [Git Rev News newsletter](https://git.github.io/rev_news/), + - the [involvement of the Git project in mentoring programs](https://git.github.io/General-Application-Information/) like [Outreachy](https://www.outreachy.org/) and the [GSoC (Google Summer of Code)](https://summerofcode.withgoogle.com/) + +- These pages are intended to be edited collaboratively (i.e., it is an alternative to us having a wiki, but one that is edited entirely via Git pushes). + + You could also send your changes as patches by email to Christian Couder < > / Kaartic Sivaraam < > (and feel free to cc git@vger.kernel.org if appropriate). + + +### Development + +If you wish to spin up the site locally, you could follow the steps below. + +* Make sure you've got ruby2 with dev-packages installed +* `sudo gem install bundler` +* Clone this repo +* `sudo apt-get install zlib1g-dev` # [ + [ref](http://www.nokogiri.org/tutorials/installing_nokogiri.html#ubuntu___debian) + ] +* `bundle install` +* `bundle exec jekyll serve` +* browse the site on http://localhost:4000 + +Based on https://help.github.com/articles/using-jekyll-with-pages/ + + +
+ +![Github Repo Size](https://img.shields.io/github/repo-size/git/git.github.io?style=for-the-badge&color=yellow) + +
+ +

See our Contributors 😄

+ + + + + +
diff --git a/_config.yml b/_config.yml index 7633f45e7..ed08f7513 100644 --- a/_config.yml +++ b/_config.yml @@ -1,2 +1,20 @@ name: Git Developer Pages permalink: /rev_news/:year/:month/:day/:title/ +plugins: + - jekyll-redirect-from + +defaults: + - { scope: { path: "links/dev" } , values: { nb: "Git Development" , permalink: "/:basename/"} } + - { scope: { path: "links/mentoring/common" } , values: { nb: "Mentoring" , permalink: "/:basename/"} } + - { scope: { path: "links/mentoring/soc" } , values: { nb: "Mentoring-SoC" , permalink: "/:basename/"} } + - { scope: { path: "links/mentoring/outreachy" } , values: { nb: "Mentoring-Outreachy", permalink: "/:basename/"} } + - { scope: { path: "rev_news" } , values: { nb: "Git Rev News" } } + +# this is used to display links in the right categories order +# be sure to match default category names defined in site.defaults +nb-order: + - "Git Development" + - "Git Rev News" + - "Mentoring" + - "Mentoring-SoC" + - "Mentoring-Outreachy" diff --git a/_includes/README.md b/_includes/README.md index d7ab46aeb..d70f2c116 100644 --- a/_includes/README.md +++ b/_includes/README.md @@ -1,29 +1,22 @@ -# About - -This homepage is maintained by editing files in the -[git/git.github.io](https://github.com/git/git.github.io) repository on -GitHub. - -It is meant to be edited collaboratively like a wiki, except that -instead of a web form, you get to use a text editor and git. What could -be better? - -If you want push access, contact peff@peff.net and provide your GitHub -username. You may also send patches by mail (and feel free to cc -git@vger.kernel.org if appropriate). - - -# Development - -* Make sure you've got ruby2 with dev-packages installed -* `sudo gem install bundler` -* Clone this repo -* `sudo apt-get install zlib1g-dev` # ref [1] -* `bundle install` -* `bundle exec jekyll serve` -* browse the site on http://localhost:4000 - -Based on https://help.github.com/articles/using-jekyll-with-pages/ - -[1] http://www.nokogiri.org/tutorials/installing_nokogiri.html#ubuntu___debian - +This is a website for information on Git development. If you stumbled into this +by mistake, you may want: + - Information on running Git and links to download the latest version from + [HERE](https://git-scm.com/) + - Wiki that has historically contained developer information from + [HERE](https://git.wiki.kernel.org/index.php/Main_Page) + +These pages are intended to collect information useful to Git developers. This +is also the web home of: + - the [Hacking Git](https://git.github.io/Hacking-Git/) page, + - the [Git Rev News newsletter](https://git.github.io/rev_news/), + - the [involvement of the Git project in mentoring + programs](https://git.github.io/General-Application-Information/) like + [Outreachy](https://www.outreachy.org/) and the [GSoC (Google Summer of + Code)](https://summerofcode.withgoogle.com/) + +These pages are intended to be edited collaboratively (i.e., it is an +alternative to us having a wiki, but one that is edited entirely via Git pushes. +The [repository](https://github.com/git/git.github.io) could be found on GitHub. +You could also send your changes as patches by email to Christian Couder < + > / Kaartic Sivaraam < > +(and feel free to cc git@vger.kernel.org if appropriate). diff --git a/_includes/navbar.html b/_includes/navbar.html index 6d52b36c9..d67cff823 100644 --- a/_includes/navbar.html +++ b/_includes/navbar.html @@ -1,11 +1,20 @@ diff --git a/_layouts/default.html b/_layouts/default.html index 2887d3b7e..0e1406e3e 100644 --- a/_layouts/default.html +++ b/_layouts/default.html @@ -5,7 +5,9 @@ {{ page.title }} + + diff --git a/_posts/2015-03-25-edition-1.markdown b/_posts/2015-03-25-edition-1.markdown index 33f0f26c7..3bb63e38f 100644 --- a/_posts/2015-03-25-edition-1.markdown +++ b/_posts/2015-03-25-edition-1.markdown @@ -28,7 +28,7 @@ requests](https://github.com/git/git.github.io/pulls) or opening ### General -* [Promoting Git developers](http://thread.gmane.org/gmane.comp.version-control.git/265165) (*written by Junio C Hamano*) +* [Promoting Git developers](https://public-inbox.org/git/54FDA6B5.8050505%40drmicha.warpmail.net/) (*written by Junio C Hamano*) Following up to a message from David Kastrup, a discussion was initiated by Christian Couder where Michael J Gruber noted @@ -47,15 +47,14 @@ contributors and thank for their help for each release. ### Reviews -* [make git-pull a builtin](http://thread.gmane.org/gmane.comp.version-control.git/265628/) +* [make git-pull a builtin](https://public-inbox.org/git/1426600662-32276-1-git-send-email-pyokagan%40gmail.com/) Paul Tan, who will probably apply to be a [Google Summer of Code (GSoC)](https://developers.google.com/open-source/soc/) student for Git this year, anticipated the start of the GSoC and sent a patch to rewrite git-pull.sh as a built-in. -Indeed as stated in [the GSoC idea -page](https://git.github.io/SoC-2015-Ideas.html): +Indeed as stated in [the GSoC idea page](https://git.github.io/SoC-2015-Ideas/): > Many components of Git are still in the form of shell and Perl @@ -111,13 +110,13 @@ Regarding the test suite, Matthieu Moy suggested: >they do, add a failing test that passes again once you uncomment the >code. -* [Forbid "log --graph --no-walk"](http://thread.gmane.org/gmane.comp.version-control.git/264899/) +* [Forbid "log --graph --no-walk"](https://public-inbox.org/git/1425632110-31863-1-git-send-email-dongcan.jiang%40gmail.com/) Dongcan Jiang, who will also probably apply to be a GSoC student for Git this year, sent a patch to prevent `git log` from being used with both the `--graph` and the `--no-walk` option. He sent this patch because the Git community asks potential students to work on a -[microproject](https://git.github.io/SoC-2015-Microprojects.html) to +[microproject](https://git.github.io/SoC-2015-Microprojects/) to make sure that they can work properly with the community. Eric Sunshine made some good general suggestions that are often made @@ -138,7 +137,7 @@ on incoming patches: > >Okay. You might also want to cite the wider discussion[1]. > ->[1]: http://article.gmane.org/gmane.comp.version-control.git/216083 +>[1]: https://public-inbox.org/git/7vvc9ylh97.fsf%40alter.siamese.dyndns.org/ > >> revision.c: Judge whether --graph and --no-walk come together when running git-log. >> buildin/log.c: Set git-log cmd flag. @@ -158,7 +157,7 @@ on the arguments it is given: > command about a connected history. Otherwise, it is a command about > discrete point(s). -* [War on broken &&-chain](http://thread.gmane.org/gmane.comp.version-control.git/265874) (*written by Junio C Hamano*) +* [War on broken &&-chain](https://public-inbox.org/git/20150320100429.GA17354%40peff.net/) (*written by Junio C Hamano*) We often see review comments on test scripts that points out a breakage in the &&-chain, but what does that mean? @@ -203,7 +202,7 @@ runs only on a case insensitive filesystem a few days later. ### Support -* [Git with Lader logic](http://thread.gmane.org/gmane.comp.version-control.git/265679/) +* [Git with Lader logic](https://public-inbox.org/git/5F9B9EBF-CD4D-42A8-8A0C-9806702231A1%40icloud.com/) People often ask the Git mailing list whether they can use Git to manage special content. Fortunately, the list is monitored by many experts in different @@ -267,7 +266,7 @@ Jeff King <>. > The latest maintenance release Git v2.3.2 is now available at > the usual places. -* [Commandline GUI-tool *tig* version 2.1](http://article.gmane.org/gmane.comp.version-control.git/265298), March 11th: +* [Commandline GUI-tool *tig* version 2.1](https://public-inbox.org/git/CAFuPQ1%2BD3QY8MxNRX87R6-nUR9eP3JRTq_yuWfRq1upQT7iC8w%40mail.gmail.com/), March 11th: > I just released version 2.1 of Tig which brings a lot of improvements to speed > up usage in large repositories such as the Linux kernel repo (see improvements @@ -287,7 +286,7 @@ Jeff King <>. > the usual places. It is comprised of 26 non-merge commits since > v2.3.2, contributed by 11 people, 1 of which is a new contributor. -* [Git v2.3.4](http://permalink.gmane.org/gmane.linux.kernel/1915412), March 23rd: +* [Git v2.3.4](https://public-inbox.org/git/xmqqlhin8kh9.fsf%40gitster.dls.corp.google.com/), March 23rd: > The latest maintenance release Git v2.3.4 is now available at the > usual places. It is comprised of 22 non-merge commits since v2.3.3, diff --git a/_posts/2015-04-15-edition-2.markdown b/_posts/2015-04-15-edition-2.markdown index e1752179a..9ce60b992 100644 --- a/_posts/2015-04-15-edition-2.markdown +++ b/_posts/2015-04-15-edition-2.markdown @@ -111,7 +111,7 @@ NFS, Amazon S3 ...) and chunking for resumable downloads. ### Reviews -* [Speeding up strbuf_getwholeline()](http://thread.gmane.org/gmane.comp.version-control.git/266789/focus=266796) +* [Speeding up strbuf_getwholeline()](https://public-inbox.org/git/20150405010611.GA15901%40peff.net/) Jeff King, alias Peff, posted a patch series to address speed regressions when accessing the packed-refs file. This lead to @@ -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. @@ -215,7 +215,7 @@ Brendan Forster put together this [Beta Testers Guide](https://gist.github.com/s > The following fixes have been backported to this maintenance release. [...] > All users of the library are encouraged to update. -* [tig-2.1.1](http://article.gmane.org/gmane.comp.version-control.git/266979), April 9th +* [tig-2.1.1](https://public-inbox.org/git/CAFuPQ1%2B5Cpb5VYPdF3E0i3Fp%2B%2BMRs6DwPnkJZ171MHNzrq5hTQ%40mail.gmail.com/), April 9th > Finally, files (or blobs) can now be searched using the new GitHub-inspired > [file finder](https://asciinema.org/a/18525) (press 'f' to launch it). diff --git a/_posts/2015-05-13-edition-3.markdown b/_posts/2015-05-13-edition-3.markdown index 4590a8bd1..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 @@ -74,13 +74,13 @@ videos, blog posts and other materials available from her [gitforteams GitHub repo](https://github.com/emmajane/gitforteams), and also in an [upcoming Git for Teams of One or More book](http://gitforteams.com/books/). -* [Git + Software Freedom Conservancy Overview](http://thread.gmane.org/gmane.comp.version-control.git/267077/) +* [Git + Software Freedom Conservancy Overview](http://article.gmane.org/gmane.comp.version-control.git/267077) At the Contributor Summit that was part of the [Git Merge 2015](http://git-merge.com), Jeff King, aka Peff, gave a presentation about the status of Git as a [Software Freedom Conservancy (SFC)](https://sfconservancy.org/) project. -Git is a [member project of the SFC since 2010](http://thread.gmane.org/gmane.comp.version-control.git/159722/). +Git is a [member project of the SFC since 2010](https://public-inbox.org/git/20101022183027.GA12124%40sigill.intra.peff.net/). This gives some legal status to "The Git Project" and makes it possible for it to handle money (around $19,000), hold domain names (git-scm.com, git-scm.org) and [the "Git" trademark](https://git-scm.com/trademark), and own a Mac! @@ -116,20 +116,20 @@ about possible changes to the current situation. ### Reviews -* ["cat-file --allow-unknown-type"](http://thread.gmane.org/gmane.comp.version-control.git/268262) +* ["cat-file --allow-unknown-type"](https://public-inbox.org/git/55463094.9040204%40gmail.com/) Karthik Nayak, a Google Summer of Code student, has been working for some months on developing the `--allow-unknown-type` option for `git cat-file`. He has been helped by Eric Sunshine, Ramsay Jones, Phil Hord, Charles Bailey, David Turner, Duy Nguyen, Jeff King and Junio Hamano, and, along the development, improving the test script led -to a [discovery and fix of a bug](http://thread.gmane.org/gmane.comp.version-control.git/268306) +to a [discovery and fix of a bug](https://public-inbox.org/git/1430724315-524-1-git-send-email-sunshine%40sunshineco.com/) in `hash-object --literally`. The 10th iteration of his patch series was merged to the 'next' branch, so the new option will probably appear in the next git release. -* ["git help" reorganisation](http://thread.gmane.org/gmane.comp.version-control.git/268348) +* ["git help" reorganisation](https://public-inbox.org/git/cover.1430770308.git.sebastien.guimmara%40gmail.com/) Sébastien Guimmara started working on improving the output of `git help`. @@ -141,14 +141,14 @@ 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 involved in the discussions: Eric Sunshine, Junio Hamano, Stefan Beller, Matthieu Moy, Johannes Schindelin, Johannes Sixt. Emma Jane Hogbin Westby -also [weighed in](http://thread.gmane.org/gmane.comp.version-control.git/268348/focus=268525) +also [weighed in](https://public-inbox.org/git/cover.1430770308.git.sebastien.guimmara%40gmail.com/) with her experience in teaching Git to people, which is a valuable piece of input. @@ -157,7 +157,7 @@ We will see how it goes and if some improvements are merged. ### Support -* [gitk won't show notes?](http://thread.gmane.org/gmane.comp.version-control.git/266662/) +* [gitk won't show notes?](https://public-inbox.org/git/551D99B9.7040200%40ubuntu.com/) Phillip Susi had trouble getting gitk to show notes. Michael J. Gruber tried to help him, but it didn't work when adding a note while gitk is @@ -175,7 +175,7 @@ Paul agreed that indeed works need to be done to fix this problem. He asked if `git notes list` is the best way to find out all the current notes, and Johan Herland who developed `git notes` answered yes. -* [git ls-files wildcard behavior considered harmful](http://thread.gmane.org/gmane.comp.version-control.git/266486/) +* [git ls-files wildcard behavior considered harmful](https://public-inbox.org/git/20150330230459.GA13927%40kitenet.net/) Joey Hess who is developing [git-annex](https://git-annex.branchable.com/) was surprised by how `git ls-files` expands wildcard characters like `*[]` and the fact that escaping these characters @@ -204,16 +204,16 @@ environment variable have been created especially for this purpose and it is a good idea to use them in script or tools, like GitHub is doing on their servers. -* [No longer builds with NO_IPV6?](http://thread.gmane.org/gmane.comp.version-control.git/268406) +* [No longer builds with NO_IPV6?](https://public-inbox.org/git/CAK4aQQJ9yT8%2BQ9jPQ78cauhyPj3j5WmpgrQJ5%3DcA-ECjaWn8BQ%40mail.gmail.com/) Eduardo Espejo found that Git does not compile anymore when using the `NO_IPV6` configuration switch. And it is not the first time that -[someone finds out that Git such a `NO_IPV6` breakage](http://thread.gmane.org/gmane.comp.version-control.git/28033/). +[someone finds out that Git such a `NO_IPV6` breakage](https://public-inbox.org/git/20060928184814.GA4294%40steel.home/). This time Junio Hamano, the Git maintainer, fixed the breakage in "daemon.c", but more importantly found that `NO_CURL` and `NO_EXPAT` configurations did not to pass the test suite. -So helped by Jeff King [he quickly fixed that too](http://thread.gmane.org/gmane.comp.version-control.git/268467/). +So helped by Jeff King [he quickly fixed that too](https://public-inbox.org/git/xmqq6185d4o1.fsf%40gitster.dls.corp.google.com/). And now he has a nightly cron job to try building and testing a few selected configurations. @@ -251,7 +251,7 @@ work on Git scalability issues. If you are interested please contact ### Event -[GSoC 2015: 2 accepted proposals](http://thread.gmane.org/gmane.comp.version-control.git/267878) +[GSoC 2015: 2 accepted proposals](https://public-inbox.org/git/vpqoam9mjuo.fsf%40anie.imag.fr/) For a long time Git has been participating in [the Google Summer of Code](http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/about_page). This summer two students, Paul Tan and Karthik Nayak, mentored by four experienced Git developers, Johannes Schindelin, Stefan Beller, Matthieu Moy and Christian Couder, will work on improving Git and will receive a stipend from Google. diff --git a/_posts/2015-06-03-edition-4.markdown b/_posts/2015-06-03-edition-4.markdown index 4919776aa..30a967a68 100644 --- a/_posts/2015-06-03-edition-4.markdown +++ b/_posts/2015-06-03-edition-4.markdown @@ -19,7 +19,7 @@ This edition covers what happened during the month of May 2015. ### General -* [submitGit for patch submission](http://thread.gmane.org/gmane.comp.version-control.git/269699/) +* [submitGit for patch submission](https://public-inbox.org/git/CAFY1edY3%2BWt-p2iQ5k64Fg-nMk2PmRSvhVkQSVNw94R18uPV2Q%40mail.gmail.com/) At the [Git Merge 2015](http://git-merge.com/) conference, during the Contributor Summit, there were discussions about how to help people send patches @@ -47,7 +47,7 @@ configured. The problem is that it is not very easy to configure to say the least, especially on Windows. [A recent discussion on the mailing -list](http://thread.gmane.org/gmane.comp.version-control.git/268000/) +list](https://public-inbox.org/git/CAHd499BqB_ZFKMNxSVCDTFx2Ge%3DTfCE6gexFn%2BrfRbS%2BybLybA%40mail.gmail.com/) shows how difficult it can be even for developers to find a way to properly send a patch to the mailing list. Toward the end of the discussion, Stefan Beller summarized the discussions at [Git Merge @@ -67,7 +67,7 @@ discussion, Stefan Beller summarized the discussions at [Git Merge A few days later, Roberto Tyley, who is the author of [the BFG repo-cleaner](https://rtyley.github.io/bfg-repo-cleaner/), -replied to Stefan's email [by announcing submitGit](http://thread.gmane.org/gmane.comp.version-control.git/269699): +replied to Stefan's email [by announcing submitGit](https://public-inbox.org/git/CAFY1edY3%2BWt-p2iQ5k64Fg-nMk2PmRSvhVkQSVNw94R18uPV2Q%40mail.gmail.com/): > Hello, I'm stepping up to do that work :) Or at least, I'm implementing a > one-way GitHub PR -> Mailing list tool, called submitGit: @@ -93,26 +93,26 @@ This announcement was met with a lot of enthusiasm from the community, especially from the [Git for Windows](https://msysgit.github.io/) developers. Junio Hamano, the Git maintainer, also liked the idea and pointed out that submitGit would be usable for an even wider audience if it only required -[a narrower scope of GitHub authorization](http://thread.gmane.org/gmane.comp.version-control.git/269733), +[a narrower scope of GitHub authorization](https://public-inbox.org/git/xmqq4mn4fugi.fsf%40gitster.dls.corp.google.com/), which [submitGit was updated to reflect a few days later](https://github.com/rtyley/submitgit/pull/3) - improvements are still coming! Aspiring contributors are encouraged to try submitGit out, and provide feedback on the mailing list or on the project's [GitHub issues](https://github.com/rtyley/submitgit/issues). -* [git-multimail resurrected!](http://thread.gmane.org/gmane.comp.version-control.git/270239) (*written by Matthieu Moy*) +* [git-multimail resurrected!](https://public-inbox.org/git/vpqr3pz5y35.fsf%40anie.imag.fr/) (*written by Matthieu Moy*) [git-multimail](https://github.com/git-multimail/git-multimail) got a new co-maintainer, and is active again after a long period of inactivity. [A summary of the recent - activity](http://thread.gmane.org/gmane.comp.version-control.git/270239) + activity](https://public-inbox.org/git/vpqr3pz5y35.fsf%40anie.imag.fr/) was posted on the Git mailing-list. A 1.1 release is expected in June. Don't hesitate to join the fun and help by reviewing pull-requests or submitting new ones! ### Reviews -* [clean/smudge empty contents](http://thread.gmane.org/gmane.comp.version-control.git/269050) (*written by Junio C Hamano*) +* [clean/smudge empty contents](https://public-inbox.org/git/1431624219-25045-1-git-send-email-gjthill%40gmail.com/) (*written by Junio C Hamano*) Jim Hill noticed that Git issues an error message saying that copy_fd() was given a bad file descriptor when clean/smudge filters is fed an file with empty contents, found that @@ -134,12 +134,12 @@ it saw EPIPE. Peff observed: > start of the cruft, and then stop for reasons of efficiency. The discussion lead to -an [enhancement](http://thread.gmane.org/gmane.comp.version-control.git/269050/focus=269383) +an [enhancement](https://public-inbox.org/git/1431624219-25045-1-git-send-email-gjthill%40gmail.com//focus=269383) to allow clean/smudge filters to quit before reading their input fully. ### Support -* [git pack protocol question: sideband responses in case of errors?](http://thread.gmane.org/gmane.comp.version-control.git/268949) +* [git pack protocol question: sideband responses in case of errors?](https://public-inbox.org/git/CAENte7j9De5Bqu2jDcmXQAxZheSGo%2BEntzsYUaen0N7cnuiCDQ%40mail.gmail.com/) Christian Halstrick said that he sometimes gets "invalid channel 101" errors when pushing over HTTP using a JGit client. @@ -172,7 +172,7 @@ And Shawn concluded with the following: > won't fit on local disk due to disk full" condition that narrows > down the offending section of JGit considerably. -* ["git commit --date" does not behave well?](http://thread.gmane.org/gmane.comp.version-control.git/269832) (*written by Junio C Hamano*) +* ["git commit --date" does not behave well?](https://public-inbox.org/git/5562646A.1080608%40alum.mit.edu/) (*written by Junio C Hamano*) Bastien Traverse was having trouble specifying the date when creating a commit with the `--date` parameter to `git commit` command. He tried various @@ -190,12 +190,12 @@ turns out that the input Bastien was feeding did not have the right "colon". ## Releases -* Git [2.3.8](http://article.gmane.org/gmane.comp.version-control.git/268828) (final for 2.3.x series for now) +* Git [2.3.8](https://public-inbox.org/git/xmqqlhgu20n4.fsf%40gitster.dls.corp.google.com/) (final for 2.3.x series for now) * Git [2.4.1 and 2.4.2](http://git-blame.blogspot.com/2015/05/git-241-and-242.html) maintenance releases. Together with Git 2.3.8, `git commit --date=now` now works correctly in timezones that honor daylight-saving-time, fixing a - breakage [Linus noticed](http://thread.gmane.org/gmane.comp.version-control.git/267183). + breakage [Linus noticed](https://public-inbox.org/git/CA%2B55aFxvcN8Dz-t6fi6etycg%2BAiyR0crXv5AcfCdv8ji-iNBpw%40mail.gmail.com/). * [Git for Windows 2.x preview](http://article.gmane.org/gmane.comp.version-control.msysgit/21601) diff --git a/_posts/2015-07-08-edition-5.markdown b/_posts/2015-07-08-edition-5.markdown index 709304d01..c5ee6eb5e 100644 --- a/_posts/2015-07-08-edition-5.markdown +++ b/_posts/2015-07-08-edition-5.markdown @@ -34,7 +34,7 @@ and on [porting git-am from shell to C too](https://github.com/pyokagan/git/comm ### Reviews -* [New `git worktree` command](http://thread.gmane.org/gmane.comp.version-control.git/272949) (*written by Eric Sunshine*) +* [New `git worktree` command](https://public-inbox.org/git/1435582278-31158-1-git-send-email-pclouds%40gmail.com/) (*written by Eric Sunshine*) The linked-worktree facility allows multiple working directories to share a single repository, with (typically) a different branch checked out in each @@ -49,22 +49,22 @@ via `git checkout --to `, and cleanup of leftover administrative files after manual deletion of `` was done with `git prune --worktrees`. However, a recent unrelated change to `git prune` led to a -[discussion](http://thread.gmane.org/gmane.comp.version-control.git/272447/focus=272546) +[discussion](https://public-inbox.org/git/20150623105042.GA10888%40peff.net/) that concluded that worktree-related maintenance functionality didn't belong in `git prune`. Consequently, Nguyễn Thái Ngọc Duy submitted a -[patch](http://thread.gmane.org/gmane.comp.version-control.git/272949) +[patch](https://public-inbox.org/git/1435582278-31158-1-git-send-email-pclouds%40gmail.com/) which introduces a new `git worktree` command, and relocates `git prune --worktrees` functionality to `git worktree prune`. Eric Sunshine then further fleshed out `git worktree` with a -[patch](http://article.gmane.org/gmane.comp.version-control.git/273032) +[patch](https://public-inbox.org/git/1435640202-95945-1-git-send-email-sunshine%40sunshineco.com/) which relocates `git checkout --to` functionality to `git worktree new`. A lengthy -[discussion](http://thread.gmane.org/gmane.comp.version-control.git/273032) +[discussion](https://public-inbox.org/git/1435640202-95945-1-git-send-email-sunshine%40sunshineco.com/) ensued, which eventually led to a second version, consisting of [23 -patches](http://thread.gmane.org/gmane.comp.version-control.git/273316), +patches](https://public-inbox.org/git/1435969052-540-1-git-send-email-sunshine%40sunshineco.com/), and which names the command `git worktree add`, rather than `git worktree new`, and gives the documentation some needed attention. @@ -84,13 +84,13 @@ checked out into new worktree `../hotfix`, as if `git worktree -b hotfix ../hotfix HEAD` had been specified. Finally, the question was -[raised](http://article.gmane.org/gmane.comp.version-control.git/273107) +[raised](https://public-inbox.org/git/CAPig%2BcT0a201MVTsvvLrndr40GsMkyvtao33Gt%3DAFhvShtr%3DKg%40mail.gmail.com/) whether `git checkout --ignore-other-worktrees` should be retired and `git checkout --force` overloaded to subsume its duties, however, Junio was [not -thrilled](http://article.gmane.org/gmane.comp.version-control.git/273108) +thrilled](https://public-inbox.org/git/xmqqtwtobzn0.fsf%40gitster.dls.corp.google.com/) by the idea. -* [Warning when charset conversion did not happen due to iconv compiled out](http://thread.gmane.org/gmane.comp.version-control.git/270952/) +* [Warning when charset conversion did not happen due to iconv compiled out](https://public-inbox.org/git/1433624551-20730-1-git-send-email-max%40max630.net/) Max Kirillov proposed a patch to warn when a conversion from a character set to another character set could not happen because iconv @@ -142,7 +142,7 @@ suggestion into account. ### Support -* [Visualizing merge conflicts after the fact](http://thread.gmane.org/gmane.comp.version-control.git/271738) +* [Visualizing merge conflicts after the fact](https://public-inbox.org/git/557F791D.3080003%40nextest.com/) Eric Raible reported the following: @@ -181,7 +181,7 @@ Michael J Gruber replied to Dscho that, as we often get this type of request, it might be a good idea to better support the above. Junio Hamano then pointed to -[a patch series from last September by Thomas Rast](http://thread.gmane.org/gmane.comp.version-control.git/256591) +[a patch series from last September by Thomas Rast](https://public-inbox.org/git/cover.1409860234.git.tr%40thomasrast.ch/) that implements a new `--remerge-diff` option for `git log` to show what a conflict resolution changed. Unfortunately, though the feature looks promising at least to Michael, it looks like some more work is @@ -205,7 +205,7 @@ git rev-list --author="My Colleague" --parents --merges HEAD ``` -* [Several date related issues](http://thread.gmane.org/gmane.comp.version-control.git/272658) +* [Several date related issues](https://public-inbox.org/git/20150625131901.5b962336%40pc09.procura.nl/) Right now `git log` supports the following date related options: @@ -262,7 +262,7 @@ And H.Merijn said that the option names are misleading, and suggested a gitk option for Peff's script. It looks like no gitk option has been developed yet for the above, but -Peff sent [a patch series](http://thread.gmane.org/gmane.comp.version-control.git/272695) +Peff sent [a patch series](https://public-inbox.org/git/20150625165341.GA21949%40peff.net/) to implement `--date=format:...` which can produce the same output as the `--date=...` options H.Merijn suggested about his first issue. diff --git a/_posts/2015-08-05-edition-6.markdown b/_posts/2015-08-05-edition-6.markdown index a4847baf8..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? @@ -73,7 +73,7 @@ Nicola's [just published piece](https://developer.atlassian.com/blog/2015/08/gra ### Support -* [git log fails to show all changes for a file](http://thread.gmane.org/gmane.comp.version-control.git/273937) +* [git log fails to show all changes for a file](https://public-inbox.org/git/20150714073035.GA22707%40aepfle.de/) Working on the Linux kernel, Olaf Hering wondered why the following command does not show all the commits that modified a function in the @@ -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 @@ -142,7 +142,7 @@ behavior might have some drawbacks. Junio concluded the thread with: > and harder to explain to new people. -* [Git tag: pre-receive hook issue](http://thread.gmane.org/gmane.comp.version-control.git/274095) +* [Git tag: pre-receive hook issue](https://public-inbox.org/git/1437159533304-7635764.post%40n2.nabble.com/) Gaurav Chhabra reported that in his company they have [a script launched by a pre-receive hook](http://pastebin.com/VnMQp5ar) in which diff --git a/_posts/2015-09-09-edition-7.markdown b/_posts/2015-09-09-edition-7.markdown index bf44dcd61..2f570cbc0 100644 --- a/_posts/2015-09-09-edition-7.markdown +++ b/_posts/2015-09-09-edition-7.markdown @@ -123,7 +123,7 @@ effect if it breaks is. Reading the students proposals and resume is rarely sufficient to really evaluate their skills, which makes the risk particularly hard to evaluate. Since 2014, we've been using -[microprojects](https://git.github.io/SoC-2015-Microprojects.html) to +[microprojects](https://git.github.io/SoC-2015-Microprojects/) to select students. This turned out to be very efficient, both at identifying good (or bad) applicants, but also at giving students a glimpse of what "contributing to Git" means. Student get an idea of @@ -136,17 +136,17 @@ and the fun will continue long after the GSoC :-). ### Reviews -* [refs lmdb backend](http://thread.gmane.org/gmane.comp.version-control.git/277138) +* [refs lmdb backend](https://public-inbox.org/git/1441245313-11907-1-git-send-email-dturner%40twopensource.com/) Last June, David Turner, who is working for Twitter, sent to the list a message titled -"[RFC/Pull Request: Refs db backend](http://thread.gmane.org/gmane.comp.version-control.git/272438)" +"[RFC/Pull Request: Refs db backend](https://public-inbox.org/git/1435020656.28466.8.camel%40twopensource.com/)" that started with: > I've revived and modified Ronnie Sahlberg's work on the refs db backend. Ronnie Sahlberg, working for Google, had sent last year some emails about -[an experimental TDB backend](http://thread.gmane.org/gmane.comp.version-control.git/252582/) and -[pluggable backends](http://thread.gmane.org/gmane.comp.version-control.git/254829/) +[an experimental TDB backend](https://public-inbox.org/git/CAL%3DYDWn-CGZGr5bXNTiZmzr4-w_8CERx3r2bmLWbczqJ0Sn7dg%40mail.gmail.com/) and +[pluggable backends](https://public-inbox.org/git/CAL%3DYDWk5C%2BbQS76_%2Bjx1BSYSxecCxaS95RG181ecbJBLCNWLkQ%40mail.gmail.com/) he had developed to store git refs. Unfortunately his work was too experimental and had not been merged. This is interesting work because Git gets slower when the number of @@ -174,7 +174,7 @@ Since June, David, helped by many reviewers like Eric Sunshine, Johan Herland, Michael Haggerty, Jacob Keller, Duy Nguyen, Stefan Beller, Johannes Sixt, Philip Oakley and Junio has worked on many related improvements, that are very helpful to advance this topic. That's why -[the last version of his patch series](http://thread.gmane.org/gmane.comp.version-control.git/277138) +[the last version of his patch series](https://public-inbox.org/git/1441245313-11907-1-git-send-email-dturner%40twopensource.com/) contains the following: > This series depends on at least the following topics in pu: @@ -199,7 +199,7 @@ Hopefully, we can expect that, with those new ref backends, users will be able to benefit soon from a huge amount of ground work that has been done during the last few years. -* [t5004: test ZIP archives with many entries](http://thread.gmane.org/gmane.comp.version-control.git/275682/focus=276393) +* [t5004: test ZIP archives with many entries](https://public-inbox.org/git/20150811104056.16465.58131%40localhost/) Johannes Schauer reported that git-archive does not use the zip64 extension and therefore is unable to properly create zip archives with @@ -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 @@ -237,7 +237,7 @@ good enough that the patch and the above `zipinfo` check work on Linux as we don't need to test the archive generated by `git archive` on every platform. -* [git-p4: add option to store files in Git LFS on import](http://thread.gmane.org/gmane.comp.version-control.git/276719/) +* [git-p4: add option to store files in Git LFS on import](https://public-inbox.org/git/1440764691-62254-1-git-send-email-larsxschneider%40gmail.com/) Lars Schneider, who is in the process of migrating huge Perforce repositories to Git, posted a RFC (Request For Comments) patch to add an option to @@ -262,7 +262,7 @@ Python 2 to Python 3 until John Keeping chimed in writing: and then explaining the reason why it's difficult to migrate. Fortunately it seems that this has not discouraged Lars to send a -[second version of his patch](http://thread.gmane.org/gmane.comp.version-control.git/277227/) +[second version of his patch](https://public-inbox.org/git/1441298148-63885-5-git-send-email-larsxschneider%40gmail.com/) that starts to address Luke's concerns and that Luke has already reviewed. Hopefully, thanks to this ongoing work, we will soon have an easy way @@ -350,7 +350,7 @@ quality commit messages, and well-organized, highly focused patches. * Git for Windows 2.5.0 [was released](http://article.gmane.org/gmane.comp.version-control.msysgit/21805). It is the first release based on Git 2.x, the first release based on [MSys2](https://msys2.github.io/) and the first release dropping the *-preview* suffix. * Git 2.5.1 [was released](http://thread.gmane.org/gmane.linux.kernel/2028843). -* Git for Windows 2.5.1 [was released soon after that](http://article.gmane.org/gmane.comp.version-control.git/276857). +* Git for Windows 2.5.1 [was released soon after that](https://public-inbox.org/git/44a7997123f03bb4d5f47724befd8417%40www.dscho.org/). * git-multimail [1.2 Alpha 1 was released](https://github.com/git-multimail/git-multimail/releases/tag/1.2.a1). Please, report bugs and give feedback on new features before the final release. * GitLab [7.14](https://about.gitlab.com/2015/08/22/gitlab-7-14-released/) and [7.14.1 was released](https://about.gitlab.com/2015/08/25/gitlab-7-dot-14-dot-1-released/). @@ -362,7 +362,7 @@ quality commit messages, and well-organized, highly focused patches. __Various__ * Johannes Schindelin, aka Dscho, wrote - [a personal note](http://thread.gmane.org/gmane.comp.version-control.git/277194) + [a personal note](https://public-inbox.org/git/alpine.DEB.1.00.1509031156510.29350%40s15462909.onlinehome-server.info/) to the list explaining that since mid-August he has been working full time for Microsoft on Git for Windows. He has already been the Git for Windows maintainer in his spare time since the beginning of diff --git a/_posts/2015-10-14-edition-8.markdown b/_posts/2015-10-14-edition-8.markdown index 6ae33b5a4..d9de76ea4 100644 --- a/_posts/2015-10-14-edition-8.markdown +++ b/_posts/2015-10-14-edition-8.markdown @@ -23,7 +23,7 @@ This edition covers what happened during the month of September 2015. ### Reviews -* [Add Travis CI support](http://thread.gmane.org/gmane.comp.version-control.git/278633) +* [Add Travis CI support](https://public-inbox.org/git/1443131004-39284-1-git-send-email-larsxschneider%40gmail.com/) Lars Schneider wrote that to avoid breaking tests in the future he configured Travis-CI to run all Git tests including git-p4 and git-lfs @@ -81,16 +81,16 @@ And then Matthieu Moy explained the benefits for everyone like this: This appear to have convinced Junio of the value of a CI tool linked to git/git, and Lars has since posted -[a version 2](http://thread.gmane.org/gmane.comp.version-control.git/279011) +[a version 2](https://public-inbox.org/git/1443981977-64604-1-git-send-email-larsxschneider%40gmail.com/) and [a version 3 of his -patches](http://thread.gmane.org/gmane.comp.version-control.git/279348), -so an interesting way to test patchs will perhaps be available soon +patches](https://public-inbox.org/git/1444586102-82557-1-git-send-email-larsxschneider%40gmail.com/), +so an interesting way to test patches will perhaps be available soon to Git developers. ### Support -* [2.6.0: Comment in rebase instruction has become too rigid](http://thread.gmane.org/gmane.comp.version-control.git/278824) +* [2.6.0: Comment in rebase instruction has become too rigid](https://public-inbox.org/git/CAEY4ZpN0C96jU4Tgvqt-hWEviR-sapDoyAv88H%2BopPSr-cs%3Dmg%40mail.gmail.com/) Shortly after git version 2.6.0 was released, Nazri Ramliy noticed that: @@ -106,7 +106,7 @@ pre check the rebase instruction sheet before starting an interactive rebase. The goal of this pre checking patch was to avoid discovering a syntax error in the instruction sheet in the middle of a rebase. -Matthieu then posted [a patch to fix the regression](http://thread.gmane.org/gmane.comp.version-control.git/278841) +Matthieu then posted [a patch to fix the regression](https://public-inbox.org/git/1443600661-19391-1-git-send-email-Matthieu.Moy%40imag.fr/) based on a suggestion by Junio Hamano. Matthieu's patch just prefilters the instruction sheet by piping it through `sed 's/^[[:space:]]*//'`. @@ -240,7 +240,7 @@ I only found this recently, it's just brilliant. Thank you, whoever it was put t __Updates__ * [Since we talked about it last month](https://git.github.io/rev_news/2015/09/09/edition-7/) David Turner -submitted [a new patch series](http://thread.gmane.org/gmane.comp.version-control.git/278757) of his work on +submitted [a new patch series](https://public-inbox.org/git/1443477738-32023-1-git-send-email-dturner%40twopensource.com/) of his work on alternate ref backends. This work is being reviewed by Michael Haggerty, Junio, and others. The ultimate goal is still to allow a lmdb-based backend, which should be faster and have fewer issues on case-insensitive filesystems than the traditional files-based backend. This work is sponsored by @@ -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/2015-11-11-edition-9.markdown b/_posts/2015-11-11-edition-9.markdown index ba58a7fe1..70c42ac78 100644 --- a/_posts/2015-11-11-edition-9.markdown +++ b/_posts/2015-11-11-edition-9.markdown @@ -23,18 +23,18 @@ This edition covers what happened during the month of October 2015. ### Reviews -* [Expose the submodule parallelism to the user](http://thread.gmane.org/gmane.comp.version-control.git/280284) +* [Expose the submodule parallelism to the user](https://public-inbox.org/git/1445969753-418-1-git-send-email-sbeller%40google.com/) Stefan Beller started posting patch series to "finish the on going efforts of parallelizing submodule network traffic". This followed -[previous work by Stefan](http://thread.gmane.org/gmane.comp.version-control.git/277705/) +[previous work by Stefan](https://public-inbox.org/git/1442012994-20374-1-git-send-email-sbeller%40google.com/) to make it possible to launch many git submodule fetches in parallel. What is interesting is that a few weeks before posting the first version of his patch series, Stefan had been involved in a -[discussion](http://thread.gmane.org/gmane.comp.version-control.git/279712/) +[discussion](https://public-inbox.org/git/loom.20151016T001449-848%40post.gmane.org/) that was started by Kannan Goundan who asked if it would be possible to "Make 'git checkout' automatically update submodules?". @@ -64,7 +64,7 @@ This will be an interesting benchmark for the submodules as well. ### Support -* [broken racy detection and performance issues with nanosecond file times](http://thread.gmane.org/gmane.comp.version-control.git/278683) +* [broken racy detection and performance issues with nanosecond file times](https://public-inbox.org/git/5605D88A.20104%40gmail.com/) At the end of last September, Karsten Blees sent an email starting with the following: @@ -226,7 +226,7 @@ features on top of it. ## Releases -* Git, following some intermediate releases, is now at [2.6.3](http://article.gmane.org/gmane.comp.version-control.git/280947/) +* Git, following some intermediate releases, is now at [2.6.3](https://public-inbox.org/git/xmqqegg43uqw.fsf%40gitster.mtv.corp.google.com/) * Git for Windows, similarly is now at [2.6.2](https://groups.google.com/d/msg/git-for-windows/R4xTgOfFu3Q/vex656-JBQAJ) * GitLab shipped several times in the last month, leaving their latest version at [8.1.3](https://about.gitlab.com/2015/11/06/gitlab-8-dot-1-dot-3-released/), after the major diff --git a/_posts/2015-12-09-edition-10.markdown b/_posts/2015-12-09-edition-10.markdown index b67eeb34e..4d3abbba3 100644 --- a/_posts/2015-12-09-edition-10.markdown +++ b/_posts/2015-12-09-edition-10.markdown @@ -23,7 +23,7 @@ This edition covers what happened during the month of November 2015. ### Reviews -* [clean: new option --exclude-from](http://thread.gmane.org/gmane.comp.version-control.git/281762) +* [clean: new option --exclude-from](https://public-inbox.org/git/1448549065-16337-1-git-send-email-rouzier%40gmail.com/) James Rouzier sent a patch to add a new `--exclude-from=` option to `git clean`. It looked quite straightforward, but as often Eric @@ -56,10 +56,10 @@ commands. In the end it is not clear if the patch will be accepted. -* [remote-http(s): Support SOCKS proxies](http://thread.gmane.org/gmane.comp.version-control.git/280191) +* [remote-http(s): Support SOCKS proxies](https://public-inbox.org/git/bf218d020e24216f55d1514c4459e645b13ec075.1445865176.git.johannes.schindelin%40gmx.de/) In a patch series called -["Miscellaneous platform-independent patches from Git for Windows"](http://thread.gmane.org/gmane.comp.version-control.git/280190/) +["Miscellaneous platform-independent patches from Git for Windows"](https://public-inbox.org/git/cover.1445865176.git.johannes.schindelin%40gmx.de/) Johannes Schindelin, alias Dscho, sent a patch from Pat Thoyts that adds SOCKS proxies support to Git: > With this patch we properly support SOCKS proxies, configured e.g. like diff --git a/_posts/2016-01-13-edition-11.markdown b/_posts/2016-01-13-edition-11.markdown index 076664190..6e0439d34 100644 --- a/_posts/2016-01-13-edition-11.markdown +++ b/_posts/2016-01-13-edition-11.markdown @@ -23,7 +23,7 @@ This edition covers what happened during the month of December 2015. ### Reviews -* [RefTree: Alternate ref backend](http://thread.gmane.org/gmane.comp.version-control.git/282677/) +* [RefTree: Alternate ref backend](https://public-inbox.org/git/CAJo%3DhJvnAPNAdDcAAwAvU9C4RVeQdoS3Ev9WTguHx4fD0V_nOg%40mail.gmail.com/) Shawn Pearce, who is one of the main Git, JGit and Gerrit contributors, sent an email about a new ref storage backend saying: @@ -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](http://thread.gmane.org/gmane.comp.version-control.git/277138), 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. @@ -75,17 +75,17 @@ reachability, and Shawn mentioned other advantages: And it looks like Shawn has a bigger plan but don't want to tell us too much for now. -* [Split .git/config in multiple worktree setup](http://thread.gmane.org/gmane.comp.version-control.git/281906/) +* [Split .git/config in multiple worktree setup](https://public-inbox.org/git/1449083626-20075-1-git-send-email-pclouds%40gmail.com/) Duy Nguyen sent a patch series that restarted -[previous work he had already done](http://thread.gmane.org/gmane.comp.version-control.git/266520) +[previous work he had already done](https://public-inbox.org/git/1427804079-13061-1-git-send-email-pclouds%40gmail.com/) on splitting config options in two different sets. Some that are 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/). @@ -136,9 +136,9 @@ Other releases: __Various__ -* Jeff King [announced that GitHub is organizing another Git Merge conference](http://article.gmane.org/gmane.comp.version-control.git/282634/) for the beginning of April 2016 with a Git Developer Summit, and asked for people interested in coming to the Summit to tell him. +* Jeff King [announced that GitHub is organizing another Git Merge conference](https://public-inbox.org/git/20151217071430.GA3711%40sigill.intra.peff.net/) for the beginning of April 2016 with a Git Developer Summit, and asked for people interested in coming to the Summit to tell him. * Jeff King, Shawn Pearce and Junio C. Hamano ganged up, urging everyone to - [support the Software Freedom Conservancy](http://permalink.gmane.org/gmane.comp.version-control.git/282881), + [support the Software Freedom Conservancy](https://public-inbox.org/git/xmqqpoxyeajy.fsf%40gitster.mtv.corp.google.com/), which is the non-profit organization that legally hosts the Git project. __Light reading__ diff --git a/_posts/2016-02-10-edition-12.markdown b/_posts/2016-02-10-edition-12.markdown index 4b21882de..e3c3292ad 100644 --- a/_posts/2016-02-10-edition-12.markdown +++ b/_posts/2016-02-10-edition-12.markdown @@ -23,15 +23,15 @@ This edition covers what happened during the month of January 2016. ### Reviews -* [refs backend rebase on pu](http://thread.gmane.org/gmane.comp.version-control.git/284036/) +* [refs backend rebase on pu](https://public-inbox.org/git/1452788777-24954-1-git-send-email-dturner%40twopensource.com/) David Turner, who works for Twitter, recently sent new versions of his work to add a database backend to store Git refs: -- [v1 "LMDB refs backend atop pre-vtable"](http://thread.gmane.org/gmane.comp.version-control.git/281925/) -- [v2 "refs backend reroll"](http://thread.gmane.org/gmane.comp.version-control.git/283739/) -- [v3 "refs backend rebase on pu"](http://thread.gmane.org/gmane.comp.version-control.git/284036/) -- [v4 "refs backend"](http://thread.gmane.org/gmane.comp.version-control.git/285604/) +- [v1 "LMDB refs backend atop pre-vtable"](https://public-inbox.org/git/1449102921-7707-1-git-send-email-dturner%40twopensource.com/) +- [v2 "refs backend reroll"](https://public-inbox.org/git/1452561740-8668-1-git-send-email-dturner%40twopensource.com/) +- [v3 "refs backend rebase on pu"](https://public-inbox.org/git/1452788777-24954-1-git-send-email-dturner%40twopensource.com/) +- [v4 "refs backend"](https://public-inbox.org/git/1454701462-3817-1-git-send-email-dturner%40twopensource.com/) This work was started a long time ago by Ronnie Sahlberg, working for Google, and has already been reported about in @@ -45,24 +45,24 @@ Gummerer, Ramsay Jones, and also a bit by Howard Chu the LMDB author. Some suggestions were about: -- [avoiding "extern" in C source](http://thread.gmane.org/gmane.comp.version-control.git/282020), -- [splitting functions](http://thread.gmane.org/gmane.comp.version-control.git/282924), -- [config options](http://thread.gmane.org/gmane.comp.version-control.git/281925), -- [indenting using tabs instead of spaces](http://thread.gmane.org/gmane.comp.version-control.git/281925), -- [option naming](http://thread.gmane.org/gmane.comp.version-control.git/282934), -- [using argv_array_* functions](http://thread.gmane.org/gmane.comp.version-control.git/282952), -- [using pointers to functions](http://thread.gmane.org/gmane.comp.version-control.git/282923), -- [typedef and pointers](http://thread.gmane.org/gmane.comp.version-control.git/282699), -- [naming call back functions](http://thread.gmane.org/gmane.comp.version-control.git/283936), -- [avoiding strcpy()](http://thread.gmane.org/gmane.comp.version-control.git/284091), -- [strings and memory leaks](http://thread.gmane.org/gmane.comp.version-control.git/284170). +- [avoiding "extern" in C source](https://lore.kernel.org/lkml/200502270134.13625.dtor_core%40ameritech.net/), +- [splitting functions](https://public-inbox.org/git/567A3EB6.9000405%40alum.mit.edu/), +- [config options](https://public-inbox.org/git/1449102921-7707-1-git-send-email-dturner%40twopensource.com/), +- [indenting using tabs instead of spaces](https://public-inbox.org/git/1449102921-7707-1-git-send-email-dturner%40twopensource.com/), +- [option naming](https://public-inbox.org/git/567AA2DF.1020408%40alum.mit.edu/), +- [using argv_array_* functions](https://public-inbox.org/git/CAPig%2BcSaZRAXJ%2BsVZgFUbWcNMzqWGtH9rgqFXjupjtTJiQVYFw%40mail.gmail.com/), +- [using pointers to functions](https://public-inbox.org/git/567A3228.2060407%40alum.mit.edu/), +- [typedef and pointers](https://public-inbox.org/git/loom.20151218T050438-482%40post.gmane.org/), +- [naming call back functions](https://public-inbox.org/git/xmqqtwmhpg4j.fsf%40gitster.mtv.corp.google.com/), +- [avoiding strcpy()](https://public-inbox.org/git/20160114205259.GA10440%40sigill.intra.peff.net/), +- [strings and memory leaks](https://public-inbox.org/git/20160115133317.GJ10612%40hank/). So the interest in this work is still big and makes it likely that it will bear fruits hopefully soon. ### Support -* [clones over rsync broken?](http://thread.gmane.org/gmane.comp.version-control.git/285099/) +* [clones over rsync broken?](https://public-inbox.org/git/20160130051133.GA21973%40dcvr.yhbt.net/) Eric Wong, a long time git developer and the original git-svn author, reported that he couldn't use the rsync protocol anymore to clone: @@ -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 @@ -185,9 +185,9 @@ addressed. ## Releases -* On January 4th, 2016, [Git 2.7.0 was released](http://article.gmane.org/gmane.linux.kernel/2118402), and a day later, [Git for Windows followed suite](http://article.gmane.org/gmane.comp.version-control.git/283383). -* On February 2nd, 2016, Git for Windows published [version 2.7.0(2)](http://article.gmane.org/gmane.comp.version-control.git/285282) primarily to address [complaints by web browsers about "unsigned" installers](https://github.com/git-for-windows/git/issues/592). -* On February 6th, 2016, [Git 2.7.1 was released](http://article.gmane.org/gmane.comp.version-control.git/285657), followed by [Git for Windows 2.7.1](http://article.gmane.org/gmane.comp.version-control.git/285699) on the same day. +* On January 4th, 2016, [Git 2.7.0 was released](http://article.gmane.org/gmane.linux.kernel/2118402), and a day later, [Git for Windows followed suite](https://public-inbox.org/git/alpine.DEB.2.20.1601051641240.14434%40virtualbox/). +* On February 2nd, 2016, Git for Windows published [version 2.7.0(2)](https://public-inbox.org/git/alpine.DEB.2.20.1602021805250.2964%40virtualbox/) primarily to address [complaints by web browsers about "unsigned" installers](https://github.com/git-for-windows/git/issues/592). +* On February 6th, 2016, [Git 2.7.1 was released](https://public-inbox.org/git/xmqqd1sabt0a.fsf%40gitster.mtv.corp.google.com/), followed by [Git for Windows 2.7.1](https://public-inbox.org/git/alpine.DEB.2.20.1602061820490.2964%40virtualbox/) on the same day. * [Release v0.24.0b12 · libgit2/rugged](https://github.com/libgit2/rugged/releases/tag/v0.24.0b12) * [Release v0.11.0 · nodegit/nodegit](https://github.com/nodegit/nodegit/releases/tag/v0.11.0) * [JGit/EGit Release 4.2](http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg03087.html) @@ -197,7 +197,7 @@ addressed. __Various__ -* [Git Merge 2016 on April 5th 2016](http://git-merge.com/) and [Git Developer Summit on April 4th 2016](http://thread.gmane.org/gmane.comp.version-control.git/285270) in New York City USA have been officially announced. +* [Git Merge 2016 on April 5th 2016](http://git-merge.com/) and [Git Developer Summit on April 4th 2016](https://public-inbox.org/git/20160202161240.GA16870%40sigill.intra.peff.net/) in New York City USA have been officially announced. * [dear-github: An open letter to GitHub from the maintainers of open source projects](https://github.com/dear-github/dear-github) * [The history behind the decision to move Python to GitHub - Brett Cannon](http://www.snarky.ca/the-history-behind-the-decision-to-move-python-to-github) * [Mercurial's author, Matt Mackall, is moving on after 10 years of leading the project](https://www.mercurial-scm.org/wiki/mpm/transition) diff --git a/_posts/2016-03-16-edition-13.markdown b/_posts/2016-03-16-edition-13.markdown index 637f7d691..195c41f06 100644 --- a/_posts/2016-03-16-edition-13.markdown +++ b/_posts/2016-03-16-edition-13.markdown @@ -19,7 +19,7 @@ This edition covers what happened during the month of February 2016. ### General -* [RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP](http://thread.gmane.org/gmane.comp.version-control.git/285921/) +* [RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP](https://public-inbox.org/git/CAJo%3DhJtHgE_vye_1sPTDsvJ0X%3DCs72HKLgRH8btpW-pMrDdk9g%40mail.gmail.com/) It is a widely known problem that `git clone` is not resumable. If the connection comes down during a clone, the clone has to be restarted @@ -29,14 +29,14 @@ A work around that is often suggested and used is to first create a bundle using `git bundle`, to rsync that bundle, then to clone from the rsync'ed bundle and eventually to fetch what is missing from the remote git repository. Some tools -[like gitolite](http://thread.gmane.org/gmane.comp.version-control.git/235040/) or +[like gitolite](https://public-inbox.org/git/CADdDZRmufDTYYxHeAuPbCUn5iQHruAOXXho5KVOQ6McfSFvPJw%40mail.gmail.com/) or [the "repo" tool that is used by AOSP](https://source.android.com/source/using-repo.html) and some websites [like kernel.org](https://www.kernel.org/) have even been making it easier to support that. There was also at one point in 2011 -[a patch series](http://thread.gmane.org/gmane.comp.version-control.git/185196/) +[a patch series](https://public-inbox.org/git/20111110074330.GA27925%40sigill.intra.peff.net/) to improve the support of this kind of clone workflow internally. And for some time this was thought of by some Git developers as just a @@ -52,7 +52,7 @@ So it was very exciting to see a number of new proposals pop up on the list during the last few months. It started on February 5 with -[a "Resumable clone revisited, proof of concept" patch series by Duy Nguyen](http://thread.gmane.org/gmane.comp.version-control.git/285555/) +[a "Resumable clone revisited, proof of concept" patch series by Duy Nguyen](https://public-inbox.org/git/1454662677-15137-1-git-send-email-pclouds%40gmail.com/) where he wrote: > I was reminded by LWN about this. Annoyed in fact because it's @@ -65,11 +65,11 @@ that reports about download operations, which is an important bug to fix." Then on February 10 Shawn Pearce sent -[an 'RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP' proposal](http://thread.gmane.org/gmane.comp.version-control.git/285921/) +[an 'RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP' proposal](https://public-inbox.org/git/CAJo%3DhJtHgE_vye_1sPTDsvJ0X%3DCs72HKLgRH8btpW-pMrDdk9g%40mail.gmail.com/) that he had discussed internally with other people at Google where he works. This was followed on March 2 by -[an email called "Resumable git clone?"](http://thread.gmane.org/gmane.comp.version-control.git/288088/) +[an email called "Resumable git clone?"](https://public-inbox.org/git/20160302012922.GA17114%40jtriplet-mobl2.jf.intel.com/) from Josh Triplett, a well known Linux Kernel developer, who asked: > In a discussion elsewhere, Al Viro suggested taking the partial pack @@ -105,7 +105,7 @@ to be worked on soon, and then later some optimizations from Al and Josh could be implemented on top of it. Then on March 5 Kevin Wern sent -[an email called "Resumable clone"](http://thread.gmane.org/gmane.comp.version-control.git/288306/), +[an email called "Resumable clone"](https://public-inbox.org/git/CANtyZjSJf5_xbsBC5tUaazFT3uiEgJnx2_kHLwYwKcn50Jy_qg%40mail.gmail.com/), where he said he began looking at relevant code to start working on it, and he asked: > Is someone working on this currently? Are there any things I should @@ -113,10 +113,10 @@ where he said he began looking at relevant code to start working on it, and he a > down/organize the feature when writing patches? Duy answered that "Resumable clone is happening." And pointed to -[some preparation work](http://thread.gmane.org/gmane.comp.version-control.git/288205/focus=288222) -by Junio Hamano [going on](http://thread.gmane.org/gmane.comp.version-control.git/288080/focus=288150). +[some preparation work](https://public-inbox.org/git/xmqq1t7r2x21.fsf%40gitster.mtv.corp.google.com/) +by Junio Hamano [going on](https://public-inbox.org/git/xmqqvb556abd.fsf%40gitster.mtv.corp.google.com/). Junio by the way answered with -[a very long email](http://thread.gmane.org/gmane.comp.version-control.git/288306/focus=288317) +[a very long email](https://public-inbox.org/git/CANtyZjSJf5_xbsBC5tUaazFT3uiEgJnx2_kHLwYwKcn50Jy_qg%40mail.gmail.com/focus=288317) that contains "a rough and still slushy outline" of what remains to be done. This was then discussed and explained further. @@ -127,11 +127,11 @@ fixed not too far away into the future. ### Reviews -* [config: add '--show-origin' option to print the origin of a config value](http://thread.gmane.org/gmane.comp.version-control.git/286198/) +* [config: add '--show-origin' option to print the origin of a config value](https://public-inbox.org/git/1455531466-16617-4-git-send-email-larsxschneider%40gmail.com/) For some time Lars Schneider has been sending versions of a short patch series to make it possible to see where a config option comes -from ([v1](http://thread.gmane.org/gmane.comp.version-control.git/285553/), [v2](http://thread.gmane.org/gmane.comp.version-control.git/285894/), [v3](http://thread.gmane.org/gmane.comp.version-control.git/286110/), [v4](http://thread.gmane.org/gmane.comp.version-control.git/286197/), [v5](http://thread.gmane.org/gmane.comp.version-control.git/286485/), [v6](http://thread.gmane.org/gmane.comp.version-control.git/286672/)): +from ([v1](https://public-inbox.org/git/1454661750-85703-1-git-send-email-larsxschneider%40gmail.com/), [v2](https://public-inbox.org/git/1455099198-11515-1-git-send-email-larsxschneider%40gmail.com/), [v3](https://public-inbox.org/git/1455373456-64691-1-git-send-email-larsxschneider%40gmail.com/), [v4](https://public-inbox.org/git/1455531466-16617-1-git-send-email-larsxschneider%40gmail.com/), [v5](https://public-inbox.org/git/1455699468-45443-1-git-send-email-larsxschneider%40gmail.com/), [v6](https://public-inbox.org/git/1455873362-66998-1-git-send-email-larsxschneider%40gmail.com/)): ``` $ git config --list --show-origin @@ -140,8 +140,8 @@ file:/Users/john/.gitconfig alias.co=checkout file:.git/config remote.origin.url=https://repos/myrepo.git ``` -Lars started this patch series with an [RFC](http://thread.gmane.org/gmane.comp.version-control.git/285246) -whereupon Jeff King pointed him to a [previous discussion](http://thread.gmane.org/gmane.comp.version-control.git/190027/focus=190267) +Lars started this patch series with an [RFC](https://public-inbox.org/git/3226E251-73F9-4410-84DE-49C8FFAD92EB%40gmail.com/) +whereupon Jeff King pointed him to a [previous discussion](https://public-inbox.org/git/20120206062713.GA9699%40sigill.intra.peff.net/) about the same idea. Jeff also posted his initial implementation which Lars' v1 was based on. @@ -181,15 +181,15 @@ One nice side effect of this patch series is that in case of a config error Git can now tell more precisely from what type of config the error originates from (e.g. `standard input` or `file`). -* [add DEVELOPER makefile knob to check for acknowledged warnings](http://thread.gmane.org/gmane.comp.version-control.git/287345) (*written by Lars Schneider*) +* [add DEVELOPER makefile knob to check for acknowledged warnings](https://public-inbox.org/git/1456389742-48052-1-git-send-email-larsxschneider%40gmail.com/) (*written by Lars Schneider*) -Jeff King noted in a [review](http://thread.gmane.org/gmane.comp.version-control.git/285553/focus=285568) +Jeff King noted in a [review](https://public-inbox.org/git/1454661750-85703-1-git-send-email-larsxschneider%40gmail.com/focus=285568) that *git style doesn't allow declaration-after-statement*. Thereupon -Lars Schneider posted a [patch](http://thread.gmane.org/gmane.comp.version-control.git/285752) +Lars Schneider posted a [patch](https://public-inbox.org/git/1454921958-53129-1-git-send-email-larsxschneider%40gmail.com/) to check for this warning in the TravisCI build. In the review of this -patch Jeff [suggested](http://thread.gmane.org/gmane.comp.version-control.git/285752/focus=285761) +patch Jeff [suggested](https://public-inbox.org/git/1454921958-53129-1-git-send-email-larsxschneider%40gmail.com//focus=285761) to codify the knowledge about the warnings into an optional Makefile knob -called "DEVELOPER". Lars combined the warnings that [Junio and Jeff](http://thread.gmane.org/gmane.comp.version-control.git/285752/focus=285761) care about and posted a revised version of the [patch](http://thread.gmane.org/gmane.comp.version-control.git/287345). +called "DEVELOPER". Lars combined the warnings that [Junio and Jeff](https://public-inbox.org/git/1454921958-53129-1-git-send-email-larsxschneider%40gmail.com//focus=285761) care about and posted a revised version of the [patch](https://public-inbox.org/git/1456389742-48052-1-git-send-email-larsxschneider%40gmail.com/). Git developers with a reasonably modern compiler can now compile Git with `DEVELOPER=1 make` or set the flag once for all make executions with @@ -264,7 +264,7 @@ The last month we saw some maintenance releases of Git, along with some RCs of t * [Git v2.7.3](https://lkml.org/lkml/2016/3/10/612) * [Git for Windows 2.7.3](https://github.com/git-for-windows/git/releases/tag/v2.7.3.windows.1) -* [Git v2.8.0-rc2](http://article.gmane.org/gmane.linux.kernel/2174436) +* [Git v2.8.0-rc2](https://public-inbox.org/git/xmqqr3fiaq9f.fsf%40gitster.mtv.corp.google.com/) And then there was a significant, albeit humbly versioned new libgit2, which dominoed through its wrapper projects: diff --git a/_posts/2016-04-20-edition-14.markdown b/_posts/2016-04-20-edition-14.markdown index 7474d7ec6..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 @@ -209,7 +209,7 @@ long merge window. Following Greg's talk, Stefan Beller asked on the mailing list if Greg could put the Git developers in touch with the 0 day bot developers -and [a discussion started](http://thread.gmane.org/gmane.comp.version-control.git/291242/) +and [a discussion started](https://public-inbox.org/git/CAGZ79kZOx8ehAB-%3DFrjgde2CDo_vwoVzQNizJinf4LLXek5PSQ%40mail.gmail.com/) about how the 0 day bot could be used. @@ -278,7 +278,7 @@ git-difftool and git-mergetool. ## Releases -* [ANNOUNCE Git v2.8.0](http://article.gmane.org/gmane.linux.kernel/2185094) +* [ANNOUNCE Git v2.8.0](https://public-inbox.org/git/xmqqoa9y1ays.fsf%40gitster.mtv.corp.google.com/) * [ANNOUNCE Git v2.8.1 and call for help to make rpmbuild users](http://article.gmane.org/gmane.linux.kernel/2189878) * [Release Git for Windows 2.8.0 · git-for-windows/git](https://github.com/git-for-windows/git/releases/tag/v2.8.0.windows.1) * [Release Git for Windows 2.8.1 · git-for-windows/git](https://github.com/git-for-windows/git/releases/tag/v2.8.1.windows.1) diff --git a/_posts/2016-05-11-edition-15.markdown b/_posts/2016-05-11-edition-15.markdown index c72148457..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. @@ -161,11 +161,11 @@ vim () { That makes vim open file "foo" at line "X" if one uses `vim foo:X` just after having run `git grep`. -* [GSoC 2016](http://thread.gmane.org/gmane.comp.version-control.git/292308/) +* [GSoC 2016](https://public-inbox.org/git/CAFZEwPMr%3Dimv%3D%3DkvVULy4PDYKW-0RRQ5a%2BX8DFqNFhNjCSyWKA%40mail.gmail.com/) 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 @@ -238,7 +238,7 @@ which is very useful when rebasing a large patch series. I also have to mention ## Releases -* [Git 2.8.2](http://article.gmane.org/gmane.comp.version-control.git/293059/) +* [Git 2.8.2](https://public-inbox.org/git/xmqq7ffgvzpn.fsf%40gitster.mtv.corp.google.com/) * [Git for Windows 2.8.2](https://groups.google.com/d/msg/git-for-windows/-Jur6cdjMjE/m02wl_qCCQAJ) * [libgit2/rugged v0.25.0b2](https://github.com/libgit2/rugged/releases/tag/v0.25.0b2) * [libgit2/nodegit v0.13.0](https://github.com/nodegit/nodegit/releases/tag/v0.13.0) @@ -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-06-15-edition-16.markdown b/_posts/2016-06-15-edition-16.markdown index 3c15168f9..eaee2ce34 100644 --- a/_posts/2016-06-15-edition-16.markdown +++ b/_posts/2016-06-15-edition-16.markdown @@ -58,7 +58,7 @@ But for sure, launching a git command will never feel the same ;-) *(written by François BEUTIN, Jordan DE GEA, William DUCLOT, Samuel GROOT, Erwan MATHONIERE, Antoine QUERU, Simon RABOURG and Tom RUSSELLO)* -* [proposal for extending smudge/clean filters with raw file access](http://thread.gmane.org/gmane.comp.version-control.git/294425) +* [proposal for extending smudge/clean filters with raw file access](https://public-inbox.org/git/20160512182432.GA27427%40kitenet.net/) Joey Hess, who is the [git-annex](https://git-annex.branchable.com/) main developer and maintainer, sent an email with some suggestions to @@ -109,7 +109,7 @@ names "clean-from-fs" and "smudge-to-fs" have been suggested for them. ### Support -* [http://thread.gmane.org/gmane.comp.version-control.git/295135](Odd Difference Between Windows Git and Standard Git) +* [Odd Difference Between Windows Git and Standard Git](https://public-inbox.org/git/nhlqd4%24ekr%241%40ger.gmane.org/) Jon Forrest sent an email about a `git status` behavior he sees on Windows, which is different than on Linux on a repository that is @@ -248,8 +248,8 @@ itself so I don't have extra dependencies :) ## Releases * Git [2.9.0](http://article.gmane.org/gmane.linux.kernel/2242820) (major release). -* Git for Windows [2.9.0](http://article.gmane.org/gmane.comp.version-control.git/297287) (major release). -* Git [2.8.3](http://article.gmane.org/gmane.comp.version-control.git/295081) and [2.8.4](http://article.gmane.org/gmane.linux.kernel/2236998) (maintenance releases). +* Git for Windows [2.9.0](https://public-inbox.org/git/alpine.DEB.2.20.1606141316530.22630%40virtualbox/) (major release). +* Git [2.8.3](https://public-inbox.org/git/xmqqh9duj5vi.fsf%40gitster.mtv.corp.google.com/) and [2.8.4](http://article.gmane.org/gmane.linux.kernel/2236998) (maintenance releases). * Git for Windows [2.8.3](https://groups.google.com/forum/#!topic/git-for-windows/P008PLusCxw) and [2.8.4](https://groups.google.com/forum/#!topic/git-for-windows/LtFxynlPdAc) (maintenance releases). * git-multimail [1.3.0](https://github.com/git-multimail/git-multimail/releases/tag/1.3.0) and [1.3.1](https://github.com/git-multimail/git-multimail/releases/tag/1.3.1) were released, @@ -257,7 +257,7 @@ itself so I don't have extra dependencies :) a few SMTP-related improvements. * Sharness [1.0.0](https://github.com/chriscool/sharness/releases/tag/v1.0.0), a shell library to test your tools like Git does, was released and - [announced on the mailing list](http://thread.gmane.org/gmane.comp.version-control.git/297324). + [announced on the mailing list](https://public-inbox.org/git/CAP8UFD0uvaB-2_CrXs2ZvoqLRHfCd8efA-S7-tE2Qa6Pn%2BrAAg%40mail.gmail.com/). * libgit2/nodegit [v0.13.2](https://github.com/nodegit/nodegit/releases/tag/v0.13.2) * libgit2/rugged [v0.25.0b4](https://github.com/libgit2/rugged/releases/tag/v0.25.0b4) * GitLab [8.8](https://about.gitlab.com/2016/05/22/gitlab-8-8-released/) with Pipelines and .gitignore templates, patched up to [8.8.4](https://about.gitlab.com/2016/06/09/gitlab-8-dot-8-dot-4-released/) @@ -270,7 +270,7 @@ __Various__ * [Git 2.9 has been released](https://github.com/blog/2188-git-2-9-has-been-released) by Peff * [New "Mastering Git" book](https://www.packtpub.com/application-development/mastering-git) by long time Git contributor Jakub Narębski * [Rebase a Pull Request without access on the Fork](https://medium.com/@p.tournaris/git-rebase-a-pull-request-without-access-on-the-fork-a4189bac81b9) told by Pavlos-Petros Tournaris -* Some really cool new Git subcommands from Adam Spiers: [new git splice subcommand for non interactive branch splicing](http://article.gmane.org/gmane.comp.version-control.git/295755) +* Some really cool new Git subcommands from Adam Spiers: [new git splice subcommand for non interactive branch splicing](https://lore.kernel.org/lkml/200504121030.j3CAUkUl005147%40shell0.pdx.osdl.net/) * [Who Needs Git When You Got ZFS?](http://zef.me/blog/6023/who-needs-git-when-you-got-zfs) Zef Hemel asks. We do, but ZFS is still interesting. * [Easily Adding Meta Information to Git Branches](https://iinteractive.com/notebook/2016/05/25/git-mo-meta.html) by Yanick Champoux * [Display git branch in Windows command prompt](https://www.nu42.com/2016/05/display-git-branch-windows-command-prompt.html) in the simplest way, by A. Sinan Unur diff --git a/_posts/2016-07-20-edition-17.markdown b/_posts/2016-07-20-edition-17.markdown index 10df4d4dd..93e014325 100644 --- a/_posts/2016-07-20-edition-17.markdown +++ b/_posts/2016-07-20-edition-17.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 17th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of June 2016. @@ -24,16 +24,16 @@ This edition covers what happened during the month of June 2016. ### Reviews -* [contrib/subtree: Remove --annotate](http://thread.gmane.org/gmane.comp.version-control.git/283340/) +* [contrib/subtree: Remove --annotate](https://public-inbox.org/git/1451963101-4901-1-git-send-email-greened%40obbligato.org/) Last January David Greene, who maintains git-subtree.sh, sent -[a patch series](http://thread.gmane.org/gmane.comp.version-control.git/283268/) +[a patch series](https://public-inbox.org/git/1451766984-4648-1-git-send-email-greened%40obbligato.org/) to remove the `--annotate` option from `git subtree` and then -[a version 2 of this patch series](http://thread.gmane.org/gmane.comp.version-control.git/283340/). +[a version 2 of this patch series](https://public-inbox.org/git/1451963101-4901-1-git-send-email-greened%40obbligato.org/). This came after previous work to add `--unannotate` some years ago -[in 2012](http://thread.gmane.org/gmane.comp.version-control.git/207341/) and -[in 2013](http://thread.gmane.org/gmane.comp.version-control.git/212954/focus=212961). +[in 2012](https://public-inbox.org/git/CABVa4NinSighUn7GKbzMx9qZj3Ao2dCtEZxUqCPwO9TocZ8Kkg%40mail.gmail.com/) and +[in 2013](https://public-inbox.org/git/1357646997-28675-1-git-send-email-greened%40obbligato.org/). The reason why adding `--unannotate` has not been pursued is that it is "difficult to define due to the numerous ways one might want to @@ -99,12 +99,12 @@ 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 -* [Fwd: what is a snapshot](http://thread.gmane.org/gmane.comp.version-control.git/297701/) +* [Fwd: what is a snapshot](https://public-inbox.org/git/CAHWPVgMWeHoD5vTiFJ1gsm2hS74LK7j4npVVbOZeR43cX3qWXw%40mail.gmail.com/) Ovatta Bianca asked: @@ -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? @@ -286,8 +286,8 @@ but didn't have an occasion to use, is the [git-imerge](https://github.com/mhagg ## Releases -* Git [2.9.1](http://article.gmane.org/gmane.linux.kernel/2263540) (maintenance release), followed by Git [2.9.2](http://article.gmane.org/gmane.linux.kernel/2267451) that fixes a regression on 32-bit and on Windows. -* Git for Windows [2.9.2](http://article.gmane.org/gmane.comp.version-control.git/299684) (maintenance release, skipping 2.9.1). +* Git [2.9.1](https://public-inbox.org/git/xmqqbn247x1f.fsf%40gitster.mtv.corp.google.com/) (maintenance release), followed by Git [2.9.2](https://public-inbox.org/git/xmqqlh12lhq1.fsf%40gitster.mtv.corp.google.com/) that fixes a regression on 32-bit and on Windows. +* Git for Windows [2.9.2](https://public-inbox.org/git/alpine.DEB.2.20.1607161120030.6426%40virtualbox/) (maintenance release, skipping 2.9.1). * [nodegit/nodegit v0.15.1](https://github.com/nodegit/nodegit/releases/tag/v0.15.1) * [libgit2/pygit2 v0.24.1](https://github.com/libgit2/pygit2/releases/tag/v0.24.1) * [JGit/EGit Release 4.4.1](http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg03176.html) @@ -298,8 +298,8 @@ but didn't have an occasion to use, is the [git-imerge](https://github.com/mhagg __Various__ -* [New archives of the Git Mailing list have been announced](http://thread.gmane.org/gmane.comp.version-control.git/299195/) by Eric Wong. -* [An RFC about questions for "Git User's Survey 2016" has been posted](http://thread.gmane.org/gmane.comp.version-control.git/299032/) by Jakub Narębski. +* [New archives of the Git Mailing list have been announced](https://public-inbox.org/git/20160710004813.GA20210%40dcvr.yhbt.net/) by Eric Wong. +* [An RFC about questions for "Git User's Survey 2016" has been posted](https://public-inbox.org/git/577E6F32.7020007%40gmail.com/) by Jakub Narębski. __Light reading__ diff --git a/_posts/2016-08-17-edition-18.markdown b/_posts/2016-08-17-edition-18.markdown index c8a065204..294e2746b 100644 --- a/_posts/2016-08-17-edition-18.markdown +++ b/_posts/2016-08-17-edition-18.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 18th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of July 2016. @@ -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-09-14-edition-19.markdown b/_posts/2016-09-14-edition-19.markdown index 0b8d706d2..ed1ca07f6 100644 --- a/_posts/2016-09-14-edition-19.markdown +++ b/_posts/2016-09-14-edition-19.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 19th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of August 2016. diff --git a/_posts/2016-10-19-edition-20.markdown b/_posts/2016-10-19-edition-20.markdown index 4b61c9ea9..08184a15e 100644 --- a/_posts/2016-10-19-edition-20.markdown +++ b/_posts/2016-10-19-edition-20.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 20th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of September 2016. @@ -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/2016-11-16-edition-21.markdown b/_posts/2016-11-16-edition-21.markdown index c64d90b3b..d62df9c32 100644 --- a/_posts/2016-11-16-edition-21.markdown +++ b/_posts/2016-11-16-edition-21.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 21st 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of October 2016. diff --git a/_posts/2016-12-14-edition-22.markdown b/_posts/2016-12-14-edition-22.markdown index 6091c8d9a..9c8e32f09 100644 --- a/_posts/2016-12-14-edition-22.markdown +++ b/_posts/2016-12-14-edition-22.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 22nd 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of November 2016. @@ -95,7 +95,7 @@ algorithms. Dun Peal wrote that he is using vimdiff as his mergetool, and has the 'mergetool.vimdiff.trustExitCode' configuration option set to 'true' -in his ~/.gitconfig file. Nervertheless when he makes vimdiff exit +in his ~/.gitconfig file. Nevertheless when he makes vimdiff exit with code 1 (to mean failure), Git still acts as if the merge had succeeded. diff --git a/_posts/2017-01-25-edition-23.markdown b/_posts/2017-01-25-edition-23.markdown index 04ad7e498..49ddaeebb 100644 --- a/_posts/2017-01-25-edition-23.markdown +++ b/_posts/2017-01-25-edition-23.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 23rd 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of December 2016. diff --git a/_posts/2017-02-22-edition-24.markdown b/_posts/2017-02-22-edition-24.markdown index 05266ed31..a2a5335db 100644 --- a/_posts/2017-02-22-edition-24.markdown +++ b/_posts/2017-02-22-edition-24.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 24th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of January 2017 and the [Git Merge 2017](http://git-merge.com/) conference which happened in Brussels on February 2nd and 3rd 2017. diff --git a/_posts/2017-03-15-edition-25.markdown b/_posts/2017-03-15-edition-25.markdown index aeec26602..b5cfcbd3e 100644 --- a/_posts/2017-03-15-edition-25.markdown +++ b/_posts/2017-03-15-edition-25.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 25th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of February 2017. diff --git a/_posts/2017-04-19-edition-26.markdown b/_posts/2017-04-19-edition-26.markdown index d82d6efe7..2d3ab124c 100644 --- a/_posts/2017-04-19-edition-26.markdown +++ b/_posts/2017-04-19-edition-26.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 26th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of March 2017. diff --git a/_posts/2017-05-17-edition-27.markdown b/_posts/2017-05-17-edition-27.markdown index 711e14bc9..d7d7443f7 100644 --- a/_posts/2017-05-17-edition-27.markdown +++ b/_posts/2017-05-17-edition-27.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 27th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of April 2017. diff --git a/_posts/2017-06-14-edition-28.markdown b/_posts/2017-06-14-edition-28.markdown index 9e5dbacf2..90eaf1a9e 100644 --- a/_posts/2017-06-14-edition-28.markdown +++ b/_posts/2017-06-14-edition-28.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 28th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of May 2017. @@ -294,7 +294,7 @@ the job done. * [Git v2.13.1](https://github.com/git/git/blob/v2.13.1/Documentation/RelNotes/2.13.1.txt) * [Git for Windows v2.13.1](https://github.com/git-for-windows/git/releases/tag/v2.13.1.windows.1) -* [What's new in Deveo 3.19](blog.deveo.com/whats-new-in-deveo-3-19/) (git hosting site) +* [What's new in Deveo 3.19](https://blog.deveo.com/whats-new-in-deveo-3-19/) (git hosting site) * [Git Tower 1.1.0 for Windows Release Notes](https://www.git-tower.com/windows/release-notes#1.1.0) (proprietary multiplatform Git GUI) * [Portable GitHub system "GitPrep 2.6" is released](http://blogs.perl.org/users/yuki_kimoto/2017/06/portable-github-system-gitprep-26-is-released---wiki-system-is-added-you-can-write-documentation.html) (opensource git hosting software, in Perl) * [JGit / EGit release 4.7.1.201706071930-r](http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg03360.html) diff --git a/_posts/2017-07-19-edition-29.markdown b/_posts/2017-07-19-edition-29.markdown index 6cf2fe8cc..1997064a3 100644 --- a/_posts/2017-07-19-edition-29.markdown +++ b/_posts/2017-07-19-edition-29.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 29th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of June 2017. diff --git a/_posts/2017-08-16-edition-30.markdown b/_posts/2017-08-16-edition-30.markdown index 3c7795674..06de58a0e 100644 --- a/_posts/2017-08-16-edition-30.markdown +++ b/_posts/2017-08-16-edition-30.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 30th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of July 2017. diff --git a/_posts/2017-09-20-edition-31.markdown b/_posts/2017-09-20-edition-31.markdown index 6e3ee11aa..ddfc097b8 100644 --- a/_posts/2017-09-20-edition-31.markdown +++ b/_posts/2017-09-20-edition-31.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 31st 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of August 2017. diff --git a/_posts/2017-10-11-edition-32.markdown b/_posts/2017-10-11-edition-32.markdown index 846184d86..8a43c70ef 100644 --- a/_posts/2017-10-11-edition-32.markdown +++ b/_posts/2017-10-11-edition-32.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 32nd 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of September 2017. @@ -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..b76d2c15d 100644 --- a/_posts/2017-11-22-edition-33.markdown +++ b/_posts/2017-11-22-edition-33.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 33rd 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of October 2017. @@ -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..dea6c3e0e 100644 --- a/_posts/2017-12-20-edition-34.markdown +++ b/_posts/2017-12-20-edition-34.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 34th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of November 2017. @@ -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-01-17-edition-35.markdown b/_posts/2018-01-17-edition-35.markdown index 843930b34..904449c50 100644 --- a/_posts/2018-01-17-edition-35.markdown +++ b/_posts/2018-01-17-edition-35.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 35th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of December 2017. diff --git a/_posts/2018-02-21-edition-36.markdown b/_posts/2018-02-21-edition-36.markdown index 4ec122f78..b6fcc29fa 100644 --- a/_posts/2018-02-21-edition-36.markdown +++ b/_posts/2018-02-21-edition-36.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 36th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of January 2018. diff --git a/_posts/2018-03-21-edition-37.markdown b/_posts/2018-03-21-edition-37.markdown index 3b5ba0ede..f9b0a5c50 100644 --- a/_posts/2018-03-21-edition-37.markdown +++ b/_posts/2018-03-21-edition-37.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 37th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened from the month of February 2018 up to the [Git Merge](https://git-merge.com/) conference on March 7th and 8th 2018. @@ -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..c458bfb7c 100644 --- a/_posts/2018-04-18-edition-38.markdown +++ b/_posts/2018-04-18-edition-38.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 38th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of March 2018. @@ -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..58aced04f 100644 --- a/_posts/2018-05-16-edition-39.markdown +++ b/_posts/2018-05-16-edition-39.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 39th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of April 2018. @@ -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..630679fe3 100644 --- a/_posts/2018-06-20-edition-40.markdown +++ b/_posts/2018-06-20-edition-40.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 40th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of May 2018. @@ -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..713828655 100644 --- a/_posts/2018-07-18-edition-41.markdown +++ b/_posts/2018-07-18-edition-41.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 41st 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of June 2018. @@ -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..c315014eb 100644 --- a/_posts/2018-08-22-edition-42.markdown +++ b/_posts/2018-08-22-edition-42.markdown @@ -11,7 +11,7 @@ navbar: false Welcome to the 42nd 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). This edition covers what happened during the month of July 2018. @@ -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. + +### Reviews + +* [[RFC] Introduce two new commands, switch-branch and restore-paths](https://public-inbox.org/git/20181120174554.GA29910@duynguyen.home/) + + Duy Nguyen sent an RFC patch to the mailing list that implemented 2 + new Git commands: + + - `git switch-branch` which "is all about switching branches" + - `git restore-paths` "for checking out paths" + + The goal is to split `git checkout` into different commands while + not deprecating it, so that "Old timers will still use + `git checkout`. But new people should be introduced to the new two + instead." + + The idea to do that appeared [following a previous patch to print something when checking out paths](https://public-inbox.org/git/20181110133525.17538-1-pclouds@gmail.com/), + though it has been considered for a long time that `git checkout` + should not do as many different things as it currently does. + + Thomas Gummerer replied that he liked the idea and had been + considering working on it. He suggested taking at look at maybe + changing the behavior of the new command a bit. + + Junio Hamano, the Git maintainer, then started to discuss the naming + of `git restore-paths` with Duy. + + Ævar Arnfjörð Bjarmason replied to Duy's original message asking + questions about arguments accepted by `git switch-branch` and + suggesting a comparison between the new commands and `git checkout` + or even other source code management tools. He also discussed with + Duy about eventually deprecating `git checkout`. + + Stefan Beller replied to Ævar and started discussing the names and + syntax of the command. Junio replied to Stefan telling that he + thought the names Duy suggested make sense, though `checkout` + already makes sense and longhands starting with `checkout`, like + `checkout-branch`, would make sense too. + + Duy then sent a [version 2](https://public-inbox.org/git/20181127165211.24763-1-pclouds@gmail.com/) + of his initial patch that "breaks down the giant patch in v1 and + starts adding some changes in these new commands". Especially the + names were changed to `checkout-branch` and `checkout-files`. + + A first discussion thread started with Junio, Duy, Stefan Beller and + Stefan Xenos about the name and syntax of the new commands. As no + clear conclusion appeared though, Duy decided to go back towards the + original names he had proposed. + + Another discussion thread among the same developers was about using + "unnamed branch" instead of "detached HEAD". + + These discussions were followed by a [version 3](https://public-inbox.org/git/20181129215850.7278-1-pclouds@gmail.com/) + where the names of the commands were changed back to `switch-branch` + and `restore-files` instead of `restore-paths`. + + There were further discussions involving Elijah Newren, Junio, Duy, + Ævar, Dan Fabulich, Thomas and Eric Sunshine, about a lot of related + subjects, though Duy decided to wait until the release of Git 2.20 + before sending an updated patch series. + + + + + +## Releases + ++ Git [2.20.1](https://public-inbox.org/git/xmqqsgyzbcyy.fsf@gitster-ct.c.googlers.com/), +[2.20.0](https://public-inbox.org/git/xmqq1s6r3xb5.fsf@gitster-ct.c.googlers.com/), +[2.20.0-rc2](https://public-inbox.org/git/xmqq36rhjnts.fsf@gitster-ct.c.googlers.com/), +[2.20.0-rc1](https://public-inbox.org/git/xmqqmuq25ufc.fsf@gitster-ct.c.googlers.com/), +[2.19.2](https://public-inbox.org/git/xmqqtvka5ugt.fsf@gitster-ct.c.googlers.com/) ++ Git for Windows [2.20.1](https://github.com/git-for-windows/git/releases/tag/v2.20.1.windows.1), +[2.20.0](https://github.com/git-for-windows/git/releases/tag/v2.20.0.windows.1), +[2.20.0-rc2](https://github.com/git-for-windows/git/releases/tag/v2.20.0-rc2.windows.1), +[2.20.0-rc1](https://github.com/git-for-windows/git/releases/tag/v2.20.0-rc1.windows.1), +[2.20.0-rc0](https://github.com/git-for-windows/git/releases/tag/v2.20.0-rc0.windows.1) ++ libgit2sharp [0.25.4](https://github.com/libgit2/libgit2sharp/releases/tag/v0.25.4) ++ GitLab [11.6RC7, 11.5.4, 11.4.11 and 11.3.13](https://about.gitlab.com/2018/12/13/critical-security-release-gitlab-11-dot-5-dot-4-released/), +[11.5.3](https://about.gitlab.com/2018/12/06/critical-security-release-gitlab-11-dot-5-dot-3-released/), +[11.4.9](https://about.gitlab.com/2018/12/04/gitlab-11-4-9-released/), +[11.5.2](https://about.gitlab.com/2018/12/04/gitlab-11-5-2-released/), +[11.5.1](https://about.gitlab.com/2018/11/28/security-release-gitlab-11-dot-5-dot-1-released/), +[11.5](https://about.gitlab.com/2018/11/22/gitlab-11-5-released/), +[11.4.7](https://about.gitlab.com/2018/11/21/gitlab-11-4-7-released/), +[11.5.0-rc12, 11.4.6 and 11.3.10](https://about.gitlab.com/2018/11/19/critical-security-release-gitlab-11-dot-4-dot-6-released/) ++ Bitbucket Server [5.16](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [2.16.1](https://www.gerritcodereview.com/2.16.html#2161) ++ GitHub Enterprise [2.15.4](https://enterprise.github.com/releases/2.15.4/notes), +[2.14.11](https://enterprise.github.com/releases/2.14.11/notes), +[2.13.17](https://enterprise.github.com/releases/2.13.17/notes), +[2.12.25](https://enterprise.github.com/releases/2.12.25/notes), +[2.15.3](https://enterprise.github.com/releases/2.15.3/notes), +[2.14.10](https://enterprise.github.com/releases/2.14.10/notes), +[2.13.16](https://enterprise.github.com/releases/2.13.16/notes), +[2.12.24](https://enterprise.github.com/releases/2.12.24/notes) + +## Other News + +__Various__ + +* [Git Contributor Summit Registration, Jan 31, 2019, Brussels](https://public-inbox.org/git/20181206094805.GA1398@sigill.intra.peff.net) +* [Git Merge 2019](https://git-merge.com/) (Jan 31 -- Feb 01) schedule announced, including: + * A “Git and version control in the enterprise” panel with GitHub, Atlassian, and GitLab + * A chat with Deb Nicholson from the Software Freedom Conservancy on the future of software + * Sessions by Google, Microsoft, and Praqma on scaling Git + * Lighting talks on everything from version control for law to Git for games +* [“The 's' is sad”: 4-year-old submits Linux kernel doc patch](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=690b0543a813b0ecfc51b0374c0ce6c8275435f0) with some assistance (via Hacker Newsletter #429) + + +__Light reading__ + +* Ed Thomson's [Git Advent Calendar](https://www.edwardthomson.com/blog/git_tips_and_tricks_advent_calendar.html). +* Samuel Walladge explains [how to use Git with (Neo)Vim](https://vimways.org/2018/vim-and-git/) on Day 6 of the Vimways Advent Calendar. +* Neil Kakkar's [How not to be afraid of Git anymore](https://medium.freecodecamp.org/how-not-to-be-afraid-of-git-anymore-fe1da7415286). +* Will Hay Jr.'s [The Architecture and History of Git: A Distributed Version Control System](https://medium.com/@willhayjr/the-architecture-and-history-of-git-a-distributed-version-control-system-62b17dd37742). See also: + * [The Git Parable](http://tom.preston-werner.com/2009/05/19/the-git-parable.html), by Tom Preston-Werner (2009) - the ideas behind the architecture of Git; covered in [Git Rev News #30](https://git.github.io/rev_news/2017/08/16/edition-30/) + * slides from ["Git Chronicles"](https://docs.google.com/file/d/0Bw3FApcOlPDhMFR3UldGSHFGcjQ/view) talk at GitTogether 2008 - early history +* Susan Potter's [Git entry](http://www.aosabook.org/en/git.html) in ["The Architecture of Open Source Applications" book](http://www.aosabook.org/en/index.html), Volume II (2012); there is [chapter on Mercurial](http://www.aosabook.org/en/mercurial.html) in Volume I (2012). +* David Gohberg's [The Biggest Misconception About Git](https://medium.com/@gohberg/the-biggest-misconception-about-git-b2f87d97ed52), that Git is all about storing differences between files. +* Aditya Sridhar's [How to become a Git expert](https://medium.freecodecamp.org/how-to-become-a-git-expert-e7c38bf54826), about amending commits and rebasing +* [Large files with Git: LFS and git-annex](https://lwn.net/Articles/774125) article on LWN.net, contributed by Antoine Beaupré +* [How I changed the law with a GitHub pull request](https://arstechnica.com/tech-policy/2018/11/how-i-changed-the-law-with-a-github-pull-request/) article on Ars Technica, contributed by Joshua Tauberer +* Caitlin Hudon's [Git Your SQL Together (with a Query Library)](https://caitlinhudon.com/2018/11/28/git-sql-together/) recommends tracking SQL queries in Git +* Eric S. Raymond's [SRC, four years later](http://esr.ibiblio.org/?p=8205), about his single-file version control system with modern UI +* Johnathan Swan's [Gradually improving our code quality with Test::Perl::Critic::Progressive](https://medium.com/adzuna-engineering/gradually-improving-our-code-quality-with-test-perl-critic-progressive-a8f98319ac56) together with Git to catch and report _new_ code style policy violations +* Peter Hutterer's [On commit messages](http://who-t.blogspot.com/2009/12/on-commit-messages.html) (2009) + +__Git tools and sites__ + +* [sr.ht](https://sr.ht/) ([https://sr.ht](https://sr.ht/)) is a very + capable software forge which is already serving the needs of many + projects in the free & open source software community site. It is + 100% open source software and includes goodies such as a wiki, + mailing lists, ticketing, with neat features such as all the pages + work without Javascript, and it is designed to support an email Git + workflow. Provided hosting is available for a low cost and + contributing to the software can get one credit towards hosting. + It was announced in a + [sr.ht, the hacker's forge, now open for public alpha](https://drewdevault.com/2018/11/15/sr.ht-general-availability.html) + blog post. + +* [Adobe's `git-server`](https://github.com/adobe/git-server), a [nodegit](https://github.com/nodegit/nodegit)-based application to serve Git repositories via `http://` and `https://`. + +* [Git Butler](https://www.gitbutler.com/): Pull Request and Issue Workflow Automation -- an alternative to [GitHub Actions](https://github.com/features/actions) (covered in [Git Rev News #44](https://git.github.io/rev_news/2018/10/24/edition-44/)), allowing to automate Git workflow by creating powerful rules with a simple visual editor + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Gabriel Alcaras <> +with help from Johannes Schindelin, Kaartic Sivaraam +and Matt Singletary. diff --git a/_posts/2019-01-23-edition-47.markdown b/_posts/2019-01-23-edition-47.markdown new file mode 100644 index 000000000..0fb0a0d6e --- /dev/null +++ b/_posts/2019-01-23-edition-47.markdown @@ -0,0 +1,223 @@ +--- +title: Git Rev News Edition 47 (January 23rd, 2019) +layout: default +date: 2019-01-23 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 47 (January 23rd, 2019) + +Welcome to the 47th 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](https://git.github.io). + +This edition covers what happened during the month of December 2018. + +## Discussions + + +### General + +* [Referring to commits in commit messages](https://public-inbox.org/git/877eg5fwd5.fsf@evledraar.gmail.com/) + + Ævar Arnfjörð Bjarmason replied to a + [patch](https://public-inbox.org/git/20181217165957.GA60293@google.com/) + that Jonathan Nieder had sent to the mailing list. He suggested using + the [standard commit-reference format documented in SubmittingPatches](https://github.com/git/git/blob/16a465bc018d09e9d7bbbdc5f40a7fb99c21f8ef/Documentation/SubmittingPatches#L143-L158) in the commit message of the patch. + + Using the standard format would have produced: + + ``` + 92068ae8bf ("stripspace: respect repository config", 2016-11-21) + ``` + + while Jonathan's patch contained: + + ``` + v2.11.0-rc3~3^2~1 (stripspace: respect repository config, 2016-11-21) + ``` + + The main difference is that the former starts with an abbreviated + object id, while the latter starts with an output from `git describe`. + + Ævar gave an example of him previously looking for a commit using + `git log --grep=0386dd37b1` and not finding it because Jonathan had + not used the standard format. + + Ævar also wondered if "we should have some mode where + `--grep=` will be combined with some mode where we try to + find various forms of `` in commit messages, then normalize + & match them..." + + Duy Nguyen replied to that by suggesting we use email style trailers + like `In-Reply-To: ...` or even `Fixes: ...` to refer + to related commits, which could make sense as we already use + [`Signed-off-by: User ` trailers](https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L306-L347) + and some other similar trailers in commit messages. + + Gábor Szeder also replied to Ævar saying that the `%h (%s, %ad)` is + even better and more widely used than the standard `%h ("%s", %ad)` as + the former avoids useless double quotes around the commit title. + + Jeff King, alias Peff, then commented to Ævar's suggestion about a new + mode for `--grep=`. He gave examples of other tools that + work better with the standard format: + + - web interfaces like GitHub have learned to replace an abbreviated + object id with a link to a page displaying the object, + + - terminals makes it easy to select object ids, but don't understand + output from `git describe`. + + Peff acknowledged that the format with an output from `git describe` + has some benefits: + + > As far as I can tell, the main advantage of using `v2.11.0-rc3~3^2~1` + > over its hex id is that it gives a better sense in time of which Git + > version we're talking about. The date in the parentheses does something + > similar for wall-clock time, but it's left to the reader to map that to + > a Git version if they choose. + + But he thought that they were not worth the disadvantages "as in the + rare instance that I care about the containing version, it's not a big + deal to use `git tag --contains`". + + He suggested anyway using something like: + + ``` + 1234abcd (the subject line, 2016-01-01, v2.11.0) + ``` + + which adds a version after the date, "if we really want to convey that + information". And he proposed some reasonable rules for this new + format. + + Jonathan replied to Peff's suggestion by discussing the possible + ambiguities in what the tag name is referring to. This led Jonathan to + prefer using trailers like `Fixes: ...` as Duy had suggested, + saying they have been working well for the Linux kernel project. + + In a separate reply to Duy's email, Jonathan copied relevant + [documentation from the Linux kernel project](https://github.com/torvalds/linux/blob/ae67ee6c5e1d5b6acdb0d51fddde651834096d75/Documentation/process/submitting-patches.rst) + where they specify a trailer that looks like: + + ``` + Fixes: e21d2170f366 ("video: remove unnecessary platform_set_drvdata()") + ``` + + Jonathan then proposed a patch to the Git Documentation that would + make the Git project adopt a similar policy. + + Peff replied to Jonathan that using `Fixes: ...` trailers is a good + idea but that "there are many other reasons to refer to another commit + in prose (or even outside of a commit message entirely)". + + Jonathan, Peff and Ævar discussed a bit more, and Jacob Keller chimed + in, but in the end it doesn't look like any change has been decided. + + + + + + + +## Releases + ++ JGit [4.5.5](https://projects.eclipse.org/projects/technology.jgit/releases/4.5.5), +[4.7.7](https://projects.eclipse.org/projects/technology.jgit/releases/4.7.7), +[4.9.8](https://projects.eclipse.org/projects/technology.jgit/releases/4.9.8), +[4.11.6](https://projects.eclipse.org/projects/technology.jgit/releases/4.11.6), +[5.1.5](https://projects.eclipse.org/projects/technology.jgit/releases/5.1.5), +[5.2.1](https://projects.eclipse.org/projects/technology.jgit/releases/5.2.1) ++ Gerrit Code Review [2.9.5](https://www.gerritcodereview.com/2.9.html#295), +[2.10.8](https://www.gerritcodereview.com/2.10.html#2108), +[2.11.12](https://www.gerritcodereview.com/2.11.html#21112), +[2.12.9](https://www.gerritcodereview.com/2.12.html#2129), +[2.13.12](https://www.gerritcodereview.com/2.13.html#21312), +[2.14.18](https://www.gerritcodereview.com/2.14.html#21418), +[2.15.8](https://www.gerritcodereview.com/2.15.html#2158), +[2.16.2](https://www.gerritcodereview.com/2.16.html#2162), +[2.16.3](https://www.gerritcodereview.com/2.16.html#2163) ++ GitHub Enterprise [2.15.5](https://enterprise.github.com/releases/2.15.5/notes), +[2.14.12](https://enterprise.github.com/releases/2.14.12/notes), +[2.13.18](https://enterprise.github.com/releases/2.13.18/notes) ++ GitLab [11.6.5](https://about.gitlab.com/2019/01/17/gitlab-11-6-5-released/), +[11.6.4, 11.5.7 and 11.4.14](https://about.gitlab.com/2019/01/16/critical-security-release-gitlab-11-dot-6-dot-4-released/), +[11.6.3](https://about.gitlab.com/2019/01/05/gitlab-11-6-3-released/), +[11.6.2](https://about.gitlab.com/2019/01/03/gitlab-11-6-2-released/), +[11.6.1, 11.5.6 and 11.4.13](https://about.gitlab.com/2018/12/31/security-release-gitlab-11-dot-6-dot-1-released/), +[11.6](https://about.gitlab.com/2018/12/22/gitlab-11-6-released/) ++ GitKraken [4.2.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [1.6.0](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ +* Security vulnerabilities in JGit and Gerrit: + - [Gerrit issue 10201](https://bugs.chromium.org/p/gerrit/issues/detail?id=10201): + When protocol v2 was enabled and used, Gerrit would make all refs visible to the + calling user. Support for protocol v2 was removed in Gerrit 2.16.2, and the issue + was fixed in JGit versions 5.1.5 and 5.2.1. + - [Gerrit issue 10262](https://bugs.chromium.org/p/gerrit/issues/detail?id=10262): + In protocol v0 stateless transport, it was possible to fetch anything that is + pointed to by any ref (using fetch-by-sha1), as long as the attacker could guess + the object name. The issue was fixed in JGit versions 4.5.5, 4.7.7, 4.9.8, 4.11.6, + 5.1.5 and 5.2.1, which were included in Gerrit versions 2.9.5, 2.10.8, 2.11.12, + 2.12.9, 2.13.12, 2.14.18, 2.15.8 and 2.16.3. +* [Outreachy](https://www.outreachy.org/) interns working on Git have been blogging about their internship: + - [Tanushree Tumane's blog](http://tanu1596.blogspot.com/) + - [Slavica Đukić's blog](https://slavicadj.github.io/blog/) +* AsciiDoc, the markup language used by [Git's manual and other documentation](https://git-scm.com/docs), + will get [an official specification under the Eclipse Foundation](https://asciidoctor.org/news/2019/01/07/asciidoc-spec-proposal/). +* Google is [seeking open source projects for Google Summer of Code 2019](https://opensource.googleblog.com/2019/01/seeking-projects-for-gsoc-2019.html). + The deadline to apply is February 6 at 20:00 UTC, chosen + organizations will be announced on February 26. + Git Development Community [is interested](https://public-inbox.org/git/CAP8UFD3Kt3dreMnfAdLiP2yc47kBLoVYCk-2yDw67OkujVY=Ew@mail.gmail.com/T/#m5568b147f03c0b2e9dc96843dc13e85f5b2f187f). +* [GitLab Serverless launched Dec. 22](https://about.gitlab.com/2018/12/11/introducing-gitlab-serverless/). +* [New year, new GitHub: Announcing unlimited free private repos and unified Enterprise offering](https://github.blog/2019-01-07-new-year-new-github/) (the former with up to three collaborators per repository). + +__Light reading__ +* [Git explained: Git Concepts and Workflows](https://docs.google.com/presentation/d/1IQCRPHEIX-qKo7QFxsD3V62yhyGA9_5YsYXFOiBpgkk/edit?usp=sharing) by Edwin Kempin +* [Gerrit explained: Gerrit Concepts and Workflows](https://docs.google.com/presentation/d/1C73UgQdzZDw0gzpaEqIC6SPujZJhqamyqO1XOHjH-uk/edit?usp=sharing) by Edwin Kempin +* [A tale of 132 e's](https://linuxwit.ch/blog/2018/12/e98e/) and [the [E]nd of eeeee](https://linuxwit.ch/blog/2018/12/everything-that-lives-is-designed-to-end/) by Iliana Weller, about [e30e/e98e](https://github.com/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee) GitHub repository and its history +* [How to teach Git](https://rachelcarmena.github.io/2018/12/12/how-to-teach-git.html) by Rachel M. Carmena +* [How To Use Git: A Reference Guide](https://dev.to/digitalocean/how-to-use-git-a-reference-guide-6b6) by Lisa Tagliaferri from DigitalOcean +* [8 Productivity Tips for GitHub](https://dev.to/_darrenburns/8-productivity-tips-for-github-44kn) by Darren Burns +* [Something Someone Somewhere Uses... Sometimes](https://dev.to/benjaminadk/something-someone-somewhere-uses-sometimes-1kab) by benjaminadk, about [gitmoji](https://gitmoji.carloscuesta.me/) +* [A new free-software forge: sr.ht [LWN.net]](https://lwn.net/Articles/775963/) by Jake Edge; this service was covered in [previous edition of Git Rev News](https://git.github.io/rev_news/2018/12/19/edition-46/#other-news) +* [Monorepos: Please don’t!](https://medium.com/@mattklein123/monorepos-please-dont-e9a279be011b) by Matt Klein + - [Monorepo: please do!](https://medium.com/@adamhjk/monorepo-please-do-3657e08a4b70), response by Adam Jacob + - see also + [Advantages of Monolithic Version Control](http://danluu.com/monorepo/) by Dan Luu + ([Git Rev News: Edition #4](https://git.github.io/rev_news/2015/06/03/edition-4/)) and + [Monorepos in Git](https://developer.atlassian.com/blog/2015/10/monorepos-in-git/?p) by Stefan Saasen + ([Git Rev News: Edition #9](https://git.github.io/rev_news/2015/11/11/edition-9/)) + - and also [splitsh/lite](https://github.com/splitsh/lite) ([Git Rev News: Edition #16](https://git.github.io/rev_news/2016/06/15/edition-16/)) and + [Lerna](https://lernajs.io/) ([Git Rev News: Edition #43](https://git.github.io/rev_news/2018/09/19/edition-43/)) tools for monorepos +* [Writing Good Commit Messages](https://medium.com/compass-true-north/writing-good-commit-messages-fc33af9d6321) by Ben Hoyt (2018) +* [Useful Tips for writing better Git commit messages](https://code.likeagirl.io/useful-tips-for-writing-better-git-commit-messages-808770609503) by Egwuenu Gift (2018) +* [1296: Git Commit -- explain xkcd](https://www.explainxkcd.com/wiki/index.php/1296:_Git_Commit) (2013) +* [How to manage binary blobs with Git](https://opensource.com/life/16/8/how-manage-binary-blobs-git-part-7) by Seth Kenlon (2016) +* [Migrating Internet Archive to Kubernetes](https://archive.org/~tracey/slides/kubecon/#/) -- slides from presentation at KubeCon 2018; slides [#35](https://archive.org/~tracey/slides/kubecon/#/35) and later are about how Git is used at [archive.org](https://archive.org/) + +__Git tools and sites__ + +* [OneDev](https://onedev.io) Open source git server with unique features such as language aware code search and navigation, source/diff annotation for code discussion and comprehension, customizable issue field and workflow, write protection for branches/tags/files, etc. +* [gitmoji -- An emoji guide for your commit messages](https://gitmoji.carloscuesta.me/) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Gabriel Alcaras <> +with help from Johannes Schindelin, Robin Shen and David Pursehouse. diff --git a/_posts/2019-02-27-edition-48.markdown b/_posts/2019-02-27-edition-48.markdown new file mode 100644 index 000000000..db94b6682 --- /dev/null +++ b/_posts/2019-02-27-edition-48.markdown @@ -0,0 +1,321 @@ +--- +title: Git Rev News Edition 48 (February 27th, 2019) +layout: default +date: 2019-02-27 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 48 (February 27th, 2019) + +Welcome to the 48th 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](https://git.github.io). + +This edition covers what happened during the month of January 2019. +It also covers the Git Contributor Summit and the Git +Merge conference that took place on January 31th and February 1st. + +## Discussions + +### General + +* Git Merge 2019 — General Sessions + + The [Git Merge](https://git-merge.com/) 2019 conference took place in Brussels, Belgium + on January 31st (workshops and contributor summit) and February 1st (main conference day). + + * This year a big theme was handling large Git repositories, + both from technical and organizational point of view + + * Ivan Frade and Minh Thai in _"Tales in scalability: how Google has seen users break Git"_ + talked about solving problems with Android (many repos, huge binary assets, many commits) + and Chromium monorepo (many unique committers). Some of the problems were caused by legacy + practices of trying to keep Subversion-like monotonic version number -- it turned out + that attempts to provide it got into troubles and were cause of much of churn. Another + problem was the change in Gerrit, which now stores patch history in git repo, resulting + in "forest of tiny bushes" graph of commits; the solution here was moving to protocol v2. + There was also talk about making the negotiation phase during fetch faster at the cost + of somewhat bigger data transfer, e.g. by skipping commits using Fibonacci number gaps. + + * Johan Abildskov, a consultant at Praqma in _"The what, how and why of scaling repositories"_ + talked about how to choose between monorepos and many-repos (and how to split the codebase + into repositories). The major idea was to not ignore the real problems (like having to + create multiple commits to handle single bug), and to base decision on data + + > Our conclusions are not better than our data + + For this reason the [git-metrics](https://github.com/Praqma/git-metrics) tool was created, + which is a set of util scripts to scrape data from git repositories to help teams improve. + + * Brandon Williams from Facebook gave a lightning talk _"Git protocols: still tinkering after all these years?"_ + focusing on introduction of protocol v2 to reduce communication overhead (especially important + for repositories with large number of branches and tags) and increase extensibility, and troubles + with adding it while maintaining all-important backwards compatibility. + + * Terry Parker from Google gave a lightning talk _"Native Git support for large objects"_ + explain how Git’s new partial clone feature (where only a subset of objects, + selected by initial filter, e.g. `--filter=blob:limit=1m`, is downloaded on clone; + the rest are fetched on demand, as needed) and the new proposal to use content distribution networks + (CDN) can help with handling repositories with large files. + + * John Briggs from Microsoft in _"Technical contributions towards scaling for Windows"_ + talked about both technical improvements in Git, like serialized commit graph (with + generation numbers) and multipack index (`*.midx`), and the "sparse" object walk + during push that is being worked on (see the ["Reviews"](#reviews) section), and + improvements in VFS for Git (formerly called GVFS), like prefetching in background + and git status serialization. He also announced that VFS for Git will be ported + to other platforms: MacOS and Linux (to handle MS Office, which itself is cross-platform + project). + + * John Austin, game studio technical lead from A Stranger Gravity and Funomena + in _"Git for games: current problems and solutions"_ talked about major problem + with using Git in game development workflows, namely many and large binary files, + for which file conflicts are lost work (minor change, like adding voiceover + or changing equalizer settings results in large changes to files). File locking + is one possibility, but it doesn't play nicely with Git -- it is inherently centralized. + He introduces a new tool, [Git Global Graph](https://github.com/Kleptine/gitglobalgraph) + (a work in progress), which can be used to check at commit time if it wouldn't + create a divergent version of a file. The idea is that there should be only + a single path through commit graph with changes to binary files. + + * Javier Fontan from source{d} gave a lightning talk _"Gitbase, SQL interface to Git repositories"_ + about [gitbase](https://github.com/src-d/gitbase) tool, which provides read-only + SQL interface to Git repositories (with Abstract Syntax Tree support). + + * Brian M. Carlson, Git Ecosystem Engineer at GitHub in _"Bridging the gap: transitioning Git to SHA-256"_ + talked about ongoing work to transition from SHA-1, which is considered weak, + to SHA-256, which is more secure: the transition plan, where we are with it, + and how to provide interoperability between versions of Git using different hash algorithms. + + * Belén Barros Pena, PhD student and interaction designer, gave talk + _"The art of patience: why you should bother teaching Git to designers"_, + where she also described _how_ to do it and provide good retention, namely: + + 1. Show things on a need-to-know basis + 2. Avoid the Git jargon + 3. Don't bother too much with the concepts; + will be grasped through practice + 4. Do things with, never for, your designer + 5. Designer should take notes and keep cheat sheet + 6. Teach command--line Git + + * Veronica Hanus in _"Version control for visual learners"_ + talked about how to enter visual representations of recently-changed elements into version control + in the form of screenshot diffing. + + +### Reviews + +* [Add a new "sparse" tree walk algorithm](https://public-inbox.org/git/pull.89.git.gitgitgadget@gmail.com/) + +Last November Derrick Stolee, who prefers to be called just Stolee, +sent a patch series to the mailing list to speed up `git push` +operations by implementing and using a new "sparse" tree walk +algorithm. + +Stefan Beller wondered how users can know about this new algorithm and +if it should be turned on by default for users. Stolee replied that +indeed "we should actually make the config setting true by default, +and recommend that servers opt-out". + +Junio Hamano, the Git maintainer, disagreed saying that we should wait +until "enough users complain that they have to turn it on" before we +turn it on by default. + +Stolee later sent a [version 2 of the patch series](https://public-inbox.org/git/pull.89.v2.git.gitgitgadget@gmail.com/) +improving the tests, then a [version 3](https://public-inbox.org/git/pull.89.v3.git.gitgitgadget@gmail.com/) +improving the documentation, and a [version 4](https://public-inbox.org/git/pull.89.v4.git.gitgitgadget@gmail.com/) +with a few code and commit message improvements. + +Junio and Stolee discussed how the `mark_trees_uninteresting_sparse()` +function is implemented in the first patch, and how a variable is +named in this function. + +They also discussed the purpose of patches 2 and 3 and agreed that +they should be merged and what the related tests should do. + +Additionally, Junio suggested a number of small code improvements in the last +patch. Especially he suggested to get rid of a global variable that +was unused. Ramsay Jones, who regularly uses the `sparse` tool and his +own `static-check.pl` script on the Git code base to find errors, had +also found this unused variable separately. + +Ævar Arnfjörð Bjarmason chimed in to ask for a clarification about +which step the patch speeds up, and if a progress bar should be added +while the user is waiting during this step, and how this step should +be named on the command line interface. It seems though that some +preliminary work would be needed to untangle the steps during which a +progress bar is already displayed. + +Stolee eventually sent a [version 5 of the patch series](https://public-inbox.org/git/pull.89.v5.git.gitgitgadget@gmail.com/) +on January 16th which has since been merged and is in the recently +released Git v2.21.0. + + + + + +## Releases + ++ Git [2.21.0](https://public-inbox.org/git/xmqqtvgtkq46.fsf@gitster-ct.c.googlers.com/), +[2.21.0-rc2](https://public-inbox.org/git/xmqq8sybz7b2.fsf@gitster-ct.c.googlers.com/), +[2.21.0-rc1](https://public-inbox.org/git/xmqq8syj9h9b.fsf@gitster-ct.c.googlers.com/), +[2.21.0-rc0](https://public-inbox.org/git/xmqqh8dgqcqn.fsf@gitster-ct.c.googlers.com/) ++ Git for Windows [2.21.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.21.0.windows.1) ++ libgit2 [0.28.1](https://github.com/libgit2/libgit2/releases/tag/v0.28.1), +[0.28.0](https://github.com/libgit2/libgit2/releases/tag/v0.28.0), +[0.27.8](https://github.com/libgit2/libgit2/releases/tag/v0.27.8) ++ libgit2sharp [0.26](https://github.com/libgit2/libgit2sharp/releases/tag/v0.26) ++ GitHub Enterprise [2.16.3](https://enterprise.github.com/releases/2.16.3/notes), +[2.15.8](https://enterprise.github.com/releases/2.15.8/notes), +[2.14.15](https://enterprise.github.com/releases/2.14.15/notes), +[2.13.21](https://enterprise.github.com/releases/2.13.21/notes), +[2.16.2](https://enterprise.github.com/releases/2.16.2/notes), +[2.15.7](https://enterprise.github.com/releases/2.15.7/notes), +[2.14.14](https://enterprise.github.com/releases/2.14.14/notes), +[2.13.20](https://enterprise.github.com/releases/2.13.20/notes), +[2.16.1](https://enterprise.github.com/releases/2.16.1/notes), +[2.15.6](https://enterprise.github.com/releases/2.15.6/notes), +[2.14.13](https://enterprise.github.com/releases/2.14.13/notes), +[2.13.19](https://enterprise.github.com/releases/2.13.19/notes) ++ GitLab [11.8](https://about.gitlab.com/2019/02/22/gitlab-11-8-released/), +[11.7.5](https://about.gitlab.com/2019/02/07/gitlab-11-7-5-released/), +[11.7.4](https://about.gitlab.com/2019/02/05/critical-security-release-gitlab-11-dot-7-dot-4-released/), +[11.7.3](https://about.gitlab.com/2019/01/31/security-release-gitlab-11-dot-7-dot-3-released/) ++ Bitbucket Server [6.0](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [2.15.11](https://www.gerritcodereview.com/2.15.html#21511), +[2.16.5](https://www.gerritcodereview.com/2.16.html#2165), +[2.15.10](https://www.gerritcodereview.com/2.15.html#21510), +[2.16.4](https://www.gerritcodereview.com/2.16.html#2164), +[2.15.9](https://www.gerritcodereview.com/2.15.html#2159) ++ GitKraken [4.2.2](https://support.gitkraken.com/release-notes/current), +[4.2.1](https://support.gitkraken.com/release-notes/current), +[4.2.0](https://support.gitkraken.com/release-notes/current), +[4.1.1](https://support.gitkraken.com/release-notes/current), +[4.1.0](https://support.gitkraken.com/release-notes/current), +[4.0.6](https://support.gitkraken.com/release-notes/current), +[4.0.5](https://support.gitkraken.com/release-notes/current), +[4.0.4](https://support.gitkraken.com/release-notes/current), +[4.0.3](https://support.gitkraken.com/release-notes/current), +[4.0.2](https://support.gitkraken.com/release-notes/current), +[4.0.1](https://support.gitkraken.com/release-notes/current), +[4.0.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [1.6.2](https://desktop.github.com/release-notes/), +[1.6.1](https://desktop.github.com/release-notes/) ++ Sourcetree [3.1](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_3.1.html) + +## Other News + +__Various__ + +* [GSoC 2019: Git's application submitted](https://public-inbox.org/git/20190204215251.GB6085@hank.intra.tgummerer.com/T/) + and [got accepted](https://summerofcode.withgoogle.com/organizations/6104737735245824/) as one of [207 open source projects](https://opensource.googleblog.com/2019/02/gsoc-2019-organizations.html); + ideas for project proposals [published](https://git.github.io/SoC-2019-Ideas/) + +* The Git Contributor Summit 2019 happened on January 30th in Brussels. Elijah + Newren took some [notes](https://public-inbox.org/git/CABPp-BGfSRy-NT+f39gSumD9haYZPAnpNPY-VnanioCbdYFoEQ@mail.gmail.com/). + A video stream of the event was broadcast and recorded, but is not + yet available for download. + +* The [Git Merge Conference 2019](https://git-merge.com/) happened on + February 1st in Brussels. Videos of the presentations are not yet + available. The GitHub team expects them to be available + [before the end of this month](https://public-inbox.org/git/20190221082218.GA3335@sigill.intra.peff.net/). + - A short [Mission report: Git Merge 2019](https://github.blog/2019-02-12-mission-report-git-merge-2019/) was posted on GitHub blog. + +* [GerritHub.io multi-site plugin is going public](https://groups.google.com/forum/#!topic/repo-discuss/A9dGOppvgGA) and has + been proposed to be hosted on gerrit-review.googlesource.com. That is going to be the first globally available Open Source + implementation for having [Gerrit Code Review](https://www.gerritcodereview.com) masters replicated and synchronized over multiple sites. + +__Light reading__ + +* [gitgeist: a git-based social network proof of concept](https://www.karimyaghmour.com/blog/2019/02/gitgeist-a-git-based-social-network-proof-of-concept.html) by Karim Yaghmour + (mentioned [on LWN.net](https://lwn.net/Articles/780365/)). + +* [France enters the Matrix [LWN.net]](https://lwn.net/Articles/779331/) by Tom Yates + covers Matthew Hodgson talk about [Matrix](https://matrix.org/blog/home/) at [FOSDEM 2019](https://fosdem.org/2019/); + Matrix is an open standard and lightweight protocol for real-time communication, + allowing to create decentralized federated instant messaging system with end-to-end encryption; + the video of the whole talk [is available](https://fosdem.org/2019/schedule/event/matrix_french_state/). + + > [...] the "first-class citizen" in Matrix is not the message, but + > the conversation history of the room. That history is stored in a + > big data structure that is replicated across a number of + > participants; in that respect, said Hodgson, Matrix is *more like + > Git* than XMPP, SIP, IRC, or many other traditional communication + > protocols. + +* [./hacker-tools lectures: Version Control](https://hacker-tools.github.io/version-control/), + focusing on Git (article with an embedded 53 minutes video). + +* [An open source parser for GitHub Actions](https://githubengineering.com/an-open-source-parser-for-github-actions/) + on GitHub Engineering Blog + ([GitHub Actions](https://github.com/features/actions) were covered in + [Git Rev News #44](https://git.github.io/rev_news/2018/10/24/edition-44/)). + +* [Snowpatch: continuous-integration testing for the kernel [LWN.net]](https://lwn.net/Articles/777421/) + by Jonathan Corbet. [Snowpatch](https://github.com/ruscur/snowpatch) + (mentioned in [Git Rev News Edition #40](https://git.github.io/rev_news/2018/06/20/edition-40/)) + is built on top of [patchwork](http://jk.ozlabs.org/projects/patchwork/) + (mentioned in [Git Rev News Edition #20](https://git.github.io/rev_news/2016/10/19/edition-20/)). + + +__Git tools and sites__ + +* [git-history](https://github.com/pomber/git-history) is a web-based tool (for Node.js) + to quickly browse the history of a file from any GitHub repository. + ([GitLab and Bitbucket support is also planned](https://github.com/pomber/git-history/issues/14)); + unfortunately the [demo service](https://github.githistory.xyz/babel/babel/blob/master/packages/babel-core/test/browserify.js) + at [was down](https://twitter.com/pomber/status/1100412811455287304) at the time of publishing this edition, + causing [Chrome](https://chrome.google.com/webstore/detail/github-history-browser-ex/laghnmifffncfonaoffcndocllegejnf) and [Firefox](https://addons.mozilla.org/firefox/addon/github-history/) extensions, + which add an _Open in Git History_ button to GitHub, not to work either. + +* [gitgeist-poc](https://github.com/opersys/gitgeist-poc) by Francois-Denis Gonthier + is a Proof-of-Concept implementation of + [gitgeist: a git-based social network proof of concept](https://www.karimyaghmour.com/blog/2019/02/gitgeist-a-git-based-social-network-proof-of-concept.html) idea. + +* [Git Gud](https://nic-hartley.github.io/git-gud/) is a pretty + barebone visual web-based Git simulator, meant to help understand + Git better, which got announced by its author Nic Hartley in + [Git Gud at git](https://dev.to/nichartley/git-gud-at-git-5d9k); + quite similar to [Learn Git Branching](https://learngitbranching.js.org/) + service (covered in [Git Rev News Edition #30](https://git.github.io/rev_news/2017/08/16/edition-30/#other-news)). + +* [GitLens — Git supercharged](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens) + extension supercharges the Git capabilities built into Visual Studio Code. + +* [github-spray](https://github.com/Annihil/github-spray) is yet another tool + to draw on your GitHub contribution graph; there is also + [GitHub Spray Generator](https://annihil.github.io/github-spray-generator/) service. + +* [gitbase](https://github.com/src-d/gitbase) from source{d} is a tool (in alpha) providing + [SQL interface to Git repositories](https://docs.sourced.tech/gitbase), written in Go. + It is part of [source{d} Engine](https://sourced.tech/engine), and implements MySQL wire protocol. + Uses [go-git](https://github.com/src-d/go-git) for accessing Git repositories, + [go-mysql-server](https://github.com/src-d/go-mysql-server) for the SQL engine implementation, + [enry](https://github.com/src-d/enry) for programming language detection for files, + and [bblfhs](https://github.com/bblfsh) for source code parsing into AST (Abstract Syntax Tree). + There is also a [web client](https://github.com/src-d/gitbase-web) for it. + +* [Gitana](http://modeling-languages.com/gitana-a-sql-based-git-repository-inspector/): a SQL-based Project Activity Inspector, + written in Python ([GitHub repository](https://github.com/SOM-Research/Gitana)), + was mentioned in [Git Rev News Edition #7](https://git.github.io/rev_news/2015/09/09/edition-7/#other-news). + Nowadays it imports and digests the data of Git repositories, issue trackers (including Bugzilla and GitHub), + Q&A web-sites (including forums and StackOverflow) and instant messaging services to a relational database + in order to ease browsing and querying activities with standard SQL syntax and tools. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Gabriel Alcaras <> +with help from David Pursehouse and Luca Milanesio. diff --git a/_posts/2019-03-20-edition-49.markdown b/_posts/2019-03-20-edition-49.markdown new file mode 100644 index 000000000..9e2b909b6 --- /dev/null +++ b/_posts/2019-03-20-edition-49.markdown @@ -0,0 +1,214 @@ +--- +title: Git Rev News Edition 49 (March 20th, 2019) +layout: default +date: 2019-03-20 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 49 (March 20th, 2019) + +Welcome to the 49th 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](https://git.github.io). + +This edition covers what happened during the month of February 2019. + +## Discussions + + + +### Reviews + +* [test-lib: make '\-\-stress' more bisect-friendly](https://public-inbox.org/git/20190208115045.13256-1-szeder.dev@gmail.com/) + + `--stress` is an option that can be passed to a test script from the + Git test suite to try to reproduce rare failures in the test script + by running it many times in parallel. + + Gábor Szeder had initially implemented this option starting + [last December](https://public-inbox.org/git/20181204163457.15717-1-szeder.dev@gmail.com/) + based on [a script](https://github.com/peff/git/blob/meta/stress) + that Jeff King, alias Peff, had developed and + [mentioned](https://public-inbox.org/git/20181122161722.GC28192@sigill.intra.peff.net/) + on the mailing list. + + That first iteration had been reviewed by Peff, Ævar Arnfjörð + Bjarmason and Junio Hamano, and was followed by a + [second iteration](https://public-inbox.org/git/20181209225628.22216-1-szeder.dev@gmail.com/) + also reviewed by Peff. + + A [third](https://public-inbox.org/git/20181230191629.3232-1-szeder.dev@gmail.com/) and + [fourth](https://public-inbox.org/git/20190105010859.11031-1-szeder.dev@gmail.com/) + iteration were sent with only minor changes. The latter then got merged last January, + so the feature was released in Git 2.21.0. + + On February 8th Gábor sent a patch to improve on top of his previous + work on `--stress`. The goal was to make it easier to use the + `--stress` along with `git bisect` to find the first commit that + introduced a test failure when the test failure is not easy to + reproduce. + + Specifically, the patch was addressing two issues with + `--stress`. The first one is that `--stress` runs the test script + endlessly when the test doesn't fail. This is fixed with a new + `--stress-limit=` option "to repeat the test script at most N + times in each of the parallel jobs, and exit with success when the + limit is reached". + + The second issue is that when the test script used with `--stress` + fails, it exits with a success error code. This is addressed by + making it exit with a failure error code in this case. + + With the improvement, it is possible to automatically find the + commit that introduced a flakiness in for example `t1234-foo.sh`, + using something like: + + ```sh + $ git bisect start origin/pu master + $ git bisect run sh -c 'make && cd t && ./t1234-foo.sh --stress --stress-limit=300' + ``` + + Gábor and Peff then discussed a few details. Regarding how to select a + good N to pass to `--stress-limit=`, Gábor suggested running the + test script with `--stress` 3-5 times to trigger the failure, taking + the highest repetition count that was necessary for the failure and + multiplying it by 4-6 to get a round number". + + Gábor later sent [a subsequent patch](https://public-inbox.org/git/20190211195803.1682-1-szeder.dev@gmail.com/) + to fix a minor issue in his previous patches, as it seems that some + shells require the `!` character to start a non-matching pattern + bracket expression instead of `^` that he had used. + + These improvements to the `--stress` option made it in the Git + 2.21.0 release too. + + Even more recently Johannes Schindelin, alias Dscho, sent + [a small patch series](https://public-inbox.org/git/pull.155.git.gitgitgadget@gmail.com/) + to improve on the previous work by: + + - having `--stress-limit=` imply `--stress` + - introducing `--stress-jobs=` + + The goal is to avoid mistakenly using `--stress=` when one wants + to limit the number of number of times the test script is run (which + should be done using `--stress-limit=`). + + Dscho then sent a [second version](https://public-inbox.org/git/pull.155.v2.git.gitgitgadget@gmail.com/) + of his patch series with a few improvements. + + These patches were reviewed by Junio, Eric Sunshine, Peff and + Gábor. The changes have been merged to the 'next' branch and are + planned to be merged in the 'master' branch soon. + + + + + + +## Releases + ++ GitLab [11.8.2](https://about.gitlab.com/2019/03/14/gitlab-11-8-2-released/), +[11.8.1](https://about.gitlab.com/2019/03/04/security-release-gitlab-11-dot-8-dot-1-released/) ++ Bitbucket Server [6.1](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [2.16.7](https://www.gerritcodereview.com/2.16.html#2167), +[2.16.6](https://www.gerritcodereview.com/2.16.html#2166), +[2.15.11](https://www.gerritcodereview.com/2.15.html#21511) ++ GitHub Enterprise [2.16.4](https://enterprise.github.com/releases/2.16.4/notes), +[2.15.9](https://enterprise.github.com/releases/2.15.9/notes), +[2.14.16](https://enterprise.github.com/releases/2.14.16/notes), +[2.13.22](https://enterprise.github.com/releases/2.13.22/notes) ++ GitHub Desktop [1.6.4](https://desktop.github.com/release-notes/), +[1.6.3](https://desktop.github.com/release-notes/) ++ GitKraken [5.0.2](https://support.gitkraken.com/release-notes/current), +[5.0.1](https://support.gitkraken.com/release-notes/current), +[5.0.0](https://support.gitkraken.com/release-notes/current) + +## Other News + +__Various__ + +* Videos of the [Git Merge 2019](https://git-merge.com/) conference + (January 31th and February 1st 2019 in Brussels, Belgium) are now + [available](https://www.youtube.com/playlist?list=PL0lo9MOBetEFqBue4vNcTEnkBjgIQU1Q3). + +* The [Gerrit User Summit 2019](https://gus2019.eventbrite.com) will take place + in Gothenburg 29-30 August, hosted by [Volvo Cars](http://volvocars.com). + The event is free but seats are limited. For the first time also the community + opens the 5 days Hackathon 24-28 August, same location, to everyone: the only + requirement is to be willing to learn and contribute to the JGit or Gerrit + Code Review project. + +* Google [is creating](https://opensource.googleblog.com/2019/03/introducing-season-of-docs.html) + a project aimed at improving OSS projects documentation: + [Season of Docs 2019](https://developers.google.com/season-of-docs/). + Mentoring organizations can begin submitting applications to Google + on April 2, 2019. + + +__Light reading__ + +* [Redesigning Github repository page](http://tonsky.me/blog/github-redesign/) + by Nikita Prokopov describes how the author would have changed the design. + +* [Write yourself a Git!](https://wyag.thb.lt/) by Thibault Polge is + an attempt at explaining the Git version control system from the + bottom up, that is, starting at the most fundamental level moving up + from there. All it takes to understand Git internals is to + reimplement Git from scratch in exactly 503 lines of very simple + Python code. + +* [10 Git Commands You Should Know; Plus tips to save time with Git](https://towardsdatascience.com/10-git-commands-you-should-know-df54bea1595c) + by Jeff Hale. + +* [Git hacks you should know about](https://dev.to/teamxenox/git-hacks-you-should-know-about-16pk) + by Ankur Biswas; most of these is a regular workflow stuff, though + (and you need to take care as some of commands rewrite history). + +* [Data Versioning](https://emilygorcenski.com/post/data-versioning/) + by Emily Gorcenski identifies four key axes on which machine + learning systems have a notion of version along with some brief + recommendations for how to simplify it a bit. + + +__Git tools and sites__ + +* [Git Interactive Rebase Tool](https://gitrebasetool.mitmaro.ca/) is + an improved sequence editor for Git interactive rebase by + [MitMaro](https://github.com/MitMaro). + +* [radicle](http://radicle.xyz/) is a peer-to-peer stack for code + collaboration based on Git and [IPFS](https://ipfs.io/). + +* [Git-graph](https://github.com/hoduche/git-graph) by + [Henri-Olivier Duché](https://github.com/hoduche) + can help you "Learn Git fast and well - by visualizing the inner graph of your Git + repositories". + +* [Pachyderm](https://www.pachyderm.io/open_source.html) is designed + to enable sustainable data science workflows via a language-agnostic + system for *data versioning* with data pipelining. Similar tools, + namely [DVC](https://dvc.org) (Data Version Control) + and [Meltano](https://gitlab.com/meltano/meltano), were described + in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/). + +* [git ready](http://gitready.com/): learn Git one commit at a time; + tips are split into beginner, intermediate and advanced. + Latest tip is from 2015, though. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Gabriel Alcaras <> +with help from Luca Milanesio <>. diff --git a/_posts/2019-04-26-edition-50.markdown b/_posts/2019-04-26-edition-50.markdown new file mode 100644 index 000000000..778959648 --- /dev/null +++ b/_posts/2019-04-26-edition-50.markdown @@ -0,0 +1,174 @@ +--- +title: Git Rev News Edition 50 (April 26th, 2019) +layout: default +date: 2019-04-26 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 50 (April 26th, 2019) + +Welcome to the 50th 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](https://git.github.io). + +This edition covers what happened during the month of March 2019. + +## Discussions + + + + + + +### Support + +* [Can't build first git commit](https://public-inbox.org/git/1551729517.4092.1.camel@libero.it/) + +Fabio Aiuto asked for support on the Git mailing list as he was trying +to build [the first commit of Git made by Linus in April 2005](https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23), +but was getting "undefined reference to symbol" errors related to the OpenSSL library. + +Santiago Torres replied suggesting him to use a toolchain from around +the time the commit was made and using an earlier OpenSSL library. + +Fabio replied that he would have liked to "to debug around that simple +version, to understand how everything works". + +Santiago suggested playing with libgit2, that has a smaller code base, +and its python bindings that "abstract the memory management and other +low-level stuff". + +Jeff King, alias Peff, suggested linking with `-lcrypto` instead of +`-lssl` and also adding `-lz` to the Makefile or the command line. +He said that `make LIBS='-lcrypto -lz'` works for him and that he +"used periodically check that Git v1.0 can fetch happily from GitHub". + +[asymptosis](https://public-inbox.org/git/20190304214829.GA573@sleipnir/) +chimed in to suggest working through +[the "Git Internals" chapter in the Git Book](https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) +to understand how Git works. He also pointed to a +[Git re-implementation as simple bash scripts](https://notabug.org/cryptarch/sgit) +he had started to understand that chapter. + +Jonathan Nieder recommended reading the +[Hacking Git chapter in the user manual documentation](https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#hacking-git) +that comes with Git. + +Peff then reported that he managed again to build Git version 1.0.0 +from December 2005 with `make NO_OPENSSL=Nope` and to use it to fetch +from GitHub. + +Fabio replied that he also succeeded in building the first commit of +Git made by Linus. + +Fabio, Santiago and Peff then discussed the fact that it was still +possible to build a 15 year old codebase with a modern toolchain. Peff +explained that it's possible because "Git has very few external +dependencies", and other than that, Git "just depends on a reasonable +C compiler and a POSIX libc, both of which have been standardized for +decades". + +Then Fabio reported a segfault in the version he had built. Peff +reproduced it and showed how to work around it. + +Fabio thanked Peff and asymptosis. He said he would "go on studying +Git this way, and follow all the improvements that were made along its +history". + + + + +## Releases + ++ Bitbucket Server [6.2](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [2.13.14](https://www.gerritcodereview.com/2.13.html#21314), +[2.14.20](https://www.gerritcodereview.com/2.14.html#21420), +[2.15.13](https://www.gerritcodereview.com/2.15.html#21513) ++ GitHub Enterprise [2.16.6](https://enterprise.github.com/releases/2.16.6/notes), +[2.15.11](https://enterprise.github.com/releases/2.15.11/notes), +[2.14.18](https://enterprise.github.com/releases/2.14.18/notes), +[2.16.5](https://enterprise.github.com/releases/2.16.5/notes), +[2.15.10](https://enterprise.github.com/releases/2.15.10/notes), +[2.14.17](https://enterprise.github.com/releases/2.14.17/notes), +[2.13.23](https://enterprise.github.com/releases/2.13.23/notes) ++ GitLab [11.10](https://about.gitlab.com/2019/04/22/gitlab-11-10-released/), +[11.9.8](https://about.gitlab.com/2019/04/11/gitlab-11-9-8-released/), +[11.9.7](https://about.gitlab.com/2019/04/10/critical-security-release-gitlab-11-dot-9-dot-7-released/), +[11.9.6](https://about.gitlab.com/2019/04/04/gitlab-11-9-6-released/), +[11.9.4](https://about.gitlab.com/2019/04/01/security-release-gitlab-11-dot-9-dot-4-released/), +[11.9.1](https://about.gitlab.com/2019/03/26/gitlab-11-9-1-released/), +[11.9](https://about.gitlab.com/2019/03/22/gitlab-11-9-released/) ++ GitKraken [5.0.4](https://support.gitkraken.com/release-notes/current), +[5.0.3](https://support.gitkraken.com/release-notes/current), +[5.0.2](https://support.gitkraken.com/release-notes/current), +[5.0.1](https://support.gitkraken.com/release-notes/current), +[5.0.0](https://support.gitkraken.com/release-notes/current) + +## Other News + +__Various__ + +* [Highlights from Git 2.21](https://github.blog/2019-02-24-highlights-from-git-2-21/) + on GitHub Blog. +* [6 new Bitbucket Cloud features that spark joy](https://bitbucket.org/blog/6-new-bitbucket-cloud-features-that-spark-joy). +* [Announcing _Building Git_](https://blog.jcoglan.com/2019/04/08/announcing-building-git/) by James Coglan; + some of the articles about diff and merge algorithms that form a part of this book were covered in + [Git Rev News Edition #25](https://git.github.io/rev_news/2017/03/15/edition-25/). + + +__Light reading__ + +* [Sending patches by email with Git](https://flusp.ime.usp.br/git/2019/02/15/sending-patches-by-email-with-git/) + by Matheus Tavares and [https://git-send-email.io/](https://git-send-email.io/) + by sourcehut are two articles on how to setup and use Git's send-email + command. +* [Learn by Contributing](https://dev.to/agoldis/learn-by-contributing-27g6) by Andrew Goldis, + about how contributing to open source projects helps you to improve + your professional skills and discover new opportunities. +* [Writing Good Source Control Commit Messages](https://dev.to/rachelsoderberg/writing-good-source-control-commit-messages-2j2m) by Rachel Soderberg; + the slightly controversial part might be leaving out the information + that can be found in issue tracker. +* [Using Graph Theory to Decide Where to Start Reading Source Code](https://medium.com/@a.lurie_78598/using-graph-theory-to-decide-where-to-start-reading-source-code-74a1e2ddf72) by Aron Lurie + (connecting files that are changed together, and finding "central" nodes in that graph). +* [Tips for a disciplined git workflow](https://drewdevault.com/2019/02/25/Using-git-with-discipline.html) by Drew DeVault. +* [5 Free Courses to Learn Git and GitHub in Depth](https://dev.to/javinpaul/5-free-courses-to-learn-git-and-github-in-depth-jpp) by javingpaul. +* [15 Git Commands You May Not Know](https://dev.to/zaiste/15-git-commands-you-may-not-know-4a8j) by Zaiste. +* [10 insanely useful Git commands you wish existed – and their alternatives](https://dev.to/datreeio/10-insanely-useful-git-commands-you-wish-existed-and-their-alternatives-8e6) by Eyar Zilberman. +* [Don’t Commit Improperly Formatted Go (golang) Code](https://medium.com/@corylanou/dont-commit-improperly-formatted-go-golang-code-5cea011d589d) - use git hooks, by Cory LaNou. +* [How does git bisect choose the commit to test?](http://julien.mascart.com/2017/03/how-does-git-bisect-choose-commit-to.html) by Julien 'jma' Mascart (2017). +* [Fun with bisecting](https://git-blame.blogspot.com/2011/07/fun-with-bisecting.html) by Junio C Hamano aka Gitster (2011). + + +__Git tools and sites__ + +* [Gitlet.js](http://gitlet.maryrosecook.com/docs/gitlet.html) + by Mary Rose Cook is Git implemented in JavaScript, + written to show how Git works under the covers + (written to be readable and heavily commented). +* [git-rs](https://github.com/chrisdickinson/git-rs): + Git, implemented in [Rust](https://www.rust-lang.org/), for fun and education. +* [Git Cheat Sheets](https://github.github.com/training-kit/): + Reference sheets covering Git commands, features, SVN migrations, + and bash. Available in multiple languages. +* [Giistr](https://giistr.com/): Contribute to build the open-source world. + Search, filter and help easily on the issues of the [GitHub] repositories you starred. +* [BDFL: A 100% accurate simulation of OSS maintenance](https://derrickstolee.github.io/bdfl/): + A silly clicker game featuring graphs. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Gabriel Alcaras <> +with help from Luca Milanesio. diff --git a/_posts/2019-05-22-edition-51.markdown b/_posts/2019-05-22-edition-51.markdown new file mode 100644 index 000000000..465621e2f --- /dev/null +++ b/_posts/2019-05-22-edition-51.markdown @@ -0,0 +1,359 @@ +--- +title: Git Rev News Edition 51 (May 22nd, 2019) +layout: default +date: 2019-05-22 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 51 (May 22nd, 2019) + +Welcome to the 51st 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](https://git.github.io). + +This edition covers what happened during the month of April 2019. + +## Discussions + + +### General + +* [GSoC students and mentors 2019](https://public-inbox.org/git/20190508171941.GC2068@hank.intra.tgummerer.com/) + + Two students are going to work on Git during this summer as part of the + [GSoC (Google Summer of Code)](https://summerofcode.withgoogle.com/): + + - [Matheus Tavares](https://summerofcode.withgoogle.com/projects/#6477677521797120) is going to work on + [making pack access code thread safe](https://public-inbox.org/git/CAHd-oW7KMrDJ-cyzk63oqW9-QVpag6fKnDp+Mo5bWxg1KfzY3g@mail.gmail.com/). + He will be mentored by Olga Telezhnaia, a former [Outreachy](https://www.outreachy.org/) intern, and Christian Couder. + Matheus has prepared [a blog](https://matheustavares.gitlab.io/gsoc) to report about his experience. + + - [Rohit Ashiwal](https://summerofcode.withgoogle.com/projects/#6407042053439488) will work on + [improving consistency of sequencer commands](https://public-inbox.org/git/20190322151157.9550-1-rohit.ashiwal265@gmail.com/). + He will be mentored by Thomas Gummerer, a former GSoC student, and Elijah Newren. + Rohit has also prepared [a blog](https://rashiwal.me) to report about his experience. + + It will be the 12th time that the Git project will mentor students + as part of the GSoC. Rohit and Matheus will be the 28th and 29th + students mentored since 2007 when Git started participating in the + GSoC. + + It will be the 15th year of GSoC and to celebrate that Google + decided to have the [GSoC Mentor Summit 2019](https://sites.google.com/view/gsoc-mentorsummit2019/home) + in a hotel in Munich, Germany instead of a Google campus in + California. The Mentor Summit will last 3.5 days (Thursday, October + 17 - Sunday, October 20) instead of the usual 2.5 days. The + additional day, Friday, October 18, will be "Fun Day Activities for + attendees to explore Munich and get to know each other before the + unconference begins". + +### Reviews + +* [[RFC PATCH] *.h: remove extern from function declarations](https://public-inbox.org/git/3e3b9d6c8e54b326809b95adabd3be39d2d0770f.1555111963.git.liu.denton@gmail.com/) + + Denton Liu sent a big RFC patch that removes `extern` keywords in + front of function declarations and that affects '.h' header files + in large numbers. + + He said that he used the following command to remove the keywords: + + ``` + $ git ls-files '*.h' | xargs sed -i'' -e 's/^\(\s*\)extern \(.*(\)/\1\2/' + ``` + + And the following one to check the result: + + ``` + $ git grep -w extern '*.h' + ``` + + Jeff King, alias Peff, replied that dropping `extern` should not be + done on function pointer declarations though, as a function pointer + is a variable, so its visibility would change if `extern` is removed + in front of it. + + Junio agreed with Peff and explained that the reason we avoid + wholesale updates "is because of an unnecessary bug like this one, + not the one-time conflict resolution load that can be subcontracted + out to 'rerere' once dealt with ;-)". + + Junio also suggested using "a tool more suited for the job + (e.g. spatch)" as it "raises the confidence level of the end result + a lot more than a 'sed and then eyeball' rewrite", though we then + have to be careful about possible "bugs in the instructions we give + to the tool". + + Denton then sent a [second version](https://public-inbox.org/git/cover.1555352526.git.liu.denton@gmail.com/) + of his work. It was now a 3 patch long patch series. + + The first patch used the `spatch` tool to do most of the `extern` + keyword removals. The second patch still used `sed` to do it where + `spatch` didn't work, but it made sure to ignore function + variables. The third patch used a Coccinelle script to make sure + that no more `extern` keywords are added to the code base. + + Thomas Gummerer replied to the first patch that it "leaves a bunch + of oddly indented parameter lists behind", as when a function has a + larger number of parameters, its declaration often spans more than + one line. + + Denton then send a [third version](https://public-inbox.org/git/cover.1555487380.git.liu.denton@gmail.com/) + of his work, with an additional patch to "manually align parameter + lists that were mangled by the tools". + + Peff replied wondering if it was a good thing to modify files in the + compat/ directory as the code there is often "copied from + elsewhere". He also wondered if it was worth keeping the Coccinelle + script as it is expensive to run. + + In the [fourth version](https://public-inbox.org/git/cover.1556062365.git.liu.denton@gmail.com/) + of his work, Denton decided to keep the Coccinelle script, but + excluded the compat/ directory from the files where `extern` is + removed. + + Junio noticed that in a commit message Denton mentioned using: + + ``` + $ git ls-files \*.{c,h} | \ + grep -v ^compat/ | \ + xargs sed -i'' -e 's/^\(\s*\)extern \([^(]*([^*]\)/\1\2/' + ``` + + and then asked him to remove the useless backslashes at the end of + the first 2 lines above, saying: + + > Your shell knows its own syntax sufficiently well, and when you end + > a line with a pipe, it knows that you haven't finished speaking to + > it and waits for you to give the command downstream of the pipe, + > without being told that you haven't finished with a backslash. + + Unfortunately Gábor Szeder then found that the Coccinelle script + failed on 'compat/obstack.h' as it is included in a '.c' file + checked by Coccinelle scripts. + + Denton replied by proposing to drop the patch that contained his + Coccinelle script, but Johannes Schindelin, alias Dscho, suggested + to exclude certain directories or certain files for certain + Coccinelle scripts. + + There was then a long discussion thread involving Peff, Denton, + Jacob Keller, Dscho, Junio and Gábor about what was possible to do + with Coccinelle and spatch and how they are used in the Git + toolchain. This thread eventually resulted in Peff writing a small + series of + [patches](https://public-inbox.org/git/20190506234334.GA13296@sigill.intra.peff.net/), + based on a previous patch by Jacob, that makes it possible to run + Coccinelle faster on machines with a lot of memory. Peff's patches + have since been merged into the 'master' branch. + + Denton in the meantime sent a [fifth version](https://public-inbox.org/git/cover.1556526308.git.liu.denton@gmail.com/) + of his work that drops the patch that contained his Coccinelle + script, and loses the useless backslashes. This patch series has + also been merged into the 'master' branch and will be part of Git + v2.22.0 that should be released at the beginning of June 2019. + + + +## Developer Spotlight: Denton Liu + +* Who are you and what do you do? + + My name is Denton and I'm a relatively new contributor to Git. I'm a + Software Engineering student at the University of Waterloo and I've been + bouncing around from internship to internship until I graduate next + year. + + I got started just over half a year ago when we had an assignment in + school that required us to make a contribution to some open-source + project. Since Git is so ubiquitous for developers, my team decided to + target it. + + Since then, I never really stopped because I've been having a lot of fun + with it. + +* What would you name your most important contribution to Git? + + I haven't really been as prolific as other contributors so I wouldn't + say that my contributions are "important", per se. I guess the most + important contribution that I've made (although it's still cooking) is + teaching `--keep-base` to rebase. + + Judging from the number of StackOverflow posts about it, I guess people + expect this to be a feature but, since it's not, I think most people + alias it away or something. + + Hopefully, this will be helpful to all the good people in the world who + bother to clean up their branches before sending them up ;). + +* What are you doing on the Git project these days, and why? + + I'd say that I'm a "selfish" contributor to Git. What I mean by this is + I've only been working on features that _I've_ wanted. + + I keep a todo list on my phone of feature requests that I would like + in Git and, whenever I have some free time, I'll code it up. So these + days, I'm mostly working all over the place, but mostly at a pretty high + level. + + Why? Because it's fun :). It's always cool running + `git pull upstream master` and seeing your work in there. + +* 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? + + Hmm, it would be nice if Git's interface were a little more standardised. + + If I could get a team of developers working on Git, I'd probably get + them to clean up Git's user interface and make it more consistent with + itself. + + In this regard, Duy has been making me happy with his work making Git + externally and internally consistent with git-restore, git-switch and + the diff-parseopt changes but if we could have a team of Duys working, + that would be amazing! + +* If you could remove something from Git without worrying about +backwards compatibility, what would it be? + + Continuing the above, my biggest gripe about Git is how inconsistent its + interface is since it was developed organically. I think the biggest + example of this would be how the meaning of `..` and `...` are + essentially swapped in diff compared to the log family of commands. I + always end up using the wrong number of dots because of this. + + If I could change one thing about Git, it'd probably be the above. Even + though it's a very small thing, it trips me up a lot of the time. + +* What is your favorite Git-related tool/library, outside of Git itself? + + I like to keep my setup as vanilla as possible so that when I move onto + other machines, I don't have to adjust my workflow very much so I only + really use the stock Git. However, a while back, I was reading about + git-imerge by Michael Haggerty. + + I'm very thankful that I haven't had to deal with any painfully large + merges recently that have necessitated it but I'm keeping this tool in + my back pocket in case the situation ever comes up. + +* Anything else you'd like to add? + + I'd like to thank the more seasoned members of the Git project for being + patient and helping me learn even through the (many) mistakes I've made + through the process. In particular, in no particular order, I'd like to + thank Junio, Ævar, Phillip Wood, Johannes Schindelin, Eric Sunshine and + many others for helping me. + + +## Releases + ++ Git [2.22.0-rc1](https://public-inbox.org/git/xmqq36la24t1.fsf@gitster-ct.c.googlers.com/), +[2.22.0-rc0](https://public-inbox.org/git/xmqqef52baih.fsf@gitster-ct.c.googlers.com/) ++ Git for Windows [2.22.0-rc1](https://public-inbox.org/git/nycvar.QRO.7.76.6.1905192229360.46@tvgsbejvaqbjf.bet/), +[2.22.0-rc0](https://public-inbox.org/git/nycvar.QRO.7.76.6.1905141056550.44@tvgsbejvaqbjf.bet/) ++ Gerrit Code Review [3.0.0](https://www.gerritcodereview.com/3.0.html) ++ GitHub Enterprise [2.16.8](https://enterprise.github.com/releases/2.16.8/notes), +[2.15.13](https://enterprise.github.com/releases/2.15.13/notes), +[2.14.20](https://enterprise.github.com/releases/2.14.20/notes), +[2.16.7](https://enterprise.github.com/releases/2.16.7/notes), +[2.15.12](https://enterprise.github.com/releases/2.15.12/notes), +[2.14.19](https://enterprise.github.com/releases/2.14.19/notes) ++ GitLab [11.10.4](https://about.gitlab.com/2019/05/01/gitlab-11-10-4-released/), +[11.10.3, 11.9.11, and 11.8.10](https://about.gitlab.com/2019/04/30/security-release-gitlab-11-dot-10-dot-3-released/), +[11.10.2](https://about.gitlab.com/2019/04/29/security-release-gitlab-11-dot-10-dot-2-released/), +[11.10.1](https://about.gitlab.com/2019/04/24/gitlab-11-10-1-released/) ++ Bitbucket Server [6.3](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitHub Desktop [1.6.6](https://desktop.github.com/release-notes/) ++ git-cinnabar [0.5.1](https://public-inbox.org/git/20190508221316.otsflud4qlcpwaeb@glandium.org) + + +## Other News + +__Various__ + +* [Git and the new SHA-1 prefix collision attack](https://public-inbox.org/git/875zqbx5yz.fsf@evledraar.gmail.com/) + is an email by Ævar Arnfjörð Bjarmason that has information and + links about a newly published paper about new attacks building on the + known "SHAttered" attack. + +* On April 1st, Ævar sent a two patches long [patch series](https://public-inbox.org/git/20190401101246.21418-1-avarab@gmail.com/) + to the mailing list. These April fool's day patches were "praise: a + culturally sensitive wrapper for 'blame'" and "praise: make + 'blameless' cultural enforcement configurable". + +* Dave Borowitz, one of the top contributors of Gerrit Code Review, + [leaves the project](https://groups.google.com/forum/#!topic/repo-discuss/ySP84Q0DHsw) after + 9k reviews, 3.4k commits and 8 years of contributions. + +* [Someone Is Hacking GitHub Repositories and Holding Code Ransom](https://www.vice.com/en_us/article/vb9v33/github-bitbucket-repositories-ransomware), + which lead to [Git ransom campaign incident report—Atlassian Bitbucket, GitHub, GitLab](https://github.blog/2019-05-14-git-ransom-campaign-incident-report/); + this topic was also discussed on git mailing list: + [Git ransom campaign incident report - May 2019](https://public-inbox.org/git/20190519051604.GC19434@sigill.intra.peff.net/t/#m5a98bd982c8994b3c275b86cd46d67dbe9ee7d7e). + + +__Light reading__ + +* [Exploring new frontiers for Git push performance](https://devblogs.microsoft.com/devops/exploring-new-frontiers-for-git-push-performance/) + includes a description of the new "sparse" push algorithm, enabled + by the `pack.useSparse` config option. + +* [The Developer Homepage of Derrick Stolee](https://stolee.dev/) + contains a number of interesting articles, presentations and links + especially about features he developed like the commit-graph. + +* [The history behind 6 years of development of Gerrit v3.0](https://gitenterprise.me/2019/05/20/gerrit-v3-0-is-here/) + goes back in time and describes the long path from the original + greenish GWT UI until the latest shiny blue Polymer-based user + experience. + +* [git rebase in depth](https://git-rebase.io/), a guide to help + demystify the powerful [git-rebase](https://git-scm.com/docs/git-rebase). + +* [Signing Git Commits](https://www.linuxjournal.com/content/signing-git-commits) + by Kyle Rankin, from Linux Journal. + +* [Git does not remember username and password on Windows](https://snede.net/git-does-not-remember-username-password/) + by André Snede Kock, or how to use Windows Credentials manager with Git, + and how to manually set credentials if needed. + +* [Stupid git tricks: Combining two files into one while preserving line history](https://devblogs.microsoft.com/oldnewthing/20190514-00/?p=102493) + by Raymond Chen; the trick is to create a rename/rename merge commit. + +* [The Essential Git Handbook](https://medium.freecodecamp.org/the-essential-git-handbook-a1cf77ed11b5) + by Sanjula Madurapperuma, teaching a little about Git. + +* [Squash commits when merging a Git branch with Bitbucket](https://bitbucket.org/blog/git-squash-commits-merging-bitbucket) by Abhin Chhabra. + +* [Serving Vue.js apps on Github Pages](https://blog.usmanity.com/serving-vue-js-apps-on-github-pages/) + by Muhammad Usman; the trick is to configure + GitHub Pages and use 'docs' folder. + + +__Git tools and sites__ + +* [gitfolio](https://github.com/imfunniee/gitfolio): + personal website + blog for every GitHub user (JavaScript with Node.js); + see . + +* [GitHub Learning Lab](https://lab.github.com/): learn new skills + by completing fun, realistic projects in your very own GitHub + repository. + +* [fh](https://github.com/xorhash/fh): record changes to a file on a per-file basis, + with ed(1), diff(1), awk(1), sed(1) and sh(1). + +* [commit-messages-guide](https://github.com/RomuloOliveira/commit-messages-guide): + a guide to understand the importance of commit messages and how to write them well. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Gabriel Alcaras <> +with help from David Pursehouse, Luca Milanesio and Denton Liu. diff --git a/_posts/2019-06-28-edition-52.markdown b/_posts/2019-06-28-edition-52.markdown new file mode 100644 index 000000000..8915ccd5d --- /dev/null +++ b/_posts/2019-06-28-edition-52.markdown @@ -0,0 +1,424 @@ +--- +title: Git Rev News Edition 52 (June 28th, 2019) +layout: default +date: 2019-06-28 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 52 (June 28th, 2019) + +Welcome to the 52nd 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](https://git.github.io). + +This edition covers what happened during the month of May 2019. + +## Discussions + + +### General + +* [I made a flame graph renderer for git's trace2 output](https://public-inbox.org/git/87zhnuwdkp.fsf@evledraar.gmail.com/) + + Ævar Arnfjörð Bjarmason sent an email saying he developed a script that uses the + [FlameGraph tool](http://www.brendangregg.com/flamegraphs.html) + to generate a + [picture](https://vm.nix.is/~avar/noindex/git-tests.svg) showing + where Git's test suite spends its time. + + His script also uses the new + [Git Trace2 API](https://github.com/git/git/blob/master/Documentation/technical/api-trace2.aodc) + which has been developed mostly by Jeff Hostetler + [starting nearly one year ago](https://public-inbox.org/git/20180713165621.52017-1-git@jeffhostetler.com/) + and then through different versions: + [RFC](https://public-inbox.org/git/pull.29.git.gitgitgadget@gmail.com/), + [V1](https://public-inbox.org/git/pull.108.git.gitgitgadget@gmail.com/), + [V2](https://public-inbox.org/git/pull.108.v2.git.gitgitgadget@gmail.com/), + [V3](https://public-inbox.org/git/pull.108.v3.git.gitgitgadget@gmail.com/), + [V4](https://public-inbox.org/git/pull.108.v4.git.gitgitgadget@gmail.com/), + [V5](https://public-inbox.org/git/pull.169.v5.git.gitgitgadget@gmail.com/), + and which has eventually been released in Git v2.22.0 at the beginning of June 2019. + + Ævar added that he plans to improve + [his script](https://github.com/avar/FlameGraph/commit/7a834718a12ed8b0d897ee90b00e2f654508cabd) + over time and maybe submit it in a pull request to the FlameGraph + tool, or perhaps integrate it in the Git test suite. + + Derrick Stolee, who prefers to be called just Stolee, replied that + he liked the idea and sent the commands using Ævar's script that he used to create + [another picture](https://github.com/derrickstolee/FlameGraph/blob/git-test/git-test.svg) + from a much smaller test. + + Gábor Szeder commented on Stolee's commands to ask why `GIT_TR2` + instead of `GIT_TRACE2` was used in the environment variables + related to the Trace2 API. Gábor referred to Ken Thompson "who + (allegedly?) later regretted spelling `creat()`/`O_CREAT` without the + 'e'...". + + Jeff King, alias Peff, replied to Ævar's initial email asking + "doesn't `perf record -g make test` already give us that granular + data?" referring to the [Linux perf tool](https://en.wikipedia.org/wiki/Perf_(Linux)) + which is already supported by the FlameGraph tool. Peff also + wondered about the usefulness of such a graph: + + > But having generated such a flamegraph, it's not all that helpful. It + > mainly tells us that we spend a lot of time on fork/exec. Which is no + > surprise, since the test suite is geared not towards heavy workloads, + > but lots of tiny functionality tests. + + Though he agreed that it could help in some cases: + + > I think the trace2 flamegraph would be most useful if you were + > collecting across a broad spectrum of workloads done by a user. You + > _can_ do that with perf or similar tools, but it can be a bit awkward. + + Ævar replied that his "actual use-case for this is to see what + production nodes are spending their time on, similar to what + Microsoft is doing with their use of this facility", and that he + used the test suite because it is a good way to test his script and + the Trace2 API as "we're pretty much guaranteed to run all our + commands, and cover a lot of unusual cases". + + Ævar pointed that his work "shows that we've got a long way to go in + improving the trace2 facility, i.e. adding region enter/leave for + some of the things we spend the most time on." + + Jeff Hostetler, who authored the Trace2 API and works for Microsoft + along with Stolee, then replied "Very Nice!" to Ævar and agreed + with him about the work still needed "to get more granular data for + interesting/problematic things". + + Ævar and Jeff then discussed this future work further in a few + emails. + + Jeff also replied to Gábor that he was ok to change `TR2` to + `TRACE2`, and Gábor sent + [two patches](https://public-inbox.org/git/20190519144309.9597-1-szeder.dev@gmail.com/) + to get that change done. These patches were agreed on and merged before + Git v2.22.0 was released on June 7th, 2019. + + +### Reviews + +* [[PATCH 00/17] [RFC] Commit-graph: Write incremental files](https://public-inbox.org/git/6d9c0911-6f36-3fb7-2be9-2be9bc68fc69@gmail.com/t/) + + The road to incremental serialized [commit-graph](https://github.com/git/git/blob/master/Documentation/technical/commit-graph.adoc) + started with [an attempt to create commit-graph file format v2](https://public-inbox.org/git/pull.112.git.gitgitgadget@gmail.com/t/#u) + + > The commit-graph file format has some shortcomings that were discussed + > on-list: + > + > 1. It doesn't use the 4-byte format ID from the\_hash\_algo. + > + > 2. There is no way to change the reachability index from generation numbers + > to [corrected commit date](https://public-inbox.org/git/6367e30a-1b3a-4fe9-611b-d931f51effef@gmail.com/). + > + > 3. The unused byte in the format could be used to signal the file is + > incremental, but current clients ignore the value even if it is + > non-zero. + > + > This series adds a new version (2) to the commit-graph file. The fifth byte + > already specified the file format, so existing clients will gracefully + > respond to files with a different version number. The only real change now + > is that the header takes 12 bytes instead of 8, due to using the 4-byte + > format ID for the hash algorithm. + + (Note that switching to corrected commit date as generation number v2 + was covered in [Git Rev News edition 45, November 2018](https://git.github.io/rev_news/2018/11/21/edition-45/)). + + It turned out however that the statement _"existing clients will + gracefully respond to files with a different version number"_ + unfortunately turned out to be not true. [Ævar Arnfjörð Bjarmason noticed](https://public-inbox.org/git/87a7gdspo4.fsf@evledraar.gmail.com/) + that older Git responds with a **hard error** to commit-graph v2, instead + of simply turning the serialized-graph feature off in such case. + + > [...] writing a v2 file + > would make most things (e.g. "status") hard error on e.g. v2.21.0: + > + > $ git status + > error: graph version 2 does not match version 1 + > $ + > + > Now as noted in [my series](https://public-inbox.org/git/20190501183108.GE4109@sigill.intra.peff.net/t/#md66d1ac26799a296d6019cd8bb1048c975ad89f5) we now on 'master' downgrade that to a warning + > (along with the rest of the errors): + > + > $ ~/g/git/git --exec-path=$PWD status + > error: commit-graph version 2 does not match version 1 + > On branch master + > [...] + > + > ...and this series sets the default version for all new graphs to v2. + > + > I think this is *way* too aggressive of an upgrade path. If these + > patches go into v2.22.0 then git clients on all older versions that grok + > the commit graph (IIRC v2.18 and above) will have their git completely + > broken if they're in a mixed-git-version environment. + + The workaround is easy: removing `.git/info/commit-graph`, or using + "`git -c core.commitGraph=false ...`". However it is not possible + to e.g. add advice describing the workaround to past Git versions + (and new versions would simply not fail hard on v2). + + It turned out that there is no need to introduce new commit-graph + file format to achieve [almost] all stated goals. The goal 1.) + turned out to be [not important](https://public-inbox.org/git/87lfzprkfc.fsf@evledraar.gmail.com/). + + > * Let's just live with "1" as the marker for SHA-1. + > + > Yeah it would be cute to use 0x73686131 instead like "struct + > git\_hash\_algo", but we can live with a 1=0x73686131 ("sha1"), + > 2=0x73323536 ("s256") mapping somewhere. It's not like we're going to + > be running into the 255 limit of hash algorithms Git will support any + > time soon. + + For 2.), Stolee noticed that generation number v2 (corrected + commit date) [can be made backward compatible](https://public-inbox.org/git/bb0c22f9-9d0b-0fa6-e826-8e2ac146c6f9@gmail.com/) + + > Since we can make the "corrected commit date" offset for a commit be + > strictly larger than the offset of a parent, we can make it so an old client + > will not give incorrect values when we use the new values. The only downside + > would be that we would fail on '`git commit-graph verify`' since the offsets + > are not actually generation numbers in all cases. + + This is discussed in a bit more detail in [Re: Revision walking, commit dates, slop](https://public-inbox.org/git/20190521020009.GC32230@google.com/T/#m418d1c46c0200de198946ec00cfb5c8c39ddf4d0) + thread. + + The issue of incremental commit-graph file, i.e. 3.), turned out to + be better solved by keeping the base as backward-compatibile + commit-graph, and deltas as separate files. Thus "Create + commit-graph file format v2" turned into [Commit-graph write refactor](https://public-inbox.org/git/pull.112.git.gitgitgadget@gmail.com/t/#mc8fda9ba6fad8fc53c55db2b9b35bd9b3bab71ca), + and Stolee started a separate [[RFC] Commit-graph: Write incremental files](https://public-inbox.org/git/6d9c0911-6f36-3fb7-2be9-2be9bc68fc69@gmail.com/t/) thread. + + The original idea was to store subsequent deltas (incremental + additions to serialized commit-graph data) in files named + `commit-graph-2`, `commit-graph-3`, etc. After involved discussion, + considering problems of concurrency, at [V6](https://public-inbox.org/git/6d9c0911-6f36-3fb7-2be9-2be9bc68fc69@gmail.com/t/#me8922324aebcdf4050bd5a4b1d18ef281bd47769) + the design has changed, to having `commit-graphs/graph-{hash}.graph` + together with `commit-graph-chain` index file. + + > The commit-graph is a valuable performance feature for repos with large + > commit histories, but suffers from the same problem as git repack: it + > rewrites the entire file every time. This can be slow when there are + > millions of commits, especially after we stopped reading from the + > commit-graph file during a write in [43d3561 (commit-graph write: don't die + > if the existing graph is corrupt)](https://git.kernel.org/pub/scm/git/git.git/commit/?id=43d356180556180b4ef6ac232a14498a5bb2b446). + > + > Instead, create a "chain" of commit-graphs in the + > `.git/objects/info/commit-graphs` folder with name graph-{hash}.graph. The + > list of hashes is given by the commit-graph-chain file, and also in a "base + > graph chunk" in the commit-graph format. As we read a chain, we can verify + > that the hashes match the trailing hash of each commit-graph we read along + > the way and each hash below a level is expected by that graph file. + > + > When writing, we don't always want to add a new level to the stack. This + > would eventually result in performance degradation, especially when + > searching for a commit (before we know its graph position). We decide to + > merge levels of the stack when the new commits we will write is less than + > half of the commits in the level above. This can be tweaked by the + > `--size-multiple` and `--max-commits` options. + + This series, as 'ds/commit-graph-incremental' branch, is currently + marked as ready to be merged into 'next'. + + + + +## Developer Spotlight: Jeff Hostetler + +* Who are you and what do you do? + + My name is Jeff Hostetler and I work for Microsoft. + I've been working on Git and on Git-related technologies + for the last 5 years. Primarily focusing on performance + and scale. + + Prior to joining Microsoft, I worked for [SourceGear](http://www.sourcegear.com/) + and built the [Veracity](https://en.wikipedia.org/wiki/Veracity_(software)) DVCS + and the [DiffMerge](http://www.sourcegear.com/diffmerge/) visual + diff and merge tool. + + A long, long time ago I was Architect for Spyglass Mosaic. + +* What would you name your most important contribution to Git? + + I'd have to say the Trace2 facility that is now in v2.22. + With this in place, it will be much easier to understand + performance bottlenecks at scale. + + Second to that would be the beginnings of the Partial Clone + feature. There's still a lot of work to do in this area, but + I think long term, it will be central to solving certain + enterprise-level scale problems. + +* What are you doing on the Git project these days, and why? + + I'm currently working on a series of blog posts explaining + Trace2 and how it can be used to measure and track Git + performance. + + Within Microsoft we continue to study Trace2 data generated + by our Windows and Office developers and look for opportunities + to improve the developer experience, such as making status and + checkout faster. And we are using the data to guide how/where + we should invest our engineering time for future performance + gains. + + Hopefully, I can encourage others to start using Trace2, + gather their own data and look for opportunities where they + can help improve Git. + +* 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? + + Bring together the Partial Clone and Sparse Checkout features + to scale to large repos. This includes completing the end-user + experience, so that it just works and doesn't require any + wizardry. + + There are several dimensions that have similar, but not + identical needs. + + For example, a moderately-sized work tree with a few large + blobs might use Partial Clone with the blob-size filter and + only demand-fetch large blobs when actually needed. This could + be seen as an easier to use solution than LFS. + + Alternatively, a repo with a gigantic tree might use Partial + Clone with the sparse filter (to get "cones" of the work tree). + That could be coordinated with the sparse-checkout file to + populate just the desired parts of the work tree. For some + users this would be simpler than using GVFS. + + Let's add new porcelain commands to create, grow, and shrink the + sparse-checkout file and automatically update the index, so that + the user doesn't have to manually manipulate it. + + Investigate a bulk pre-fetch command or hook, such as before a + checkout, to reduce the overhead of individually demand-loading + missing objects. + + Finally, update Protocol V2 to include whatever verbs we need + to make all of this work efficiently. + + With this we could probably retire most if not all of GVFS and + hopefully let our Windows and Office developers use core Git + and not need a private fork. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + I'd like to revisit the design of the index. Switch to a sparse + and hierarchical format, for example. This is a large task and + touches everything from the on-disk format to every index-related + loop in the program. + + [Ben Peart](https://git.github.io/rev_news/2017/09/20/edition-31/) + and [Derrick Stolee](https://git.github.io/rev_news/2018/08/22/edition-42/) + both touched upon this in earlier issues. + +* What is your favorite Git-related tool/library, outside of Git itself? + + I'm mostly a terminal user, so I don't use very many third-party + tools. I do highly recommend + [GitGitGadget](https://github.com/gitgitgadget/gitgitgadget). + I use it to run CI builds on all Windows, Mac, and Linux and to send + patches to the mailing list. + +## Releases + ++ Git [2.22.0](https://public-inbox.org/git/xmqq36klozfu.fsf@gitster-ct.c.googlers.com/), +[2.22.0-rc3](https://public-inbox.org/git/xmqqlfyito3a.fsf@gitster-ct.c.googlers.com/), +[2.22.0-rc2](https://public-inbox.org/git/xmqqpnnzws9q.fsf@gitster-ct.c.googlers.com/) ++ Git for Windows [2.22.0](https://github.com/git-for-windows/git/releases/tag/v2.22.0.windows.1) ++ libgit2 [0.28.2](https://github.com/libgit2/libgit2/releases/tag/v0.28.2) ++ GitHub Enterprise [2.17.2](https://enterprise.github.com/releases/2.17.2/notes), +[2.16.11](https://enterprise.github.com/releases/2.16.11/notes), +[2.15.16](https://enterprise.github.com/releases/2.15.16/notes), +[2.14.23](https://enterprise.github.com/releases/2.14.23/notes), +[2.17.1](https://enterprise.github.com/releases/2.17.1/notes), +[2.16.10](https://enterprise.github.com/releases/2.16.10/notes), +[2.15.15](https://enterprise.github.com/releases/2.15.15/notes), +[2.14.22](https://enterprise.github.com/releases/2.14.22/notes), +[2.17.0](https://enterprise.github.com/releases/2.17.0/notes), +[2.16.9](https://enterprise.github.com/releases/2.16.9/notes), +[2.15.14](https://enterprise.github.com/releases/2.15.14/notes), +[2.14.21](https://enterprise.github.com/releases/2.14.21/notes) ++ GitLab [12.0.1](https://about.gitlab.com/2019/06/25/gitlab-12-0-1-released/), +[12.0](https://about.gitlab.com/2019/06/22/gitlab-12-0-released/), +[11.11.3](https://about.gitlab.com/2019/06/10/gitlab-11-11-3-released/), +[11.11.2](https://about.gitlab.com/2019/06/05/gitlab-11-11-2-released/), +[11.10.6](https://about.gitlab.com/2019/06/05/gitlab-11-10-6-released/), +[11.11.1, 11.10.5, and 11.9.12](https://about.gitlab.com/2019/06/03/security-release-gitlab-11-dot-11-dot-1-released/), +[11.11](https://about.gitlab.com/2019/05/22/gitlab-11-11-released/) ++ Bitbucket Server [6.4](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [2.15.14](https://www.gerritcodereview.com/2.15.html#21514), +[2.16.9](https://www.gerritcodereview.com/2.16.html#2169) ++ GitKraken [6.0.0](https://support.gitkraken.com/release-notes/current), +[5.0.4](https://support.gitkraken.com/release-notes/current), +[5.0.3](https://support.gitkraken.com/release-notes/current), +[5.0.2](https://support.gitkraken.com/release-notes/current), +[5.0.1](https://support.gitkraken.com/release-notes/current), +[5.0.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.0.4](https://desktop.github.com/release-notes/), +[2.0.3](https://desktop.github.com/release-notes/), +[2.0.2](https://desktop.github.com/release-notes/), +[2.0.1](https://desktop.github.com/release-notes/), +[2.0.0](https://desktop.github.com/release-notes/) ++ Sourcetree [3.2.1](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_3.2.1.html), +[3.2](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_3.2.html) + + +## Other News + +__Various__ + +* [GitHub Maintainer Security Advisories](https://dwheeler.com/blog/2019/05/25/#github-maintainer-security-advisories) + are a way to _privately_ report vulnerabilities to OSS projects on GitHub, + currently in a [public beta](https://dwheeler.com/blog/2019/05/25/#github-maintainer-security-advisories). + Those are a part of a larger effort by GitHub to support security (especially targeting OSS projects). + For more information about this effort see the following GitHub Help pages: + + * [About maintainer security advisories](https://help.github.com/en/articles/about-maintainer-security-advisories) + * [About security alerts for vulnerable dependencies](https://help.github.com/en/articles/about-security-alerts-for-vulnerable-dependencies) + +* [Introducing new ways to keep your code secure](https://github.blog/2019-05-23-introducing-new-ways-to-keep-your-code-secure/) by Justin Hutchings on GitHub Blog. +* [Announcing GitHub Sponsors: a new way to contribute to open source](https://github.blog/2019-05-23-announcing-github-sponsors-a-new-way-to-contribute-to-open-source/) by Devon Zuegel on GitHub Blog; + see also [TechCrunch article](https://techcrunch.com/2019/05/23/github-launches-sponsors-lets-you-pay-your-favorite-open-source-contributors/) by Frederic Lardinois on the same subject. +* [Introducing GitHub Package Registry](https://github.blog/2019-05-10-introducing-github-package-registry/) by Simina Pasat on GitHub Blog; + [GitHub Package Registry feature](https://github.com/features/package-registry) is currently in limited beta (you need to sign up for the beta). + + +__Light reading__ + +* [FreeBSD and Git](https://www.freebsdfoundation.org/wp-content/uploads/2018/10/FreeBSD-and-Git.pdf) (PDF) + -- slides from Ed Maste's presentation at the FreeBSD Vendor Summit 2018. +* [Things I Learnt The Hard Way (in 30 Years of Software Development)](https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/) by Julio Biason, + including few thoughts about the use of version control and Git. +* [Rebasing and merging in kernel repositories [LWN.net]](https://lwn.net/Articles/791284/) by Jonathan Corbet. +* [Enforcing Conventional Commits using Git hooks](https://endaphelan.me/guides/git/using-git-hooks-to-enforce-conventional-commits/) by Enda Phelan. + [Conventional Commits](https://www.conventionalcommits.org/) is a specification for adding human and machine readable meaning to commit messages. + The presented solution was turned into the [Sailr](https://github.com/craicoverflow/sailr) project. +* [Learn Git concepts, not commands](https://dev.to/unseenwizzard/learn-git-concepts-not-commands-4gjc) by Nico Riedmann: + An interactive Git tutorial for beginners meant to teach you how Git works, + not just which commands to execute. +* [A Git Origin Story](https://www.linuxjournal.com/content/git-origin-story) by Zack Brown (2018). + + +__Git tools and sites__ + +* [Sailr](https://github.com/craicoverflow/sailr): a global Git hook for adhering to the [Conventional Commit specification](https://www.conventionalcommits.org/) + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Gabriel Alcaras <> +with help from Jeff Hostetler, David Pursehouse and +Johannes Schindelin. diff --git a/_posts/2019-07-24-edition-53.markdown b/_posts/2019-07-24-edition-53.markdown new file mode 100644 index 000000000..3596a3747 --- /dev/null +++ b/_posts/2019-07-24-edition-53.markdown @@ -0,0 +1,225 @@ +--- +title: Git Rev News Edition 53 (July 24th, 2019) +layout: default +date: 2019-07-24 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 53 (July 24th, 2019) + +Welcome to the 53rd 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](https://git.github.io). + +This edition covers what happened during the month of June 2019. + +## Discussions + + + + +### Reviews + +* [Easy bulk commit creation in tests](https://public-inbox.org/git/20190628093751.GA3569@sigill.intra.peff.net/) + + Derrick Stolee, who prefers to be called Stolee, has been sending + "Git Test Coverage Report" emails to the mailing list + [since September 2018](https://public-inbox.org/git/4bcd63bf-648d-f3f6-dac8-aabe7ea1e480@gmail.com/). + + These emails contain reports made using `contrib/coverage-diff.sh` + to combine the `gcov` output from `make coverage-test ; make coverage-report` + with the output from `git diff A B` to discover _new_ lines of code that are + not covered by the test suite. + + In June 2019 Stolee sent + [a new report](https://public-inbox.org/git/49d98293-9f0b-44e9-cb07-d6b7ac791eb6@gmail.com/) + which stated that some new lines of code contributed by Jeff King, + alias Peff, were not covered by any test. Peff replied that when + running the test that exercises the surrounding code, we hit the early + return above the lines that are not tested when there are fewer than + 100 commits to index. + + One solution to that problem could be to create 100 commits, instead of just + 10, in the test, though that would slow down the test. Peff then + concluded: + + > It would be nice if we had a "test_commits_bulk" that used fast-import + > to create larger numbers of commits. + + A few hours later Peff replied to himself by sending a 6 patch long + patch series which implements the `test_commit_bulk` function he + suggested. + + In this patch series Peff converted a few places in the code to use + this function and reported that it saves around 7.5 seconds from his + test runs. He commented: "Not ground-breaking, but I think it's nice + to have a solution where we don't have to be afraid to generate a + bunch of commits." + + The comments above the function explains it like this: + + ``` + # Similar to test_commit, but efficiently create commits, each with a + # unique number $n (from 1 to by default) in the commit message. + # + # Usage: test_commit_bulk [options] + # -C : + # Run all git commands in directory + # --ref=: + # ref on which to create commits (default: HEAD) + # --start=: + # number commit messages from (default: 1) + # --message=: + # use as the commit message (default: "commit $n") + # --filename=: + # modify in each commit (default: "$n.t") + # --contents=: + # place in each file (default: "content $n") + # --id=: + # shorthand to use and $n in message, filename, and contents + # + # The message, filename, and contents strings are evaluated by the shell inside + # double-quotes, with $n set to the current commit number. So you can do: + # + # test_commit_bulk --filename=file --contents='modification $n' + # + # to have every commit touch the same file, but with unique content. Spaces are + # OK, but you must escape any metacharacters (like backslashes or + # double-quotes) you do not want expanded. + ``` + + Johannes Schindelin replied to Peff that he likes the direction + because "it would make it super easy to go one step further that would + probably make a huge difference on Windows: to move `test_commit_bulk` + to `test-tool commit-bulk`". + + Peff replied that "in the biggest case we dropped 900 processes to + 4" so that he thought it would not make a big difference to convert + `test_commit_bulk` to C code and integrate it as `test-tool commit-bulk`. + But anyway Peff suggested 3 different ways to have only 1 process. + + One of the ways Peff suggested was to add a feature to fast-import to + say "build on top of ref X". Elijah Newren replied to Peff that such + a feature already exists using something like `from refs/heads/branch^0`. + + Peff thanked Elijah and used the feature in a patch he attached, which + further reduces the number of processes used. + + Ævar Arnfjörð Bjarmason also replied to Peff wondering if just + having a few "template" repositories, that could just be copied in + many tests, would be a better approach. + + Peff replied to Ævar that just "seeing the end result of running a + bunch of commands" is less instructive than following "the steps + that the author was thinking about", and that "it's more annoying to + update". Peff though would find cool that we could "allow caching of + the on-disk state at certain points in a test script", for example + by annotating some test snippets as "SETUP", like a prerequisite. + + Stolee also replied to Peff, congratulating him for the quick + turnaround, providing results from performance tests on Windows + which were similar as those provided by Peff, and suggesting + possible improvements to the `test_commit_bulk` function. These + suggestions were then discussed by Junio Hamano, the Git + maintainer, and Peff. + + Junio, Ævar, Eric Sunshine and Gábor Szeder also discussed with Peff + some aspects of the implementation and documentation of the new + feature. + + Peff then sent [a version 2](https://public-inbox.org/git/20190629045322.GA8155@sigill.intra.peff.net/) + of the patch that implements `test_commit_bulk` with many of the + improvements that had been discussed. Junio discussed the + implementation a bit further, but seemed happy with the patch series. + + Peff recently sent [a version 3](https://public-inbox.org/git/20190719215417.GA31841@sigill.intra.peff.net/), + which will hopefully be merged soon. + + + + + +## Releases + ++ GitLab [12.1.0](https://about.gitlab.com/2019/07/22/gitlab-12-1-released/), +[12.0.3, 11.11.5, and 11.10.8](https://about.gitlab.com/2019/07/03/security-release-gitlab-12-dot-0-dot-3-released/), +[12.0.2](https://about.gitlab.com/2019/06/26/gitlab-12-0-2-11-11-4-11-10-7-released/), +[12.0.1](https://about.gitlab.com/2019/06/25/gitlab-12-0-1-released/), +[12.0](https://about.gitlab.com/2019/06/22/gitlab-12-0-released/) ++ Bitbucket Server [6.5](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [2.16.10](https://www.gerritcodereview.com/2.16.html#21610), +[3.0.1](https://www.gerritcodereview.com/3.0.html#301) ++ GitHub Enterprise [2.17.5](https://enterprise.github.com/releases/2.17.5/notes), +[2.16.14](https://enterprise.github.com/releases/2.16.14/notes), +[2.15.19](https://enterprise.github.com/releases/2.15.19/notes), +[2.17.4](https://enterprise.github.com/releases/2.17.4/notes), +[2.16.13](https://enterprise.github.com/releases/2.16.13/notes), +[2.15.18](https://enterprise.github.com/releases/2.15.18/notes), +[2.14.25](https://enterprise.github.com/releases/2.14.25/notes), +[2.17.3](https://enterprise.github.com/releases/2.17.3/notes), +[2.16.12](https://enterprise.github.com/releases/2.16.12/notes), +[2.15.17](https://enterprise.github.com/releases/2.15.17/notes), +[2.14.24](https://enterprise.github.com/releases/2.14.24/notes) ++ GitHub Desktop [2.1.0](https://desktop.github.com/release-notes/) ++ GitKraken [6.0.1](https://support.gitkraken.com/release-notes/current) + +## Other News + +__Various__ + +* Synergy is looking for a Git expert to join as a partner or in a + freelance role. We are a startup developing an Enterprise Content + Management solution for the office worker and we are looking to + expand the team to build our GUI client and manage the + infrastructure. If interested, please reach out to + jaime.rivas@synergy.page + + +__Light reading__ + +* [My Personal Git Tricks Cheatsheet](https://dev.to/antjanus/my-personal-git-tricks-cheatsheet-23j1) + by Antonin Januska, with some improvements based on feedback in comments + +* [Manage your dev.to blog posts from a Git repo + and use continuous deployment to auto publish/update them](https://dev.to/maxime1992/manage-your-dev-to-blog-posts-from-a-git-repo-and-use-continuous-deployment-to-auto-publish-update-them-143j) + by Maxime (@maxime1992) + +* [Object Oriented Programming in C: A Case Study - Git and Linux Kernel](https://matheustavares.gitlab.io/assets/oop_git_and_kernel.pdf): + slides by Matheus Tavares and Renato Lui Geh (PDF) + +* [C# or Java? TypeScript or JavaScript? + Machine learning based classification + of programming languages](https://github.blog/2019-07-02-c-or-java-typescript-or-javascript-machine-learning-based-classification-of-programming-languages/) + by Kavita Ganesan on GitHub Blog (OctoLingua project) + + +__Git tools and sites__ + +* [CallPath](https://github.com/matheustavares/callpath), by Matheus + Tavares, "lets you see all the paths your code take until a + specified function". Matheus is a Google Summer of Code student + currently working on + [making pack access code thread-safe](https://matheustavares.gitlab.io/gsoc/). + +* [diffr](https://github.com/mookid/diffr), by Nathan Moreau, is a new + diff highlighting tool "trying to improve on the + [diff-highlight](https://github.com/git/git/tree/master/contrib/diff-highlight) + script distributed with Git". + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Gabriel Alcaras <> +with help from Jaime Rivas and Carlo Marcelo Arenas Belón. diff --git a/_posts/2019-08-21-edition-54.markdown b/_posts/2019-08-21-edition-54.markdown new file mode 100644 index 000000000..a4e665fad --- /dev/null +++ b/_posts/2019-08-21-edition-54.markdown @@ -0,0 +1,509 @@ +--- +title: Git Rev News Edition 54 (August 21st, 2019) +layout: default +date: 2019-08-21 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 54 (August 21st, 2019) + +Welcome to the 54th 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](https://git.github.io). + +This edition covers what happened during the month of July 2019. + + +## An Introduction to git-filter-repo (*written by Elijah Newren*) + +There is a new tool available for surgery on git repositories: +[git-filter-repo](https://github.com/newren/git-filter-repo). It +claims to have [many new unique +features](https://github.com/newren/git-filter-repo#design-rationale-behind-filter-repo-why-create-a-new-tool), +[good +performance](https://public-inbox.org/git/CABPp-BGOz8nks0+Tdw5GyGqxeYR-3FF6FT5JcgVqZDYVRQ6qog@mail.gmail.com/), +and an ability to scale -- from making simple history rewrites +trivial, to facilitating the creation of entirely new tools which +leverage existing capabilities to handle more complex cases. + +You can read more about [common use cases and base capabilities of +filter-repo](https://github.com/newren/git-filter-repo/blob/a6a6a1b0f62d365bbe2e76f823e1621857ec4dbd/Documentation/git-filter-repo.txt#L17-L55), +but in this article, I'd like to focus on two things: providing a simple +example to give a very brief flavor for git-filter-repo usage, and answer a +few likely questions about its purpose and rationale (including a short +comparison to other tools). I will provide several links along the way for +curious folks to learn more. + +### A simple example + +Let's start with a simple example that has come up a lot for me: +extracting a piece of an existing repository and preparing it to be +merged into some larger monorepository. So, we want to: + + * extract the history of a single directory, src/. This means that only + paths under src/ remain in the repo, and any commits that only touched + paths outside this directory will be removed. + * rename all files to have a new leading directory, my-module/ (e.g. so that + src/foo.c becomes my-module/src/foo.c) + * rename any tags in the extracted repository to have a 'my-module-' + prefix (to avoid any conflicts when we later merge this repo into + something else) + +Doing this with filter-repo is as simple as the following command: +```shell + git filter-repo --path src/ --to-subdirectory-filter my-module --tag-rename '':'my-module-' +``` +(The single quotes are unnecessary, but make it clearer to a human that we +are replacing the empty string as a prefix with `my-module-`.) + +By contrast, filter-branch comes with a pile of caveats even once you +figure out the necessary (OS-dependent) invocation(s): + +```shell + git filter-branch \ + --index-filter 'git ls-files \ + | grep -v ^src/ \ + | xargs git rm -q --cached; \ + git ls-files -s \ + | sed "s%$(printf \\t)%&my-module/%" \ + | git update-index --index-info; \ + git ls-files \ + | grep -v ^my-module/ \ + | xargs git rm -q --cached' \ + --tag-name-filter 'echo "my-module-$(cat)"' --prune-empty -- --all + git clone file://$(pwd) newcopy + cd newcopy + git for-each-ref --format="delete %(refname)" refs/tags/ \ + | grep -v refs/tags/my-module- \ + | git update-ref --stdin + git gc --prune=now +``` + +BFG is not capable of this type of rewrite, and this type of rewrite is +difficult to perform safely using fast-export and fast-import directly. + +You can find a lot more examples in [filter-repo's +manpage](https://github.com/newren/git-filter-repo/blob/a6a6a1b0f62d365bbe2e76f823e1621857ec4dbd/Documentation/git-filter-repo.txt#L434). +(If you are curious about the "pile of caveats" mentioned above or the +reasons for the extra steps for filter-branch, you can [read more +details about this +example](https://github.com/newren/git-filter-repo#example-usage-comparing-to-filter-branch)). + +### Why a new tool instead of contributing to other tools? + +There are two well known tools in the repository rewriting space: + + * [git-filter-branch](https://git-scm.com/docs/git-filter-branch) + * [BFG Repo Cleaner](https://rtyley.github.io/bfg-repo-cleaner/) + +and two lesser-known tools: + + * [reposurgeon](http://www.catb.org/~esr/reposurgeon/reposurgeon.html) + * [git-fast-export](https://git-scm.com/docs/git-fast-export) and + [git-fast-import](https://git-scm.com/docs/git-fast-import) + +(While fast-export and fast-import themselves are well known, they are +usually thought of as export-to-another-VCS or import-from-another-VCS +tools, though they also work for git->git transitions.) + +I will briefly discuss each. + +#### filter-branch and BFG + +It's natural to ask why, if these well-known tools lacked features I +wanted, they could not have been extended instead of creating a new tool. +In short, they were philosophically the wrong starting point for extension +and they also had the wrong architecture or design to support such an +effort. + +From the philosophical angle: + + * BFG: easy to use flags for some common cases, but not extensible + * filter-branch: relatively versatile capability via user-specified + shell commands, but rapidly becomes very difficult to use beyond + trivial cases especially as usability defaults increasingly + conflict and cause problems. + +I wanted something that made the easy cases simple like BFG, but which +would scale up to more difficult cases and have versatility beyond that +which filter-branch provides. + +From the technical architecture/design angle: + + * BFG: works on packfiles and packed-refs, directly rewriting tree and + blob objects; Roberto proved you can get a lot done with this design + with his work on the BFG (as many people who have used his tool can + attest), but this design does not permit things like differentiating + paths in different directories with the same basename nor could it be + used to allow renaming of paths (except within the same directory). + Further, this design even sadly runs into a + [lot](https://github.com/newren/git-filter-repo/blob/a6a6a1b0f62d365bbe2e76f823e1621857ec4dbd/contrib/filter-repo-demos/bfg-ish#L32-L39) + [of](https://github.com/newren/git-filter-repo/blob/a6a6a1b0f62d365bbe2e76f823e1621857ec4dbd/contrib/filter-repo-demos/bfg-ish#L29-L31) + [roadblocks](https://github.com/newren/git-filter-repo/blob/a6a6a1b0f62d365bbe2e76f823e1621857ec4dbd/contrib/filter-repo-demos/bfg-ish#L23-L26) + [and](https://github.com/newren/git-filter-repo/blob/a6a6a1b0f62d365bbe2e76f823e1621857ec4dbd/contrib/filter-repo-demos/bfg-ish#L66-L68) + [limitations](https://github.com/newren/git-filter-repo/blob/a6a6a1b0f62d365bbe2e76f823e1621857ec4dbd/contrib/filter-repo-demos/bfg-ish#L27-L28) + even within its intended use case of removing big or sensitive content. + + * filter-branch: performance really shouldn't matter for a one shot + usage tool, but filter-branch can turn a few hour rewrite + (allowing an overnight downtime) into an intractable three-month + wait. Further, its design architecture leaks through every level + of the interface, making it nearly impossible to change anything + about the slow design without having backward compatibility + issues. These issues are well known, but what is less well known + is that even ignoring performance, [the usability choices in + filter-branch rapidly become increasingly conflicting and + problematic](https://github.com/newren/git-filter-repo/blob/a6a6a1b0f62d365bbe2e76f823e1621857ec4dbd/contrib/filter-repo-demos/filter-lamely#L9-L61) + for users with larger repos and more involved rewrites, + difficulties that again cannot be ameliorated without breaking + backward compatibility. + +#### reposurgeon + +Some brief impressions about reposurgeon: + + * Appears to be + [almost](http://www.catb.org/~esr/reposurgeon/features.html) + [exclusively](http://www.catb.org/~esr/reposurgeon/dvcs-migration-guide.html) + focused on transitioning between different version control systems + (CVS, SVN, Hg, Bazaar, Git, etc.), and in particular handling the myriad + edge and corner cases that arise in transitioning from CVS or SVN to a + DVCS. + * Provides very thorough reference-style documentation; if you read all + reposurgeon documentation, you will likely feel as though you can take + an existing example and modify it in many ways. + * [Absolutely no full-fledged + examples](https://public-inbox.org/git/CAA01Csq0eX2L5cKpjjySs+4e0Sm+vp=10C_SAkE6CLpCHBWZ8g@mail.gmail.com/) + [or user-guide style + documentation](https://public-inbox.org/git/CAA01Csp+RpCXO4noewBOMY6qJiBy=Gshv3rUh83ZY2RJ5Th3Ww@mail.gmail.com/) + are provided for getting started. + * Appears to not have any facilities for quick (in terms of time spent by + the user) conversions similar to filter-branch, BFG, or filter-repo. + Users who want such capabilities are likely to be frustrated by + reposurgeon and give up. + * Strikes me as "GDB for history rewriting"; it has lots of facilities + for manually inspecting and editing, but is not intended for the + first-time or casual history spelunker. Only those who view history + spelunking as a frequent hobby or job are likely to dive in. And it's + not quite clear whether it is only useful to those transitioning from + CVS/SVN or whether the facilities would also be useful to others. + * Built on top of fast-export and fast-import, which I contend is the + right architecture for a history filtering tool (see below). + +I have read the reposurgeon documentation multiple times over the years, +and am almost at a point where I feel like I know how to get started with +it. I haven't had a need to convert a CVS or SVN repo in over a decade; if +I had such a need, perhaps I'd persevere and learn more about it. I +suspect it has some good ideas I could apply to filter-repo. But I haven't +managed to get started with reposurgeon, so clearly my impressions of it +should be taken with a grain of salt. + +#### fast-export and fast-import + +Finally, fast-export and fast-import can be used with a little editing of +the fast-export output to handle a number of history rewriting cases. I +have done this many times, but it has some +[drawbacks](https://public-inbox.org/git/CABPp-BGL-3_nhZSpt0Bz0EVY-6-mcbgZMmx4YcXEfA_ZrTqFUw@mail.gmail.com/): + + * Dangerous for programmatic edits: It's tempting to use `sed` or `perl` + one-liners to e.g. try to modify filenames, but you risk accidentally + also munging unrelated data such as commit messages, file contents, and + branch and tag names. + * Easy to miss corner cases: for example, fast-export only quotes + filenames when necessary; as such, your attempt to rename a directory + might leave files with spaces or UTF-8 characters in their original + location. + * Difficult to directly provide higher level facilities: for example, + rewriting (possibly abbreviated) commit hashes in commit messages to + refer to the new commit hashes, or stripping of non-merge commits which + become empty or merge commits which become degenerate and empty. + * Misses a lot of pieces needed to round things out into a usable + tool. + +However, fast-export and fast-import are the right architecture for +building a repository filtering tool on top of; they are fast, provide +access to almost all aspects of a repository in a very machine-parseable +format, and will continue to gain features and capabilities over time +(e.g. when replace refs were added, fast-export and fast-import immediately +gained support). To create a full repository surgery tool, you "just" need +to [combine fast-export and fast-import together with a whole lot of +parsing and +glue](https://github.com/newren/git-filter-repo#how-filter-repo-works), +which, in a nutshell, is what filter-repo is. + +#### Upstream improvements + +But to circle back to the question of improving existing tools, during the +development of filter-repo and its predecessor, lots of [improvements to +both fast-export and +fast-import](https://github.com/newren/git-filter-repo/tree/develop#upstream-improvements) +were submitted and included in git.git. + +(Also, [filter-repo started in early 2009 as +git_fast_filter.py](https://public-inbox.org/git/51419b2c0904072035u1182b507o836a67ac308d32b9@mail.gmail.com/) +and therefore technically predates both BFG and reposurgeon.) + +### Why not a builtin command? + +One could ask why this new command is not written in C like most of Git. +While that would have several advantages, it doesn't meet the necessary +design requirements. See the ["VERSATILITY" section of the +manpage](https://github.com/newren/git-filter-repo/blob/a6a6a1b0f62d365bbe2e76f823e1621857ec4dbd/Documentation/git-filter-repo.txt#L306-L326) +or see the "Versatility" section under the [Design Rationale of the +README](https://github.com/newren/git-filter-repo#design-rationale-behind-filter-repo-why-create-a-new-tool). + +Technically, we could perhaps provide a mechanism for people to write +and compile plugins that a builtin command could load, but having users +write filtering functions in C sounds suboptimal, and requiring gcc for +filter-repo sounds more onerous than using python. + +### Where to from here? + +This was just a quick intro to filter-repo, and I've provided a lot of +links above if you want to learn more. Just a few more that might be of +interest: + + * [Ramifications of repository + rewrites](https://github.com/newren/git-filter-repo/blob/a6a6a1b0f62d365bbe2e76f823e1621857ec4dbd/Documentation/git-filter-repo.txt#L340-L350); + including + [some](https://github.com/newren/git-filter-repo/blob/a6a6a1b0f62d365bbe2e76f823e1621857ec4dbd/Documentation/git-filter-repo.txt#L376-L410) + [tips](https://github.com/newren/git-filter-repo/blob/a6a6a1b0f62d365bbe2e76f823e1621857ec4dbd/Documentation/git-filter-repo.txt#L426-L431) + (not specific to filter-repo) + * [Finding big objects/directories/extensions (and renames) in your + repo](https://github.com/newren/git-filter-repo/blob/a6a6a1b0f62d365bbe2e76f823e1621857ec4dbd/Documentation/git-filter-repo.txt#L356-L361) + (can be used together with tools other than filter-repo too) + * [Creating new history rewriting tools](https://github.com/newren/git-filter-repo/tree/master/contrib/filter-repo-demos) + + +## Discussions + + + +### Reviews + +* [[RFC/PATCH] CodingGuidelines: spell out post-C89 rules](https://public-inbox.org/git/xmqq4l3l520f.fsf_-_@gitster-ct.c.googlers.com/) + + Carlo Arenas recently [commented on a patch by Emily Shaffer](https://public-inbox.org/git/CAPUEspgjSAqHUP2vsCCjqG8b0QkWdgoAByh4XdqsThQMt=V38w@mail.gmail.com/) + that moving a declaration out of a "for" loop would allow building on + a CentOS 6 box. + + Junio Hamano, the Git maintainer, replied to Carlo that we indeed + "still reject variable definition in for loop control" even if "for + past several years we've been experimenting with a bit more modern + features". + + Junio then sent a patch to update the Documentation/CodingGuidelines + file. This file describes which coding conventions are, and should + be, used by developers working on the Git codebase. + + One very important part of these conventions are the C language + features that the developers are allowed or disallowed to use. + + For a very long time, to be compatible with as many systems as + possible, only features part of the + [C89 standard](https://en.wikipedia.org/wiki/ANSI_C) were + allowed. Since 2012 though features part of the C99 standard have + been very slowly introduced. + + When these new features were introduced, they were introduced in + "weather balloons" patches, which are very limited changes that are + easy to undo in case someone complains. + + Fortunately in most cases, though not in the "for" loop case, since + the patches have been merged, no one has complained that they + couldn't compile Git's code due to these patches, which means that + code using these new features can now be more widely accepted. + + The goal of Junio's patch was to document that fact and these new + features at the same time. + + One of the new features is allowing an enum definition whose last + element is followed by a comma. Jonathan Nieder replied to Junio + that someone complained about that in [2010](https://public-inbox.org/git/20100311163235.GC7877@thor.il.thewrittenword.com/), + but, as it has not happened since 2012 when the feature was + reintroduced in the code base, it is ok. + + Jonathan even suggested that we "say that the last element should + always be followed by a comma, for ease of later patching", and + Junio found this idea interesting. + + A few more comments were made by Jonathan and Bryan Turner about + small possible improvements to Junio's patch. Junio then sent an + updated version of the patch which has since been merged to the + master branch. + + + + +## Developer Spotlight: Jean-Noël Avila + +* Who are you and what do you do? + + My name is Jean-Noël Avila, father of three daughters and husband of + an incredibly understanding wife. I graduated a long time ago from a + french engineering school, with a speciality in signal processing, + not really in computer science. + + Professionally, I work in the R&D team of a + [small company](https://www.scantech.com) that makes industrial + online measurement systems, and guess what, we're using Git as an + ubiquitous revision control system (software, documentation); my + colleagues know who they should call for any issue. Sadly though, I + don't work on Git. + +* What would you name your most important contribution to Git? + + For the Git project itself, my most important and only contribution + has been to deliver the french localization of the software + since... 2013 (gasp!) and occasionally propose some patches to fix + internationalization issues. + + At the beginning, I proposed some patches to fix glob-pattern + matching in the `.gitignore` file, but even if it fixed the issue, + it turned out later that the patch had introduced a performance + regression. So I chose to stick to a less harmful activity in the + community (although bad translation can be quite harmful). + + In the Git ecosystem more generally, I've been working on + translating the Pro Git book [to French](https://git-scm.com/book/fr/v2) and managing with Peff and + Pedro (@pedrorijo91) the publishing of the translations of the book + on [http://git-scm.com](http://git-scm.com). So, to sum it up, not working on the core, + but on the public interfaces of the project. + +* What are you doing on the Git project these days, and why? + + Following the path of localization, what is a localized application + worth if the documentation is still an impediment? In this idea, at + the beginning of this year, I've started an effort to translate the + manual pages in French and to propose the translation framework put + in place for this purpose to other languages. + + So far, only two languages have translated content, but I expect to + have some more soon. The pages are already available at + [http://git-scm.com/docs/](http://git-scm.com/docs/). What is still missing is the packaging + for other distributions of Git. Maybe when we have more content to + provide. + +* 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? + + Functionally, we've been bitten by some wrong merges of concurrent + branches, and I wish Git could have some knowledge in patch algebra + to better handle these corner cases. I know that it would be quite + orthogonal to the present design, but even just detecting and + showing warnings that something nasty is happening would prevent + surprises (to say the least) of the users in complex histories. + + From a translator's stand point, a project that would not require a + big expertise while still being useful would be to introduce rules + and factorize internationalization. This part of Git is still the + wild west by some aspects with a lot of freedom left to developers + to choose their own formatting. A sizeable part of these strings are + almost identical: with or without an ending period, with quoted or + unquoted `%s`, with uppercase or not. Some strings are very similar: + "foo and bar are mutually exclusive", and so on. In the end, the + number of segments to translate in Git amounts to 4674 for v2.23.0, + which basically bars the entry to new translations. + + As an aside, providing a `po` file for core strings and another one + for less used strings would also help kickstart translations by + focusing on more productive work for translators of new languages. I + understand this kind of task would be Sisyphos' work, but that would + really help the community grow by giving access to Git to users less + educated in computer science. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + Translating Git and the manpages gives a good overview of what's + available and what is being introduced. So far, I haven't + experienced anything strikingly bad about a particular feature. At + the limit, I would make rebasing require a more advanced knowledge + of Git's internals by not providing such an easy way to shoot in + one's foot. + +* What is your favorite Git-related tool/library, outside of Git itself? + + In fact, in my daily work with Git, I don't use the command line + that much. I'm an Emacs fan, and [Magit](https://magit.vc/) is really a miraculous tool + when it comes to interacting with a Git repository from my favorite + editor. + +## Releases + ++ Git [2.23.0](https://public-inbox.org/git/xmqqy2zszuz7.fsf@gitster-ct.c.googlers.com/), +[2.22.1](https://public-inbox.org/git/xmqqh86m9npi.fsf@gitster-ct.c.googlers.com/), +[2.23.0-rc2](https://public-inbox.org/git/xmqqk1bmcf3q.fsf@gitster-ct.c.googlers.com/), +[2.23.0-rc1](https://public-inbox.org/git/xmqq36ijjk8i.fsf@gitster-ct.c.googlers.com/), +[2.23.0-rc0](https://public-inbox.org/git/xmqqh874tssp.fsf@gitster-ct.c.googlers.com/) ++ Git for Windows [2.23.0](https://github.com/git-for-windows/git/releases/tag/v2.23.0.windows.1) ++ libgit2 [0.28.3](https://github.com/libgit2/libgit2/releases/tag/v0.28.3) ++ libgit2sharp [0.26.1](https://github.com/libgit2/libgit2sharp/releases/tag/v0.26.1) ++ Bitbucket Server [6.5](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [2.15.15](https://www.gerritcodereview.com/2.15.html#21515), +[2.16.11](https://www.gerritcodereview.com/2.16.html#21611) ++ GitHub Enterprise [2.17.6](https://enterprise.github.com/releases/2.17.6/notes), +[2.16.15](https://enterprise.github.com/releases/2.16.15/notes), +[2.15.20](https://enterprise.github.com/releases/2.15.20/notes) ++ GitLab [12.1.6](https://about.gitlab.com/2019/08/12/critical-security-release-gitlab-12-dot-1-dot-6-released/), +[12.1.4](https://about.gitlab.com/2019/08/06/gitlab-12-1-4-released/), +[12.1.3](https://about.gitlab.com/2019/07/31/gitlab-12-1-3-released/), +[12.1.2](https://about.gitlab.com/2019/07/29/security-release-gitlab-12-dot-1-dot-2-released/), +[12.1.1](https://about.gitlab.com/2019/07/24/gitlab-12-1-1-released/) ++ GitKraken [6.1.3](https://support.gitkraken.com/release-notes/current/#version-613), +[6.1.2](https://support.gitkraken.com/release-notes/current/#version-612), +[6.1.1](https://support.gitkraken.com/release-notes/current/#version-611), +[6.1.0](https://support.gitkraken.com/release-notes/current/#version-610) ++ GitHub Desktop [2.1.1](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + +* The first translations of manpages are finally hitting git-scm.com. The project was kicked off and [announced](https://public-inbox.org/git/1992944.NOdEsaAZKb@cayenne/) in January 2019. It was decided to hold the translation outside the main git repository and use a converter from the original asciidoc format to gettext po. After some more work on tooling and [more people](https://public-inbox.org/git/CAHtYWY4g4BYDr_z7pfS-p=aX_YkVo4HzGR1Dsytn4RkzBo0GjA@mail.gmail.com/) joining the project, the toolchain to allow publishing on git-scm.com is in place and you can already see [some results](https://git-scm.com/docs/git-add/pt_BR). There are presently 9 languages of which 2 have several complete translated manpages. The upcoming tasks are to direct priority-oriented translators to most viewed content and generate packages for distribution along Git itself. +* [GitHub Actions now supports CI/CD, free for public repositories](https://github.blog/2019-08-08-github-actions-now-supports-ci-cd/) + +__Light reading__ + +* [A Deep Dive into Git Performance using Trace2](https://devblogs.microsoft.com/devops/a-deep-dive-into-git-performance-using-trace2/) + by Jeff Hostetler explains everything about the Trace2 logging framework which was released in Git 2.22.0. +* [Documenting Proper Git Usage](https://www.linuxjournal.com/content/documenting-proper-git-usage) + by Zack Brown in Linux Journal, mainly about the + [Rebasing and merging in kernel repositories](https://lwn.net/Articles/791284/) + article by Jonathan Corbet in LWN.net, mentioned in + [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/). +* [Patch Workflow With Mutt - 2019](http://kroah.com/log/blog/2019/08/14/patch-workflow-with-mutt-2019/) + by Greg Kroah-Hartman. +* [Using Conventional Commit in Projects](https://dzone.com/articles/using-conventional-commit-in-project) + by Sathyabodh Mudhol on DZone. [Conventional Commits](https://www.conventionalcommits.org/) specification + was mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/). + +__Git tools and sites__ + +* [Game of Trees (Got)](https://gameoftrees.org/index.html) is a + version control system developed by and for OpenBSD developers which + prioritizes ease of use and simplicity over flexibility. Got wants + to remain on-disk compatible with bare Git repositories. +* [git-revise](https://mystor.github.io/git-revise.html) by Nika Layzell + is a history editing tool designed for the patch-stack workflow + (similarly to [StGit](http://procode.org/stgit/), [Quilt](http://savannah.nongnu.org/projects/quilt), [Guilt (formerly gq)](https://github.com/jeffpc/guilt) or [TopGit](https://github.com/mackyle/topgit)). + It is intended to be fast, at least for small editing tasks; + it is not meant to be a complete replacement for `git rebase -i`. +* [StoryTime](https://storytime.dev/) is a tool + that enables developers to easily simulate debugger-like visuals + to tell or read a story about pieces of code (in their GitHub repositories). + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Gabriel Alcaras <> +with help from Elijah Newren, Jeff Hostetler, Andrew Ardill and Jean-Noël Avila. diff --git a/_posts/2019-09-25-edition-55.markdown b/_posts/2019-09-25-edition-55.markdown new file mode 100644 index 000000000..ed939cf82 --- /dev/null +++ b/_posts/2019-09-25-edition-55.markdown @@ -0,0 +1,204 @@ +--- +title: Git Rev News Edition 55 (September 25th, 2019) +layout: default +date: 2019-09-25 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 55 (September 25th, 2019) + +Welcome to the 55th 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](https://git.github.io). + +This edition covers what happened during the month of August 2019. + +## Discussions + +### General + +* Google Summer of Code 2019 is over. + + Both students, Rohit Ashiwal and Matheus Tavares, passed their final evaluation + and posted a final report on their blog. See: + + * [Rohit's report about improving the consistency of sequencer commands](https://rashiwal.me/2019/final-report/) + + * [Matheus' report about making pack access code thread-safe](https://matheustavares.gitlab.io/posts/gsoc-final-report) + +* [Virtual Git Contributor Summit](https://public-inbox.org/git/nycvar.QRO.7.76.6.1907031429420.44@tvgsbejvaqbjf.bet/) + + Johannes Schindelin, alias Dscho, organized the first Virtual Git + Contributor Summit which happened on Thursday September 12 and + Friday September 13 over a Zoom call. + + [Notes](https://docs.google.com/document/d/1Yp6tz_JgUYjoofTDogtosLsdykwiAyYu9yM42yTuFA4/edit) + ([plain text](https://public-inbox.org/git/nycvar.QRO.7.76.6.1909261253400.15067@tvgsbejvaqbjf.bet/)) + have been taken and are used to organize follow up actions. + +* [RFC - Git Developer Blog](https://public-inbox.org/git/20190806014935.GA26909@google.com/) + + Emily Shaffer asked on the mailing list if people would be + interested in creating a "Git-project-blessed blog written by Git + contributors". The goal was "to make Git better understood in the + rest of the world", in a not very formal setting. + + A number of people replied to Emily saying that they thought it was + a good idea, and sometimes agreeing to submit articles for the new + blog or to review other people's submissions. + + Jeff King, who manages the git-scm.com web site, suggested hosting it + at the same place using blog.git-scm.com, which Emily accepted. + + Following the Virtual Git Contributor Summit + [a repository](https://gitlab.com/git-scm/blog/) + has been created for the blog by James Ramsay. + + + +### Support + +* [diff.renames not working?](https://public-inbox.org/git/CAHd499BT35jvPtsuD9gfJB0HJ=NxtzyQOaiD7-=sHJbFYhphpg@mail.gmail.com/) + + Robert Dailey wondered if the `diff.renames` config option worked + correctly when it's set to `copies`, as `git diff --name-status` and + `git diff --follow` (which is not documented) showed that one file + was copied from another when they were passed a path to a file as + argument, but `git diff` and `git diff -M` didn't. + + Jeff King, alias Peff, replied to Robert explaining how rename + detection works and what are the current limitations. He also + suggested some possible improvements. + + Bryan Turner and Peff also noticed that `-M` detects renames, not + copies. + + Junio agreed with Peff and gave extra historical information and + also discussed possible improvements. + +## Developer Spotlight: Emily Shaffer + +* Who are you and what do you do? + + I'm a California resident, dog mom, maker, and software engineer at + Google contributing to Git as my day job! + +* What would you name your most important contribution to Git? + + [The My First Contribution tutorial](https://git-scm.com/docs/MyFirstContribution.html) - + it's helping folks who are interested in committing to Git full-time + figure out how to write and send patches, and more importantly (to + me), it has launched a conversation about better internal + documentation for Git contributors, which I'm really excited about. + +* What are you doing on the Git project these days, and why? + + Lately, I've been making it easier for the Git team at Google to + distribute Git to Googlers (gee). For the benefit of the broader + community, I have started working on a tool to help users generate + helpful, actionable bug reports. Soon I hope to be doing some work + with hook management. + +* 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? + + Submodules! I think they're such a cool idea but they have a long + way to go right now. It's a little personal for me; I also + contribute to [OpenBMC](https://openbmc.org) which I think could benefit a + lot from using submodules as well, but it hasn't been feasible yet. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + That's a good question! There are lots of depths of Git that I + haven't been subjected to yet, so I think I have to do some more + homework before I can decide what I'd do away with. + +* What is your favorite Git-related tool/library, outside of Git itself? + + Probably the high number of tiny `.bashrc` aliases I've got for the + Git CLI. My work would be much slower without quick aliases for + `git grep`, `git format-patch`, and so on. Or, I suppose related to the + Git project (but not the Git tool), I learned to use mutt for + interacting with the Git mailing list and am still thrilled to be + able to email in Vim. + + +## Releases + ++ Gerrit Code Review [2.16.12](https://www.gerritcodereview.com/2.16.html#21612), +[2.15.17](https://www.gerritcodereview.com/2.15.html#21517), +[3.0.2](https://www.gerritcodereview.com/3.0.html#302) ++ GitHub Enterprise [2.18.2](https://enterprise.github.com/releases/2.18.2/notes), +[2.17.8](https://enterprise.github.com/releases/2.17.8/notes), +[2.16.17](https://enterprise.github.com/releases/2.16.17/notes), +[2.15.22](https://enterprise.github.com/releases/2.15.22/notes), +[2.18.1](https://enterprise.github.com/releases/2.18.1/notes), +[2.17.7](https://enterprise.github.com/releases/2.17.7/notes), +[2.16.16](https://enterprise.github.com/releases/2.16.16/notes), +[2.15.21](https://enterprise.github.com/releases/2.15.21/notes) ++ GitLab [12.3](https://about.gitlab.com/2019/09/22/gitlab-12-3-released/), +[12.1.11](https://about.gitlab.com/2019/09/19/gitlab-12-1-11-released/), +[12.2.5, 12.1.9, and 12.0.9](https://about.gitlab.com/2019/09/10/critical-security-release-gitlab-12-dot-2-dot-5-released/), +[12.2.4](https://about.gitlab.com/2019/09/02/gitlab-12-2-4-released/), +[12.2.3](https://about.gitlab.com/2019/08/29/security-release-gitlab-12-dot-2-dot-3-released/), +[12.2.1](https://about.gitlab.com/2019/08/23/gitlab-12-2-1-released/) ++ Bitbucket Server [6.6](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitKraken [6.2.0](https://support.gitkraken.com/release-notes/current), +[6.1.4](https://support.gitkraken.com/release-notes/current), +[6.1.3](https://support.gitkraken.com/release-notes/current), +[6.1.2](https://support.gitkraken.com/release-notes/current), +[6.1.1](https://support.gitkraken.com/release-notes/current), +[6.1.0](https://support.gitkraken.com/release-notes/current), +[6.0.1](https://support.gitkraken.com/release-notes/current), +[6.0.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.1.3](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ +* [Highlights from Git 2.23](https://github.blog/2019-08-16-highlights-from-git-2-23/) + on GitHub blog by Taylor Blau. +* There is an informal [Git standup on IRC](https://public-inbox.org/git/20180713170018.GA139708@aiede.svl.corp.google.com/t/#u) + on #git-devel on irc.freenode.net every two weeks; + you can find dates in [Git Events](https://calendar.google.com/calendar/embed?src=nk8ph2kh4p5tgfcctb8i7dm6d4%40group.calendar.google.com) calendar ([.ics](https://calendar.google.com/calendar/ical/nk8ph2kh4p5tgfcctb8i7dm6d4%40group.calendar.google.com/public/basic.ics)); + logs are at . +* [Sunsetting Mercurial support in Bitbucket](https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket). + +__Light reading__ +* [“They Didn’t Teach Us This”: A Crash Course for Your First Job in Software](https://stackoverflow.blog/2019/09/05/they-didnt-teach-us-this-a-crash-course-for-your-first-job-in-software/) by Max Pekarsky, + which includes Git Workflow section. +* [First Steps Contributing to Git](https://matheustavares.gitlab.io/posts/first-steps-contributing-to-git) by Matheus Tavares, GSoC 2019 student. +* [Maintaining the kernel's web of trust [LWN.net]](https://lwn.net/Articles/798230/) by Jonathan Corbet; + one of the proposed solutions is to use [pgpkeys.git](https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git) repository to hold GPG keys for kernel developers. +* [Defragmenting the kernel development process [LWN.net]](https://lwn.net/Articles/799134/) + article by Jonathan Corbet, including section about version control + and Git. It mentions and references [Change IDs for kernel patches [LWN.net]](https://lwn.net/Articles/797613/). +* [GitLens: where have you been all my life!](https://dev.to/glsolaria/gitlens-where-have-you-been-all-my-life-1c2d) by G.L Solaria, + told using animated screenshots GIFs. + [GitLens](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens) + add-on for Visual Studio Code was mentioned in + [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/). +* [Git Can Do That?](https://docs.google.com/presentation/d/1xbzgdj_gnUSEvpTedoyJXVvREwOxBi1amm7A_FdMFCc/edit?usp=sharing) Git presentation given at [Web Weekend Kathmandu, 2019](https://2019.wwktm.co/speakers/pratik-karki/) by Pratik Karki. + +__Git tools and sites__ +* [patchew](https://github.com/patchew-project/patchew) + is a patch email tracking and testing system, + very similar to [patchwork](http://jk.ozlabs.org/projects/patchwork/) + (mentioned in [Git Rev News Edition #20](https://git.github.io/rev_news/2016/10/19/edition-20/)). +* [gitin2it](https://github.com/slefevre/gitin2it), + set of [git] aliases to make git actions more intuitive. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Gabriel Alcaras <> +with help from Emily Shaffer, James Ramsay, Pratik Karki and Thomas Ferris. diff --git a/_posts/2019-10-26-edition-56.markdown b/_posts/2019-10-26-edition-56.markdown new file mode 100644 index 000000000..566f0ea54 --- /dev/null +++ b/_posts/2019-10-26-edition-56.markdown @@ -0,0 +1,293 @@ +--- +title: Git Rev News Edition 56 (October 26th, 2019) +layout: default +date: 2019-10-26 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 56 (October 26th, 2019) + +Welcome to the 56th 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](https://git.github.io). + +This edition covers what happened during the month of September 2019. + +## Discussions + +### General + +* [Growing the Git community](https://public-inbox.org/git/b6835484-62a4-6f89-b6b1-f43afe794272@iee.email/) + + Derrick Stolee, who prefers to be called Stolee, emailed the mailing + list after the Virtual Contributor Summit (see [previous edition](/rev_news/2019/09/25/edition-55/#general)) + saying he wanted to further discuss some ideas, that had been shared + during the Summit, about "Inclusion & Diversity" with the goal of + making the community more welcoming to new contributors of all + kinds. + + He listed some possible problems that could prevent new contributors + entering the community: + + 1. Discovering how to contribute to Git is non-obvious. + + 2. Submitting to a mailing list is a new experience for most + developers. This includes the full review and discussion + process. + + 3. The high standards for patch quality are intimidating to new + contributors. + + 4. Some people do not feel comfortable engaging in a community + without a clear Code of Conduct. This discomfort is significant + and based on real experiences throughout society. + + 5. Since Git development happens in a different place than where + users acquire the end product, some are not aware that they can + contribute. + + Then Stolee proposed actions to address the problems: + + 1. Improve the documentation for contributing to Git. + + 2. Add more pointers to GitGitGadget. + + 3. Introduce a new "mentors" mailing list. + + 4. Add an official Code of Conduct. + + 5. Advertise that Git wants new contributors. + + Each action was explained and justified, sometimes pointing to interesting research like the recent paper + [""We Don't Do That Here": How Collaborative Editing With Mentors Improves Engagement in Social Q&A Communities"](http://www.chrisparnin.me/pdf/chi18.pdf). + + Stolee also proposed some metrics to be measured between releases to + monitor how the community are doing: + + 1. How many first-time contributors sent a patch? + + 2. How many contributors had their first commit accepted into + the release? + + 3. How many contributors started reviewing? + + 4. How many total patches/reviews did the list receive? + + His email was very detailed with many suggestions about how to + implement the actions, and he asked interesting questions to gather + peoples' opinion. + + Denton Liu replied to Stolee sharing some thoughts as a "relatively + new contributor (just less than a year)". He said that from his + experience to get more contributors, we should try to answer the + "how do we make it more fun to contribute to Git?" question. + + He recalled that most of his time learning to contribute to Git + "stemmed from the fact that there's a lot of tribal knowledge that's + not really written down anywhere". + + As Stolee had mentioned + [the "My First Contribution" document](https://git-scm.com/docs/MyFirstContribution), + which was recently contributed by Emily Shaffer, Denton said that it + would have really helped him get started. + + Denton also suggested improving transparency about what happens to + patches sent to the mailing list. + + Mike Hommey replied to Stolee suggesting an additional problem which + is that newcomers don't really have any idea what they could + contribute. + + Johannes Schindelin, alias Dscho, replied to Mike that newcomers + need experienced developers to validate the ideas they would like + to implement in Git, before they can be confident enough to work on + them. And they also need to be shown ideas they could + implement. Dscho then talked about + [the GitGitGadget issue list](https://github.com/gitgitgadget/git/issues) which is open and + "intended to accumulate possible project ideas". Dscho also + acknowledged [the Chromium Git issue list](https://crbug.com/git) which is another issue tracker + with a similar purpose. + + Replying to Stolee, Jeff King, alias Peff, who is responsible for + [the main Git web site](https://git-scm.com), suggested improving + [the community page](https://git-scm.com/community) to add more + information for beginners. He said he was open to accepting patches + or [pull requests](https://github.com/git/git-scm.com). + + Elijah Newren mostly agreed with Stolee's email, but suggested a + less strongly worded tone when talking about goals and existing + problems. + + Junio Hamano, the Git maintainer, replied to Stolee about the goal + of the project and the metrics that we could use with the following: + + > We first should make sure that we serve existing users and + > existing community members well. So well that other people who + > are not yet our "existing" users and members would want to become + > part of us, in order to join the fun and share the benefit. If we + > cannot serve even the existing members well, we shouldn't be + > talking about acquiring new members. + + He then proposed to measure "community-member happiness" with metrics + like "This many percent of total community member population have + been active this month". + + The discussion involved a number of other Git developers like Jakub + Narębski, Emily Shaffer, Garima Singh, Pierre Tardy, Philip Oakley + and Randall S. Becker. + + A number of people commented especially on the subject of adding an + official Code of Conduct, which will be reported on in a separate + article below. + + Otherwise it remains to be seen if many actions will be taken to + make the project more welcoming to new contributors. + +* [[PATCH] add a Code of Conduct document](https://public-inbox.org/git/20190924064454.GA30419@sigill.intra.peff.net/) + + Following the Virtual Contributor Summit (see [previous edition](/rev_news/2019/09/25/edition-55/#general)) and + the discussions about growing the Git community (see the article + above), Jeff King, alias Peff, decided to send a patch to add a code + of conduct. + + In his patch he says that "it may be a good time to cement our + expectations when things are quiet, since it gives everybody some + distance rather than focusing on a current contentious issue". Many + people indeed agreed in the previous discussions with that point of + view, and the idea of a Code of Conduct in the first place. + + Peff says that his patch adapts the Contributor Covenant Code of + Conduct from + [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html) + and that "it's also the same document used by the Git for Windows + project". + + One of the changes is that for dealing with community issues, the + document spreads the responsibility to the Project Leadership + Committee (git@sfconservancy.org) instead of the only maintainer, + Junio C Hamano. + + Peff also mentioned [a commit](https://github.com/mhagger/git/commit/c6e6196be8fab3d48b12c4e42eceae6937538dee) + by Michael Haggerty from June 2013 that he found in a previous + discussion and that has nice set of guidelines about how to review + code. + + A number of the replies were about the Project Leadership Committee + as it's not easy to know who is part of it. This was acknowledged by + Peff who sent + [a follow-up patch](https://public-inbox.org/git/20190926072046.GB20653@sigill.intra.peff.net/) + to address the issue by listing the Project Leadership Committee + members with their email addresses and by saying that they can also + be contacted individually. + + Even though there was some disagreement, in general most of the people + taking part in the discussion agreed with Peff's patches. Junio + later sent a + [follow-up email](https://public-inbox.org/git/xmqqd0f6n5a4.fsf_-_@gitster-ct.c.googlers.com/) + with the subject "Raise your hand to Ack jk/code-of-conduct if your + Ack fell thru cracks" to get more developers to formally agree with the + final patch, which then several did. + + The commit adding the Code of Conduct has since been merged into the + master branch. + + + + + + + +## Releases + ++ Git [2.24.0-rc0](https://public-inbox.org/git/xmqq4l065zx5.fsf@gitster-ct.c.googlers.com/) ++ Git for Windows [2.24.0-rc0](https://public-inbox.org/git/nycvar.QRO.7.76.6.1910220004190.46@tvgsbejvaqbjf.bet/) ++ GitHub Enterprise [2.18.4](https://enterprise.github.com/releases/2.18.4/notes), +[2.17.10](https://enterprise.github.com/releases/2.17.10/notes), +[2.16.19](https://enterprise.github.com/releases/2.16.19/notes), +[2.15.24](https://enterprise.github.com/releases/2.15.24/notes), +[2.18.3](https://enterprise.github.com/releases/2.18.3/notes), +[2.17.9](https://enterprise.github.com/releases/2.17.9/notes), +[2.16.18](https://enterprise.github.com/releases/2.16.18/notes), +[2.15.23](https://enterprise.github.com/releases/2.15.23/notes) ++ GitLab [12.4](https://about.gitlab.com/blog/2019/10/22/gitlab-12-4-released/), +[12.3.5, 12.2.8, and 12.1.14](https://about.gitlab.com/blog/2019/10/07/security-release-gitlab-12-dot-3-dot-5-released/), +[12.3.4](https://about.gitlab.com/blog/2019/10/03/gitlab-12-dot-3-dot-4-released/), +[12.3.3, 12.2.7, and 12.1.13](https://about.gitlab.com/blog/2019/10/02/security-release-gitlab-12-dot-3-dot-3-released/), +[12.3.2, 12.2.6, and 12.1.12](https://about.gitlab.com/blog/2019/09/30/security-release-gitlab-12-dot-3-dot-2-released/), +[12.3.1](https://about.gitlab.com/blog/2019/09/24/gitlab-12-3-1-released/), +[12.3](https://about.gitlab.com/blog/2019/09/22/gitlab-12-3-released/) ++ Bitbucket Server [6.7](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.0.3](https://www.gerritcodereview.com/3.0.html#303) ++ GitKraken [6.3.0](https://support.gitkraken.com/release-notes/current), +[6.2.1](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.2.1](https://desktop.github.com/release-notes/), +[2.2.0](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + +* A new maintainer for Git-Gui, Pratyush Yadav (@prati0100), + [came forward](https://public-inbox.org/git/xmqq7e655ryx.fsf@gitster-ct.c.googlers.com/). + Let's praise and thank him for volunteering. +* The Gerrit User Summit 2019 is going to be [broadcasted on live.gerritforge.com](https://live.gerritforge.com) and will + include talks about JGit and Gerrit Code Review, including major members of the Git Community, like Jonathan Nieder and Terry Parker. + +__Light reading__ + +* [Commit graph drawing algorithms](https://pvigier.github.io/2019/05/06/commit-graph-drawing-algorithms.html) + by pvigier (Pierre Vigier), describes algorithms used by various + tools including one in pvigier's prototype git client called [gitamine](https://github.com/pvigier/gitamine). + +* [Git Pathspecs and How to Use Them](https://css-tricks.com/git-pathspecs-and-how-to-use-them/) + by Adam Giese. + +* [GitHub Actions, the missing notes: CMake, Qt and IFW](https://skypjack.github.io/2019-10-23-gh-greets-qt/) + by Michele 'skypjack' Caini, shows how he uses [GitHub Actions](https://github.com/features/actions) + in his project. (GitHub Actions, still in public beta, were first + covered in [Git Rev News #44](https://git.github.io/rev_news/2018/10/24/edition-44/)) + +* [An Unintentionally Comprehensive Introduction to GitHub Actions CI](https://dev.to/bnb/an-unintentionally-comprehensive-introduction-to-github-actions-ci-blm) + by Tierney Cyren -- with example of an application build on top of + Node.js. + +* [Scheduling Jekyll posts with Netlify and GitHub Actions](https://humanwhocodes.com/blog/2019/10/scheduling-jekyll-posts-netlify-github-actions/) + by Nicholas C. Zakas on his Human Who Codes blog: using a GitHub + Action cron job to schedule Netlify builds for static site generated + blog posts (which was previously done [using Netlify and AWS Lambda](https://humanwhocodes.com/blog/2018/03/scheduling-jekyll-posts-netlify/)). + +* ["git request-pull" and confusing diffstats [LWN.net]](https://lwn.net/Articles/802797/) + by Jonathan Corbet talks about what to do if the history to be + pulled includes merges from outside (e.g. to obtain the dependencies + for a fix), and why it happens. + +* [How Bash completion works](https://tuzz.tech/blog/how-bash-completion-works) and + [Adding Bash completion to my tool](https://tuzz.tech/blog/adding-bash-completion) + by Chris Patuzzo; Git's Bash completion can be found in + [`contrib/completion/git-completion.bash`](https://github.com/git/git/blob/master/contrib/completion/git-completion.bash). + + +__Git tools and sites__ + +* [Gollum](https://github.com/gollum/gollum) is a simple, Git-powered + wiki written in Ruby with a sweet API and local frontend. +* [git_examples.sh](https://bitbucket.org/BitPusher16/dotfiles/raw/49a01d929dcaebcca68bbb1859b4ac1aea93b073/refs/git/git_examples.sh) + -- 99% of the Git commands you'll need at work, + demonstrated in a single script. + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Gabriel Alcaras <> +with help from Emily Shaffer, Luca Milanesio and George Espinoza. diff --git a/_posts/2019-11-20-edition-57.markdown b/_posts/2019-11-20-edition-57.markdown new file mode 100644 index 000000000..6e0b7fe8c --- /dev/null +++ b/_posts/2019-11-20-edition-57.markdown @@ -0,0 +1,352 @@ +--- +title: Git Rev News Edition 57 (November 20th, 2019) +layout: default +date: 2019-11-20 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 57 (November 20th, 2019) + +Welcome to the 57th 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](https://git.github.io). + +This edition covers what happened during the month of October 2019. + +## Discussions + +### General + +* [RFC: Moving git-gui development to GitHub](https://public-inbox.org/git/20191023201310.thzpxyoeb3ta55dc@yadavpratyush.com/t/#u) + + Pratyush Yadav, a new maintainer for git-gui, asked about whether it + is a better idea to use GitHub for development instead of email + (after [discussion with Dscho](https://public-inbox.org/git/nycvar.QRO.7.76.6.1910061054470.46@tvgsbejvaqbjf.bet/)), + stating arguments in favor and against of moving to GitHub. There + were some voices for the idea, and some against, describing + additional advantages and disadvantages. One idea was to use + GitHub Issues as a centralized issue / bug tracker + regardless of where development would take place, which + [Yadav did](https://github.com/prati0100/git-gui/issues). + + An interesting vote against the idea was that of Elijah Newren, who wrote + that he had been pondering asking the opposite question for + [filter-repo](https://github.com/newren/git-filter-repo/), i.e. + moving its development to git mailing list. + + +### Reviews + +* [[PATCH 0/9] [RFC] New sparse-checkout builtin and "cone" mode](https://public-inbox.org/git/6b461ad3-164d-46ff-4a68-99f8e6562a72@gmail.com) + + Last August, Derrick Stolee, who prefers to be called just "Stolee", + sent to the mailing list an RFC patch series to "make the + sparse-checkout more user-friendly" and to increase performance in + very large repositories. + + The patch series achieves that by introducing a new + `git sparse-checkout` command with 4 subcommands: `init`, `add`, `list` + and `disable`. The series also introduces the `--sparse` option to + `git clone`. + + This helps users manipulate how a sparse-checkout is performed + compared to [the current way](https://git-scm.com/docs/git-read-tree#_sparse_checkout). + + The performance boost is achieved through a new mode called "cone + mode" where all the patterns in the sparse-checkout file are "based + on prefix matches at a directory level". In this mode it can be + faster to match the patterns to the files and directories that + should or should not be checked out, because a hashset (a set + implemented using a hash table) can be used. + + Elijah Newren reviewed Stolee's patches. As Stolee had mentioned + that some people have created + [their own helper tools](http://www.marcoyuen.com/articles/2016/06/07/git-sparse.html), + Elijah first revealed that he also created a "sparsify" script + specific to his company's internal repository. + + Elijah then was concerned about how the feature worked along with + [worktrees](https://git-scm.com/docs/git-worktree) and how the `add` + subcommand and the cone mode worked. He suggested that the + `core.sparseCheckout` config option could be tri-state to make it + explicit how the sparse-checkout file should be parsed. + + Eric Sunshine also chimed into the discussion. + + Stolee replied to Elijah that he hadn't considered worktrees and was + going to take a look at them. He accepted the suggestions about how + `add` should work and about making `core.sparseCheckout` a tri-state + and then sent a + [V2 version of the patch series](https://public-inbox.org/git/pull.316.v2.git.gitgitgadget@gmail.com/) + with those changes and a few other improvements. + + The `add` subcommand was also replaced with a `set` + subcommand, and the tri-state was actually implemented by adding a + new `core.sparseCheckoutCone` config option. + + The discussion continued between Stolee and Elijah, mostly about the + documentation and commit messages. Then Stolee sent a + [V3 version of the patch series](https://public-inbox.org/git/pull.316.v3.git.gitgitgadget@gmail.com/) + with small bug fixes and various improvements, especially in the + documentation and commit messages according to Elijah's suggestions. + + After another round of review from Elijah, Stolee sent a + [V4 version of the patch series](https://public-inbox.org/git/pull.316.v4.git.1571147764.gitgitgadget@gmail.com/) + with only a few small changes. + + Then Gábor Szeder commented on few bugs and small things he had + found; Jon Simons and Elijah also made a few comments. So Stolee sent a + [V5 version of the patch series](https://public-inbox.org/git/pull.316.v5.git.1571666186.gitgitgadget@gmail.com/) + on October 21st addressing the comments. + + Phillip Wood, Stolee and Junio Hamano then discussed another small + issue. It seems though that the patch series will be merged into the + next branch soon. + + + +## Developer Spotlight: Phillip Wood + +* Who are you and what do you do? + + I'm a physicist by training, unfortunately I had to stop working + some years ago due to a chronic health condition. Since then I've + spent some time coding and I got into contributing to Git after + using it on another open source project. + +* What would you name your most important contribution to Git? + + That's hard to say. Personally it was getting `rebase -i` to create + commits without forking `git commit`. I think it was my first big + contribution, it gave a noticeable performance improvement and + meant learning the API around commit creation as well as getting to + grips with the sequencer code that drives cherry-picks and + interactive rebases. + +* What are you doing on the Git project these days, and why? + + I'm still mostly working around the code in the + sequencer. Interactive rebases are one of the features I like best + about Git. Being able to rewrite commits in order to polish a + feature before merging it or posting patches helps make it easier to + understand and review. I've also contributed to `add -p` and + `diff --color-moved-ws` as I find those really useful as well. + + I also try to spend some time reviewing patches in the areas I'm + interested in. One of the great things about contributing to Git is + the reviews one receives when posting patches, they're always + friendly and constructive and I try to do the same for others. It's + also interesting to see what problems other people who use Git are + facing and how they're solving them. + +* 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? + + Gosh that would be fantastic. I'd probably concentrate on the + UI. Firstly I'm interested in being able to amend commits more + easily by providing a simpler interface to `rebase -i` that does not + involve editing a todo file. I'm currently working on a script that + lets you amend the commit that created the current line directly + from an editor and lets you walk backwards and forwards through + history rewriting it as you go. Being able to say "amend the commit + responsible for this line" with a single key stroke is really + convenient. + + There are a number of other UI related projects I'm interested in. I + use diff-highlight but wish it would work on hunks with different + numbers of additions and deletions. Adapting it to diff the diff in + order to highlight the changes would be useful but would need some + careful heuristics to distinguish between when highlighting the + changes is useful and when it is just confusing. Another diff + improvement I'd like to see is implementing `--color=porcelain` for + `git diff` that would allow apps like `tig` and `magit` to show + moved lines. + + I'd also like to improve `git push` and `git pull` to extend the idea of + `--force-with-lease` to support synchronizing between a laptop, + desktop and remote server by allowing forced updates of the local + branch when it has not changed since it was last pushed and improve + `push --force-with-lease` to default to using the hash of the last + pushed commit. + + If there's still some time left then working on the documentation to + make it more approachable for new users would be great. At the + moment the man pages detail the individual commands but there's not + much documentation introducing high level concepts and ideas. There + are some other things such as adding a `--reword` option to `commit` + and improving `add -p` to allow the selection of groups of lines but + that's probably enough for now. + +* If you could remove something from Git without worrying backwards + compatibility, what would it be? + + Personally I'd like to change the way ignored files are handled so + that Git never overwrites them (we could add a new category for + files that are expendable). The relative priority of `.gitignore` + and `.git/info/excludes` could also be tweaked. + + Standardizing option names across the commands would also help users + I think. + +* What is your favorite Git-related tool/library, outside of Git itself? + + I use `tig` for inspecting history with `log` and `blame`. I also + use [Public Inbox](https://public-inbox.org/git) a lot for searching + the mailing list. + +## Releases + ++ Git [2.24.0](https://public-inbox.org/git/xmqq7e4gyzgt.fsf@gitster-ct.c.googlers.com/), +[2.24.0-rc2](https://public-inbox.org/git/xmqqblty3dtx.fsf@gitster-ct.c.googlers.com/), +[2.24.0-rc1](https://public-inbox.org/git/xmqqeez2fzsy.fsf@gitster-ct.c.googlers.com/) ++ Git for Windows [2.24.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.24.0.windows.2), +[2.24.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.24.0.windows.1) ++ GitLab [12.4.2](https://about.gitlab.com/blog/2019/11/04/gitlab-12-4-2-released/), +[12.4.1](https://about.gitlab.com/blog/2019/10/30/security-release-gitlab-12-dot-4-dot-1-released/) ++ Bitbucket Server [6.8](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.1.0](https://www.gerritcodereview.com/3.1.html), +[3.0.4](https://www.gerritcodereview.com/3.0.html#304), +[2.16.13](https://www.gerritcodereview.com/2.16.html#21613), +[2.15.18](https://www.gerritcodereview.com/2.15.html#21518) ++ GitHub Enterprise [2.19.1](https://enterprise.github.com/releases/2.19.1/notes), +[2.19.0](https://enterprise.github.com/releases/2.19.0/notes), +[2.18.6](https://enterprise.github.com/releases/2.18.6/notes), +[2.17.12](https://enterprise.github.com/releases/2.17.12/notes), +[2.16.21](https://enterprise.github.com/releases/2.16.21/notes), +[2.18.5](https://enterprise.github.com/releases/2.18.5/notes), +[2.17.11](https://enterprise.github.com/releases/2.17.11/notes), +[2.16.20](https://enterprise.github.com/releases/2.16.20/notes) ++ TortoiseGit [2.9.0](https://tortoisegit.org/download/) ++ GitKraken [6.3.1](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.2.3](https://desktop.github.com/release-notes/), +[2.2.2](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + +* Welcome to Kaartic Sivaraam to the Git Rev News edition team! And + thanks to Gabriel Alcaras, who leaves the team after contributing to + the interviews and as the author of the script that scrapes some + websites to help prepare the "Releases" section. + +* Emily Shaffer [announced](https://public-inbox.org/git/20191114194708.GD60198@google.com/) + the new [git-mentoring@googlegroups.com mailing list](https://groups.google.com/forum/#!forum/git-mentoring) as "a great place + for those who are new to Git and interested in learning how to + contribute to ask questions and expect kind, thorough answers out of + the spotlight of the main Git mailing list". + +* GitHub announced [GitHub Archive Program](https://archiveprogram.github.com/), + intended to preserve open source software for future generations + in partership with Long Now Foundation, the Internet Archive, + the Software Heritage Foundation, Arctic World Archive, Microsoft Research, + the Bodleian Library, and Stanford Libraries. On **February 2, 2020**, + GitHub will capture a snapshot of every active public repository, + to be preserved in the [GitHub Arctic Code Vault](https://archiveprogram.github.com/#arctic-code-vault). + This data will be stored on 3,500-foot film reels. + +* It [looks like](https://public-inbox.org/git/CAP8UFD0WXrG=XbZj9fyo1v0zy8p7yNnGZGVH8bHDqPOLThGD-w@mail.gmail.com/t/#u) + the [Git Merge](https://git-merge.com/) 2020 conference + will be in Los Angeles on March 4 2020. + + +__Light reading__ + +* [Highlights from Git 2.24](https://github.blog/2019-11-03-highlights-from-git-2-24/) + on GitHub Blog by Taylor Blau: feature macros, commit graph by default, + adopting the Contributor Covenant (see [previous Git Rev News](https://git.github.io/rev_news/2019/10/26/edition-56/)), + recommending new history-rewriting tool: [git-filter-repo](https://github.com/newren/git-filter-repo/) + (more about which can be found in [Git Rev News #54](https://git.github.io/rev_news/2019/08/21/edition-54/)), + and other. + +* [Updates to the Git Commit Graph Feature](https://devblogs.microsoft.com/devops/updates-to-the-git-commit-graph-feature/) by Derrick Stolee + describes new commit-graph related changes in Git version 2.24.0: + new faster algorithm for topological sorting (e.g. for `git log --graph`), + namely an iterative version of Kahn’s algorithm (making use of generation numbers), + incremental commit-graph format with adaptive merging, + new `fetch.writeCommitGraph` setting to update commit-graph after every `git fetch`, + and having `core.commitGraph` and `gc.writeCommitGraph` on by default. + See also [this Twitter thread](https://twitter.com/stolee/status/1194242763413438465). + + Previous blog posts in the series about commit-graph were linked to + in [Git Rev News Edition #41](https://git.github.io/rev_news/2018/07/18/edition-41/), [#45](https://git.github.io/rev_news/2018/11/21/edition-45/) and [#51](https://git.github.io/rev_news/2019/05/22/edition-51/). + Developing incremental commit-graph was covered in detail in + [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/). + At the time of writing link to mentioned article was not yet posted + to [Derrick Stolee developer homepage](https://stolee.dev/). + +* [[LWN.net] Next steps for kernel workflow improvement](https://lwn.net/Articles/803619/) + by Jonathan Corbet: fix attestation with minisig, add base-tree information, + and going beyond email. + +* [[LWN.net] Analyzing kernel email](https://lwn.net/Articles/804511/) + by Jake Edge, about research which goal is "formalizing and assessing + the Linux kernel development process". + +* [I posted my password / API key on GitHub. Now what?](https://flaviocopes.com/git-secrets/) + by Flavio Copes. There are various tools to detect such situation, + and/or to safely store secrets in Git repository; some links + can be found for example in [Git Rev News #39](https://git.github.io/rev_news/2018/05/16/edition-39/). + +* [Three Simple Rules for Putting Secrets into Git](https://engineering.udacity.com/three-simple-rules-for-putting-secrets-into-git-d47b207852b9) + by Jesse Swidler (2018), author of [LockGit](https://github.com/jswidler/lockgit). + +* "Stupid git commit-tree tricks" series of blog posts by Raymond Chen, starting with + [Part 1: Building a commit manually out of a tree](https://devblogs.microsoft.com/oldnewthing/20190506-00/?p=102478). + +* [My favourite Git commit](https://fatbusinessman.com/2019/my-favourite-git-commit) + by David Thompson. + +* [How to write a kickass README](https://dev.to/scottydocs/how-to-write-a-kickass-readme-5af9) + by James.Scott (@scottydocs). + +* [What nobody tells you about documentation](https://www.divio.com/blog/documentation/), + namely that it needs to include and be structured around its four different functions: + _tutorials_, _how-to guides_, _explanation_ and _technical reference_, + each of which requires a distinct mode of writing. + + +__Git tools and sites__ + +* [Git Graph](https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph) + extension for Visual Studio Code -- view a commit graph of your repository, + and easily perform Git actions from the graph. +* [git-subtrac](https://github.com/apenwarr/git-subtrac) is a helper tool + that makes it easier to keep track of your git submodule contents. + It collects the entire contents of the entire history of all your submodules + (recursively) into a separate git branch, which can be pushed, pulled, + forked, and merged however you want. + [Announced as a sequel to git-subtree](https://public-inbox.org/git/CAHqTa-15fKjH-3Z-vHhgNpfx6c1OQXbDXwKJHT9JX6G+7tjGBA@mail.gmail.com/T/#u) + by Avery Pennarun, creator of git-subtree. +* [myrepos](https://myrepos.branchable.com/) is a tool to manage + all your version control repositories, for example + to update them all at once, or push out all your local changes + (similar to [git-repo](https://gerrit.googlesource.com/git-repo/) + or [gitslave](http://gitslave.sourceforge.net/) tools). +* [LockGit](https://github.com/jswidler/lockgit) is a CLI tool + for storing encrypted secrets in a git repo. +* [Onefetch](https://github.com/o2sh/onefetch) is a command line tool + that displays summary information about your Git repository + directly on your terminal. +* [USA-Constitution](https://github.com/JesseKPhillips/USA-Constitution) + repository, with a history of edits to the US Constitution + as it has been amended. Written in Markdown to match original formatting. +* [Gitter](https://gitter.im/) is an open-source instant messaging + and chat room system for developers and users of GitHub repositories, + similar to Slack. Gitter is provided as software-as-a-service. +* [.gitignore Generator](https://marketplace.visualstudio.com/items?itemName=piotrpalarz.vscode-gitignore-generator) + extension for Visual Studio Code - easily and quickly generate .gitignore + file for your project. It uses the [gitignore.io](https://gitignore.io/) API. + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Phillip Wood and Andrew Ardill. diff --git a/_posts/2019-12-26-edition-58.markdown b/_posts/2019-12-26-edition-58.markdown new file mode 100644 index 000000000..fb22a4c80 --- /dev/null +++ b/_posts/2019-12-26-edition-58.markdown @@ -0,0 +1,181 @@ +--- +title: Git Rev News Edition 58 (December 25th, 2019) +layout: default +date: 2019-12-25 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 58 (December 25th, 2019) + +Welcome to the 58th 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](https://git.github.io). + +This edition covers what happened during the month of November 2019. + +## Discussions + + +### General + +* Two [Outreachy interns](https://www.outreachy.org/alums/) have been accepted to work on Git this winter + + * Heba W. from New Zealand will be mentored by Emily Shaffer and + Jonathan Tan to work on the '*Add "Did you mean?" hints*' + project. Heba started [blogging about her + internship](https://medium.com/@heba.waly). + + * Miriam Rubio from Barcelona, Spain will be mentored by Christian + Couder to work on the '*Finish converting "git bisect" from shell to + C*' project. Miriam also started [blogging about her internship](https://mirucam.gitlab.io/outreachy_blog/). + + +### Reviews + +* [[RFC] xl command for visualizing recent history](https://public-inbox.org/git/20191029003023.122196-1-matvore@google.com/) + + Matthew DeVore sent an RFC patch implementing a `git xl` command + that would show "a graph of recent history, including all existing + branches (unless flagged with a config option) and their upstream + counterparts". + + In practice the command would show graph like this one, where the + XXXXXXXX would be the beginning of a commit hash: + + ``` + XXXXXXXX * 1 committer@example.com [HEAD branch3] + | baz + | + XXXXXXXX | * 2 committer@example.com [branch2] + |/ bar + | + XXXXXXXX * 3 committer@example.com + foo + ``` + + The command would also associate refs with all visible + commits. These refs would have names in the form of `h/#` where # is + an incrementing count. + + It would by default show only what has not been pushed upstream yet, + and the branches with their commits would be shown as a graph. + + Emily Shaffer first replied to Matthew, making suggestions to + improve the name of the command as well as the commit subject and + the commit message. + + Johannes Schindelin, alias Dscho, replied to Emily's reply. He + agreed with her that the name of the command was not a good one and + suggested instead to make this functionality a mode of an existing + command, like `git show-branch --unpushed` or `git branch --show-unpushed`. + + About the `h/#` refs, that he called "ephemeral refs", Dscho + suggested implementing them in a separate patch, using `^` + instead of "h/#" for their syntax, and making them only available for + a "reasonably short time" by default, and then offering a config + setting to change this time. + + He also suggested implementing an option to show those "ephemeral + refs" in other commands too. + + Phillip Wood agreed with Dscho about the "ephemeral refs", especially + "having them as a feature of the rev listing machinery rather than + specific to a particular command". + He also suggested to use `getsid()` rather than `getppid()` to tie them + to a terminal, and expressed his uncertainty how this should be done + on Windows and whether a split was also necessary/wanted per worktree. + + Dscho also commented on Matthew's initial RFC patch. He suggested + commit message improvements. He reiterated some of the suggestions + he made in his reply to Emily, and reviewed the code suggesting many + changes there too. He wrote though that he loved the main ideas + proposed by Matthew. + + + + + +## Releases + ++ Git [2.24.1 and others](https://public-inbox.org/git/xmqqr21cqcn9.fsf@gitster-ct.c.googlers.com/) ++ Git for Windows [2.24.1(2)](https://github.com/git-for-windows/git/releases/tag/v2.24.1.windows.2) ++ libgit2 [0.28.4](https://github.com/libgit2/libgit2/releases/tag/v0.28.4) ++ libgit2sharp [0.26.2](https://github.com/libgit2/libgit2sharp/releases/tag/v0.26.2) ++ Bitbucket Server [6.9](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.1.2](https://www.gerritcodereview.com/3.1.html#312), +[3.0.6](https://www.gerritcodereview.com/3.0.html#306), +[2.16.15](https://www.gerritcodereview.com/2.16.html#21615), +[3.1.1](https://www.gerritcodereview.com/3.1.html#311), +[3.0.5](https://www.gerritcodereview.com/3.0.html#305), +[2.16.14](https://www.gerritcodereview.com/2.16.html#21614) ++ GitHub Enterprise [2.19.4](https://enterprise.github.com/releases/2.19.4/notes), +[2.18.9](https://enterprise.github.com/releases/2.18.9/notes), +[2.17.15](https://enterprise.github.com/releases/2.17.15/notes), +[2.16.24](https://enterprise.github.com/releases/2.16.24/notes), +[2.19.3](https://enterprise.github.com/releases/2.19.3/notes), +[2.18.8](https://enterprise.github.com/releases/2.18.8/notes), +[2.17.14](https://enterprise.github.com/releases/2.17.14/notes), +[2.16.23](https://enterprise.github.com/releases/2.16.23/notes), +[2.19.2](https://enterprise.github.com/releases/2.19.2/notes), +[2.18.7](https://enterprise.github.com/releases/2.18.7/notes), +[2.17.13](https://enterprise.github.com/releases/2.17.13/notes), +[2.16.22](https://enterprise.github.com/releases/2.16.22/notes) ++ GitLab [12.6](https://about.gitlab.com/blog/2019/12/22/gitlab-12-6-released/), +[12.5.5](https://about.gitlab.com/blog/2019/12/17/gitlab-12-5-5-released/), +[12.0.12, 12.1.17, and 12.2.12](https://about.gitlab.com/blog/2019/12/16/gitlab-12-2-12-release/), +[12.5.4, 12.4.6, and 12.3.9](https://about.gitlab.com/blog/2019/12/10/critical-security-release-gitlab-12-5-4-released/), +[12.5.3](https://about.gitlab.com/blog/2019/12/03/gitlab-12-5-3-released/), +[12.5.1](https://about.gitlab.com/blog/2019/11/27/security-release-gitlab-12-5-1-released/), +[12.5.2](https://about.gitlab.com/blog/2019/11/27/security-release-gitlab-12-5-2-released/), +[12.5](https://about.gitlab.com/blog/2019/11/22/gitlab-12-5-released/), +[12.4.3](https://about.gitlab.com/blog/2019/11/18/gitlab-12-4-3-released/) ++ GitKraken [6.4.1](https://support.gitkraken.com/release-notes/current), +[6.4.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.2.4](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + +* The latest [Git releases](https://lore.kernel.org/git/xmqqr21cqcn9.fsf@gitster-ct.c.googlers.com/) and + [Git for Windows releases](https://github.com/git-for-windows/git/releases/tag/v2.24.1.windows.2) + are security releases. They fix a significant number of serious + security issues. Upgrading to one of these new versions is highly + recommended. + +* The [Git Merge Contributor's Summit](https://lore.kernel.org/git/20191213050038.GA75792@coredump.intra.peff.net/) + has been announced. It will happen on March 5, 2020, in Los Angeles, + the day after the [Git Merge](https://git-merge.com/). + +__Light reading__ + +* [What are git objects under the hood](https://blog.alexlai.xyz/what-are-git-objects-under-the-hood/) + is a blog post about Git objects. + +* [Git Repository Transfer Keeping All History](https://itnext.io/git-repository-transfer-keeping-all-history-670fe04cd5e4) + by Nassos Michas explains "how to replicate your Git repo and keep + all previous commits, branches, and tags". + +__Git tools and sites__ + +* [GitVine](https://insanesharpness.gitlab.io/GitVine/), + an application to better visualise git commits has been + [announced on the mailing list](https://public-inbox.org/git/CAMNO-Ba0-Me67qEEfHoJyBoWg0X_x7=qmmZ1D8ZK9S_0Tk=J5Q@mail.gmail.com/). + +* [git-cpcover](https://public-inbox.org/git/20191203201233.661696-1-mst@redhat.com/), + a script to copy cover letters, has been announced on the mailing list. + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Emily Shaffer, Pratyush Yadav and Phillip Wood. diff --git a/_posts/2020-01-22-edition-59.markdown b/_posts/2020-01-22-edition-59.markdown new file mode 100644 index 000000000..6513790b0 --- /dev/null +++ b/_posts/2020-01-22-edition-59.markdown @@ -0,0 +1,158 @@ +--- +title: Git Rev News Edition 59 (January 22nd, 2020) +layout: default +date: 2020-01-22 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 59 (January 22nd, 2020) + +Welcome to the 59th 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](https://git.github.io). + +This edition covers what happened around the month of December 2019. + +## Discussions + + + + + +### Support + +* [Push a ref to a remote with many refs](https://public-inbox.org/git/CH2PR11MB429411CA1288526D21C7AF26CF4C0@CH2PR11MB4294.namprd11.prod.outlook.com/) + + Patrick Marlier sent an email about performance issues when pushing + from a local repository with a few refs to a remote repository with + a lot more refs (1000+) and Git objects. + + The local Git client receives the entire list of refs on the remote, + and then checks in its repository if the objects exist for all the + remote refs, but in Patrick's case most of the objects are unknown. + + As the local repository is using many [alternates](https://git-scm.com/docs/gitrepository-layout/#Documentation/gitrepository-layout.txt-objectsinfoalternates), + Git will try to find each unknown object in all the alternates which + amplifies the problem. To work around this Patrick showed a patch + that skips the refs that are not part of the push when looking for + objects. + + Jeff King, alias Peff, replied to Patrick that the behavior is + expected and that not looking at the refs which are not part of the + push could miss objects that are already in the remote repo, and + therefore result in pushing more objects than needed. + + Peff proposed an alternative patch that uses an `OBJECT_INFO_QUICK` + flag when checking if objects exist. That flag makes the check + faster but less thorough, which is ok in this case. + + Patrick then thanked Peff for the patch saying that he would try it, + and later replied with some numbers showing a median time decreasing + from 7 minutes and 38 seconds to 5 minutes and 40 seconds. Peff + replied to those numbers suggesting applying the patch to Git 2.21 + or higher, instead of Git 2.19, as a memory cache was introduced in + 2.21 that would further speed up the checks. + + In general it's a good idea to always use the most recent Git version + for maximum performance as improvements are regularly merged into + each new version. + + Meanwhile Junio Hamano, the Git maintainer wondered if improvements + could be made regarding the different flags that can be used when + checking objects. Peff replied that these flags have been coming up + in discussions "about once a month lately" and pointed to + [a previous analysis made by Jonathan Tan](https://public-inbox.org/git/20191011220822.154063-1-jonathantanmy@google.com/). + He also suggested some small changes in the flags according to the analysis. + + Jonathan Tan then chimed in to give his opinion about the flag issue + and mostly agreed with Peff's suggestion. Junio then also agreed + with Peff's and Jonathan's findings. + + Jonathan Nieder reviewed Peff's patch asking a few questions to make + sure he understood it properly. Peff then answered those questions + explaining a few more details. + + Peff's patch eventually got merged into the master branch and is + included in the recent Git 2.25 release. + + + +## Releases + ++ Git [2.25.0](https://public-inbox.org/git/xmqqtv4zjgv5.fsf@gitster-ct.c.googlers.com/), +[2.25.0-rc2](https://public-inbox.org/git/xmqq8smh1t3m.fsf@gitster-ct.c.googlers.com/), +[2.25.0-rc1](https://public-inbox.org/git/xmqqpng1cu2c.fsf@gitster-ct.c.googlers.com/), +[2.25.0-rc0](https://public-inbox.org/git/xmqqblrwm65l.fsf@gitster-ct.c.googlers.com/) ++ Git for Windows [2.25.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.25.0.windows.1) ++ GitHub Enterprise [2.19.5](https://enterprise.github.com/releases/2.19.5/notes), +[2.18.10](https://enterprise.github.com/releases/2.18.10/notes), +[2.17.16](https://enterprise.github.com/releases/2.17.16/notes), +[2.16.25](https://enterprise.github.com/releases/2.16.25/notes) ++ GitLab [12.6.4, 12.5.7, and 12.4.8](https://about.gitlab.com/releases/2020/01/13/critical-security-release-gitlab-12-dot-6-dot-4-released/), +[12.6.3](https://about.gitlab.com/releases/2020/01/09/gitlab-12-6-3-released/), +[12.6.2, 12.5.6, and 12.4.7](https://about.gitlab.com/releases/2020/01/02/security-release-gitlab-12-6-2-released/), +[12.6.1](https://about.gitlab.com/releases/2019/12/27/gitlab-12-6-1-released/) ++ Bitbucket Server [6.10](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) + +## Other News + +__Various__ + +* Registration for the Git Contributor Summit, on March 5, 2020, at + Los Angeles is now [open](https://public-inbox.org/git/20200115200532.GA4101552@coredump.intra.peff.net/). +* [Highlights from Git 2.25](https://github.blog/2020-01-13-highlights-from-git-2-25/) + by Taylor Blau on GitHub Blog +* [Git team releases 2.25, takes step towards Perl freedom](https://devclass.com/2020/01/14/git-team-releases-2-25-takes-step-towards-perl-freedom/) + by Julia Schmidt + + +__Light reading__ + +* [Bring your monorepo down to size with sparse-checkout](https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/) + by Derrick Stolee on GitHub Blog +* [Stage. Commit. Push. A Git Story (Comic)](https://dev.to/erikaheidi/stage-commit-push-a-git-story-comic-a37) + by Erika Heidi +* [6 handy Bash scripts for Git](https://opensource.com/article/20/1/bash-scripts-git) + by Bob Peterson: gitlog, gitlog.id, gitlog.grep, gitbranchcmp, gitlog.find,... +* [`git switch ` – Easily checkout git branches with this new command](https://bluecast.tech/blog/git-switch-branch/) + by Irshad Bluecast +* [Git tips for trunk-based development](https://dev.to/alediaferia/git-tips-for-trunk-based-development-1i1g) + by Alessandro Diaferia +* [Understanding delta file changes and merge conflicts in Git pull requests](https://devblogs.microsoft.com/devops/understanding-delta-file-changes-and-merge-conflicts-in-git-pull-requests/) + by Aram on Azure DevOps Blog + + +__Git tools and sites__ + +* [git-filter-repo](https://github.com/newren/git-filter-repo) v2.25.0 + has been [announced](https://public-inbox.org/git/CABPp-BFP38okGPTmyUJ-vVqq4=T0CypuyD05e6ArEfwhq2mdpg@mail.gmail.com/) + on the mailing list. + +* [git-cinnabar](https://github.com/glandium/git-cinnabar) 0.5.3 + has also been [announced](https://public-inbox.org/git/20200118024728.4dugot7nmj3tdkhx@glandium.org/) + on the mailing list. + +* [GitVine](https://insanesharpness.gitlab.io/GitVine/) by Insane Sharpness: + A simpler visualisation of Git Commits, inspired by Clearcase Version Tree. + _Not open-source_. + +* [GitAhead](https://gitahead.github.io/gitahead.com/) is a graphical Git client + for Windows, Linux and macOS designed to help you understand and manage + your source code history, by [SciTools™](https://scitools.com/). + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <>. diff --git a/_posts/2020-02-19-edition-60.markdown b/_posts/2020-02-19-edition-60.markdown new file mode 100644 index 000000000..0b75ec2c0 --- /dev/null +++ b/_posts/2020-02-19-edition-60.markdown @@ -0,0 +1,429 @@ +--- +title: Git Rev News Edition 60 (February 19th, 2020) +layout: default +date: 2020-02-19 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 60 (February 19th, 2020) + +Welcome to the 60th 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](https://git.github.io). + +This edition covers what happened during the month of January 2020. + +## The Pros and Cons of Reposurgeon (*written by [Eric S. Raymond](http://www.catb.org/~esr/)*) + +On January 12th 2020, the history of the GNU Compiler Collection was +lifted from Subversion to Git. At 280K commits, with a history +containing traces of two previous version-control systems (CVS and +RCS) this was the largest and most complex repository conversion of an +open-source project ever. It swamped the previous record-holder -- +Emacs's move from Bazaar to Git back in 2011 -- by an order of magnitude. + +Both those conversions were done by [reposurgeon](https://gitlab.com/esr/reposurgeon). +Neither of them could practically have been performed by any other +conversion tool available. This article will explain why that is, and +under what circumstances you might consider using reposurgeon +yourself. + +Let's start with a brief description of what reposurgeon actually +does. When you use it, you start by reading in a version-control +repository... but actually, that's not quite right. What reposurgeon +actually does is read in a git fast-import stream. It looks like it +reads repositories because it knows how to call front ends that use +exporters such as git-fast-export and cvs-fast-export to serialize a +repository for it. + +Actually, that's not quite right either. Subversion doesn't have an +exporter -- there is no svn-fast-export (well, not one that works for +more than trivial cases, anyway). Instead, reposurgeon reads the +native serialization produced by Subversion's svnadmin dump +tool. Internally, this is massaged into the equivalent of a git +fast-import stream and represented as one inside reposurgeon. + +There are reposurgeon-compatible exporters for RCS, CVS, bzr, hg, SRC, +bk, and of course git itself. With a little extra work using sccs2rcs +it's possible to reach all the way back to collections of SCCS files. + +Now that you've caught your repository, what can you do with it? + +I observed earlier that what you have, internally, is a deserialized +version of a git fast-input stream. A productive way to think about +what reposurgeon does is to remember that this is basically just a DAG +(directed acyclic graph) with text attached to the nodes. Now think of +reposurgeon as an editor for this graph and its nodes. Then, think of +it as a DSL (domain-specific language) designed to be *scripted* -- +that is, designed to reproducibly apply editing procedures to this +graph. + +So the general answer to "what can you do with it" is "anything you +want to". I enjoy thinking about and implementing DSLs, and once I had +the basic design idea it was pretty much inevitable that I was going +to write the most general set of primitives I could imagine -- and I +have a very fertile imagination. + +Elijah Newren's aside on reposurgeon in [Git Rev News 54](https://git.github.io/rev_news/2019/08/21/edition-54/) +described it as “GDB for history rewriting”. That's a pretty good +analogy, actually. Better than even I knew until recently, because it +turns out the Python Cmd library I originally used to write its +command interpreter was designed to emulate the interface style of gdb +and earlier symbolic debuggers. + +Accordingly, you can immediately use reposurgeon for a lot of +relatively simple tasks like (1) removing extremely bulky content that +shouldn't have been checked in, (2) partitioning and merging +repositories, (3) transcoding Latin-1 metadata to UTF-8, (4) +debubbling an unnecessary complex history to make reading it easier. + +Often, though, those things can be done with other tools like his +git-filter-repo. It's repository conversions for which you are likely +to actually *need* the full power of a domain-specific language +designed for repository surgery. + +Which brings us to how you write out your graph as a live +repository. Reposurgeon doesn't do that directly either. When it needs +to write out a repository, it hands a git fast-import stream to an +importer back end. That could be git fast-import itself, or the +corresponding importers for hg, bzr, darcs, bk, RCS, or SRC. + +Here's what reading in and immediately converting a small Subversion +dump would look like: + +```shell +$ reposurgeon +reposurgeon% read |<27860> reparent --use-order +# /branches/apple-200511-release-branch +<105446>|<105574> reparent --use-order +# /branches/apple-gcc_os_35-branch +<90334>|<90607> reparent --use-order +# /branches/apple-tiger-release-branch +<96593>|<96595> reparent --use-order +``` + +The GCC conversion was pretty hairy -- 343 lines of DSL scripting -- but +there are whole new levels of complexity when, as still sometimes +happens, you need to recover history from pre-version-controlled +sources to stitch the repository together. + +In [one extreme case](http://esr.ibiblio.org/?p=2491), I ended up +stitching together material from 18 different release tarballs, 11 +unreleased snapshot tarballs, one release tarball I could reconstruct, +one release tarball mined out of an obsolete Red Hat source RPM, two +shar archives, a pax archive, five published patches, two zip files, a +darcs archive, and a partial RCS history, + +But reposurgeon can handle this, because it make conversion +experiments easy. The workflow it's designed for is carefully building +a script that assembles your source repository and other data into a +simulacrum of what a Git repository tracking your project from the +beginning of time would have looked like. + +Almost never will you get this right the first time. It takes testing, +polishing, tripping over assumptions you didn't know you and your +tools were making, and correcting for those assumptions. In the GCC +case it took many hours of work to locate and develop fixes for the +misplaced branch joins. + +A subtle but important point is that I didn't do that work +myself. That kind of thing is not a job for reposurgeon's maintainer, +it's a job for a "Mr. Inside" who knows the project's history +intimately -- in this case it was actually the GCC project lead, Joseph +Myers. One of reposurgeon's requirements is that it has to be a tool +that a "Mr. Inside" can learn to use with minimum friction. + +And generally it is, if you're being driven to it by the kind of +problem it was designed to solve -- it's like gdb that way. I've been +taken to task about the tool having no intro documentation; this is +not because I'm lazy, it's because there's +[no plausible way to write any](http://esr.ibiblio.org/?p=8551), any +more than there is for gdb. You're ready to learn reposurgeon, as +Joseph Myers did, when you're stuck into a conversion or editing +problem so deep that the *very* complete +[reposurgeon command reference](http://www.catb.org/~esr/reposurgeon/reposurgeon.html) +starts to make sense to you. + +You can find more about conversions with reposurgeon +[here](http://www.catb.org/~esr/reposurgeon/dvcs-migration-guide.html). + +## Discussions + + + + + +### Support + +* [Broken branch after git commit](https://lore.kernel.org/git/07c84224bb0b093ab3770be9b5ab2ec23ce2d31a.camel@gmail.com/) + + Torsten Krah wrote that after using `git restore --staged $my-files` + to remove some files from the index, but not the working tree, and + then `git commit` to commit other changes, he found that the files + were marked as deleted in the index though they are still in the + working tree. + + He didn't understand what happened and didn't know how to fix the + situation. He later added that the `git commit` he had done had + actually committed the files even though `git status` told him that + the files wouldn't go into the commit. And he also sent instructions + to help reproduce the issue. + + Jeff King, alias Peff, replied to Torsten saying that he couldn't + reproduce the issue and asking for more details and examples. + + Torsten then sent an example with a lot more details which enabled + Peff to reproduce the issue. Peff confirmed that there was a bug in + `git restore` and also found that the index-reading code could + segfault when it processes bogus cache-trees. + + Peff also mentioned that Emily Shaffer had recently found a similar + segfault and that she had provided [a fix](https://lore.kernel.org/git/20200108023127.219429-1-emilyshaffer@google.com/), + and then came up with [a patch](https://lore.kernel.org/git/20200108114344.GA3380580@coredump.intra.peff.net/) + to fix the bug in `git restore --staged`. + + Junio Hamano, the Git maintainer, reviewed the patch and praised Peff, + while Dennis Kaarsemaker reported just being bitten by seemingly the + same bug. + + In the meantime Torsten also thanked Peff for investigating the + issue and asked for a way to fix his current index. Peff suggested + using `git reset --hard ` after finding the + original commit in the reflog. Torsten replied that he actually had + to remove the index using `rm .git/index` first to get back to a + working state. + +## Developer Spotlight: Chris Webster +* Who are you and what do you do? + + I am a retired software developer. After 25+ years in commercial + software development I wanted to contribute to open source. + Having used GNU Make and Perl extensively in a build system + I wanted to give back. GitGitGadget caught my attention when + I was contributing a fix to diff-highlight.pm in Git. + Dscho guided me through my many errors to get the change + approved. I decided to help with GitGitGadget to say thanks. + Fun/scary facts: Primary language -- IBM mainframe assembler, + Secondary language: C++. + +* What would you name your most important contribution to Git? + + My contributions are mainly to GitGitGadget and I think adding + the `/preview` command was really helpful. It only gets used + once by most new contributors to Git but it gives them a chance + to see what their change requests would look like. I hope seeing + the email gives these contributors the confidence to submit their + changes to the general Git community. It wasn't a big change but + it appears to get used by a lot of first time contributors. + +* What are you doing on the Git ecosystem these days, and why? + + I am still very much in learning mode. Working on GitGitGadget + provides an opportunity to work with modern TypeScript and + JavaScript features. There are some issues I would still like + to help with. Contributing more to Git is a next step. + Helping to make tools easier and more reliable is my motivation. + +* Can you briefly explain your user experience with Git so far? + + So far I have been mostly using Git from the command line and + only recently started to look at Git-GUI and gitk. This is a + stark contrast to my previous use of CM/Synergy and PVCS + where the GUI was used almost exclusively. Working on GitGitGadget + requires getting to know some of the plumbing of Git and GitHub, + which is interesting. For personal projects, most use is pretty basic. + +* Have you ever felt that something that you've used in other version + control software is missing from Git? + + VS Code shows a side-by-side diff for working objects. CM/Synergy + allowed a side-by-side diff for any versions of the objects. I have + not seen a way to do that. Sometimes it is easier to debug when you + have the complete source to see changes. + + ***Note**: Chris was told that `git difftool` might help him with getting + side-by-side diff in Git. He acknowledged the same stating "Difftool looks + like what I am looking for".* + +* What is your favorite Git-related tool/library, outside of Git itself? + + My answer should be GitGitGadget but I'm not really a user these + days -- need to be more of a contributor to Git to appreciate GitGitGadget. + VS Code is providing more Git specific tooling (i.e. Timeline view) that + looks really interesting along with the GitLens extension. + +## Releases + ++ Git [2.25.1](https://lore.kernel.org/git/xmqq36b9n2da.fsf@gitster-ct.c.googlers.com/) ++ GitLab [12.7.6](https://about.gitlab.com/releases/2020/02/13/critical-security-release-gitlab-12-dot-7-dot-6-released/), +[12.7.5](https://about.gitlab.com/releases/2020/01/31/gitlab-12-7-5-released/), +[12.7.4, 12.6.6, and 12.5.9](https://about.gitlab.com/releases/2020/01/30/security-release-gitlab-12-7-4-released/), +[12.7.2](https://about.gitlab.com/releases/2020/01/24/gitlab-12-7-2-released/), +[12.7](https://about.gitlab.com/releases/2020/01/22/gitlab-12-7-released/) ++ Bitbucket Server [6.10](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-6-10-release-notes-987140367.html) ++ Gerrit Code Review [3.1.3](https://www.gerritcodereview.com/3.1.html#313), +[3.0.7](https://www.gerritcodereview.com/3.0.html#307), +[2.16.16](https://www.gerritcodereview.com/2.16.html#21616), ++ GitHub Enterprise [2.20.0](https://enterprise.github.com/releases/2.20.0/notes), +[2.19.7](https://enterprise.github.com/releases/2.19.7/notes), +[2.18.12](https://enterprise.github.com/releases/2.18.12/notes), +[2.17.18](https://enterprise.github.com/releases/2.17.18/notes), +[2.19.6](https://enterprise.github.com/releases/2.19.6/notes), +[2.18.11](https://enterprise.github.com/releases/2.18.11/notes), +[2.17.17](https://enterprise.github.com/releases/2.17.17/notes) ++ GitKraken [6.5.1](https://support.gitkraken.com/release-notes/current), +[6.5.0](https://support.gitkraken.com/release-notes/current), ++ GitHub Desktop [2.3.1](https://desktop.github.com/release-notes/), +[2.3.0](https://desktop.github.com/release-notes/) ++ git-cinnabar [0.5.4](https://github.com/glandium/git-cinnabar/releases/tag/0.5.4) + +## Other News + +__Various__ + +* Heads-up for SSH users: as mentioned in [the release notes of OpenSSH v8.2](https://www.openssh.com/txt/release-8.2), the prevalent `ssh-rsa` keys will be disabled. If you use SSH with private keys depending on SHA-1, you will want to regenerate them soon. +* [REBASE: A complete Guide on Rebasing in Git](https://rebase-book.com/) + is a new less than 200 pages book from Pascal Precht (with a free sample). + +__Light reading__ + +* [The History of Git: The Road to Domination in Software Version Control](https://www.welcometothejungle.com/en/articles/btc-history-git) + was made using interviews and material from members of this + community, especially Linus Torvalds, Johannes Schindelin and Jeff King. +* Transitioning Git to SHA-256: + * [A new hash algorithm for Git [LWN.net]](https://lwn.net/Articles/811068/) by Jonathan Corbet. + * [Git takes baby steps towards swapping out vulnerable SHA-1 hashing algo for SHA-256](https://www.theregister.co.uk/2020/02/05/git_sha_256_work/) by Tim Anderson in The Register. + * [Bridging the gap: transitioning Git to SHA-256 - Git Merge 2019](https://www.youtube.com/watch?v=qHERDFUSa14) + video of Brian M. Carlson presentation at Git Merge 2019 + (event which was covered in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/#discussions) and [#49](https://git.github.io/rev_news/2019/03/20/edition-49/#other-news)). +* [Automating MySQL schema migrations with GitHub Actions and more](https://github.blog/2020-02-14-automating-mysql-schema-migrations-with-github-actions-and-more/) + by Shlomi Noach on GitHub Blog, using GitHub-developed [gh-ost](https://githubengineering.com/gh-ost-github-s-online-migration-tool-for-mysql), + an online table migration solution, and [skeema](https://www.skeema.io/) by Evan Elias, + an open source schema management utility. +* [Better tools for kernel developers [LWN.net]](https://lwn.net/Articles/811528/) + by Jonathan Corbet, about [posting of a simple tool called get-lore-mbox](https://lwn.net/ml/workflows/20200201030105.k6akvbjpmlpcuiky@chatter.i7.local/). +* In [Re: [Lsf-pc] [LSF/MM/BPF TOPIC] FS Maintainers Don't Scale](https://lwn.net/ml/linux-fsdevel/20200202214620.GA20628@dread.disaster.area/) + Dave Chinner writes on the need and usefulness of doing code review, + without being experienced in the area that the patch series cover. +* [Fedora gathering requirements for a Git forge [LWN.net]](https://lwn.net/Articles/810776/) + by Jake Edge, with three possibilities: GitHub, GitLab CE, and [Pagure](https://pagure.io/pagure) + (the last one was mentioned in [Git Rev News Edition #24 (February 22nd, 2017)](https://git.github.io/rev_news/2017/02/22/edition-24/#other-news)). +* ['Succinct Data Structure for Delta Encoding for Modern Databases'](https://github.com/terminusdb/terminus-server/blob/dev/docs/whitepaper/terminusdb.pdf) [PDF] + or How we built a Git for Data (and Learned to Stop Worrying and Love the Bomb) - + whitepaper about TerminusDB. +* [Lecture 6: Version Control (Git)](https://missing.csail.mit.edu/2020/version-control/) + is a part of "The Missing Semester of Your CS Education" class at MIT. +* [Weird Hobby: Scraped Git Histories](https://blog.afoolishmanifesto.com/posts/weird-hobby-scraped-git-histories/) by fREW Schmidt. +* [How to Bisect Perl](https://www.perlmonks.org/?node_id=11110663) on PerlMonks. +* [Commit Often, Perfect Later, Publish Once: Git Best Practices](http://sethrobertson.github.io/GitBestPractices/) + by Seth Robertson (2012). +* [🙏 Please Add .gitattributes To Your Git Repository - DEV Community](https://dev.to/deadlybyte/please-add-gitattributes-to-your-git-repository-1jld) by deadlybyte. +* [A guide on commit messages - DEV Community](https://dev.to/yvonnickfrin/a-guide-on-commit-messages-d8n) by Yvonnick Frin. +* [Stage. Commit. Push. A Git Story (Comic) - DEV Community](https://dev.to/erikaheidi/pick-squash-drop-rebase-comic-607) by Erika Heidi. +* [Git Commands – 10 Terminal Tricks Every Developer Should Know](https://www.freecodecamp.org/news/10-important-git-commands-that-every-developer-should-know/) by Cem Eygi. + + +__Git tools and sites__ + +* [git-repo](https://github.com/aliyun/git-repo-go) is a + reimplementation in Golang by [Alibaba Cloud](https://github.com/aliyun) of the + [Android repo tool](https://source.android.com/setup/develop/repo). +* [OneDev](https://github.com/theonedev/onedev) is an all-in-one DevOps platform, + with issue tracking, Git management, pull requests, and build farm; + written in Java. +* [Introducing Scalar: Git at scale for everyone](https://devblogs.microsoft.com/devops/introducing-scalar/). +* [chronologer](https://github.com/dandavison/chronologer): + visualize changes in program timing (performance) over git commit history; + uses [hyperfine](https://github.com/sharkdp/hyperfine) for the benchmarking. +* [skeema](https://www.skeema.io/) is an open source pure-SQL database + schema management system, with which you can diff, push, and pull + schemas. + There are various other tools to help version-control database schemas, + including: + * [Sqitch](https://sqitch.org/) is database-native change management + for framework-free development and dependable deployment. + * [Alembic](https://alembic.sqlalchemy.org/) is a lightweight database migration tool + for usage with the [SQLAlchemy](https://www.sqlalchemy.org/) Database Toolkit for Python. + * [Flyway](https://flywaydb.org/) by Redgate, + with Apache v2 licensed Community Edition version. + * [Liquibase](https://www.liquibase.org/) by Datical, + with free Liquibase Community edition. + +* [get-lore-mbox](https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/get-lore-mbox.py) + by Konstantin Ryabitsev is a Python script that given the message ID + for any email in a thread of interest; it will download the entire + thread from the [lore.kernel.org](https://lore.kernel.org/) archive + into a local mbox file, for an easy applying to git repository. +* [GitHub and Government](https://government.github.com/) is a site to + gather, curate, and feature stories of public servants and civic hackers + using GitHub as part of their open government innovations. +* [git-evtag](https://github.com/cgwalters/git-evtag): Extended verification for git tags, + that can be used as a replacement for `git-tag -s`. +* [shit](https://git.sr.ht/~sircmpwn/shit) (shit == Shell Git) is an implementation + of Git [plumbing] using (almost) entirely POSIX shell; more proof-of-concept + than a practical tool. +* [git-tfs](http://git-tfs.com/) is a two-way bridge between TFS and git, + similar to `git-svn`; no more actively maintained because the authors + are no longer users of TFS: + * [Why you should abandon TFS and adopt Git](https://www.continuousimprover.com/2015/06/why-you-should-abandon-tfs-source.html) + by Dennis Doomen (2015). + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Eric S. Raymond, Josh Steadmon and +Johannes Schindelin. diff --git a/_posts/2020-03-25-edition-61.markdown b/_posts/2020-03-25-edition-61.markdown new file mode 100644 index 000000000..e25f2d047 --- /dev/null +++ b/_posts/2020-03-25-edition-61.markdown @@ -0,0 +1,253 @@ +--- +title: Git Rev News Edition 61 (March 25th, 2020) +layout: default +date: 2020-03-25 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 61 (March 25th, 2020) + +Welcome to the 61st 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](https://git.github.io). + +This edition covers what happened during the month of February 2020. + +## Discussions + + +### General + +* [Git Merge 2020 conference](https://git-merge.com/) + + The Git Merge conference happened on March 4, 2020 in Los + Angeles. It was organized by GitHub and sponsored by GitHub, GitLab + and the [Software Freedom Conservancy](https://sfconservancy.org/). + + Over 300 people attended. Some people didn't attend, and some talks + had to be changed at the last minute due to coronavirus related + reasons. + + On the wall [a big timeline](/images/git_merge_2020_timeline.jpg) + mentioned some important events in Git history. + + There was a party in the evening with + [a big cake dedicated to Git's 15th anniversary](/images/git_merge_2020_cake.jpg). + +* [Git Contributor Summit](https://lore.kernel.org/git/AC2EB721-2979-43FD-922D-C5076A57F24B@jramsay.com.au/) + + The Git Contributor Summit happened on March 5, 2020 in Los Angeles, + the day after the Git Merge conference. The event was also organized + by GitHub. + + There were 26 people attending physically and 5 people attending + remotely. + + As usual it was an unconference where people wrote topics on a + whiteboard during the breakfast and then voted on them by putting a + tick-mark on the board. The topics were then discussed during the + day roughly from the most voted on to the less voted on. + + [Notes](https://lore.kernel.org/git/AC2EB721-2979-43FD-922D-C5076A57F24B@jramsay.com.au/) + have been taken collaboratively and sent to the mailing list + afterwards. + +* [AGit-Flow and git-repo](https://git-repo.info/en/2020/03/agit-flow-and-git-repo/) (*written by Jiang Xin*) + + [AGit-Flow and git-repo](https://git-repo.info/en/2020/03/agit-flow-and-git-repo/) + is a blog post on a missing speech from Git + Merge 2020. Jiang Xin, a developer at Alibaba China, had planned to + speak at the Git Merge 2020 conference, but canceled his flight due + to a coronavirus outbreak in China. He wrote this blog post about the + topic he wanted to present at the conference. + + In this blog post, he introduces a centralized workflow (named AGit-Flow) + implemented at Alibaba, and an Open Source command-line tool "git-repo", + which is hosted on GitHub: + [https://github.com/alibaba/git-repo-go](https://github.com/alibaba/git-repo-go). + The tool is not bound to a single protocol or a single server. It is + extensible and can run on Gerrit, AGit-Flow or other compatible protocols. + + The implementation of AGit-Flow has been contributed to + [the Git mailing list](https://public-inbox.org/git/20200304113312.34229-1-zhiyou.jx@alibaba-inc.com/), + and this feature is under code review. Junio stated that the proposed name of + the new hook was inappropriate. Therefore, after a code review of these + patches, expect some updates on the blog post. + + + + + +## Developer Spotlight: Christian Couder + +* Who are you and what do you do? + + In the Git community I am a contributor since 2006, a member of the + PLC (the "Project Leadership Committee" which represents Git in the + [Conservancy](https://sfconservancy.org/)) since a few years ago and a + Git Rev News editor since exactly 5 years ago when it started! I also + regularly mentor or co-mentor GSoC students or Outreachy interns, and + sometimes give presentations about Git at conferences. + + My current job title is Senior Backend Engineer in the Gitaly team at + GitLab. I have been working full time for GitLab since October last + year. Previously since October 2015 I was freelancing for GitLab, + Booking.com and Protocol Labs. + + I am very happy that GitLab supports my involvement in Git and the Git + community. At GitLab I am involved in development activities, and a + bit in support, marketing, community relations and sometimes even + sales, around Git. + + As a hobby I am singing in a choir and with a teacher. I also enjoy + time with my 3 teenager kids. + +* What would you name your most important contribution to Git? + + I think the improvements I contributed to `git bisect` around + 2007-2008 helped the Linux kernel community and gave Git an additional + edge. At that time it was not clear that Git was going to overcome + other version control systems. + + Also around 2008 I co-mentored for the first time a GSoC student + working on the sequencer which has become more and more useful as it's + now the default underlying engine behind `git rebase`. + + More recently I am happy that my patches to make it possible to have + more than one promisor remote have been merged. I think it's an + interesting way to improve performance and to broaden usage. + +* What are you doing on the Git ecosystem these days, and why? + + My time is spent on probably too many different things, like GSoC or + Outreachy, Git Rev News, PLC, GitLab activities, improving partial + clone, helping with getting GitHub patches merged upstream. + +* 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? + + Right now I think it would be a good time to work on specialized + drivers/helpers for additional promisor remotes, and on improving + partial clone. I am glad though that the main companies contributing + to Git have already asked their developers to focus on improving + partial clone. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + I think I would streamline as much as possible what's in the Git repo. + That is I would remove git-gui, gitk, gitweb, git-svn, git-p4, + contrib/ and even the Git test framework, which could perhaps be + merged with [Sharness](https://github.com/chriscool/sharness/). These + related tools could live in their own repo but still be discussed on + the mailing list and automatically be released at the same time as + Git. It would be a significant amount of work to set this up properly, + but then new Git related tools, like git-filter-repo or git-subtrac, + and perhaps old tools too could probably better find their place in + the ecosystem. + +* What is your favorite Git-related tool/library, outside of Git itself? + + In 2016 I became the maintainer of + [Sharness](https://github.com/chriscool/sharness/) which was extracted + from the Git test framework in 2011. I have thought for a long time + that the Git test framework has helped tremendously in keeping the + amount of regressions and bugs in Git very low. I don't have much time + to take care of Sharness, but I think it can still help a lot. + +## Releases + ++ Git [2.26.0](https://public-inbox.org/git/xmqqa7477u6j.fsf@gitster.c.googlers.com/), +[2.25.2](https://public-inbox.org/git/xmqqeetqh6fp.fsf@gitster.c.googlers.com/), +[2.26.0-rc2](https://public-inbox.org/git/xmqqa74fj30p.fsf@gitster.c.googlers.com/), +[2.26.0-rc1](https://public-inbox.org/git/xmqqo8t4z29k.fsf@gitster-ct.c.googlers.com/), +[2.26.0-rc0](https://public-inbox.org/git/xmqq5zfi4g0p.fsf@gitster-ct.c.googlers.com/) ++ Git for Windows [2.26.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.26.0.windows.1) ++ Bitbucket Server [7.0](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [2.16.17](https://www.gerritcodereview.com/2.16.html#21617) ++ GitHub Enterprise [2.20.3](https://enterprise.github.com/releases/2.20.3/notes), +[2.20.2](https://enterprise.github.com/releases/2.20.2/notes), +[2.19.9](https://enterprise.github.com/releases/2.19.9/notes), +[2.18.14](https://enterprise.github.com/releases/2.18.14/notes), +[2.17.20](https://enterprise.github.com/releases/2.17.20/notes), +[2.20.1](https://enterprise.github.com/releases/2.20.1/notes), +[2.19.8](https://enterprise.github.com/releases/2.19.8/notes), +[2.18.13](https://enterprise.github.com/releases/2.18.13/notes), +[2.17.19](https://enterprise.github.com/releases/2.17.19/notes) ++ GitLab [12.9](https://about.gitlab.com/releases/2020/03/22/gitlab-12-9-released/), +[12.8.7](https://about.gitlab.com/releases/2020/03/16/gitlab-12-8-7-released/), +[12.8.6](https://about.gitlab.com/releases/2020/03/11/critical-security-release-gitlab-12-dot-8-dot-6-released/), +[12.8.5](https://about.gitlab.com/releases/2020/03/09/gitlab-12-8-5-released/), +[12.8.2](https://about.gitlab.com/releases/2020/03/04/gitlab-12-dot-8-dot-2-released/), +[12.8.1](https://about.gitlab.com/releases/2020/02/24/gitlab-12-8-1-released/), +[12.8](https://about.gitlab.com/releases/2020/02/22/gitlab-12-8-released/) ++ GitKraken [6.5.4](https://support.gitkraken.com/release-notes/current), +[6.5.3](https://support.gitkraken.com/release-notes/current), +[6.5.2](https://support.gitkraken.com/release-notes/current) + +## Other News + +__Various__ + +* [Outreachy](https://www.outreachy.org/) winter internships + finished. Both Heba Waly and Miriam Rubio successfully finished + their Outreachy internships. Miriam posted + [a final blog post](https://mirucam.gitlab.io/outreachy_blog/post/week13/) + about it. +* Git has been selected as a + [Google Summer of Code 2020](https://summerofcode.withgoogle.com/) + mentor organization. Students willing to participate need to apply + online until March 31. +* [Tower for Teachers & Universities](https://www.git-tower.com/education/): + Teachers and universities get free access to Tower "Pro" Git GUI. + +__Light reading__ + +* Derrick Stolee's slides for his "Git at Scale for Everyone" talk + during the Git Merge 2020 conference are [available](https://stolee.dev/docs/git-merge-2020.pdf). +* Elijah Newren's slides for his "Scaling the Merge Machinery" talk + during the Git Merge 2020 conference are [available](https://github.com/newren/presentations/blob/pdfs/merge-performance/merge-performance-slides.pdf) + in his personal notes and presentations repository. + Steps to reproduce the speedups he got can be found [here](https://github.com/newren/git/blob/git-merge-2020-demo/README.md). +* [Graph operations in Git, and how to make them faster](https://speakerdeck.com/jnareb/graph-operations-in-git-and-how-to-make-them-faster) presentation slides by Jakub Narębski on SpeakerDeck; also available on [SlideShare](https://www.slideshare.net/JakubNarbski/graph-operations-in-git-version-control-system-how-the-performance-was-improved-for-large-repositories-how-can-it-be-further-improved) and as [PDF file](https://drive.google.com/open?id=1psMBVfcRHcZeJ7AewGpdoymrEfFVdXoK). + +* [Highlights from Git 2.26](https://github.blog/2020-03-22-highlights-from-git-2-26/) by Taylor Blau on GitHub Blog +* [Git moves to new defaults in 2.26 release](https://devclass.com/2020/03/23/git-moves-to-new-defaults-in-2-26-release/) by Julia Schmidt, about version 2 of the transport protocol, backend used by `git rebase`, etc. +* [How Git Partial Clone lets you fetch only the large file you need](https://about.gitlab.com/blog/2020/03/13/partial-clone-for-massive-repositories/) by James Ramsay on GitLab Blog. +* [Make advanced Git tasks simple with Lazygit: 5 ways to harness the power of git with the Lazygit terminal UI](https://opensource.com/article/20/3/lazygit) by Jesse Duffield. + [Lazygit](https://github.com/jesseduffield/lazygit) was mentioned in [Git Rev News Edition #42 (August 22nd, 2018)](https://git.github.io/rev_news/2018/08/22/edition-42/). +* [Introducing b4 and patch attestation](https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation) by Konstantin Ryabitsev. + The [b4 tool](https://git.kernel.org/pub/scm/utils/b4/b4.git) started out as `get-lore-mbox`; + the latter was mentioned in [Git Rev News Edition #60 (February 19th, 2020)](https://git.github.io/rev_news/2020/02/19/edition-60/#other-news). + * [Attestation for kernel patches [LWN.net]](https://lwn.net/Articles/813646/) by Jonathan Corbet. +* [Please stop recommending Git Flow!](https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/) by George Stocker (Git Flow branching model was popularized by blog post entitled [A Successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/)). + * [The problem with Git flow: Learn why Git flow complicates the lifecycle and discover an alternative to streamline development](https://about.gitlab.com/blog/2020/03/05/what-is-gitlab-flow/) by Suri Patel on GitLab Blog. +* [A Beginner’s Guide to Git -- How to Write a Good Commit Message](https://www.freecodecamp.org/news/a-beginners-guide-to-git-how-to-write-a-good-commit-message/) by Gaël Thomas. +* [10 Git Techniques You Need to Know Before You Join a Team](https://www.sitepoint.com/git-techniques-to-know-before-you-join-a-team/) by Shaumik Daityari on Sitepoint. +* [Feature Flags and GitOps. 5 Use Cases to Help You ‘Git’r Done.](https://dev.to/cloudbees/feature-flags-and-gitops-5-use-cases-to-help-you-git-r-done-45ga) by Kristin Baskett of CloudBees. + The idea of [GitOps](https://www.cloudbees.com/blog/gitops-dev-dash-ops) was mentioned in + [Git Rev News Edition #42 (August 22nd, 2018)](https://git.github.io/rev_news/2018/08/22/edition-42/) and [#43](https://git.github.io/rev_news/2018/09/19/edition-43/). +* [Microsoft’s Scalar speeds up Git](https://www.infoworld.com/article/3528008/microsofts-scalar-speeds-up-git.html) by Paul Krill in InfoWorld. + [Scalar](https://github.com/microsoft/scalar/) was mentioned in [Git Rev News Edition #60 (February 19th, 2020)](https://git.github.io/rev_news/2020/02/19/edition-60/). + +__Git tools and sites__ + +* [Scalar](https://github.com/microsoft/scalar/) by Microsoft is a set of tools, settings and extensions for Git to help manage large Git repositories. +* [bash-git-prompt](https://github.com/magicmonty/bash-git-prompt): an informative and fancy bash prompt for Git users, a port of the "[Informative git prompt for zsh](https://github.com/olivierverdier/zsh-git-prompt)". +* [showthedocs](http://showthedocs.com/) is a both a syntax highlighter and a documentation browser that finds the relevant docs for your code. Given code, it parses and highlights it, and makes it possible to jump directly to the place in the docs where an item is explained. Includes support for the [gitconfig](https://git-scm.com/docs/git-config) "language". +* [//grep.app](https://grep.app/): Search across a half million git repos, currently public repositories on GitHub; you can search by regular expression, using the RE2 syntax. + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Jiang Xin and Nuritzi Sanchez. diff --git a/_posts/2020-04-23-edition-62.markdown b/_posts/2020-04-23-edition-62.markdown new file mode 100644 index 000000000..3477f4913 --- /dev/null +++ b/_posts/2020-04-23-edition-62.markdown @@ -0,0 +1,301 @@ +--- +title: Git Rev News Edition 62 (April 23rd, 2020) +layout: default +date: 2020-04-23 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 62 (April 23rd, 2020) + +Welcome to the 62nd 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](https://git.github.io). + +This edition covers what happened during the month of March 2020. + +## Discussions + +### General + +* [Happy birthday to all of us ;-)](https://lore.kernel.org/git/xmqqzhbmpyh6.fsf@gitster.c.googlers.com/) + + On April 7, Junio Hamano, the Git maintainer, sent a happy birthday + message to the mailing list to celebrate that "it was today 15 years + ago that Linus announced the availability of the first tarball of + Git". + + Junio thanked the contributors and everyone in the ecosystem, + including people from the [Software Freedom Conservancy](https://sfconservancy.org/) + and employers of contributors. + + His email ended with "Thanks all, and let's look forward to see the + next 15 years be as wonderful years for Git as the past 15 years + ;-)" + + A number of people replied especially thanking Junio for his work as + the maintainer of the project. Edward Thomson, who is a maintainer + of [libgit2](https://libgit2.org/), also thanked everyone, on behalf + of libgit2. + + Let's all also thank Junio, Linus and every contributor in the Git + ecosystem! + + + +### Support + +* [Regression in v2.26.0-rc0 and Magit](https://lore.kernel.org/git/3091652.KAqcNXvZJ4@cayenne/) + + Jean-Noël Avila reported to the mailing list that git version + 2.26.0-rc0 segfaulted under Magit with auto-revert enabled. + + [Magit](https://magit.vc/) is a popular Emacs interface to Git, and + the [auto-revert mode](https://magit.vc/manual/magit/Automatic-Reverting-of-File_002dVisiting-Buffers.html) + lets Emacs revert files that have changed on disk when a Git command + has been run outside of Emacs. + + Jean-Noël had bisected the issue to a commit that was improving the + error message which Git issues when it dies due to processing a path + outside the repository. This commit though didn't consider the + case of a bare repo which triggered the segfault. + + Jonathan Nieder replied that the bug was fixed by another commit by + Emily Shaffer that had not yet made it to the master branch. He + asked Junio Hamano, the Git maintainer, if the commit could be + fast-tracked, and Emily if she could add a test to her commit. + + Junio replied suggesting that a few tests should be added, and that + there were a few days left before v2.26.0-rc2 to add them. The next + day though Junio replied to himself with a patch adding the tests + and asking for comments. + + Jonathan Nieder reviewed Junio's tests adding his "Reviewed-by:", + and said that Emily was out of office so they were well timed. + + Junio replied to himself again discussing one test he wrote that + tested that both `git log -- ..` and `git ls-files -- ..` fail when + the current working directory is the `.git` directory. + + He wondered why, if "." instead of ".." is used in the above + commands, Git should behave as if the current working directory was + the top-level of the working tree instead of `.git`, and why Magit + is expecting `cd .git && git ls-files ..` to show the entire working + tree. + + Kyle Meyer replied to Junio that internally Magit's call which + triggered the bug is running `git ls-files` from `.git` to ask + whether the file used to edit a commit message is actually tracked, + as it makes no distinction between files in .git and in the working + tree. He said that he would propose a change in Magit to improve + this. + + Gábor Szeder also replied to Junio's patch suggesting a small + improvement in the tests which Junio accepted sending an improved + patch. + + The fix with Emily's code and Junio's tests was then merged into + v2.26.0-rc2. + +## Developer Spotlight: Eric S. Raymond + +* Who are you and what do you do? + + I've been an open-source hacker since long before that term was coined. + Back around the turn of the century I wrote "The Cathedral and the + Bazaar", which helped reinvent the movement and gained it mainstream + acceptance. I'm also the author of "The Art of Unix + Programming". More recently I've headed the + [GPSD](https://gpsd.gitlab.io/gpsd/index.html) and + [NTPsec](https://www.ntpsec.org/) projects. My most Git-relevant work + is [reposugeon](http://www.catb.org/esr/reposurgeon/). + +* You've recently gifted us with an [article about reposurgeon on Git + Rev News edition 60](https://git.github.io/rev_news/2020/02/19/edition-60/#the-pros-and-cons-of-reposurgeon-written-by-eric-s-raymond), + is there something you would like to add about reposurgeon, + its history, or the article? + + Probably the most interesting additional thing I can say is that I + discovered a fundamental strategy for designing good DSLs + (Domain-Specific Languages) while working on reposurgeon. + + Here it is: Whatever domain you're trying to capture, first develop + a way to do that capture in a declarative markup. Then write an + editor for that markup, and you will implicitly have a DSL that + spans the domain. It's rather like the mathematical concept + of a functor. + + In reposurgeon's case, the domain is Git repositories and the + declarative markup is fast-import streams. Reposurgeon is all + about exploiting that equivalence. + +* You used reposurgeon to migrate the GCC repository, which has about + 280K commits, from SVN to Git. Can you tell us a bit more about the + context in which such migrations happen. Like what are the timelines, + goals, tools, people, etc involved in such migrations? + + I've already written about this in some detail + [here](http://www.catb.org/~esr/reposurgeon/dvcs-migration-guide.html). + I'm going to be reworking that over the next couple of weeks based in + part on the GCC experience and in part to reflect the unfortunate + fact that Mercurial isn't really a contender any more. + + One thing that has been on my mind recently is the importance of + having a "Mr. Inside". The ideal team to do a major conversion pairs + a reposurgeon expert (Mr. Outside) with a project member who knows the + history of the repository intimately, can make policy decisions, and + is willing to learn enough about reposurgeon to edit the recipe. + + On GCC we had the ideal situation - the project lead chose to be + Mr. Inside. And a good thing, too - this conversion was *difficult*. + +* Can you describe how Git is related to reposurgeon, other software you + have been working on and your work in general? + + Reposurgeon depends on the leverage offered by git fast-import streams. + It uses them as an interchange format between different version-control + streams. Conversely, Reposurgeon (and a front-end I also maintain, + cvs-fast-export) enables higher-quality migrations from older VCSes + than anyone has ever been able to do before. + + As for how it relates to my other work, there is + [cvs-fast-export](http://www.catb.org/esr/cvs-fast-export/). I didn't + write the crucial analysis parts of cvs-fast-export myself; Keith + Packard of X fame did that, it used to be called cvsparse. I did + rescue it and give it the ability to emit a fast-import stream, + because reposurgeon needed a better CVS importer than I could find + elsewhere. + + More generally, I love writing DSLs and will take pretty much any + opportunity to do that. I have especially enjoyed inventing and + working on reposurgeon because - well, I used to be a mathematician. + I *like* working on things where graph theory and abstract algebra are + important. Reposurgeon scratches that itch. + +* What is something about Git or its ecosystem that you admire? + + How freaking *comprehensive* it is. Pretty much anything you can + imagine wanting to do with a version-control history there is tool + support for somewhere. + +* 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? + + That's easy. I'd port it to Go and toss out the C code. C still has + its uses, but for anything without hard latency requirements C is now + obsolete. Not something I would have said even three years ago, but + times change. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + There's a weird feature I've forgotten the name of where you can pass + around binary pack files rather than MRs or patches. Ah, git bundles, + that's it. Having worked with it once, I hate the lack of + transparency, that you can't easily eyeball a bundle before you apply + it. I'd shoot that feature through the head in a heartbeat. + + If I pick one thing to *fix* rather than remove without worrying about + backwards compatibility, it would be git-cvsimport. That thing is + very badly broken; the engine it uses misplaces branch joins. The Git + devs know it's broken but have stuck to it because of an + incremental-conversion feature that I think is effectively + useless. They should scrap it and rewrite the CVS import procedure to + use cvs-fast-export instead. + +* What is your favorite Git-related tool/library, outside of Git itself? + + You mean other than the ones I've written myself? I don't think I + have one, sorry. + +## Releases + ++ Git [2.26.2 and others](https://public-inbox.org/git/xmqq4kterq5s.fsf@gitster.c.googlers.com/), +[2.26.1 and others](https://public-inbox.org/git/xmqqy2qy7xn8.fsf@gitster.c.googlers.com/) ++ Git for Windows [2.26.2(1)](https://github.com/git-for-windows/git/releases/tag/v2.26.2.windows.1), +[2.26.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.26.1.windows.1) ++ libgit2 [1.0.0](https://github.com/libgit2/libgit2/releases/tag/v1.0.0) ++ Gerrit Code Review [3.1.4](https://www.gerritcodereview.com/3.1.html#314), +[3.0.8](https://www.gerritcodereview.com/3.0.html#308) ++ GitHub Enterprise [2.20.5](https://enterprise.github.com/releases/2.20.5/notes), +[2.19.11](https://enterprise.github.com/releases/2.19.11/notes), +[2.18.16](https://enterprise.github.com/releases/2.18.16/notes), +[2.17.22](https://enterprise.github.com/releases/2.17.22/notes), +[2.20.4](https://enterprise.github.com/releases/2.20.4/notes), +[2.19.10](https://enterprise.github.com/releases/2.19.10/notes), +[2.18.15](https://enterprise.github.com/releases/2.18.15/notes), +[2.17.21](https://enterprise.github.com/releases/2.17.21/notes) ++ GitLab GitLab [12.10](https://about.gitlab.com/releases/2020/04/22/gitlab-12-10-released/), +[12.9.4](https://about.gitlab.com/releases/2020/04/20/gitlab-12-9-4-released/), +[12.9.3, 12.8.9, and 12.7.9](https://about.gitlab.com/releases/2020/04/14/critical-security-release-gitlab-12-dot-9-dot-3-released/), +[12.9.2](https://about.gitlab.com/releases/2020/03/31/gitlab-12-9-2-released/), +[12.9.1](https://about.gitlab.com/releases/2020/03/26/security-release-12-dot-9-dot-1-released/) ++ Bitbucket Server [7.1](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitHub Desktop [2.4.1](https://desktop.github.com/release-notes/), +[2.4.0](https://desktop.github.com/release-notes/) ++ GitKraken [6.6.0](https://support.gitkraken.com/release-notes/current) + +## Other News + +__Various__ + +* [Peff interviewed Junio](https://github.blog/2020-04-07-celebrating-15-years-of-git-an-interview-with-git-maintainer-junio-hamano/) + on the GitHub Blog to celebrate Git’s 15th anniversary. + An interview with Git creator Linus Torvalds on Git's 10th anniversary [can be found](https://www.linux.com/news/10-years-git-interview-git-creator-linus-torvalds/) + in [Git Rev News #2 (April 15th, 2015)](https://git.github.io/rev_news/2015/04/05/edition-2/). +* [Git credential helper vulnerability announced](https://github.blog/2020-04-14-git-credential-helper-vulnerability-announced/) + by Taylor Blau on GitHub Blog -- please upgrade to [2.26.2](https://public-inbox.org/git/xmqq4kterq5s.fsf@gitster.c.googlers.com/) which fixes the mentioned vulnerability and yet another related vulnerability. +* [GitHub sharply slashes plan pricing, offers core features for free to all](https://arstechnica.com/gadgets/2020/04/github-sharply-slashes-plan-pricing-offers-core-features-for-free-to-all/). +* [GitLab moves 18 features to open source](https://about.gitlab.com/blog/2020/03/30/new-features-to-core/). + +__Light reading__ + +* [GitLab: Our ultimate guide to Git](https://about.gitlab.com/blog/2020/04/20/ultimate-git-guide/). + Tagline: "Open source pioneer Git is 15 years old. Here is our guide to making the most of it." +* [15 years of Git: How to get started or learn something new](https://opensource.com/article/20/4/get-started-git) + by Seth Kenlon (Red Hat) on [Opensource.com](https://opensource.com). +* [4 Git scripts I can't live without](https://opensource.com/article/20/4/git-extras) + by Vince Power on Opensource.com. The scripts can be found in the [git-extras](https://github.com/tj/git-extras) project. +* [Optimizing Git For Ryzen CPUs (1.5x Faster)](https://docs.keydb.dev/blog/2020/04/08/blog-post/), + utilizing Intel's SHA-NI instruction set to speed up SHA-1, by John Sully. +* [Create web tutorials with Reveal.js and Git](https://opensource.com/article/20/4/create-web-tutorial-git) by Eric D. Schabell (Red Hat). +* [Using a self-rewriting README powered by GitHub Actions to track TILs (Today I Learneds)](https://simonwillison.net/2020/Apr/20/self-rewriting-readme/) + by Simon Willison. +* [GitOps - A Security Perspective (Part 1)](https://dev.to/alcide/gitops-a-security-perspective-part-1-16ci) + by Gadi Naor of Alcide. [GitOps](https://www.gitops.tech/) is a paradigm that puts Git + at the heart of building and operating cloud native applications + by using Git as the single source of truth. +* [Computer Science Visualized: Useful Git Commands](https://dev.to/lydiahallie/cs-visualized-useful-git-commands-37p1) + by Lydia Hallie. +* [How To Make Life Easier When Using Git](https://www.smashingmagazine.com/make-life-easier-when-using-git/) + by Shane Hudson. +* [A Beginner’s Guide to Git — What is a Changelog and How to Generate it](https://www.freecodecamp.org/news/a-beginners-guide-to-git-what-is-a-changelog-and-how-to-generate-it/) + by Gaël Thomas. +* [Setting Up Git Identities](https://www.micah.soy/posts/setting-up-git-identities/) by Micah Henning, + with use of a Git alias to switch identities. +* [Maintaining Different Git Identities](https://dev.to/maxlmator/maintaining-different-git-identities) + by Max Kleucker (2018), with help of Git's "[conditional includes](https://git-scm.com/docs/git-config#_conditional_includes)". +* [The phases of remote adaptation](https://about.gitlab.com/company/culture/all-remote/phases-of-remote-adaptation/) + is a list of phases for teams switching from a colocated environment to a remote one put together by GitLab. + +__Git tools and sites__ + +* [Git Extras](https://github.com/tj/git-extras): shell Git utilities for repo summary, repl, changelog population, author commit percentages and more, by TJ Holowaychuk. +* [Ovid / git-workflow](https://github.com/Ovid/git-workflow) contains a simplified subset of the git tools used by [All Around the World](https://allaroundtheworld.fr/) organization. +* [Dolt](https://github.com/liquidata-inc/dolt) is Git for data, versioning tables: a database with branches. + [DoltHub](https://www.dolthub.com/) is a place on the internet to share Dolt repositories. +* [GitFiend](https://gitfiend.com/) by Toby Suggate is a new Git client for Windows, Mac and Linux, + deliberately not trying to follow in the footsteps of other Git clients. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Eric S. Raymond, Junio Hamano and Philip Oakley. diff --git a/_posts/2020-05-28-edition-63.markdown b/_posts/2020-05-28-edition-63.markdown new file mode 100644 index 000000000..bdc95d112 --- /dev/null +++ b/_posts/2020-05-28-edition-63.markdown @@ -0,0 +1,264 @@ +--- +title: Git Rev News Edition 63 (May 28th, 2020) +layout: default +date: 2020-05-28 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 63 (May 28th, 2020) + +Welcome to the 63rd 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](https://git.github.io). + +This edition covers what happened during the month of April 2020. + +## Discussions + +### General + +* [GSoC 2020 Students and Projects](https://lore.kernel.org/git/CAP8UFD1iBxiOZ_OA4DbMF9Kx2UHL15TPygoX6x-JrDGuReG1Vw@mail.gmail.com/) + + The following three students have been officially accepted to work on Git + as part of the [GSoC (Google Summer of Code) 2020](https://summerofcode.withgoogle.com/): + + - Abhishek Kumar will work on + [Implement Generation Number v2](https://summerofcode.withgoogle.com/projects/#6140278689234944). + He will be co-mentored by Jakub Narebski and Derrick Stolee. + More information is available on his + [proposal](https://lore.kernel.org/git/20200326101520.GA19326@Abhishek-Arch/) + and [blog](https://abhishekkumar2718.github.io/blog). + + - Hariom Verma will work on + [Unify ref-filter formats with other \-\-pretty formats](https://summerofcode.withgoogle.com/projects/#4593212745842688). + He will be co-mentored by Heba Waly and Christian Couder. + More information is available on his + [proposal](https://lore.kernel.org/git/CA+CkUQ966swTrR7D2vxgQ2ZA3E=Le=u8yvEAopOsphoCWGgDeg@mail.gmail.com/) + and [blog](https://harry-hov.github.io/blogs/posts/). + + - Shourya Shukla will work on + [Convert submodule to builtin](https://summerofcode.withgoogle.com/projects/#6451304047575040). + He will be co-mentored by Kaartic Sivaraam and Christian Couder. + More information is available on his + [proposal](https://lore.kernel.org/git/20200325185053.10274-1-shouryashukla.oo@gmail.com/) + and [blog](https://shouryashukla.blogspot.com/). + + It will be the 13th Summer that the Git project will mentor students + as part of the GSoC. Shourya, Hariom and Abhishek will be the 30th, + 31st and 32nd students mentored since 2007 when Git started + participating in the GSoC. + + It will be the 16th year of the GSoC, but unfortunately because of + the current sanitary situation in the world, there will be no GSoC + Mentor Summit, and no swag will be sent to participants this year. + +### Reviews + +* [remote.c: fix handling of push:remote_ref](https://lore.kernel.org/git/20200228172455.1734888-1-damien.olivier.robert+git@gmail.com/) + + Last February Damien Robert sent a patch to change how + 'ref-filter.c' interprets `%(push:remoteref)`. + + Damien had already sent [a patch](https://lore.kernel.org/git/20190417081754.bd27mjxjx7qdxhty@doriath/) + in April 2019 to fix another bug in 'ref-filter.c' + related to `%(push:track)`. This patch was incorporated in Git 2.22. + + 'ref-filter.c' is some internal API that formats information about + Git refs or Git objects. It's used by commands like `git branch` and + `git for-each-ref`. + + The issue Damien wanted to fix was that 'ref-filter.c' didn't take + into account the [`push.default` config option](https://git-scm.com/docs/git-config#Documentation/git-config.txt-pushdefault) + which is used when no refspec is specified for the push. + + Peff, alias Jeff King, replied to Damien, and made it clear that it + was about taking `push.default` into account. He also found that + Damien's patch wouldn't work in the case where `push.default` was set + to `upstream` and a branch has been set to track a specific branch + different than the default one. + + Peff then commented on the code and asked for some tests, saying + that the current tests were not covering this case and that they + would wrongly fail if Damien's patch was applied. + + Damien replied to Peff agreeing about the `upstream` case and to add + more tests. He found that his initial code also wouldn't work when + `push.default` was set to `nothing`. + + Peff and Damien discussed a bit more some details of the possible + changes in the code, while Peff proposed a preparatory patch to + clean up the current code before Damien's changes. Then Damien sent + a [version 2](https://lore.kernel.org/git/20200303161223.1870298-1-damien.olivier.robert+git@gmail.com/) + of his patch along with Peff's preparatory patch. + + The version 2 handled all `push.default` cases and added tests for + them, but Junio Hamano, the Git maintainer, suggested improvements + in the commit message of the preparatory patch. Peff suggested + improvements of his own but agreed with Junio's suggestion too. + + Meanwhile Damien found issues in version 2 of his own patch, and + separately Junio commented on it and suggested some + improvements. Damien and Junio soon agreed, and then Damien sent a + [version 3](https://lore.kernel.org/git/20200312164558.2388589-1-damien.olivier.robert+git@gmail.com/) + of his patch. This version contained only Damien's patch, as Peff's + patch was merged separately. + + Peff found a memory leak around Damien's patch, but the leak had + already been there before the patch. Peff also suggested small + improvements to the tests, and eventually sent + [his own version](https://public-inbox.org/git/20200328133134.GA1196665@coredump.intra.peff.net/) + of Damien's patch for him to "to try it out or hack on it further". + + Damien found [an issue](https://public-inbox.org/git/20200416151213.xbo5x6jt477ezwvo@feanor/) + in Peff's patch though, and, after improving the tests in his patch, + more existing issues in the current code in case of a + [triangular workflow](https://public-inbox.org/git/20200406160439.gg5uu6kepnyxpvuc@feanor/). + Peff commented that these issues could be left for a separate fix + though. + + Damien then sent a + [version 6](https://lore.kernel.org/git/20200406175648.25737-1-damien.olivier.robert+git@gmail.com/) + of his patch, though the title in the cover letter mistakenly + contains "v4", saying version 4 and version 5 were intermediate + versions he made but did not send to the mailing list. + + This version contained a preparatory patch to fix the triangular workflow + issues Damien had found, as well as his updated patch with tests for + both his fixes in this patch and the triangular workflow fixes. However, + this patch series was marked as RFC, since its first patch was not very + polished and did not fix all + [corner triangular workflow cases](https://lore.kernel.org/git/20200418173651.djzriazxj5kbo6ax@doriath/). + + This led to some [release confusion](https://lore.kernel.org/git/20200416211208.xqnnrkvcl2jw3ejr@doriath/) + as Junio then had merged the 2 patches to the `next` branch, while + Damien had sent a + [version 8](https://lore.kernel.org/git/20200416150355.635436-1-damien.olivier.robert+git@gmail.com/) + that contained only his patch without the triangular workflow fixes + and test cases. + + This last version is now merged in the `pu` branch, and is + likely to find its way to `master`, while hopefully the fixes + related to triangular workflows will be re-sent separately. + + + + + +## Releases + ++ Git [2.27.0-rc2](https://lore.kernel.org/git/xmqqtv02mt2m.fsf@gitster.c.googlers.com/), +[2.27.0-rc1](https://public-inbox.org/git/xmqqsgfuv2ko.fsf@gitster.c.googlers.com/), +[2.27.0-rc0](https://public-inbox.org/git/xmqqy2punll7.fsf@gitster.c.googlers.com/) ++ Git for Windows [2.27.0-rc2](https://github.com/git-for-windows/git/releases/tag/v2.27.0-rc2.windows.1), +[2.27.0-rc1](https://github.com/git-for-windows/git/releases/tag/v2.27.0-rc1.windows.1), +[2.27.0-rc0](https://github.com/git-for-windows/git/releases/tag/v2.27.0-rc0.windows.1) ++ GitHub Enterprise [2.20.8](https://enterprise.github.com/releases/2.20.8/notes), +[2.19.14](https://enterprise.github.com/releases/2.19.14/notes), +[2.18.19](https://enterprise.github.com/releases/2.18.19/notes), +[2.17.25](https://enterprise.github.com/releases/2.17.25/notes), +[2.20.7](https://enterprise.github.com/releases/2.20.7/notes), +[2.19.13](https://enterprise.github.com/releases/2.19.13/notes), +[2.18.18](https://enterprise.github.com/releases/2.18.18/notes), +[2.17.24](https://enterprise.github.com/releases/2.17.24/notes) ++ GitLab [13.0](https://about.gitlab.com/releases/2020/05/06/gitlab-com-13-0-breaking-changes/), +[12.10.6](https://about.gitlab.com/releases/2020/05/15/gitlab-12-10-6-released/), +[12.10.5](https://about.gitlab.com/releases/2020/05/13/gitlab-12-10-5-released/), +[12.10.3](https://about.gitlab.com/releases/2020/05/04/gitlab-12-10-3-released/), +[12.10.2, 12.9.5, 12.8.10](https://about.gitlab.com/releases/2020/04/30/security-release-12-10-2-released/) ++ Bitbucket Server [7.2](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [2.16.19](https://www.gerritcodereview.com/2.16.html#21619), +[2.16.18](https://www.gerritcodereview.com/2.16.html#21618) ++ GitKraken [7.0.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.5.0](https://desktop.github.com/release-notes/), +[2.4.3](https://desktop.github.com/release-notes/) ++ isomorphic-git [1.0.0](https://isomorphic-git.org/blog/2020/02/25/version-1-0-0) + +## Other News + +__Various__ + +* New [git-filter-repo](https://github.com/newren/git-filter-repo) resources: + a [cheat sheet for converting filter-branch commands](https://github.com/newren/git-filter-repo/blob/master/Documentation/converting-from-filter-branch.md#cheat-sheet-conversion-of-examples-from-the-filter-branch-manpage) + which shows equivalents for all examples from the filter-branch manpage, and a similar + [cheat sheet for converting BFG repo cleaner commands](https://github.com/newren/git-filter-repo/blob/master/Documentation/converting-from-bfg-repo-cleaner.md#cheat-sheet-conversion-of-examples-from-bfg) + which shows equivalents for all the examples from the BFG web page. +* [Java 16: Migration to Git and GitHub gets closer](https://jaxenter.com/java-16-migration-to-git-and-github-jdk-172076.html) + (from Mercurial). +* [Why AppsFlyer moved from Bitbucket to [self-hosted] GitLab](https://about.gitlab.com/blog/2020/04/27/appsflyer-moves-to-gitlab/). +* [GitHub Codespaces lets you code in your browser without any setup](https://thenextweb.com/dd/2020/05/06/github-codespace-lets-you-code-in-your-browser-without-any-setup/); + see also [New from Satellite 2020: Start coding in seconds on GitHub with Codespaces](https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/#codespaces). +* [DVC 3 Years 🎉 and 1.0 Pre-release 🚀](https://dvc.org/blog/dvc-3-years-and-1-0-release); + [DVC](https://dvc.org) (Data Version Control), an open-source version control + system for Data Science projects was first mentioned in [Git Rev News #42](https://git.github.io/rev_news/2018/08/22/edition-42/). + + +__Light reading__ + +* [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) + by Martin Fowler (author of the [Refactoring: Improving the Design of Existing Code](https://martinfowler.com/books/refactoring.html) book); + _note_ that this article is being released in installments, + and at the time of publishing this edition it finished describing all the patterns but was not yet complete. +* [How LinkedIn handles merging code in high-velocity repositories](https://engineering.linkedin.com/blog/2020/continuous-integration) + by Niket Parikh. +* [How to Set up the HTTP Git Server for Private Projects](https://thenewstack.io/how-to-set-up-the-http-git-server-for-private-projects/) + on Ubuntu 18.04 with nginx, by Jack Wallen. +* [Git on Windows](https://code-maven.com/git-on-windows) by Gabor Szabo, + a video series where you can learn how to use Git on MS Windows + (half of links to videos are behind a Code Maven paywall). +* [Git Explained: The Basics](https://dev.to/milu_franz/git-explained-the-basics-igc) + by Milu Franz. +* [Git Explained: An In-Depth Comparison](https://dev.to/milu_franz/git-explained-an-in-depth-comparison-18mk) + of the commands `revert`, `checkout`, `reset`, `merge`, and `rebase` + by Milu Franz. +* [The life-changing magic of `git rebase -i`](https://opensource.com/article/20/4/git-rebase-i) + by Dave Neary. +* [How to resolve a git merge conflict](https://opensource.com/article/20/4/git-merge-conflict) + by Brian Breniser. +* [Managing Git projects with submodules and subtrees](https://opensource.com/article/20/5/git-submodules-subtrees) + by Manaswini Das. +* [Improve Git Diffs for Structured Data](https://blog.afoolishmanifesto.com/posts/improve-git-diffs-structured-data/) + by fREW Schmidt. The solution uses `.gitattributes` and a custom shell script + for wrapping the `git diff` command, using `jq` and `sponge` to process JSON files. +* [Comparing Code Quality Meta Tools](https://blog.urth.org/2020/05/08/comparing-code-quality-meta-tools/), + that is linters and beautifiers operating on the whole project + (many of those tools being systems for managing Git hooks): + [tidyall][], [pre-commit][], [lefthook][], [husky][], [overcommit][], and [precious][]; + article by Dave Rolsky. + +[tidyall]: https://metacpan.org/pod/distribution/Code-TidyAll/bin/tidyall +[pre-commit]: https://pre-commit.com/ +[lefthook]: https://github.com/Arkweid/lefthook +[husky]: https://github.com/typicode/husky +[overcommit]: https://github.com/sds/overcommit +[precious]: https://github.com/houseabsolute/precious + + +__Git tools and sites__ + +* [Fork](https://fork.dev/), a fast and friendly proprietary git client for Mac and Windows + (with free evaluation). +* [Git-Stats](https://gitstats.me/) is an open-source GitHub contribution analyzer + service written in Node.js. +* [Git Insights](https://www.gitinsights.io/) is an open-source analytics tool + to give you insights on your software projects and teams, currently supporting + only GitHub (as GitHub App); support for Bitbucket, GitLab and self-hosted + repositories is planned. +* [GitSavvy](https://github.com/timbrel/GitSavvy) is an open-source + Sublime Text 3 plugin providing full Git and GitHub integration. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Johannes Schindelin, Elijah Newren and +Damien Robert. diff --git a/_posts/2020-06-25-edition-64.markdown b/_posts/2020-06-25-edition-64.markdown new file mode 100644 index 000000000..dedee2cde --- /dev/null +++ b/_posts/2020-06-25-edition-64.markdown @@ -0,0 +1,218 @@ +--- +title: Git Rev News Edition 64 (June 25th, 2020) +layout: default +date: 2020-06-25 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 64 (June 25th, 2020) + +Welcome to the 64th 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](https://git.github.io). + +This edition covers what happened during the month of May 2020. + +## Discussions + + + +### Reviews + +* [fetch: allow adding a filter after initial clone](https://lore.kernel.org/git/20200513200040.68968-1-delphij@google.com/) + + Xin Li sent a patch to allow using a partial clone filter when + fetching even if the original clone didn't use one. + + As the patch was lacking a proper commit message, Junio Hamano, the + Git maintainer, asked Xin to add one. So Xin sent an explanation of + what the commit does taking as an example a shallow clone, with + `git clone --depth=1 ...`, that is transformed into a partial clone + with `git fetch --unshallow --filter=blob:none ...`. Xin wrote that + being able to do so is easier for the user than having to manually + set the `core.repositoryFormatVersion` and `extensions.partialClone` + config options. + + Junio replied asking how we could be sure that the server actually + supports the protocol extensions required for partial clone, as + setting up the config options manually or automatically shouldn't be + done without verifying that. + + Brian Carlson also replied to Xin's initial patch wondering if it + was safe to set the `core.repositoryFormatVersion` to `1` as it would + make Git fail if any already configured `extensions.*` config + option, like `extensions.tomatoSalad`, was not recognized. + + Xin then sent a version 2 of his patch. This time there was a commit + message in the patch and a cover letter along with the patch that + explained the changes. The patch itself added tests and checked that + the existing configuration had no unsupported `extensions.*` + configuration before upgrading the `core.repositoryFormatVersion` + config option to `1`. + + Jonathan Nieder reviewed the patch suggesting a number of small + changes and moving some content from the cover letter to the commit + message. Xin then sent a version 3 of his patch applying Jonathan's + suggestions and without a cover letter. + + Junio in the meantime commented on the version 2 that it was not + enough to check that the existing configuration had no unsupported + `extensions.*` configuration variable, but that instead the code + should check that there is no `extensions.*` configuration variable + at all, as any such configuration variable could have an unsupported + value. Jonathan then agreed with Junio. + + Xin replied to them that the current code doesn't actually check + repositoryFormatVersion, so setting `extensions.partialclone` is + enough to make `git fetch --filter=...` work. He then asked what we + want to do about this situation. + + Jonathan replied that this should be fixed even though it was a + separate concern from the patch. + + Xin then sent a version 4 of his patch taking into account Junio's + comments. Junio reviewed it and suggested other improvements. He + further elaborated on `core.repositoryFormatVersion` upgrade by + suggesting the following criteria: + + > (1) if upgrading from v0, there must be no `extensions.*` and + > + > (2) if upgrading from other versions, there must be no + > `extensions.*` we do not recognize. + + Jonathan also reviewed version 4 of Xin's patch focusing on the + changes made in tests. + + Xin sent a version 5 of the patch addressing the comments. He also + replied to Jonathan's review. Junio also replied to Jonathan's + review agreeing with him that some changes in the patch actually + belong to another patch. + + Xin then sent a version 6 with 4 patches instead of 1. Junio + reviewed the patches and found that only the last one could be + controversial as it could perhaps break an existing set-up. + + The last patch indeed contained the changes about checking + repositoryFormatVersion that Jonathan and Junio wanted to see + separately. With that patch the `extensions.*` config options don't + take effect unless `core.repositoryFormatVersion` has been upgraded + to `1` or higher. + + So for example if `extensions.worktreeConfig` is set to `true` but + `core.repositoryFormatVersion` isn't set, then with the patch Git + will behave as if `extensions.worktreeConfig` wasn't set. + + Junio thinks that this change is the right thing to do in the longer + term though. He asked for comments about that but no-one + answered. So the patch series has been merged to 'pu' and then + 'next' and according to the last "What's cooking in git.git" email from Junio, + the plan is to merge to 'master'. + + + + + +## Releases + ++ Git [2.27.0](https://public-inbox.org/git/xmqqzh9mu4my.fsf@gitster.c.googlers.com/) ++ Git for Windows [2.27.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.27.0.windows.1) ++ git-filter-repo [2.27.1](https://lore.kernel.org/git/CABPp-BFo=SRkMezdD_FvM92-bgdeBzfExpjtjYiEvg0UM1rWQQ@mail.gmail.com/), +[2.27.0](https://lore.kernel.org/git/CABPp-BF+xvzroi5QU8zPp-7KoSS16v1CsM43vWx1WO5NjyU0BQ@mail.gmail.com/) ++ libgit2 [1.0.1](https://github.com/libgit2/libgit2/releases/tag/v1.0.1) ++ GitLab [13.0.6, 12.10.11, 12.9.10](https://about.gitlab.com/releases/2020/06/10/critical-security-release-13-0-6-released/), +[12.10.10](https://about.gitlab.com/releases/2020/06/04/gitlab-12-10-10-released/), +[13.0.5](https://about.gitlab.com/releases/2020/06/04/gitlab-13-0-5-released/), +[13.0.4, 12.10.9, 12.9.9](https://about.gitlab.com/releases/2020/06/03/critical-security-release-13-0-4-released/), +[12.10.8](https://about.gitlab.com/releases/2020/05/29/gitlab-12-10-8-released/), +[13.0.3](https://about.gitlab.com/releases/2020/05/29/gitlab-13-0-3-released/), +[13.0.1, 12.10.7, 12.9.8](https://about.gitlab.com/releases/2020/05/27/security-release-13-0-1-released/) ++ Bitbucket Server [7.3](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.2.2](https://www.gerritcodereview.com/3.2.html#322), +[3.1.7](https://www.gerritcodereview.com/3.1.html#317), +[3.0.11](https://www.gerritcodereview.com/3.0.html#3011), +[3.2.1](https://www.gerritcodereview.com/3.2.html#321), +[3.1.6](https://www.gerritcodereview.com/3.1.html#316), +[3.0.10](https://www.gerritcodereview.com/3.0.html#3010), +[2.16.21](https://www.gerritcodereview.com/2.16.html#21621), +[2.15.19](https://www.gerritcodereview.com/2.15.html#21519), +[2.14.21](https://www.gerritcodereview.com/2.14.html#21421), +[3.2.0](https://www.gerritcodereview.com/3.2.html), +[2.16.20](https://www.gerritcodereview.com/2.16.html#21620), +[3.1.5](https://www.gerritcodereview.com/3.1.html#315), +[3.0.9](https://www.gerritcodereview.com/3.0.html#309) ++ GitHub Enterprise [2.21.0](https://enterprise.github.com/releases/2.21.0/notes), +[2.20.9](https://enterprise.github.com/releases/2.20.9/notes), +[2.19.15](https://enterprise.github.com/releases/2.19.15/notes), +[2.18.20](https://enterprise.github.com/releases/2.18.20/notes) ++ GitKraken [7.0.1](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.5.2](https://desktop.github.com/release-notes/), +[2.5.1](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + +* The Git PLC (Project Leadership Committee) [announced](https://lore.kernel.org/git/CAP8UFD1KfEps4hS8eadBK-E4e5WyWSh93XivRabZAVhiCuQimQ@mail.gmail.com/) + that it drafted a statement "regarding Git and branch naming" with + the [Software Freedom Conservancy](https://sfconservancy.org/) that + has been [posted at Conservancy's site](https://sfconservancy.org/news/2020/jun/23/gitbranchname/). + Articles related to this issue include: + * [Proposal to Rename the ‘Master’ Branch of WordPress-Owned Git Repositories](https://wptavern.com/proposal-to-rename-the-master-branch-from-wordpress-owned-git-repositories) + * [Loaded terms in free software [LWN.net]](https://lwn.net/Articles/823224/) + * [Replacing master in git](https://dev.to/damcosset/replacing-master-in-git-2jim) + * [Migrating your default git branch to 'main'](https://blog.b12.io/migrating-your-default-git-branch-to-main-a0fb706e3668) + * [GitHub to replace "master" with alternative term to avoid slavery references](https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/); + note that while BitKeeper used master/slave terminology for repositories, 'master' branch in Git is about being 'master copy' + +* Eric Wong, the developer of [public-inbox.org](https://public-inbox.org/README.html), + [implemented a read-only IMAP/IMAPS server](https://lore.kernel.org/git/20200610184147.GA1887@dcvr/), + so that a Git mailing list archive can now be accessed through + initially 8, and now 9, IMAP mailboxes sliced into ~50k messages to + not overload clients. + +* Matheus Tavares, who was a [GSoC](https://summerofcode.withgoogle.com/) + student [last year](https://matheustavares.gitlab.io/gsoc/), has been + hired as a freelancer by Amazon to improve Git + performance. Congratulations to him! + +* A new [Hacking Git](https://git.github.io/Hacking-Git/) page lists + documents helpful to develop Git. + +* [Introducing GitHub Super Linter: one linter to rule them all](https://github.blog/2020-06-18-introducing-github-super-linter-one-linter-to-rule-them-all/) by Lucas Gravley on GitHub Blog. + +* [DVC 1.0 release: new features for MLOps](https://dvc.org/blog/dvc-1-0-release); the + [1.0 Pre-release](https://dvc.org/blog/dvc-3-years-and-1-0-release) was mentioned + in a [previous edition of Git Rev News](https://git.github.io/rev_news/2020/05/28/edition-63/#other-news). + + +__Light reading__ + +* [Using GitHub Actions for MLOps (Machine Learning Operations) & Data Science](https://github.blog/2020-06-17-using-github-actions-for-mlops-data-science/) by Hamel Husain on GitHub Blog. +* [How to squash git commits](https://levelup.gitconnected.com/how-to-squash-git-commits-9a095c1bc1fc) by Srebalaji Thirumalai. +* [Rebase and retag](https://github.polettix.it/ETOOBUSY/2020/06/11/rebase-retag/) and [Rebase and retag, but manually](https://github.polettix.it/ETOOBUSY/2020/06/12/rebase-auto-retag/) is a series of short articles by Flavio Poletti on how to use tagging to schedule blog article publication and how to use rebase to change planned publishing date. +* [Reordering git commits (not patches) with interactive rebase](https://blog.plover.com/prog/git-reorder-3.html) by Mark Dominus (a very specific use-case). +* [Speeding up a Git monorepo at Dropbox with <200 lines of code](https://dropbox.tech/application/speeding-up-a-git-monorepo-at-dropbox-with--200-lines-of-code) by Utsav Shah on Dropbox.Tech . +* [Using `make` and `git diff` for a simple and powerful test harness](https://chrismorgan.info/blog/make-and-git-diff-test-harness/) by Chris Morgan +* [Git Explained: Proper Team Etiquette](https://dev.to/milu_franz/git-explained-proper-team-etiquette-1od) by Milu. + + +__Git tools and sites__ + +* [Piranha](https://github.com/uber/piranha/) by Uber is an Open Source tool for automated clean up of stale code caused by [feature flags](https://www.martinfowler.com/articles/feature-toggles.html) that are no longer required. It currently supports Java, Swift, and Objective-C. +* [git-fuzzy](https://github.com/bigH/git-fuzzy) is a CLI interface to Git that relies heavily on the [fzf](https://github.com/junegunn/fzf) general-purpose command-line fuzzy finder (version 0.21.0 or higher). + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <>. diff --git a/_posts/2020-07-30-edition-65.markdown b/_posts/2020-07-30-edition-65.markdown new file mode 100644 index 000000000..a3960eb5e --- /dev/null +++ b/_posts/2020-07-30-edition-65.markdown @@ -0,0 +1,379 @@ +--- +title: Git Rev News Edition 65 (July 29th, 2020) +layout: default +date: 2020-07-29 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 65 (July 29th, 2020) + +Welcome to the 65th 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](https://git.github.io). + +This edition covers what happened during the month of June 2020. + +## Discussions + +### General + +* The history of `master` in Git (*written by Andrew Ardill*) + + Amidst [all the discussion](https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@mail.gmail.com/) + around changing the default branch from `master` to something else, + many people have asked why `master` was chosen in the first place. + As `master` has a few different meanings in English, just which + meaning was intended? + + [Konstantin Ryabitsev](https://lore.kernel.org/git/20200504174548.r3zaftqcq52yhd2u@chatter.i7.local/) + was the first to discuss the meaning of `master`, saying + > Git doesn't use "master-slave" terminology -- the "master" comes + > from the concept of having a "master" from which copies (branches) are made + + [This post from the GNOME mailing list](https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html) + was then [linked by Simon Pieters](https://lore.kernel.org/git/CAOAHyQx=+fM1FpAv+g3M+j7j4MgLJA03=MGFmXLvZcfJKAEpGg@mail.gmail.com/) + with the claim that + > Git's `master` is in fact a reference to master/slave + + That post points out that the first use of `master` was in + [a CVS helper script](https://github.com/git/git/commit/3e91311ae750af9bf2e3517b1e701288ac3066b9), + links that to BitKeeper (the version control system used to manage + Linux development when Linus Torvalds first wrote Git), and claims + BitKeeper used the "master and slave" meaning of `master`. + + Many people considered `master` to mean a "master copy", so this + connection to slavery was very surprising. + + [Andrew Ardill investigated the BitKeeper source code](https://lore.kernel.org/git/a34e4244-835e-976a-8fb4-7fc766d100bd@gmail.com/T/#m9589009ba3b6663ca38c2ef19c18c933e46c253a) + and came to the conclusion that "the overwhelming majority of + \[the usages of master in BitKeeper\] are of the "Master Copy" + variant", or as [Michal Suchánek said](https://lore.kernel.org/git/20200616085004.GB21462@kitsune.suse.cz/) + "even in BitKeeper the use of master/slave is the exception rather + than the norm." + + Off the list discussions were ongoing, and + [Petr Baudis wrote on Twitter about naming the `master` branch in Git](https://twitter.com/xpasky/status/1271477451756056577) + + > I picked the names "master" (and "origin") in the early Git tooling back in 2005. + > + > (this probably means you shouldn't give much weight to my name preferences :) ) + > + > I have wished many times I would have named them "main" (and "upstream") instead. + > + > Glad it's happening @natfriedman + + When asked for which meaning of `master` was intended, + [Petr replied](https://twitter.com/xpasky/status/1272280760280637441) + > "master" as in e.g. "master recording". Perhaps you could say the + > original, but viewed from the production process perspective. + > + > A clueless Central European youngster whose command of English + > was mostly illusory came up with the term, which is why it isn't + > very obvious... + + In [a follow-up to that original GNOME mailing list post](https://mail.gnome.org/archives/desktop-devel-list/2020-June/msg00023.html), + Bastien Nocera retracted their claims from the original post, saying + > I emailed Linus Torvalds recently... and he told me that it was + > unlikely that the "Git master" branch name was influenced by + > BitKeeper, and that "master" was "fairly standard naming" for this + > sort of thing and "more likely to be influenced by the + > CVS master repository" + + Going on, Bastien discusses Petr Baudis' tweets and then concludes + "it doesn't matter where the name comes from... The fact that it has + bad connotations, or inspires dread for individuals and whole + communities, is reason enough to change it." + + This is something that + [Brian M. Carlson had also pointed out on the Git mailing list](https://lore.kernel.org/git/20200505231641.GH6530@camp.crustytoothpaste.net/), + saying + > "master", even though from a different origin, brings the idea of + > human bondage and suffering to mind for a non-trivial number of + > people, which of course was not the intention and is undesirable. + > I suspect if we were making the decision today, we'd pick another + > name, since that's not what we want people to think of when they use Git. + + Brian goes on to lay out changes required in Git to rename `master` + as the default, suggesting that there is a decent amount of work and + that due to compatibility concerns "we'd probably want to make it in + a \[Git version\] 3.0". + + Around the web the discussion about renaming `master` continues. + The incorrect claims around the history of `master` persist, even in + our own [Git Rev News: Edition 64](https://git.github.io/rev_news/2020/06/25/edition-64/#other-news), + but seem to be quickly corrected where possible such as on + [GitLab's discussion on the topic](https://gitlab.com/gitlab-org/gitlab/-/issues/221164#note_372560473). + + +### Reviews + +* [More commit-graph/Bloom filter improvements](https://lore.kernel.org/git/pull.659.git.1592252093.gitgitgadget@gmail.com/) + + Derrick Stolee, who prefers to be called Stolee, sent a patch series + to the mailing list, based on a + [previous experimental patch series](https://lore.kernel.org/git/20200529085038.26008-1-szeder.dev@gmail.com/) + sent a few weeks earlier by Gábor Szeder. + + When he sent his patch series, Gábor said that his work was a proof + of concept started more than a year ago, that he had no time to + finish yet. He was motivated to send it as-is with changes to commit + messages, when he recently took a look at the current changed-path Bloom filter + implementation. This implementation was developed for a long time + mainly by Garima Singh and was merged at the beginning of May. He + saw that it had some of the same issues that he had stumbled upon, + and that it missed some optimization opportunities. + + Gábor listed a lot of very interesting benefits from his work, but + also a lot of drawbacks that would prevent it from being merged as + is. Many of the benefits are linked to a new format used to store + the changed-path Bloom filter. This new format was justified by + [an impressive commit message](https://public-inbox.org/git/20200529085038.26008-16-szeder.dev@gmail.com/). + + Stolee, Taylor Blau, Johannes Schindelin and Junio Hamano, when + reviewing Gábor's work, were disappointed that Gábor was not trying + to contribute to the current implementation. It appeared though that + a number of Gábor's 34 patches and ideas could be applied on top of + the current implementation. + + That's what Stolee did by first sending + [10 patches from Gábor's series](https://lore.kernel.org/git/pull.650.git.1591362032.gitgitgadget@gmail.com/) + at the beginning of June. This patches series required a bit of + work, but Stolee left out what would have been more difficult to + apply to the current code. René Scharfe, Stolee, Gábor and Junio + commented a bit on it, but didn't find anything that would require + a new version of this patch series. So it is now "cooking" in the + 'next' branch. + + Stolee's next patch series called + ["More commit-graph/Bloom filter improvements"](https://lore.kernel.org/git/pull.659.git.1592252093.gitgitgadget@gmail.com/) + was about adding a few extra improvements, several of which are + rooted in Gábor's original series. Even though Gábor's patches did + not apply or cherry-pick at all, Stolee still credited Gábor as the + author of 4 patches out of 8. + + Anyway this new series contained 2 changes that improve the + false-positive rate which increases performance, and + one change that improves usability. René and Taylor + suggested improvements and bug fixes. Taylor even sent a patch. + + Stolee then sent [a version 2](https://lore.kernel.org/git/pull.659.v2.git.1592934430.gitgitgadget@gmail.com/) + of the series, taking into account the feedback and adding the patch + from Taylor to the series. René, Gábor, Junio and Stolee discussed a + few more points. + + That led to Stolee sending + [a version 3](https://lore.kernel.org/git/pull.659.v3.git.1593174636.gitgitgadget@gmail.com/) + in which Gábor reported a bug that Stolee subsequently fixed. + + So Stolee sent + [a version 4](https://lore.kernel.org/git/pull.659.v4.git.1593610050.gitgitgadget@gmail.com/) + which is now cooking in the 'next' branch, along with the first + series that has 10 patches from Gábor. + + In the meantime though Gábor [commented on this first series](https://public-inbox.org/git/20200710211342.GE11341@szeder.dev/) + saying that it has a number of issues. Hopefully these issues will + be addressed soon, and these 2 patch series will be merged in the + near future. + + + +## Developer Spotlight: Jonathan Tan + +* Who are you and what do you do? + + I'm a Software Engineer at Google who works on Git. I also contribute + to [JGit](https://www.eclipse.org/jgit/) (a Java implementation of Git) as one of its committers. + +* What would you name your most important contribution to Git? + + I would say "[partial clone](https://git-scm.com/docs/partial-clone)" - the + ability to clone a repository, but not necessarily have all of + that repository's objects (accumulated throughout its history) in + your clone. Quite a few articles have been written about it, but in + summary, it improves Git performance especially for large repositories. + +* What are you doing on the Git project these days, and why? + + The thing that immediately comes to mind is "partial clone". The + fundamentals are there, but some Git commands still operate under the + assumption that objects are only a disk read away (instead of a + network fetch - in a partial clone, if an object is needed but + missing, it is automatically fetched). I'm improving those commands to + be more cognizant of this fact - typically, this means batching the + fetch of all the objects it will need once it realizes that it does + not have some of them, instead of "I need this object, so go fetch it; + OK let me process it; oops I need another one, so go fetch that". + +* 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? + + Along the lines of "partial clone" and large repositories, I would + like them to investigate the feasibility of having Git servers be able + to serve results of computations (thus, not just objects). One case is + `git blame` - if a Git client could ask a Git server to send the + results of such a command, it could offload most of the computation to + the server, only needing to build upon the server's results with the + locally-created objects that the server does not know about. This is + especially useful with partial clone, because the client does not even + have most of the objects needed and would have to fetch them + otherwise. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + One small thing that I can think of: remove the ability of `git reset` + to update the working tree and the objects staged in the index. The + [`git restore`](https://git-scm.com/docs/git-restore) command, + relatively recently introduced, does this with more beginner-friendly + parameter names (`--worktree` and `--staged`, respectively, instead of + the `--hard`, `--mixed`, and `--soft` of `git reset`). This change + would make it easier, for example, to read scripts written by other + people - I would no longer need to think so much about what that + `reset` in the script would do. + +## Releases + ++ Git [2.28.0](https://public-inbox.org/git/xmqq5za8hpir.fsf@gitster.c.googlers.com), +[2.28.0-rc2](https://public-inbox.org/git/xmqqblk75uel.fsf@gitster.c.googlers.com), +[2.28.0-rc1](https://public-inbox.org/git/xmqqv9ildh46.fsf@gitster.c.googlers.com), +[2.28.0-rc0](https://public-inbox.org/git/xmqqh7ugwen6.fsf@gitster.c.googlers.com) ++ Git for Windows [2.28.0](https://lore.kernel.org/git/20200728103216.7378-1-johannes.schindelin@gmx.de), +[2.28.0-rc2](https://public-inbox.org/git/20200722195905.6540-1-johannes.schindelin@gmx.de), +[2.28.0-rc1](https://public-inbox.org/git/20200718011007.6808-1-johannes.schindelin@gmx.de), +[2.28.0-rc0](https://public-inbox.org/git/20200710135935.6416-1-johannes.schindelin@gmx.de) ++ git-filter-repo [2.28.0](https://lore.kernel.org/git/CABPp-BGVFKKm+n8wTN9dqbA6=HJSZ5m3bnG7fLZ5DGevXSXBAA@mail.gmail.com) ++ Bitbucket Server [7.4](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.1.8](https://www.gerritcodereview.com/3.1.html#318), +[3.0.12](https://www.gerritcodereview.com/3.0.html#3012), +[2.16.22](https://www.gerritcodereview.com/2.16.html#21622) ++ GitHub Enterprise [2.21.3](https://enterprise.github.com/releases/2.21.3/notes), +[2.20.12](https://enterprise.github.com/releases/2.20.12/notes), +[2.19.18](https://enterprise.github.com/releases/2.19.18/notes), +[2.18.23](https://enterprise.github.com/releases/2.18.23/notes), +[2.21.2](https://enterprise.github.com/releases/2.21.2/notes), +[2.20.11](https://enterprise.github.com/releases/2.20.11/notes), +[2.19.17](https://enterprise.github.com/releases/2.19.17/notes), +[2.18.22](https://enterprise.github.com/releases/2.18.22/notes) ++ GitLab [13.1.5](https://about.gitlab.com/releases/2020/07/24/gitlab-13-1-5-released/), +[13.2.1](https://about.gitlab.com/releases/2020/07/24/gitlab-13-2-1-released/), +[13.2](https://about.gitlab.com/releases/2020/07/22/gitlab-13-2-released/), +[13.0.10](https://about.gitlab.com/releases/2020/07/09/gitlab-13-0-10-released/), +[13.1.4](https://about.gitlab.com/releases/2020/07/09/gitlab-13-1-4-released/), +[13.1.3, 13.0.9 and 12.10.14](https://about.gitlab.com/releases/2020/07/06/critical-security-release-gitlab-13-1-3-released/), +[13.1.2, 13.0.8 and 12.10.13](https://about.gitlab.com/releases/2020/07/01/security-release-13-1-2-release/) ++ GitKraken [7.1.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.5.3](https://desktop.github.com/release-notes/) + +## Other News + +__Events__ + +* Carmen Andoh, who works for Google, and Jonathan Nieder’s team at + Google have volunteered to organize a + [Git Inclusion Summit](https://lore.kernel.org/git/CA+TwhoKBYwUKmtQTyiocPWJD=KeZQryS+6Q8JKxKgLEy0qJwAw@mail.gmail.com/). + It would be a virtual contributor summit with the purpose of + engaging core Git contributors as active participants in diversity + and inclusion initiatives for the Git project. Interested Git + contributors can vote on their preferred summit duration and times + on [a whenisgood poll](http://whenisgood.net/9z2diyy) by Thursday, + July 30th. + +__Various__ + +* Junio Hamano, the Git maintainer, has renamed the `pu` branch of + git.git to `seen`. This has been done to use a more meaningful name + and make room for topics from those contributors whose two-letter + name abbreviation needs to be 'pu'. This was announced in + "[What's cooking in git.git (Jun 2020, #04; Mon, 22)](https://public-inbox.org/git/xmqqimfid2l1.fsf@gitster.c.googlers.com)" + +* The Git Project Leadership Committee has been briefly interviewed via + email by [Elizabeth Landau](https://en.wikipedia.org/wiki/Elizabeth_Landau) + for an [article](https://www.wired.com/story/tech-confronts-use-labels-master-slave/) + in [Wired](https://www.wired.com/) about current changes to Git's + default name for the initial branch. + +* [Highlights from Git 2.28](https://github.blog/2020-07-27-highlights-from-git-2-28/) + by Taylor Blau on GitHub Blog, mentioning among others `init.defaultBranch`, + changed-path Bloom filters, the `git bugreport` command and `git log`'s new `--show-pulls` option. + +* The [Tower](https://www.git-tower.com/) Git client for Windows and MacOS now supports + [CMD+Z for Git](https://css-tricks.com/cmdz-for-git-is-here/) (a universal undo). + +* [Exciting new updates to the Git experience in Microsoft Visual Studio 2019](https://devblogs.microsoft.com/visualstudio/exciting-new-updates-to-the-git-experience-in-visual-studio/). + +* [GitHub Archive Program: the journey of the world’s open source code to the Arctic](https://github.blog/2020-07-16-github-archive-program-the-journey-of-the-worlds-open-source-code-to-the-arctic/) + by Julia Metcalf on GitHub Blog. The GitHub Archive Program along with the + GitHub Arctic Code Vault were introduced at GitHub Universe 2019, and mentioned + in [Git Rev News #57 (November 20th, 2019)](https://git.github.io/rev_news/2019/11/20/edition-57/). + +* [Updating the Git protocol for SHA-256 [LWN.net]](https://lwn.net/Articles/823352/) + by John Coggeshall. + +__Light reading__ + +* [Git Rebase - A Complete Guide](https://www.alchemists.io/articles/git_rebase) by Brooke Kuhlmann at Alchemists. +* [How to safely use GitHub Actions in organizations](https://humanwhocodes.com/blog/2020/07/safely-use-github-actions-in-organizations/) + by Nicholas C. Zakas, mainly about handling credentials and other secrets. + Various tools for checking the repository for secrets and/or safely storing secrets + were mentioned in [Git Rev News Edition #25](https://git.github.io/rev_news/2017/03/15/edition-25/), + [#28](https://git.github.io/rev_news/2017/06/14/edition-28/), + [#36](https://git.github.io/rev_news/2018/02/21/edition-36/), + [#39](https://git.github.io/rev_news/2018/05/16/edition-39/) and + [#57](https://git.github.io/rev_news/2019/11/20/edition-57/) +* [Fedora Classroom: Git 101 with Pagure](https://fedoramagazine.org/fedora-classroom-session-git-101-with-pagure/) + session was [streamed on YouTube](https://www.youtube.com/watch?v=HfsKvRecniI) + on the Fedora Project channel. +* [How To Create A GitHub Profile README](https://dev.to/m0nica/how-to-create-a-github-profile-readme-1paj) + by Monica Powell on Dev.to. +* [Top 13 GitHub Alternatives in 2020 [Free and Paid]](https://dzone.com/articles/top-13-github-alternatives-in-2020-free-and-paid) + by Momchil Koychev on DevOps Zone. +* [Git Best Practices -- AFTER Technique](https://dzone.com/articles/git-best-practices-after-technique-1) + by Rajeev Bera on DevOps Zone. +* [6 best practices for teams using Git](https://opensource.com/article/20/7/git-best-practices) + by Ravi Chandran on OpenSource.com. +* [Use `broot` and `meld` to diff before commit](https://dystroy.org/blog/gg/) by Denys Séguret + (author of [broot](https://dystroy.org/broot/), which is a tool to navigate file trees). +* [Basic Git Analogy for Contributing to Open Source Project](https://medium.com/@thesagarsehgal/basic-git-analogy-for-contributing-to-open-source-project-8c314789326e) + by Sagar Seghal on Medium. +* [Can You Restore A Deleted Commit on Git?](https://www.hackernoon.com/can-you-restore-a-deleted-commit-on-git-yr1x3ygx) + by Dmytro Khmelenko on Hacker Noon (the answer is yes, with the help of the reflog). +* [Git Concepts I Wish I Knew Years Ago](https://dev.to/g_abud/advanced-git-reference-1o9j) + by Gabriel Abud on Dev.to. + +__Git tools and sites__ + +* [Git Lint](https://www.alchemists.io/projects/git-lint) - A command line interface for analyzing Git commit quality and consistency for yourself and/or team. Can be used as a Git Hook and/or wired into your continuous integration build system. +* [git-assembler: update git branches using high-level instructions](https://www.thregr.org/~wavexx/software/git-assembler/); + it can perform automatic merge and rebase operations following a simple declarative script + (like “make”, for branches). +* [git-manpages-l10n](https://github.com/jnavila/git-manpages-l10n) is repository + for translating Git manpages (the Git documentation). +* [icdiff](https://www.jefftk.com/icdiff) is improved colored diff. + Instead of trying to be a `diff` replacement for all circumstances, + the goal of `icdiff` is to be a tool you can reach for to get a better picture + of what changed when it's not immediately obvious from `diff`. + Docs include examples on how to integrate it with Git, Mercurial and Subversion. +* [Guitar](https://github.com/soramimi/Guitar) is a multi-platform graphical Git client + under development, written in C++ and powered by Qt. +* [SCM Breeze](https://madebynathan.com/2011/10/19/git-shortcuts-like-youve-never-seen-before/) + is a set of shell scripts (for `bash` and `zsh`) that make it easier to use Git. + It integrates with your shell to give you numbered file shortcuts, a repository index + with tab completion, and a community driven collection of useful SCM functions. + SCM Breeze lives on GitHub at +* [Gitpod](https://www.gitpod.io/) - Prebuilt Dev Environments for GitLab, GitHub and Bitbucket; + on the cloud or self-hosted, with a free tier. + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Andrew Ardill, Jonathan Tan, +Brooke Kuhlmann, Eric Sunshine, Carlo Marcelo +Arenas Belón and Gábor Szeder. diff --git a/_posts/2020-08-27-edition-66.markdown b/_posts/2020-08-27-edition-66.markdown new file mode 100644 index 000000000..f5687fc5d --- /dev/null +++ b/_posts/2020-08-27-edition-66.markdown @@ -0,0 +1,286 @@ +--- +title: Git Rev News Edition 66 (August 27th, 2020) +layout: default +date: 2020-08-27 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 66 (August 27th, 2020) + +Welcome to the 66th 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](https://git.github.io). + +This edition covers what happened during the month of July 2020. + +## Discussions + + + + +### Reviews + +* [git-mv: improve error message for conflicted file](https://lore.kernel.org/git/pull.678.git.1595028293855.gitgitgadget@gmail.com/) + + Chris Torek sent a patch to change the error message from `git mv` + when it's used on a file that has unresolved conflicts. Previously, + in this special case `git mv` would error out with the same error + message as if the file was not managed by Git, that is: + + "fatal: not under version control, src=..." + + This was of course misleading, so Chris' patch implemented detecting this + case and then using the new "must resolve merge conflict first" + error message if applicable. + + Eric Sunshine first reviewed the patch suggesting a small code + improvement in the detection of this case, and a more succinct new + error message, "conflicted". Eric also commented on the test case + that Chris' patch added, suggesting a number of small changes that + would make the test look more modern. + + Junio Hamano, the Git maintainer, commented on the code detecting + this case. He suggested a less wasteful way to do that. + + Chris then replied to Eric's review saying he will use Junio's + suggestion for the detection code and Eric's suggestions for the + error message and the test. + + Chris also asked if he should clean up and modernize other tests in + the test script that could benefit from Eric's suggestions, but Eric + replied that the test script, "t7001-mv.sh", had so many old style + issues that such improvements should happen in a dedicated patch + series. + + Interestingly Eric listed 17 different old style issues, and for + each one he described what should be done to fix them, so that + [his email](https://lore.kernel.org/git/CAPig+cQpUu2UO-+jWn1nTaDykWnxwuEitzVB7PnW2SS_b7V8Hg@mail.gmail.com/) + can be read as a guide to modernizing test scripts. + + Elijah Newren replied to Junio's suggestion, pointing to + [an email from two years ago](https://lore.kernel.org/git/xmqqk1ozb6qy.fsf@gitster-ct.c.googlers.com/), + where the same issue was already discussed and where Junio suggested + that `git mv` on a conflicting file could just move the file and + remove its conflicting status, in the same way as `git rm` and + `git add` already work on such a file. + + Elijah said that he was still planning to implement what Junio had + suggested in that email, but that in the meantime fixing the error + message was perfectly fine. + + Junio replied to Elijah saying that he was not convinced any more + that what he had suggested two years ago was actually the right + thing to do, and then describing in details some issues with his old + suggestion. Junio agreed though that fixing the error message as in + Chris' patch was a "strict improvement". + + Elijah and Junio then discussed a bit more technical issues related + to Junio's old proposal. + + Chris sent a version 2 of his patch implementing Junio's and Eric's + suggestions, including the shortened "conflicted" error message that + Eric had suggested. + + Junio replied to Chris and discussed a bit the "conflicted" error + message, but Chris' version 2 patch got merged to the master branch + as is. + + +### Support + +* [How can I search git log with certain keyword but without the other keyword?](https://public-inbox.org/git/CAAvDm6Z2HcQkyinCD4hKTnqGR3gcXodhoo0YKSnbB-vDJcn3MQ@mail.gmail.com/t/#u) + + 孙世龙 sunshilong asked how to search for commits in `git log` that include + certain keyword A, but at the same time do not have another keyword B in them. + The example provided was a branch with three commits: + + > b90b03f b12 + > 27f7577 b1 + > 7268b40 t123 + + The original poster wanted to use `git log --grep` to find commits that match + "12" but not "t123". In this example it should return only "b90b03f b12" as + search result. + + Carlo Arenas proposed using features of [PCRE syntax](https://perldoc.perl.org/perlre.html) + (Perl Compatible Regular Expressions) with a negative lookahead assertion and + word boundary to generate expression that matches one but not the other: + + > `git log -P --all-match --grep '12' --grep '\b(?!t123\b)\w+'` + + The syntax was explained by Jeff King, alias Peff, who also said that the + short option `-P` had to be spelled `--perl-regexp` before Git version + v2.14.0. He also reminded that for this to work one also needs a version of Git + built with libpcre support. + + It turned out however that it [didn't resolve](https://public-inbox.org/git/CAAvDm6Z6SA8rYYHaFT=APBSx0tM+5rHseP+fRLufgDxvEthsww@mail.gmail.com/) + the [more] real issue that sunshilong had: + + > I wonder why this command doesn't work well. + > + > I intend to find the comment with the keyword "12" but without "comments" + > whereas the output is something like this: + > + > git log --perl-regexp --all-match --grep=12 --grep '\b(?!comments\b)\w+' + > commit f5b6c3e33bd2559d6976b1d589071a5928992601 + > Author: sunshilong + > Date: 2020-04-12 23:00:29 +0800 + > + > comments 2020.04.12 ng + + Peff responded that he can't think of a way to achieve that just using a regex, + and that currently [Git supports similar feature only in `git grep`](https://public-inbox.org/git/20200717063324.GB1179001@coredump.intra.peff.net/): + + > The natural thing to me would be the equivalent of: + > + > git grep -e 12 --and --not -e comments + > + > The underlying grep machinery in Git understands how to compose multiple + > patterns like this, and the command above really does work (though of + > course it is searching for lines in a file and not commit messages). + > + > But none of that is exposed via the command-line of "git log". I think + > it would be possible to do so, but I'm not sure how tricky it would be + > (certainly one complication is that "\-\-not" already means something else + > there, but presumably we could have "\-\-grep-and", "\-\-grep-not", etc). + + The idea of introducing `--grep-and` and `--grep-not` to disambiguate from `--not` (which + means something completely different for the log family) is + [as old as 2012](https://lore.kernel.org/git/7vr4q45y65.fsf@alter.siamese.dyndns.org/), + as Junio C Hamano reminded. He then went to [explain the problem](https://public-inbox.org/git/xmqq7dv2fnpb.fsf@gitster.c.googlers.com/) + with properly implementing such feature: + + > Having said that, I do not think our underlying grep machinery is + > equipped to answer "find every commit whose log message has X but + > not Y", even if we exposed the interface that is equivalent to that + > of "git grep" to "git log". + > + > There are two levels of boolean combination involved in running our + > "grep" machinery. The lower level is used to determine if each line + > matches the criteria. The main consumer of the "grep" machinery is + > of course "git grep" and because it is line oriented, we have quite + > a rich set of operations and combinations to say things like "if a + > line has X and Y on it in any order, but not Z on it, then the line + > is a match." That is what "\-\-not", "\-\-and", "\-\-or" (not exposed to + > the "git log" interface) express and we even take "(" and ")" for + > grouping, e.g. "( X \-\-or Y ) \-\-and \-\-not Z". + > + > Another level of combination is to determine if the entire document + > matches. It often happens that you want to find a document with + > both X and Y in it, and "grep -e X \-\-and -e Y" is \*NOT\* a way to do + > so --- the "\-\-and" is a line-level combinator and tells the machinery + > to find lines that have both X and Y on them. + > + > We have a fairly ad-hoc single mechanism for boolean combination at + > this level and that is the "\-\-all-match" option, which says "Look at + > the boolean expression you used to find each matching line, and + > separate them at the OR operator at the top level. Now, apply the + > matching logic to all lines in a document and see if _all_ the + > clauses joined by the top-level OR operators matched at least once. + > If yes, then the document matches." + > + > That is how "git grep \-\-all-match -e X -e Y" finds documents that + > refer to both X and Y but not necessarily on the same line. + > + > There is not much room for the line-level "\-\-not" operator to + > participate in this picture. "git grep -e X \-\-not -e Y" would mean + > "find lines that has X, or that does not have Y", so as long as a + > document has one line with X on it and one line (which can be but + > does not have to be the same line) that does not have Y on it, the + > variant of that search with "\-\-all-match" in it would say "yup the + > doc matches". But that is definitely not what the user who wants to + > say "if a doc has X in it, I want to see it, but I do not want to + > see it if it also has Y" wants to see. + + Then the discussion petered out, without much further help. It remains to be + seen if somebody would take up the challenge of improving Git search + capabilities by adding support for boolean combinations of line-level and + document-level match operations. + + + +## Releases + ++ Gerrit Code Review [3.2.3](https://www.gerritcodereview.com/3.2.html#323) ++ GitHub Enterprise [2.21.5](https://enterprise.github.com/releases/2.21.5/notes), +[2.20.14](https://enterprise.github.com/releases/2.20.14/notes), +[2.19.20](https://enterprise.github.com/releases/2.19.20/notes), +[2.18.25](https://enterprise.github.com/releases/2.18.25/notes), +[2.21.4](https://enterprise.github.com/releases/2.21.4/notes), +[2.20.13](https://enterprise.github.com/releases/2.20.13/notes), +[2.19.19](https://enterprise.github.com/releases/2.19.19/notes), +[2.18.24](https://enterprise.github.com/releases/2.18.24/notes) ++ GitLab [13.3](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/), +[13.2.6](https://about.gitlab.com/releases/2020/08/18/critical-security-release-gitlab-13-2-6-released/), +[13.2.5](https://about.gitlab.com/releases/2020/08/18/critical-security-release-gitlab-13-2-5-released/), +[13.2.4](https://about.gitlab.com/releases/2020/08/11/gitlab-13-2-4-released/), +[13.2.3](https://about.gitlab.com/releases/2020/08/05/gitlab-13-2-3-released/), +[13.2.2](https://about.gitlab.com/releases/2020/07/30/gitlab-13-2-2-released/) ++ Bitbucket Server [7.5](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitKraken [7.2.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.5.4](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + +* GitLab is looking for a Backend Engineer with Git experience to join + their Gitaly team. See + [the job description](https://about.gitlab.com/job-families/engineering/backend-engineer/#gitaly) + and [apply through the GitLab Talent Community](https://about.gitlab.com/jobs/careers/) + if you are interested. +* [China is building a GitHub alternative called Gitee](https://techcrunch.com/2020/08/21/china-is-building-its-github-alternative-gitee/) (on TechCrunch). +* [Conditional steps and improvements to logs in Bitbucket Pipelines](https://bitbucket.org/blog/conditional-steps-and-improvements-to-logs-in-bitbucket-pipelines) + by Peter Plewa. + +__Light reading__ + +* [Creating a GitHub Action to detect toxic comments using TensorFlow.js](https://charliegerard.dev/blog/github-action-toxic-comments) + by Charlie Gerard (also on [Dev.to](https://dev.to/devdevcharlie/creating-a-github-action-to-detect-toxic-comments-using-tensorflow-js-13bo)), + using TensorFlow's toxicity pre-trained model. +* [What Is Git ? – Explore A Distributed Version Control Tool](https://www.edureka.co/blog/what-is-git/) + by Reshma Ahmed on the Edureka! blog. +* [Lecture 6: Version Control (git) (2020)](https://www.youtube.com/watch?v=2sjqTHE0zok), + part of lecture videos from the class offered during MIT's Independent Activities Period in 2020, + from the ["Missing Semester" course](https://missing.csail.mit.edu/about/) + providing hands-on introduction to tools and techniques in Computer Science. +* [Don't ignore .gitignore](https://opensource.com/article/20/8/dont-ignore-gitignore) + by Rajeev Bera on opensource.com. +* [How to write a good commit message](https://dev.to/chrissiemhrk/git-commit-message-5e21) + by Chrissie on Dev.to; one of many such articles. +* [Searching code with Sourcegraph [LWN.net]](https://lwn.net/Articles/828748/) + by Ben Hoyt. Open-sourcing [Sourcegraph](https://about.sourcegraph.com/) was covered in + [Git Rev News #44 (October 24th, 2018)](https://git.github.io/rev_news/2018/10/24/edition-44/). +* [Using Git with WordPress — Part 1](https://www.git-tower.com/blog/git-wordpress-1/) + by Kristian Lumme. +* [A Resource for all Things Git](https://codeburst.io/a-resource-for-all-things-git-b63d6626beca) + by Lea Cohen on codeburst.io is a list of articles about Git, with descriptions. + +__Git tools and sites__ + +* [Sourcegraph Cloud](https://sourcegraph.com/search) + allows to search "top" public repositories from various code hosting sites, + while self-hosted instances can be used to also search private and local repositories; + there are also [browser extensions](https://docs.sourcegraph.com/integration/browser_extension) for Chrome and Firefox + that enable its features to be used when browsing on hosts like GitHub and GitLab. +* [Autohook](https://github.com/Autohook/Autohook) + is a very, _very_ small Git hook manager in bash with focus on automation. +* [RepoZ](https://github.com/awaescher/RepoZ) + is a zero-conf git repository hub for Windows and macOS, + providing a navigation widget allowing for quick overview of your repositories, + with a sidekick command line app called `grr` and Windows Explorer enhancements. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <>. diff --git a/_posts/2020-09-24-edition-67.markdown b/_posts/2020-09-24-edition-67.markdown new file mode 100644 index 000000000..2a3b98de9 --- /dev/null +++ b/_posts/2020-09-24-edition-67.markdown @@ -0,0 +1,306 @@ +--- +title: Git Rev News Edition 67 (September 24rd, 2020) +layout: default +date: 2020-09-24 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 67 (September 24rd, 2020) + +Welcome to the 67th 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](https://git.github.io). + +This edition covers what happened during the month of August 2020. + +## Discussions + +### General + +* [GSoC 2020 End](https://summerofcode.withgoogle.com/organizations/4722049416691712/#projects) + + The Google Summer of Code 2020 officially ended on September 8, 2020. + Congratulations to the three students who were mentored by the + Git community, as they successfully passed all the + evaluations! Their final reports and code submissions are available: + + * Hariom Verma, who was mentored by Heba Waly and Christian Couder, + worked on ["Unify ref-filter formats with other \-\-pretty formats"](https://harry-hov.github.io/blogs/posts/the-final-report). + + * Abhishek Kumar, who was mentored by Jakub Narębski and D. Stolee, + worked on ["Implement Generation Number v2"](https://github.com/abhishekkumar2718/GSoC20/blob/master/README.md). + + * Shourya Shukla, who was mentored by Kaartic Sivaraam and Christian Couder, + worked on ["Convert submodule to builtin"](https://shouryashukla.blogspot.com/2020/08/the-final-report.html). + +### Reviews + +* [[RFC PATCH 0/2]extend \-\-abbrev support to diff-patch format](https://lore.kernel.org/git/cover.1596887883.git.congdanhqx@gmail.com/) + + Đoàn Trần Công Danh sent a small RFC patch series that makes the diff + machinery, which is used by `git diff` and similar commands, support + the `--abbrev` option when it shows a patch. + + In addition to the familiar `--patch` format, which is used when + showing regular diffs in a way similar to the + [unified format of the Unix `diff` command](https://en.wikipedia.org/wiki/Diff#Unified_format), + the diff machinery can produce the `--raw` format output to show object + names before and after the change for each path like this: + + ``` + :100644 100644 86e5411f39 f1b1bc8aa0 M Makefile + ``` + + In the `--patch` format, object names before and after the change + appear on the index line, which looks like this: + + ``` + index 4adb9ce124..67d9801da3 100644 + ``` + + The `--abbrev` option used to control the abbreviation of the + object names in the `--raw` format but did not affect those shown + on the index line in the `--patch` format. Đoàn's patch series + makes the option control both. + + In the cover letter of his RFC patch series, Đoàn explained + how the changes would improve his workflow when dealing with + patches. But Junio Hamano and Jeff King, alias Peff, replied saying + that they had trouble understanding the purpose of the series from + the explanations in the cover letter. + + After a discussion with Peff and Junio, it turns out that using + the `--full-index` option is a better approach to help Đoàn's workflow + (the option was specifically designed to ensure that the index + line in the `--patch` format can be used to exactly identify the + objects involved in the change to help the users, which was what + Đoàn's workflow wanted). However, a consensus was reached that + Đoàn's patch series was worth moving forward, because it improved + consistency between the diff formats. + + So Đoàn sent a + [version 2](https://lore.kernel.org/git/cover.1597146478.git.congdanhqx@gmail.com/) + of his patch series with only changes in the cover letter and in the + commit message of the second patch. + + Junio replied to the first patch of the series though. This patch + changed how `--no-abbrev` was dealt with. Junio asked for + clarifications in the commit message, especially about why the patch + was necessary. + + So Đoàn sent a + [version 3](https://lore.kernel.org/git/cover.1597364493.git.congdanhqx@gmail.com/) + of his patch series with only changes in the commit message of the + first patch. After further discussion with Junio, it appears that + the patch was not actually necessary. + + In the meantime though Gábor Szeder found that the tests in the + second patch were failing when run with + `GIT_TEST_DEFAULT_HASH=sha256`. This setting makes Git use the + [SHA-256 hash algorithm](https://en.wikipedia.org/wiki/SHA-2) + instead of the usual + [SHA-1 hash algorithm](https://en.wikipedia.org/wiki/SHA-1) + for object names. + + A discussion about the best approach to fix this then followed + between Đoàn, Junio and Brian M. Carlson, who has been working for a + long time on implementing support for SHA-256 in Git. + + Đoàn eventually sent a + [version 4](https://lore.kernel.org/git/cover.1597926783.git.congdanhqx@gmail.com/) + of his patch series, where the first patch of his version 3 had been + discarded, but a new patch to improve handling of SHA-256 object + names in the tests replaced it. + + Junio and Đoàn discussed further improvements to the commit messages + of both patches. Then Đoàn sent a + [version 5](https://lore.kernel.org/git/cover.1598010556.git.congdanhqx@gmail.com/) + taking these improvements into account. + + The patch series has since been merged into the 'master' branch. + + + +## Developer Spotlight: Đoàn Trần Công Danh + +* Who are you and what do you do? + + I'm just another average developer addicted to an exotic environment. + Outside of my $dayjobs, I maintain Git and some other packages for + VoidLinux. + +* What would you name your most important contribution to Git? + + I would consider fixing remaining problems with musl libc my most + important contributions to Git, since I mostly stay inside my musl + box these days. + +* What are you doing on the Git project these days, and why? + + I mostly watch for sideline these days, since I'm busy with other + things. Occasionally, I jump in one or two discussion since that topic + looks relevant to me. Sometimes, I write a patch or two to support my + own jobs. + +* 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 don't have anything specific in mind, except the transition into the + new hash algorithm, brian m. carlson has done a very good job, and + I understand the transition would require a long transition period, + testing, a lot of testing. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + The diff to merge-base notation (upstream...fork) of the diff family. + This has been floating in the mailing list for a while, and I won't + waste this opportunity to not mention it again. + + There's an on-going change from Denton Liu to [support `--merge-base`](https://public-inbox.org/git/cover.1600600823.git.liu.denton@gmail.com/) + into the diff family. Hopefully, people can retrain their brain-muscles to + use this new option instead. + +## Releases + ++ GitHub Enterprise [2.22.0](https://enterprise.github.com/releases/2.22.0/notes), +[2.21.7](https://enterprise.github.com/releases/2.21.7/notes), +[2.20.16](https://enterprise.github.com/releases/2.20.16/notes), +[2.19.22](https://enterprise.github.com/releases/2.19.22/notes), +[2.21.6](https://enterprise.github.com/releases/2.21.6/notes), +[2.20.15](https://enterprise.github.com/releases/2.20.15/notes), +[2.19.21](https://enterprise.github.com/releases/2.19.21/notes) ++ GitLab [13.4](https://about.gitlab.com/releases/2020/09/22/gitlab-13-4-released/), +[13.3.6](https://about.gitlab.com/releases/2020/09/14/gitlab-13-3-6-released/), +[13.3.5](https://about.gitlab.com/releases/2020/09/04/gitlab-13-3-5-released/), +[13.3.4](https://about.gitlab.com/releases/2020/09/02/security-release-gitlab-13-3-3-released/), +[13.3.2](https://about.gitlab.com/releases/2020/08/28/gitlab-13-3-2-released/), +[13.3.1](https://about.gitlab.com/releases/2020/08/25/gitlab-13-3-1-released/) ++ Bitbucket Server [7.6](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitKraken [7.3.2](https://support.gitkraken.com/release-notes/current), +[7.3.1](https://support.gitkraken.com/release-notes/current), +[7.3.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.5.5](https://desktop.github.com/release-notes/) + +## Other News + +__Events__ + +* The first [Git Contributors' Inclusion Summit](https://code.googlesource.com/git/summit/2020/+/main/index.md) + happened on Monday, September 14th, and Tuesday, September 15th. It + was attended by around 30 people. Some notes were taken but it's not + clear if they are going to be publicly available. + +__Various__ + +* [Set the default branch for newly-created GitHub repositories](https://github.blog/changelog/2020-08-26-set-the-default-branch-for-newly-created-repositories/) + on GitHub Blog. + On **October 1, 2020**, if you haven't changed the default branch + for new repositories for your user, organization, or enterprise on + GitHub, it will automatically change from **`master`** to + **`main`**. You can opt out of this change at any time. Existing + repositories will continue to have the same default branch they have + now. + +* ['There is no way we can keep coding local': GitPod's cloud + development platform released into sunlight of open source](https://www.theregister.com/2020/08/25/gitpod_open_sources_cloud_development_platform/) -- + _The Register_ chats with co-founder Sven Efftinge. + +* [Discussions](https://lore.kernel.org/git/20200828065609.GA2105118@coredump.intra.peff.net/) + have been going on about the Git project participating in the next + [Outreachy](https://www.outreachy.org/) round. So far + [3 projects](https://www.outreachy.org/apply/project-selection/#git) + have been proposed. + +__Light reading__ + +* Arista Networks, a Fortune 500 company, has rolled out mandatory + commit signing across their Git repositories. Read about their + journey at + + and learn about how they: + * Manage code signing keys across a large company + * Enforce that all commits are signed + * Audit Git repositories to ensure that no unsigned commits are added. + +* Guillaume Papin in his development notes [on a compilation database](https://sarcasm.github.io/notes/dev/compilation-database.html) + (a concept that includes, but is not limited to a [JSON Compilation Database](http://clang.llvm.org/docs/JSONCompilationDatabase.html)) + includes [section on Git](https://sarcasm.github.io/notes/dev/compilation-database.html#git) + as one of (and at this time the only) case studies on open source projects. + + There is a patch by Philippe Blain to [add support for generating a JSON compilation database](https://lore.kernel.org/git/pull.714.git.1598815707540.gitgitgadget@gmail.com/t/#u) + to Git's Makefile. It is currently [merged into 'next'](https://github.com/git/git/commit/4f4cb66b091c1d87cd42e8a7905b479f3560b28b). + +* Keith Peters writes how to create your own [Git-based Wiki](https://www.bit-101.com/blog/2020/09/git-based-wiki/) + to save information that one might need later. The idea is to make + use of the fact that many Git hosting sites render Markdown on-line, + by storing the data in interlinked Markdown files -- the article + proposes the template to use. + +* [Patterns for writing better git commit messages](https://dev.to/helderburato/patterns-for-writing-better-git-commit-messages-4ba0) + by Helder Burato Berto, with references to other articles, and + a [`git commit` template](https://github.com/helderburato/dotfiles/blob/master/git/.gittemplates/commit). + +* [Learn Enough Git and Github to take part in the Weekly Challenge](https://dev.to/davorg/learn-enough-git-and-github-to-take-part-in-the-perl-weekly-challenge-gpm) + by Dave Cross (**not** intended as "beginners guide to Git and Github"). + +* [Git Concepts and Workflow for Beginners](https://livecodestream.dev/post/2020-08-21-git-concepts-and-workflow-for-beginners/) + by Juan Cruz Martinez on Live Code Stream. + +__Git tools and sites__ + +* [ugit: DIY Git in Python](https://www.leshenko.net/p/ugit/#) is a + tutorial to help learn about Git internals by building an + implementation of Git in Python. + +* [gitoxide](https://github.com/Byron/gitoxide) (`gix`) is a + command-line interface (CLI) to access Git repositories. It's + written to optimize the _user-experience_, and perform as _good or + better than the canonical implementation_. + + It provides an idiomatic, lean, fast and safe pure Rust + implementation of Git, and it also provides an easy and safe to use + API in the form of various small crates for implementing your own + tools. + +* [grokmirror-2.0](https://lore.kernel.org/git/20200921170651.aszbydzvnj7l4y2w@chatter.i7.local/) + is a Git mirroring software announced by Konstantin Ryabitsev on the + Git mailing list. It was developed by kernel.org for their own use. + +* [GitQlient](https://github.com/francescmm/GitQlient), pronounced as + git+client (_/gɪtˈklaɪənt/_), is a multi-platform Git client written + with Qt, originally forked from [QGit](https://github.com/tibirna/qgit). + + Related project is [GitQlientPlugin](https://github.com/francescmm/GitQlientPlugin), + the project to build an integrated QtCreator plugin of GitQlient. + +* [Graphtage: A New Semantic Diffing Tool](https://blog.trailofbits.com/2020/08/28/graphtage/) + is a command line utility and underlying library for semantically + comparing and merging tree-like structures such as JSON, JSON5, XML, + HTML, YAML, and TOML files. You can even compare files that are in + two different formats. When paired with the [PolyFile tool](https://blog.trailofbits.com/2019/11/01/two-new-tools-that-tame-the-treachery-of-files/) + you can semantically diff arbitrary file formats. + +* [Sourcetrail](https://www.sourcetrail.com/) is a free and + [open-source](https://github.com/CoatiSoftware/Sourcetrail) + cross-platform interactive source explorer, that helps you get + productive on unfamiliar source code. It currently supports + C, C++, Java and Python. + +* [`git-in`](https://gist.github.com/phil-blain/d350e91959efa6e7afce60e74bf7e4a8) is + a small Python script to import a message or an entire thread from a mailing list + to an IMAP mailbox. Very useful when you are **not** subscribed to the list but want to answer + an email from the list, while being be able to quote parts of the message. + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Ethan Rahn, Philippe Blain and Junio Hamano. diff --git a/_posts/2020-10-30-edition-68.markdown b/_posts/2020-10-30-edition-68.markdown new file mode 100644 index 000000000..f6488f813 --- /dev/null +++ b/_posts/2020-10-30-edition-68.markdown @@ -0,0 +1,287 @@ +--- +title: Git Rev News Edition 68 (October 30th, 2020) +layout: default +date: 2020-10-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 68 (October 30th, 2020) + +Welcome to the 68th 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](https://git.github.io). + +This edition covers what happened during the month of September 2020. + +## Discussions + + + + + +### Support + +* [Apply Git bundle to source tree?](https://lore.kernel.org/git/CAHpGcMJqmUmCR_u3fxSVppzwBo8_6RJG5-WLrXAWXm+OQ6_3bA@mail.gmail.com/) + + Andreas Grünbacher asked the mailing list if there was "a way to + apply a particular head in a bundle to a source tree". Using the + Linux kernel as an example, he said he would like to create + [a bundle](https://git-scm.com/docs/git-bundle) containing Git + objects from version 5.8 to version 5.9-rc1: + + ``` + $ git bundle create v5.9-rc1.bundle v5.8..v5.9-rc1 + ``` + + and then be able to "apply" this bundle either to an existing + repository or only a source tree that would already contain code for + version 5.8. + + Taylor Blau replied to Andreas that there is no such thing as + `git bundle apply`, but that `git fetch` and `git pull` can be used + to update an existing repo from a bundle, for example: + + ``` + $ git pull /path/to/bundle 'refs/tags/v5.9-rc1' + ``` + + Andreas replied to Taylor that he was looking for a way to apply a + bundle to an actual source tree, not a Git repository, but Taylor + didn't think it was possible. + + Then another Andreas, Andreas Schwab, chimed in to discuss with + Andreas Grünbacher what basis was needed to "apply" a bundle. + + In the meantime Junio Hamano, the Git maintainer, replied to the + original email from Andreas G. saying that a bundle created with + "v5.8..v5.9-rc1" was not like a patch but rather "an equivalent of a + (shallow) repository" that required having v5.8 for the bundle to be + usable. Junio suggested ways to use such a bundle to update and then + work in an existing repo that has v5.8, and asked for ideas to + improve the `git bundle` documentation. + + Andreas G. replied to Junio that the documentation was fine, and + that he then saw that there's simply not enough information in a + bundle for what he wants to achieve on a source tree. + + Konstantin Ryabitsev, a maintainer of kernel.org, also replied to + Andreas G.'s initial email suggesting the following command: + + ``` + curl --header 'Accept-Encoding: gzip' -L https://git.kernel.org/torvalds/p/v5.9-rc1/v5.8 | + gunzip - | git apply + ``` + + Andreas G. liked it, but said that the use case he was thinking + about was to replace the patches that are, along with a baseline + release, in source packages provided by Linux distributions. As + bundles would provide actual Git history, they would be nicer than + patches, if they could replace them. + + Thomas Guyot-Sionnest replied that bundles could do that and that + it was a "neat idea". He said "bundles could be used for both the base + release *and* patches". The source packages would be "bigger + initially than a single release", but old bundles could help + downloading just the additional bits needed for the next + versions. That would help packagers as patches are "best maintained + in Git" already. + + Thomas also mentioned that he has been using bundles "since the very + beginning" for backups as it's "an efficient way to archive an entire + bare repo into a single file and ship it offsite". + + Brian M. Carlson also replied to Andreas G. saying that "Debian + considered using Git as part of the 3.0 (git) format", but that + there were issues with upstream having "non-free or undistributable + material in their repositories". "Tarballs can be repacked, but it's + harder to rewrite Git history to exclude objects." + + +## Developer Spotlight: Matheus Tavares Bernardino + +* Who are you and what do you do? + + I'm a software developer and MSc student, living in São Paulo, Brazil. I + started contributing to Git just over a year ago, through Google Summer of Code + (GSoC). During the program, I was fascinated with the internal mechanics of Git + and with Git features that I had not known until then. So, at the end of GSoC, I + definitely wanted to stick around and learn more. Today, I'm working as a + contract developer for Amazon, seeking to parallelize checkout and other Git + operations. + +* What would you name your most important contribution to Git? + + The improvements in `git grep`'s parallelism, during GSoC. With + these changes, we've got [up to 3.3x faster](https://matheustavares.gitlab.io/posts/git-2.26-faster-git-grep) + `git grep` searches in the object store, using threads. + +* What are you doing on the Git project these days, and why? + + I'm currently working on parallelizing checkout. The parallel version has shown + to be particularly effective for repositories located on SSDs or over network + file systems ([here are some benchmark numbers](https://lore.kernel.org/git/cover.1597093021.git.matheus.bernardino@usp.br/)). + The idea is to make it available to all commands that perform checkout: from + the plumbing `git read-tree` to `git clone`, `git sparse-checkout`, and + `git checkout` itself. + + It's been an exciting and challenging project! And containing patches + and ideas from two previous parallel checkout approaches (by + [Duy](https://lore.kernel.org/git/CACsJy8Ab=q0mbdcXn9O7=dKHaOuhUCNk4g6BU5kZHdPM+z7yng@mail.gmail.com/) + and [Jeff Hostetler](https://github.com/gitgitgadget/git/pull/628)), I think it + really goes to show the power of collaboration and open-source. + +* 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? + + Hmm, it would be nice to try to minimize the global states in the codebase. We + have a fair amount of thread-unsafe operations, due to reads and writes to + global variables or function-scoped static variables. Such variables do offer + quite practical mechanics, but they can also hinder the process of adding + multi-thread support. Furthermore, they are sometimes hard to locate, which can + potentially lead to race conditions. The alternative approach, using + multi-processes, usually requires writing more code for communication and + synchronization (besides having an extra cost for subprocess spawning). + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + Hmm, nothing comes to mind right now. + +* What is your favorite Git-related tool/library, outside of Git itself? + + I rarely use Git-related tools besides Git itself. But I've always wanted to + try and incorporate `tig blame` more in my daily life. I use `git blame` quite + a lot, to dig through the code's history and find answers regarding specific + designs or implementations. In that sense, what I find most attractive about + the `tig` interface, is that it allows to interactively load blame for parent + commits, which is quite handy. I guess I still tend to go with the plain + `git blame` out of habit. + +## Releases + ++ Git [2.29.1](https://public-inbox.org/git/xmqq4kmlj9q9.fsf@gitster.c.googlers.com/), +[2.29.0](https://public-inbox.org/git/xmqqy2k2t77l.fsf@gitster.c.googlers.com/), +[2.29.0-rc2](https://public-inbox.org/git/xmqqk0vrdxid.fsf@gitster.c.googlers.com/), +[2.29.0-rc1](https://public-inbox.org/git/xmqq7drzv1bn.fsf@gitster.c.googlers.com/), +[2.29.0-rc0](https://public-inbox.org/git/xmqqa6x070tn.fsf@gitster.c.googlers.com/) ++ Git for Windows [2.29.1](https://github.com/git-for-windows/git/releases/tag/v2.29.1.windows.1), +[2.29.0](https://github.com/git-for-windows/git/releases/tag/v2.29.0.windows.1) ++ git-filter-repo [2.29.0](https://public-inbox.org/git/CABPp-BG+uP2-t62AfgBauvoRtXfF4pU-xXKq3+YEEhjDdiHR_w@mail.gmail.com/) ++ git-assembler [1.2](https://public-inbox.org/git/87mu1f2rc0.fsf@wavexx.thregr.org) ++ libgit2 [1.1.0](https://github.com/libgit2/libgit2/releases/tag/v1.1.0) ++ GitLab [13.3.8](https://about.gitlab.com/releases/2020/10/23/gitlab-13-3-8-released/), +[13.5](https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/), +[13.5.1](https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-1-released/), +[13.4.4](https://about.gitlab.com/releases/2020/10/15/gitlab-13-4-4-released/), +[13.4.3](https://about.gitlab.com/releases/2020/10/05/gitlab-13-4-3-released/), +[13.4.2](https://about.gitlab.com/releases/2020/10/01/security-release-13-4-2-release/) ++ Bitbucket Server [7.7](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitHub Enterprise [2.22.2](https://enterprise.github.com/releases/2.22.2/notes), +[2.21.10](https://enterprise.github.com/releases/2.21.10/notes), +[2.20.19](https://enterprise.github.com/releases/2.20.19/notes), +[2.19.25](https://enterprise.github.com/releases/2.19.25/notes), +[2.22.1](https://enterprise.github.com/releases/2.22.1/notes), +[2.21.9](https://enterprise.github.com/releases/2.21.9/notes), +[2.20.18](https://enterprise.github.com/releases/2.20.18/notes), +[2.19.24](https://enterprise.github.com/releases/2.19.24/notes) ++ GitHub Desktop [2.5.6](https://desktop.github.com/release-notes/) ++ TortoiseGit [2.11.0](https://tortoisegit.org/download/) + +## Other News + +__Various__ + +* [The default branch for newly-created repositories (on GitHub) is now 'main'](https://github.blog/changelog/2020-10-01-the-default-branch-for-newly-created-repositories-is-now-main/). + The history of the term `master` in Git was covered in [Git Rev News Edition #65](https://git.github.io/rev_news/2020/07/29/edition-65/#discussions), + if one is interested. + +* [Mercurial planning to transition away from SHA-1 [LWN.net]](https://lwn.net/Articles/832111/); + discovering the problem with SHA-1 was discussed in [Git Rev News Edition #25](https://git.github.io/rev_news/2017/03/15/edition-25/), + and the state of SHA-1 transition in Git (in 2018) in [Edition #41](https://git.github.io/rev_news/2018/07/18/edition-41/). + +* [What's cooking on Sourcehut? September 2020](https://sourcehut.org/blog/2020-09-15-whats-cooking-september-2020/) and [October 2020](https://sourcehut.org/blog/2020-10-15-whats-cooking-october-2020/); + Sourcehut, or [sr.ht](https://sr.ht/), is a software forge which was covered in + [Git Rev News Edition #46](https://git.github.io/rev_news/2018/12/19/edition-46/#other-news). + +* [Google Summer of Code 2021](https://opensource.googleblog.com/2020/10/google-summer-of-code-2021-is-bringing.html) + has been announced with significant changes compared to previous + editions. Notably coding hours and period will be reduced from 350 + hours and 12 weeks to 175 hours and 10 weeks; there would be 2 evaluations + (instead of 3). Additionally, eligibility requirements will be relaxed, + among others allowing people participating in a variety of different + licensed academic programs, not just students of accredited university programs. + +* [How Gitlab puts gRPC in the Real World](https://www.programmableweb.com/news/how-gitlab-puts-grpc-real-world/analysis/2020/10/28) + talks about GitLab internals, especially access and management of + Git repos through gRPC and a software layer written in Go called + Gitaly. + +__Light reading__ + +* [Sourcegraph: Devs are managing 100x more code now than they did in 2010](https://arstechnica.com/gadgets/2020/10/sourcegraph-devs-are-managing-100x-more-code-now-than-they-did-in-2010/) + by Jim Salter on ArsTechnica. +* [Git scraping: track changes over time by scraping to a Git repository](https://simonwillison.net/2020/Oct/9/git-scraping/) + by Simon Willison on his weblog. +* [Pachyderm and the power of GitHub Actions: MLOps meets DevOps](https://github.blog/2020-10-15-pachyderm-and-the-power-of-github-actions-mlops-meets-devops/) + by Kathryn Hsu on GitHub Blog; [Pachyderm](https://www.pachyderm.com/), + a data version control tool, was covered in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/#other-news). +* [Project Cambria: Translate your data with lenses](https://www.inkandswitch.com/cambria.html), + about the [Cambria](https://github.com/inkandswitch/cambria) tool to help + translate between data schemas while maintaining compatibility between + different versions, APIs and components. +* [Stockpiling blog posts](https://github.polettix.it/ETOOBUSY/2020/10/07/stockpiling-posts/) + for publishing when out of time with Git, a short article by Flavio Poletti. +* [The Code Review Guide](https://dev.to/camilaleniss/the-code-review-guide-4gfo) + by Camila Lenis on Dev.to. +* [Beginner's guide to Git and Open-Source Contribution](https://dev.to/williamotieno/beginner-s-guide-to-git-and-open-source-contribution-34h) + by William Otieno on Dev.to. +* [What is Git Rebase and How Is it Different from Merging?](https://www.cloudsavvyit.com/852/what-is-git-rebase-and-how-is-it-different-than-merging/) + by Anthony Heddings. +* [How Git works inside](https://docable.cloud/chrisparnin/examples/tutorials/Git.md): + an interactive [Docable](https://github.com/ottomatica/docable) notebook, + rendered as static HTML with animated GIFs. + + +__Git tools and sites__ + +* [bit](https://github.com/chriswalz/bit) is an experimental modernized Git CLI, + written in Go, built on top of `git`, that provides happy defaults and other + niceties, with some commands taken from [git-extras](https://github.com/tj/git-extras). + It takes some inspiration from [Gitless](https://gitless.com/), which was + covered in [Git Rev News Edition #20](https://git.github.io/rev_news/2016/10/19/edition-20/#other-news). + +* [nb](https://github.com/xwmx/nb) is a command line note-taking, bookmarking, + archiving, and knowledge base application with plain-text data storage, + encryption, and Git-backed versioning and syncing, written in Bash. + +* [Cambria](https://github.com/inkandswitch/cambria) is a Javascript/Typescript + library for converting JSON or YAML data between related schemas, via _lenses_ + (bidirectionally specifying a transformation). This helps version-control + data exchange formats. + +* [Codeberg](https://codeberg.org/) is a collaboration platform and git hosting + for free and open source software, content, projects. It is hosted in EU. + +* [Git exercises](https://gitexercises.fracz.com/) is an open-source platform + and service where one can learn and practice Git and discover its features, + with the help of 23 exercises. + +* [git-send-email.io](https://git-send-email.io/) by [Sourcehut](https://sourcehut.org/) + is a step-by-step tutorial on how to contribute to email-driven projects + like the Linux kernel, PostgreSQL, or Git. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Matheus Tavares Bernardino. diff --git a/_posts/2020-11-27-edition-69.markdown b/_posts/2020-11-27-edition-69.markdown new file mode 100644 index 000000000..3705cad6a --- /dev/null +++ b/_posts/2020-11-27-edition-69.markdown @@ -0,0 +1,323 @@ +--- +title: Git Rev News Edition 69 (November 27th, 2020) +layout: default +date: 2020-11-27 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 69 (November 27th, 2020) + +Welcome to the 69th edition of [Git Rev News](https://git.github.io/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 [About Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the month of October 2020. + +## Discussions + + + +### Reviews + +* [[PATCH] userdiff: support Bash](https://lore.kernel.org/git/373640ea4d95f3b279b9d460d9a8889b4030b4e9.camel@engmark.name/) + + Victor Engmark sent a patch to add support for Bash and POSIX shell + to the userdiff mechanism. This mechanism is used by the diff code + to make diffs more informative and better suited to the content, + in this case Bash or POSIX shell programs. + + As explained in [the documentation](https://git-scm.com/docs/gitattributes#_defining_a_custom_hunk_header), + diffs contain sections called hunks that look like: + + ``` + @@ -k,l +n,m @@ TEXT + ``` + + where `k`, `l`, `n` and `m` are numbers indicating the lines that + are concerned, and `TEXT`, which is called the "hunk-header", is a + part of a line of the file to further help identify the related + context of the diff in the file. + + The best thing for programs is often to have the name of the + enclosing function, or method, in the hunk-header. As detecting + functions is programming language specific, it's the role of the + userdiff mechanism to provide a regex (regular expression) that can + be used to do that. + + Another role of the userdiff mechanism is to provide a regex to + [customize word diffs](https://git-scm.com/docs/gitattributes#_customizing_word_diff). + + Victor's patch then mainly consisted in adding regexes for Bash and + POSIX shells to `userdiff.c`, along with some documentation and a + lot of tests. + + Junio Hamano, the Git maintainer, replied to Victor, by commenting a + bit on the tests and a lot on the complex regex to detect a + function. He wondered if it correctly accepts white spaces + where they are allowed, and suggested for more clarity to break it down like this: + + ``` + "^[ \t]*" /* (op) leading indent */ + "(" /* here comes the whole thing */ + "(function[ \t]+)?" /* (op) noiseword "function" */ + "[a-zA-Z_][a-zA-Z0-9_]*" /* identifier - function name */ + "[ \t]*(\\([ \t]*\\))?" /* (op) start of func () */ + "[ \t]*(\\{|\\(\\(?|\\[\\[)" /* various "opening" of body */ + ")", + ``` + + Victor then sent a [version 2](https://lore.kernel.org/git/1442e85cfbe70665890a79a5054ee07c9c16b7c6.camel@engmark.name/) + of his patch implementing Junio's suggestions and answering his + comments. + + Johannes Sixt then suggested a number of improvements especially + about the tests, and about the regex to customize word diffs. Victor + replied about the latter asking for pointers to look at, as it + seemed that there were no tests for that. + + Victor nevertheless sent a [version 3](https://lore.kernel.org/git/6c6b5ed2166ec2c308c53bf87c78b422fdc5084f.camel@engmark.name/) + implementing Johannes' suggestions, and Johannes indeed replied that + he was happy with the result. Junio was also happy with the result + after fixing a typo in the commit message. + + The patch was later merged to the `next` and then `master` branches, + so Git should soon support shell scripts in a better way, while it + itself has been developed for a long time using shell scripts. + + + +## Developer Spotlight: Philippe Blain + +* Who are you and what do you do? + + I'm a scientist at the Canadian Center for Meteorological and + Environmental Prediction, in Montréal, Québec, Canada. I'm part of the + development team for the numerical model we use to predict the movement, + growth and melt of sea-ice, the frozen parts of the Arctic and Antarctic + oceans. Like most computer models in the field of weather forecasting, + this software is written in good old Fortran, and runs on our + supercomputers. We use Git extensively to track changes across all + layers of our technological stack, and I quickly developed an interest + in Git's inner workings. + +* What would you name your most important contribution to Git? + + Since I started contributing to the project a little more than one year + ago, I've mostly been trying to fix the bugs I encounter in the course + of my daily work. So I'm not sure which one of my topics has had the + biggest impact on other users. However, I can say that the contribution + I'm most proud of is [fixing `git checkout --recurse-submodules`](https://github.com/git/git/compare/d0654dc308b0ba76dd8ed7bbb33c8d8f7aacd783...846f34d3514b81764dea7c2a4851f6187ab31aad) + to correctly switch between branches when one branch has nested + submodules and the other branch has no submodules at all. I learned + enormously during the process of developing this fix, not only about how + Git ["unpack trees"](https://github.com/git/git/blob/master/unpack-trees.c) + to keep the index, working directory and HEAD consistent, but also how + [`fork` and `exec`](https://en.wikipedia.org/wiki/Fork%E2%80%93exec) + calls work and especially how to debug such spawned processes using GDB + and LLDB. + +* What are you doing on the Git project these days, and why? + + Right now I'm working on a fix to prevent `git checkout + --recurse-submodules` from losing uncommitted work in submodules. + Although the documentation says this shouldn't happen, I've found a few + cases where it does, and since it's never a nice experience to lose + work, I'd like to fix that. + +* 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? + + Apart from rewriting the whole thing in C++, you mean? Jokes aside, I + would like for more work to be put towards better submodule support. + There was a colossal effort a couple of years ago to add + `--recurse-submodules` flags to several Git commands, so that submodules + worktrees stay up to date when switching between superproject commits. + Unfortunately this effort has died off due to core contributors to the + submodule code changing jobs, and some porcelain commands still lack + that capability. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + I think it's unfortunate that the dot-dot vs. dot-dot-dot syntax mean + different things in `git diff` than in the rest of Git commands. It's + another one of those tricky things that users have to remember. The fact + that `checkout` and `reset` have so many different modes of operation + also make them confusing for beginners. The introduction of `git switch` + and `git restore` should help with that, though. + +* What is your favorite Git-related tool/library, outside of Git itself? + + Since I've heard of it I've been using + [`diff-so-fancy`](https://github.com/so-fancy/diff-so-fancy#readme) as a + way to make Git diffs more easily readable. Apart from that I mostly + stick to the Git command line. Recently I discovered + [`git-crecord`](https://github.com/andrewshadura/git-crecord#readme), an + ncurses interface for, among other features, interactive line-by-line + staging. + +## Releases + ++ Git [2.29.2](https://public-inbox.org/git/xmqqlffo4qjw.fsf@gitster.c.googlers.com/) ++ Git for Windows [2.29.2(2)](https://github.com/git-for-windows/git/releases/tag/v2.29.2.windows.2), +[2.29.2(1)](https://github.com/git-for-windows/git/releases/tag/v2.29.2.windows.1) ++ GitHub Enterprise [2.22.4](https://enterprise.github.com/releases/2.22.4/notes), +[2.21.12](https://enterprise.github.com/releases/2.21.12/notes), +[2.20.21](https://enterprise.github.com/releases/2.20.21/notes), +[2.22.3](https://enterprise.github.com/releases/2.22.3/notes), +[2.21.11](https://enterprise.github.com/releases/2.21.11/notes), +[2.20.20](https://enterprise.github.com/releases/2.20.20/notes), +[2.19.26](https://enterprise.github.com/releases/2.19.26/notes) ++ Bitbucket Server [7.8](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.2.5.1](https://www.gerritcodereview.com/3.2.html#3251), +[3.2.5](https://www.gerritcodereview.com/3.2.html#325), +[3.1.10](https://www.gerritcodereview.com/3.1.html#3110), +[3.0.15](https://www.gerritcodereview.com/3.0.html#3015), +[2.16.25](https://www.gerritcodereview.com/2.16.html#21625), +[2.15.21](https://www.gerritcodereview.com/2.15.html#21521), +[2.14.22](https://www.gerritcodereview.com/2.14.html#21422) ++ GitLab [13.6.1](https://about.gitlab.com/releases/2020/11/23/gitlab-13-6-1-released/), +[13.6](https://about.gitlab.com/releases/2020/11/22/gitlab-13-6-released/), +[13.5.4](https://about.gitlab.com/releases/2020/11/13/gitlab-13-5-4-released/), +[13.5.3](https://about.gitlab.com/releases/2020/11/03/gitlab-13-5-3-released/), +[13.5.2](https://about.gitlab.com/releases/2020/11/02/security-release-gitlab-13-5-2-released/) ++ GitKraken [7.4.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.6.0](https://desktop.github.com/release-notes/), +[2.5.7](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + +* [Announcing the Release of the Git Experience in Visual Studio](https://devblogs.microsoft.com/visualstudio/announcing-the-release-of-the-git-experience-in-visual-studio/); + the new Git tooling is now the default source control experience + in Visual Studio 2019, beginning with + [version 16.8](https://devblogs.microsoft.com/visualstudio/visual-studio-2019-v16-8/#git-productivity). +* Kernel.org manager Konstantin Ryabitsev announced that + [signed git pushes](https://people.kernel.org/monsieuricon/signed-git-pushes) + are now supported by the kernel.org system. Among other things, push signatures + can be preserved in a commit transparency log, + [which is also now provided](https://people.kernel.org/monsieuricon/introducing-the-kernel-org-git-transparency-log) + by kernel.org. + +__Light reading__ + +* [Git before GitHub](https://tarunbatra.com/blog/x/git-before-github/) + by Tarun Batra is a beginner-friendly article explaining how to submit + patches using git's built-in tools without using a platform like GitHub. +* [How to keep your Git history clean with interactive rebase](https://about.gitlab.com/blog/2020/11/23/keep-git-history-clean-with-interactive-rebase/) + by Tobias Günther on GitLab Blog. Interactive rebase is one of Git's + most versatile tools. Here's how to use it to correct commit messages, + fix mistakes, and more. +* [How I remember everything I learn](https://aurelio.me/blog/How-I-remember-everything-I-learn/) by Aurelio Ogliari; he uses [his personal wiki](https://github.com/nobitagit/knowledge), + which is nothing more than a Git repo (on GitHub), divided in folders + with a bunch of READMEs in each of them. +* [GitHub Actions for semi-static web sites](https://dev.to/davorg/github-actions-for-semi-static-web-sites-597g) + by Dave Cross on Dev.To explains how to keep a site up-to-date where + there are only a few ways that it can change, like [CPAN Dashboard](https://cpandashboard.com/). + ([GitHub Actions](https://github.com/features/actions), then beta, + were covered in [Git Rev News #44](https://git.github.io/rev_news/2018/10/24/edition-44/)). +* [What adding CI to 30 projects revealed](https://dev.to/szabgab/what-adding-ci-to-30-projects-revealed-3d4k) + by Gabor Szabo on Dev.To. Among others it found developer forgetting to add + file to Git repository, or pushing some changes, or that build script depends + on unreleased code or local configuration, or that not all dependencies were + declared. +* [Nbdev: A literate programming environment that democratizes software engineering best practices](https://github.blog/2020-11-20-nbdev-a-literate-programming-environment-that-democratizes-software-engineering-best-practices/) + by Hamel Husain on GitHub Blog. (See also nbdev's mention in the 'Git + tools and sites' section below.) [nbdev](https://nbdev.fast.ai/) + builds on top of Jupyter notebooks to encompass the entire software + development life cycle: automated generation of docs, Continuous + Integration (CI), writing tests directly in notebooks, etc. Many of + those features are integrated with GitHub (GitHub Actions, GitHub + Pages, GitHub Codespaces). +* [Git is simply too hard](https://changelog.com/posts/git-is-simply-too-hard): + a fancified excerpt of Mislav Marohnić's unpopular opinion on [Go Time #153](https://changelog.com/gotime/153) + podcast. See also [Gitless](https://gitless.com/), the experimental reworking of Git, + based on [research on difficulties in Git](https://gitless.com/#research), + mentioned in [Git Rev News #20](https://git.github.io/rev_news/2016/10/19/edition-20/). +* Gerrit Code Review fixes two important security vulnerabilities, + [Issue 13621](https://bugs.chromium.org/p/gerrit/issues/detail?id=13621) and + [Issue 13514](https://bugs.chromium.org/p/gerrit/issues/detail?id=13514). + They have been found during the test migrations of the + [OpenDev Code Review service](https://review.opendev.org/) to the latest version v3.2. + The issue was particularly sensitive for all those setups hosted in + Europe, because of the potential exposure to other people's personal + information, such as e-mail and external ids, and was impacting only + those very old setups that had recently migrated to v2.14 or later. + +__Git tools and sites__ + +* [repositorch](https://github.com/kirnosenko/Repositorch) is a VCS repository analysis + engine written in C#, which supports Git. It allows to get some basic and advanced + statistics including LOCs, Burndown, Code ownership, Defect density and more. +* [Githru](https://github.com/githru/githru) is an interactive visual analytics system + that enables developers to effectively understand the context of development history + through the [interactive exploration of Git metadata](https://githru.github.io/demo/). + It uses [novel techniques](https://arxiv.org/abs/2009.03115) (graph reconstruction, + clustering, and Context-Preserving Squash Merge (CSM) methods) to abstract + a large-scale Git commit graph. +* [nbdev](https://nbdev.fast.ai/) is a library that allows you to + develop a Python library in Jupyter Notebooks, putting all your + code, tests and documentation in one place. (See also nbdev's + mention in the 'Light reading' section above.) Among other features + it provides a robust, two-way sync between notebooks and source + code, and tools for merge/conflict resolution with notebooks in a + human readable format. It is set-up out of the box for integration + with GitHub Pages and GitHub Actions. Compare with + [nbdime](http://nbdime.readthedocs.io/en/latest/) -- a tool for + diffing and merging of Jupyter Notebooks, mentioned in + [Git Rev News #37](https://git.github.io/rev_news/2018/03/21/edition-37/), + and [jupytext](https://github.com/mwouts/jupytext) -- a plugin for + Jupyter that can save Jupyter notebooks as Markdown documents, or + Julia, Python or R scripts, or + [Review Notebook GitHub App](https://github.com/marketplace/review-notebook-app) + (free for Open Source and Education). +* [Flagsmith](https://www.flagsmith.com/) (formerly Bullet Train) is an open source + service to help release features with confidence by managing + [feature flags](https://martinfowler.com/articles/feature-toggles.html) + across web, mobile and server side applications. Hosted service is free + for smaller projects. +* [Tara.AI](https://tara.ai/) is a product development service that helps provide + clarity around the release cycle by connecting Git to tasks and sprints + (with GitHub integration). Base tier free forever plan has unlimited tasks, + sprints and workspaces, with no user limits; paid for features are + planned. +* [Git Credential Manager Core](https://github.com/microsoft/Git-Credential-Manager-Core) (GCM Core) + is a secure Git credential helper built on .NET Core that runs on Windows and macOS + (Linux support is in an early preview). It replaces the .NET Framework-based + [Git Credential Manager for Windows](https://github.com/microsoft/Git-Credential-Manager-for-Windows) (GCM), + and the Java-based [Git Credential Manager for Mac and Linux](https://github.com/microsoft/Git-Credential-Manager-for-Mac-and-Linux) (Java GCM). +* [Git-completion](https://github.com/felipec/git-completion/wiki/Zsh) + is a friendly fork of the official Git completion and prompt scripts + for Zsh and Bash. + It's a sister project of the [Oh My Zsh gitfast plugin](https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/gitfast). +* [git-crecord](https://github.com/andrewshadura/git-crecord) + is a `git` subcommand (written in Python), which allows users to interactively select + changes to commit or stage using a ncurses-based text user interface. +* [ForgeFed](https://notabug.org/peers/forgefed) - Federation Protocol for Forge Services. + ForgeFed (formerly GitPub) is an _upcoming_ decentralized federation protocol based on + the W3C's [ActivityPub](https://www.w3.org/TR/activitypub/), which extends + [ActivityStream 2.0](https://www.w3.org/TR/activitystreams-core/). It provides + a server to server API for pull request, forking and subscription of repositories + provided by Git web services (services like GitLab, Gogs, Gitea or SourceHut). +* [Visualizing Git Concepts with D3](http://onlywei.github.io/explain-git-with-d3/) + is a website designed to help you understand some basic Git concepts visually, + with sandboxes split by specific Git commands and a few specific real-world scenarios; + adding/staging your files for commit is not covered. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Philippe Blain, Semyon Kirnosenko, +Tarun Batra, Philip Oakley and Luca Milanesio. diff --git a/_posts/2020-12-26-edition-70.markdown b/_posts/2020-12-26-edition-70.markdown new file mode 100644 index 000000000..05da64b08 --- /dev/null +++ b/_posts/2020-12-26-edition-70.markdown @@ -0,0 +1,444 @@ +--- +title: Git Rev News Edition 70 (December 26th, 2020) +layout: default +date: 2020-12-26 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 70 (December 26th, 2020) + +Welcome to the 70th 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](https://git.github.io). + +This edition covers what happened during the month of November 2020. + +## Discussions + + +### General + +* Three [Outreachy interns](https://www.outreachy.org/alums/) have + been accepted to work on Git this winter: + + * Sangeeta from India will be mentored by Kaartic Sivaraam and + Christian Couder to work on the '*Accelerate rename detection and + the "range-diff" command in Git*' project. Sangeeta started + [blogging about her internship](https://sangu09.github.io/). + + * Joey Salazar from Costa Rica will be mentored by Emily Shaffer and + Jonathan Nieder to work on the '*Add Git protocol support to + Wireshark*' project. Joey also started + [blogging](https://jsal.home.blog/blog/). + + * Charvi Mendiratta from Faridabad, Haryana, India will be mentored + by Phillip Wood and Christian Couder to work on on the '*Improve + dropping and rewording commits in Git interactive rebase*' + project. Charvi also started + [blogging](https://charvi-077.github.io/). + +### Reviews + +* [[PATCH 00/10] Advertise trace2 SID in protocol capabilities](https://lore.kernel.org/git/cover.1604006121.git.steadmon@google.com/) + + Last October Josh Steadmon sent a patch series to the mailing + list. The goal of the patch series was to allow a Git client and a + Git server, that are communicating to perform a Git operation like a + push, a fetch or a clone, to share each other's trace2 session ID + (SID). + + [Trace2](https://git-scm.com/docs/api-trace2) is a relatively new + tracing mechanism that was developed primarily by Jeff Hostetler to + improve on the previous [trace mechanism](https://git-scm.com/docs/api-trace). + + These tracing mechanisms let users print debug, performance, and + telemetry logs to a file or a file descriptor, so that they can + better understand what's going on inside Git processes. + + Josh's patch series allows a Git client to record the server's + trace2 session ID in its logs, and vice versa, by advertising the + session ID in a new "trace2-sid" protocol capability. + + Josh asked 2 questions in the cover letter of his patch series + though. He first asked if the code in the `trace2/` directory was + supposed to contain only implementation details hidden from the rest + of Git and accessible only through the `trace2.h` and `trace2.c` + files. The reason for this question is that Josh's code needed to + access the trace2 session ID which was previously managed only in + `trace2/tr2_sid.h` and `trace2/tr2_sid.c`. + + Josh's second question was if it was OK to add a + `trace2.announceSID` configuration option for the feature his patch + series implemented. The reason is that some Git processes on + servers, like `git upload-pack`, have previously been prevented to + read some potentially malicious config options from local + repositories for security reasons. + + Jeff Hostetler was very happy with Josh's patch series saying "Very + nice! This should be very helpful when matching up client and server + commands." + + He also replied that he indeed intended the `trace2/` directory to + be opaque, so "that just `trace2.h` contains the official API". And he + suggested adding a new `trace2_session_id()` function to `trace2.h` + and `trace2.c`, that would just call the existing `tr2_sid_get()` + function from `trace2/tr2_sid.h` and `trace2/tr2_sid.c`. + + Jeff also pointed to the fact that the session ID of a process was + built up based on the session IDs of its parent processes. For + example a Git process spawned from another Git process will have a + session ID of the form `/`, where `` is the + session ID of its parent. And if it spawns another Git process, the + session ID of this new process will be of the form + `//`. + + Jeff also mentioned that if the `GIT_TRACE2_PARENT_SID` environment + variable, which is used to communicate the session ID of the parent + process, already contains something, for example 'hello', when the + initial Git process is launched, then the session IDs will + accumulate after this existing content, like + `hello///`. + + Jeff wondered if clients and servers should share only the last + session ID component, for example ``, instead of the full + session ID. + + While Jeff couldn't answer Josh's second question about possible + security issues with using a new `trace2.announceSID` configuration + option, Junio Hamano, the Git maintainer, replied that it was + probably OK, given the fact that Git processes, like `git + upload-pack`, already take into account at least some boolean config + options, like `uploadpack.allowrefinwant`. + + Josh thanked Jeff for his review, and said that in the + [version 2](https://lore.kernel.org/git/cover.1604355792.git.steadmon@google.com/) + of his patch series he had implemented the new `trace2_session_id()` + function in `trace2.h` and `trace2.c` Jeff had suggested, and that + it was probably OK for clients and servers to share their full + session ID rather than the last component. + + Junio asked Josh to document this design decision to share the full + session ID. Josh replied to Junio that he did that in the + [version 3](https://lore.kernel.org/git/cover.1605136908.git.steadmon@google.com/) + of his patch series. + + In reply to version 2 of the patch series though, Junio had also + requested that session IDs, how they look like, and what special + characters they can contain, should be better documented to help + third parties writing their own implementation of the protocol. + + This spawned a small discussion thread where Jeff, Ævar Arnfjörð + Bjarmason, Junio and Josh eventually agreed on limiting the content + of the `GIT_TRACE2_PARENT_SID` environment variable and session ID to + printable, non-whitespace characters that fit into a Git protocol + line. + + Another discussion following version 2 between Josh, Junio and + Johannes Schindelin, alias Dscho, was about Junio's suggestion to + separate the concept of "session" from the trace2 mechanism. This + led to the decision to use just "session ID", instead of "trace2 + session ID", in the documentation, and to call the new configuration + option `transport.advertiseSID` instead of `trace2.announceSID`. + + Other smaller discussions over details of the implementation and the + documentation followed version 2, but version 3 got merged into the + `next` and then the `master` branch. So this new feature will be + released in soon upcoming Git v2.30. + + + +## Developer Spotlight: Felipe Contreras + +* Who are you and what do you do? + + I'm a software engineer who has worked in all areas of software + development. These days they use the term "full stack developer" for a + developer that works on all areas of web development, which I have + done, but I've also worked on Linux kernel development, middleware, + UI; you name it. + + Right now I'm a freelancer offering services to local companies doing + mostly web development, but not quite. + + It's hard to pigeonhole me because I not only do software development, + I also write a blog (which is not only about software), I've moderated + online communities, and I read a lot from intellectuals regarding the + ongoing culture war, and so on. + + I guess you could say I'm a jack of all trades (but I've actually + mastered a few). + +* What would you name your most important contribution to Git? + + That's very hard to tell because I've worked all over the place, so + most of my changes are minor improvements. But I guess the one with + the biggest impact to users would have to be `git-remote-hg`; a + bidirectional bridge between Git and Mercurial. + + Ironically I've never had to use Mercurial, nor worked on a project + that uses Mercurial. However, I did work on projects that used + Subversion and CVS back in 2005, when Git started, and I found it + useful that there existed tools to use Git while working with other + version control systems. + + I used to contribute to Pidgin (the MSN protocol parts), which used + Monotone, and I refused to work on such a horrendous VCS, so I started + to work on scripts to convert Monotone repositories to Git, and I + contributed my patches back through Bugzilla (like all other + contributors). + + This gave me insight into the inner workings of Git, and eventually + when the Pidgin project decided to move to Mercurial (an obvious + mistake in my opinion), I started surveying the tools to convert from + Git to Mercurial, and I found lots of areas of improvement. + + Regarding these tools I would be remiss if I didn't give attribution + to Rocco Rutte, who created the first `fast-export` script, which I used + as inspiration for `git-remote-hg`, but unfortunately died of cancer in 2009. + Without his work I might not have started this particular journey. + + Using Rocco Rutte's program, I had the idea to take that approach, but + hide it inside Git's remote-helper infrastructure, which was + surprisingly easy. Everything else that came after was fine-tuning, + adding features, and improving Git's infrastructure to make such + features possible. + + In response to some pushback that I received from more established Git + developers -- who claimed that some of these changes were specific to + `git-remote-hg` -- I decided to create `git-remote-bzr` as a proof of + concept to interact with Bazaar (again, I never personally had to use + Bazaar), but it turned out there was a huge demand for such a tool, so + I kept working on it. + + Some GNU Emacs developers loved `git-remote-bzr`, and it probably helped + in the eventual move to Git, even though Richard Stallman initially + pushed back hard against it. + + So, even though I never really used `git-remote-hg` or `git-remote-bzr`, I + kept working at them because clearly other people did. I understand + all too well the frustration of working on a VCS that is foreign and + suboptimal, especially when you know Git has everything you need; it's + like being stranded. + +* What are you doing on the Git project these days, and why? + + A lot of things. I stopped working on the Git project for many years, + but right now I have motivation to work on it again, and there's + literally dozens of features I'm working on. Unfortunately my patches + have a tendency to not be accepted, so many of these will not end up + helping the end users, but I'm thinking of ways to make these + available outside of Git. + + The main one is improvements to `git pull`. Initially there was a + [complaint from a Red Hat employee](https://lore.kernel.org/git/742df4c2-2bc5-8a4b-8de1-cd5e48718398@redhat.com/) + about an annoying warning added + recently, which prompted me to look back at work I did in 2013 which + solves all this, but was never merged. Back then the `git pull` code + was written in shell script, now it's in C, so I had to rewrite all + this functionality. + + It's a lot of work because there are many different workflows, + configurations, and options that affect the way `git pull` works. I + think the bulk of the code is mostly done, but there's a few options I + would like to explore that I haven't mentioned yet in the mailing + list, since the current patch series is controversial as it is. + + Part of the work is reading back old mail threads which go back to 2008. + A lot of problems and suggestions have been mentioned throughout + the years, and my patch series tries to compile all of those, in + addition to the comments from 2020. + + The story of these changes is interesting enough that I have been + writing a blog post about it, which is going to be enormous, but a lot + more work is needed to finish it properly. Hopefully it will be ready + for the next edition of Git Rev News. + + In another irony; I don't even use `git pull` (I use `git fetch` + + `git merge` / `git rebase`). + +* If you could get a team of expert developers to work full time + on something in Git for a full year, what would it be? + + I would split Git into a library and a command line interface. + + Clearly there's a need for a stand-alone library, since there is + libgit2, but Git doesn't use libgit2, so one has to always catch up + with the other. + + Recently Ævar Arnfjörð Bjarmason mentioned a thought about somehow + splitting the porcelain and plumbing of Git; the part that is for + typical end users, and the part that is for advanced users or scripts. + Splitting the command line from the library would allow us to more + easily see what part belongs where. Plus, I would split the command + line into two; `git` and `git-tool`. The `git` command should be + for typical end users, and the documentation about those commands + should not include any implementation details, or plumbing. + + I believe having a clean command line, which hides implementation + details and plumbing, would be of great benefit to the average Git + user, and in addition would help developers visualize what changes are + more likely to affect the end user, plus where the focus of improving + documentation should be. + + Oh, and one person on the team should be not a developer, but a copy + editor, and his job would be to rewrite *all* the documentation. It's + probably incontrovertible that Git's documentation can be improved a + lot. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + I don't think I would remove anything from Git. + + Plus, I don't believe any good developer should stop worrying about + backwards compatibility, ever. I'm of the opinion that there's always + a way to implement changes that are incompatible with previous + versions, but there's a series of steps. First you add the new + functionality, then you add a deprecation period, then you make the + new functionality the default, but always allowing the user to access + the old functionality. + + It's a lot more work, and takes a lot more time, which is why many bad + projects don't do it, but I think you always need to worry about + backwards compatibility, and it's a good thing Git developers do worry + about that. + + OK, maybe `merge.defaultToUpstream`, nobody uses that. + +* What is your favorite Git-related tool/library, outside of Git itself? + + I don't really use anything outside of Git. + + I find Git vanilla to be mostly good enough to do everything I need; + and when I don't, I try to introduce that directly into Git itself. + + I created a fork of Git called `git-fc` with all the features I didn't + manage to land into Git upstream, but I have not updated it in some + years (it's in my endless to-do list), and even though I miss those + features a lot, I can manage. + + I also have a bunch of projects that add other functionality, like + [`git-related`](https://github.com/felipec/git-related), + [`git-reintegrate`](https://github.com/felipec/git-reintegrate), + and [`git-send-series`](https://github.com/felipec/git-send-series), + but I could live fine without those. + + I think the only tool I would find very hard to live without is + [`git-smartlist`](https://github.com/felipec/git-smartlist). Since + I use `gitk` a lot to visualize commit history, very often I just want + to see the history from the master branch to the current branch I'm + at, and while usually you can do that with `master..@`, that's not + always the case and `git smartlist` helps a lot in telling `gitk` + exactly what I want to see. + +* Outside of code, is there anything you would like to change about + the Git project? + + I think there's a disconnection between users and developers. Recently + I've been talking about the curse of knowledge; the better you know + something, the less you remember about how hard it was to learn. It's + very typical for experts to underestimate how hard it is to understand + something, because they've had many years of experience with it. + + One example is rebasing. Basically all Git developers are very + familiar with rebasing, so they can't imagine what it must be like for + a user to not know how to rebase, or worse; to not know what a rebase + is. But feedback from people whose job is to train users tells us the + vast majority of new users have no idea what a rebase is. + + Of course the Git developers care about the users, but many times we + have to imagine hypothetical users and their needs, and it's not rare + that these don't match the needs of real users. + + That's why [Git Users' Surveys](https://public-inbox.org/git/577E6F32.7020007%40gmail.com/) + are so important. Unfortunately they haven't been made in many years, + and to be honest I don't see much point in them if the developers + are not going to trust the results and use them to guide the project. + + In all the users' surveys the number one and two areas of improvement + without fail are: user-interface, and documentation, and I believe + those are the two areas that are neglected the most. + + I would take this feedback seriously, and as a project make a real + effort to try to improve in these areas. + +## Releases + ++ Git [2.30.0-rc2](https://public-inbox.org/git/xmqqtusc5djv.fsf@gitster.c.googlers.com/), +[2.30.0-rc1](https://public-inbox.org/git/xmqqsg82qur4.fsf@gitster.c.googlers.com/), +[2.30.0-rc0](https://public-inbox.org/git/xmqq7dpkdup6.fsf@gitster.c.googlers.com/) ++ Git for Windows [2.30.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.30.0-rc2.windows.1), +[2.30.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.30.0-rc1.windows.1), +[2.30.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.30.0-rc0.windows.1), +[2.29.2(3)](https://github.com/git-for-windows/git/releases/tag/v2.29.2.windows.3) ++ Gerrit Code Review [3.3.0](https://www.gerritcodereview.com/3.3.html) ++ GitHub Enterprise [2.22.6](https://enterprise.github.com/releases/2.22.6/notes), +[2.21.14](https://enterprise.github.com/releases/2.21.14/notes), +[2.20.23](https://enterprise.github.com/releases/2.20.23/notes), +[2.22.5](https://enterprise.github.com/releases/2.22.5/notes), +[2.21.13](https://enterprise.github.com/releases/2.21.13/notes), +[2.20.22](https://enterprise.github.com/releases/2.20.22/notes) ++ GitLab [13.7.1](https://about.gitlab.com/releases/2020/12/23/gitlab-13-7-1-released/), +[13.7](https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-released/), +[13.6.3](https://about.gitlab.com/releases/2020/12/10/gitlab-13-6-3-released/) +[13.6.2](https://about.gitlab.com/releases/2020/12/07/security-release-gitlab-13-6-2-released/) ++ GitKraken [7.4.1](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.6.1](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + +- Felipe Contreras shared his [sharness/test Vim syntax file to the list](https://lore.kernel.org/git/CAMP44s1D-Zp3KDS+Hi74a=Lkc7Nc_0qiEzQEF0Pmj=bD8i+=JQ@mail.gmail.com/). + It enables syntax highlighting for the body of test_success, test_failure etc. + +__Light reading__ + +- [Use the Git History to Identify Pain Points in Any Project](https://preslav.me/2020/03/01/use-the-git-history/) + "basic idea - files that change often (with some exceptions) tend to be the ones where most issues occur" - let's go find them with this useful command. Includes a useful follow on reading about your code crimes. +- [Commits are snapshots, not diffs](https://github.blog/2020-12-17-commits-are-snapshots-not-diffs/) + by Derrick Stolee on GitHub Blog. +- [Get up to speed with partial clone and shallow clone](https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/) + by Derrick Stolee on GitHub Blog. +- [Optimize your monorepo experience - GitHub Universe 2020](https://www.youtube.com/watch?v=RcqLV1lU408): + video of presentation by Derrick Stolee, Staff Software Engineer, GitHub. +- [The Philosophy of Scalar](https://github.com/microsoft/scalar/blob/main/docs/philosophy.md), + a part of [Scalar](https://github.com/microsoft/scalar/) docs; the tool itself, + intended to provide settings and extensions for Git to help manage large Git repositories, + was introduced in [Git Rev News #60](https://git.github.io/rev_news/2020/02/19/edition-60/) + and further mentioned in [Git Rev News #61](https://git.github.io/rev_news/2020/03/25/edition-61/). +- [How to Make Your Code Reviewer Fall in Love with You](https://mtlynch.io/code-review-love/) + by Michael Lynch; a good counterpart to [The Gentle Art Of Patch Review](https://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/) + by Sage Sharp from 2014. +- [8 Git aliases that make me more efficient](https://opensource.com/article/20/11/git-aliases) + by Ricardo Gerardi on Opensource.com. Use aliases to create shortcuts + for your most-used or complex Git commands. +- [10 Git Anti Patterns You Should be Aware of](https://speakerdeck.com/lemiorhan/10-git-anti-patterns-you-should-be-aware-of), + slide deck presented by Lemi Orhan Ergin at ITAKE UnConf 2018; + though one should take it and especially the proposed solutions with a critical eye. +- [Regular Expression Matching with a Trigram Index, or How Google Code Search Worked](https://swtch.com/~rsc/regexp/regexp4.html) + by Russ Cox (2012). + +__Git tools and sites__ + +- [Radicle](https://radicle.xyz/) intends to be a peer-to-peer stack for building software together, + based on Git and Radicle Link peer-to-peer protocol. + Compare with [ForgeFed](https://notabug.org/peers/forgefed) (formerly GitPub), + a federation protocol for software forges, mentioned in + [previous Git Rev News](https://git.github.io/rev_news/2020/11/27/edition-69/). +- [git-smartlist](https://github.com/felipec/git-smartlist) by Felipe Contreras; + a tool to help create typical revisions (e.g. `master..@`) by generic name, + so that you don’t have to. + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Felipe Contreras and Philip Oakley. diff --git a/_posts/2021-01-28-edition-71.markdown b/_posts/2021-01-28-edition-71.markdown new file mode 100644 index 000000000..c042f19f1 --- /dev/null +++ b/_posts/2021-01-28-edition-71.markdown @@ -0,0 +1,278 @@ +--- +title: Git Rev News Edition 71 (January 28th, 2021) +layout: default +date: 2021-01-28 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 71 (January 28th, 2021) + +Welcome to the 71st 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](https://git.github.io). + +This edition covers what happened during the month of December 2020. + +## Discussions + + + +### Reviews + +* [[PATCH 00/26] git-log: implement new --diff-merge options](https://lore.kernel.org/git/20201101193330.24775-1-sorganov@gmail.com/) + + Last November Sergey Organov sent a 26 patch long series to the + mailing list. This series added a number of new modes to + `git log --diff-merges=`. + + Before this patch series, there would be no diff for merge commits + unless one of `-m`, `-c` or `--cc` was given. And in case one of + these options was given, then `--diff-merges=off`, or its + `--no-diff-merges` synonym, could be used to remove that diff output + for merge commits. This was the only possible use of + `--diff-merges=`. + + Sergey's patch series introduced four new modes. Three of them, + "separate", "combined" and "dense-combined" do not generate new diff + output. They are just synonyms of `-m`, `-c` and `--cc` + respectively. + + The fourth new mode, called "first-parent", though allows to get the + same output as `-p --first-parent`, but "without the changes in + history traversal that the `--first-parent` option causes". + + Sergey's patch series also refactored some code and fixed a small + issue. In a follow up email Sergey asked questions related to + further possible issues related to how `-m`, `-c` and `--cc` + interact with `--oneline`. + + Elijah Newren replied to Sergey's questions, and a long discussion + involving Junio Hamano, the Git maintainer, started about different + technical topics, especially the interactions between `-p` and the + `-m`, `-c` and `--cc` options. + + Elijah and Philip Oakley also commented on small issues in a few + patches. + + Sergey then sent a new version, that he named v1, of his patch + series with 27 patches, so one more than in the original series. The + changes were mostly typo and documentation fixes. + + Elijah and Junio commented on the patch series. Elijah and Sergey + discussed some new `--remerge-diff` and `--remerge-diff-only` + options Elijah had been working on, and how there could also be a + related `--diff-merges=remerge` mode. + + Junio found a few issues and suggested some renaming and test + improvements. + + Sergey sent a new v2 version of his patch series with 33 patches, so + 6 more than in v1. One change compared to the previous version was + that the diff output for the new `--diff-merges` options didn't affect + non-merge commits. Another change was that short mnemonics + `--diff-merges=(1|m|c|cc)` were provided on top of long mode + names. A lot of smaller changes addressed Elijah's and Junio's + reviews. + + Elijah and Sergey then discussed further improvements especially to + the documentation. Felipe Contreras and Junio sometimes also chimed + in with further explanations or suggestions. + + Sergey sent a new v3 version, with 32 patches, one less than in v2. + The changes were mostly following reviewers' suggestions. Felipe + commented positively on one patch, and Junio said he didn't spot + anything objectionable in the series and was OK to start merging it + to the next branch. + + + +## Developer Spotlight: Sergey Organov + +* Who are you and what do you do? + + I'm a software engineer and system architect at JAVAD GNSS, working in their + Moscow Research Center, in Russia. We design (and manufacture) high-end + GNSS receivers, both hardware and software. Design and implementation of + receiver firmware is my primary job for about 25 years already. I'm + also responsible for the development tools our team is using, and that's + where GNU/Linux and then Git come to the picture. + + Graduated from "Moscow Engineering Physics Institute" back in 1989 and + qualified in "Experimental Methods in Nuclear Physics", I was always + interested in computing. I then worked for about 10 years in "Kurchatov + Institute" in the field of computer modeling of nuclear radiation and + detectors, as well as in advanced processing of experimental results. + Then, a few years later, I started to work for JAVAD as well, in parallel. + A few more years later, I left Kurchatov and entirely focused on + working for JAVAD full-time, which is my current job. + + Real-time embedded applications, also using Linux on the targets, is my + primary field of expertise nowadays. + +* What would you name your most important contribution to Git? + + I didn't contribute much. I'd name the method of rebasing of merge + commits, that has been [covered in the Git Rev News](https://git.github.io/rev_news/2018/04/18/edition-38#general) + some time ago, as the most important one. + +* What are you doing on the Git project these days, and why? + + Right now I'm working on `--diff-merges` options for `git log`. The + original stimulus was very surprising output of `git log -p -m` that + made me mad the first time I encountered it. After finishing initial + implementation of the `--diff-merges` options, I now aim at finally giving + `git log -m` natural meaning of printing the diff for merge commits with + respect to the first parent only. + +* 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? + + Actually, I have 2 favorites: + + 1. Designing support for explicit commits grouping, somewhat similar to + grouping objects in graphical editors, likely implemented as a container + commit capturing a particular part of the DAG. It'd be then seen as a + single commit by default, unless the user specifically asks to look inside. + If we had it, our typical history would be more linear, feature branches + essentially becoming single (group) commits, that'd make history simpler + to traverse and to reason about. + + Right now the only poor-man approximation for that is a branch that is merged + back to its origin (the true-non-evil merge, as I call it), which results in a + history that looks like a sequence of bubbles, but it lacks direct + support which the specific grouping feature would have. + + 2. Designing a new history editor that will aim at being the ultimate + replacement for both `git rebase` and `git cherry-pick`, which are + essentially the same thing at fundamental level. As useful as these + existing features are, they have wide opportunities for improvements + that apparently don't fit into the current design, and their history of + incremental adaptations to different needs made quite a mess of them. + + Covering all the functionality of `rebase` and `cherry-pick`, the two most + important new features I'd like to see are: + + - Ensuring, by design, one of the primary features of any reasonable + editing tool: carefully preserve the content if no actual editing has + been made or requested. This should be ensured even if the tool is + forced to do the full job of re-creating the history according to the + instructions. I.e., the cycle: load/mark-as-modified/save should result in + the original result by default. + + - Better replacement for to-do lists. Carefully designed format for + describing the DAG in a text form convenient for humans and for editing with + a text editor, with simple yet strictly defined syntax and semantics, + preferably supporting generic programming language features. For + example, it could be based on some existing language, say, Tcl. Yet it + should take the best features of the current format and look familiar + enough to be immediately useful without a significant learning cycle. + + [That said, do we need two teams of expert developers for that, or one + would suffice, I wonder?] + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + Support for octopus merges. Multiple (back) references could then be + reused for more useful things, like keeping history of rebasing, and/or + for commits grouping (see above). + +* If you could add something to Git without worrying about + backwards compatibility, what would it be? + + I'd add a simple model behind the Git command-line options, so that their + design came from the model rather than entirely from the use cases, as + it happens to be now. It'd play a similar positive role in UI design as + the Git core data model plays in the features design. + + Then, I sometimes think about the addition of a single NULL-commit, the + ultimate parent of all the Git commits all over the world. I'm not sure + it has enough value in simplifying corner cases in Git's implementation, + but it fits so nice into the elegant Git data model! + +* What is your favorite Git-related tool/library, outside of Git + itself? + + Emacs and the Magit, its interface to Git, in particular, as well as a + few parts of Emacs generic VC interface that features Git among others. + The Magit got to the point already where I rarely find myself using the Git + command-line directly, and then mostly for some batch-processing, or on + hosts where Emacs is not readily available. + +## Releases + ++ Git [2.30.0](https://public-inbox.org/git/xmqqk0t1g326.fsf@gitster.c.googlers.com/) ++ Git for Windows [2.30.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.30.0.windows.2), +[2.30.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.30.0.windows.1) ++ GitHub Enterprise [3.0.0](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.0.rc1) ++ GitLab [13.8](https://about.gitlab.com/releases/2021/01/22/gitlab-13-8-released/) +[13.7.4, 13.6.5 and 13.5.7](https://about.gitlab.com/releases/2021/01/14/critical-security-release-gitlab-13-7-4-released/), +[13.7.3](https://about.gitlab.com/releases/2021/01/08/gitlab-13-7-3-released/), +[13.7.2, 13.6.4, and 13.5.6](https://about.gitlab.com/releases/2021/01/07/security-release-gitlab-13-7-2-released/) ++ Bitbucket Server [7.9](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.3.1](https://www.gerritcodereview.com/3.3.html#331), +[3.2.6](https://www.gerritcodereview.com/3.2.html#326), +[3.1.11](https://www.gerritcodereview.com/3.1.html#3111) ++ GitKraken [7.5.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.6.2](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + +* [Meet Praefect: The traffic manager making your Git data highly available](https://about.gitlab.com/blog/2021/01/21/high-availability-git-storage-with-praefect/): + How GitLab scales Git and makes it highly available. +* [Git your updates now: Version control system hits 2.30, preps for main switch](https://devclass.com/2021/01/04/git-2_30-version-control/) + by Julia Schmidt. + +__Light reading__ + +* [Git clone: a data-driven study on cloning behaviors](https://github.blog/2020-12-22-git-clone-a-data-driven-study-on-cloning-behaviors/) + by Solmaz Abbaspoursani on GitHub blog continues where + [Derrick Stolee's article on `git clone` options](https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/), + mentioned in the [previous edition](https://git.github.io/rev_news/2020/12/26/edition-70/), left off. +* [Git Metadata Cloning](https://www.alchemists.io/articles/git_metadata_cloning) - Learn about the + performance impacts of cloning repository metadata. +* [MAINTAINERS truth and fiction](https://lwn.net/Articles/842415/) + article by Jonathan Corbet on LWN.net + describes how one can analyze Git history of the Linux kernel + for insights to be gleaned from comparing MAINTAINERS entries + against activity in the real world. +* [How to Use Multiple Git Configs on One Computer](https://www.freecodecamp.org/news/how-to-handle-multiple-git-configurations-in-one-machine/) + with the help of `includeIf` directive, + by Dhruv Barochiya on freeCodeCamp. +* [Keeping Git Commit Messages Consistent with a Custom Template](https://dev.to/timmybytes/keeping-git-commit-messages-consistent-with-a-custom-template-1jkm) + by Timothy Merritt on DEV.to. +* [Conflict resolution in various mergetools](https://www.eseth.org/2020/mergetools.html) + by Seth House was [previously an appeal to mergetools authors to stop doing three-way merges from scratch](https://github.com/whiteinge/eseth/blob/e993b4b9c5f7e5d2c83890bcb7cd218abe867afd/2020/mergetools.md), + but now describes the effect of [patches by Felipe Contreras and several other people](https://lore.kernel.org/git/5fe4bec2da21a_19c92085f@natae.notmuch/T/#t) + that changed the default behaviour of `git mergetool` (this can be controlled + with the new `mergetool.autoMerge` and `mergetool..autoMerge` config options). +* [10 things to love about Git](https://opensource.com/article/20/12/git) by Joshua Allen Holm + lists OpenSource.com readers' favorite Git articles of the year 2020. + +__Git tools and sites__ + +* [code-compass](https://github.com/ag91/code-compass) is a package that is intended + to guide you in your software development within Emacs. For example, you can + [let history show you which files to edit next](https://ag91.github.io/blog/2021/01/12/emacs-as-your-code-compass-let-history-show-you-which-files-to-edit-next/) or + [examine how files are historically related to each other](https://ag91.github.io/blog/2021/01/07/emacs-as-your-code-compass-how-related-are-these-modules/). +* [Crev](https://github.com/crev-dev/crev) is a Scalable, social, + Code REView and recommendation system (rather than _change_ review system); + currently [Crev for Rust/cargo](https://github.com/crev-dev/cargo-crev) + is ready and working. + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Sergey Organov and Brooke Kuhlmann. diff --git a/_posts/2021-02-27-edition-72.markdown b/_posts/2021-02-27-edition-72.markdown new file mode 100644 index 000000000..76a6dc461 --- /dev/null +++ b/_posts/2021-02-27-edition-72.markdown @@ -0,0 +1,280 @@ +--- +title: Git Rev News Edition 72 (February 27th, 2021) +layout: default +date: 2021-02-27 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 72 (February 27th, 2021) + +Welcome to the 72nd 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](https://git.github.io). + +This edition covers what happened during the month of January 2021. + +## Discussions + + + +### Reviews + +* [[PATCH 0/5] Support for commits signed by multiple algorithms](https://lore.kernel.org/git/20210111003740.1319996-1-sandals@crustytoothpaste.net/) + + brian m. carlson sent a patch series to allow verifying signed + commits and tags when using multiple hash algorithms. This is a + follow up from brian's multi-year work on supporting the SHA-256 + hash algorithm in Git, to deal with the fact that the original SHA-1 + algorithm is becoming more and more outdated and insecure. + + One of the trickiest part in supporting a new hash algorithm is that + when Git objects (except blobs) are converted to the new hash, their + contents changes, because the hashes they contain (to reference + other Git objects) are converted too. So old signatures they contain + become invalid. + + A way to overcome this issue is to add a new signature, that signs + the converted object, to each signed object that is converted. This + way such object would have 2 signatures, and can always be verified + using one of them, even if it gets converted back and forth. + + brian's patch series addressed the issue that for SHA-256 tags it + was initially planned to have the signature in a Git object header + (which is called a header signature) instead of at the end of the + tag message (which is called a trailing signature), but + unfortunately the patch implementing that got lost. So we use + trailing signatures. + + brian then explained "We can't change this now, because otherwise it + would be ambiguous whether the trailing signature on a SHA-256 + object was for the SHA-256 contents or whether the contents were a + rewritten SHA-1 object with no SHA-256 signature at all." So the + solution he implemented was to "use the trailing signature for the + preferred hash algorithm and use a header for the other variant". + + brian thinks this solution is the best we can do in the current + situation, as it still allows converting back and forth between + hashes, and verifying signatures created with older versions of Git, + though tags signed with multiple algorithms can't be verified with + older versions of Git. + + For commits, brian's patch series fixes the bug that old header + signatures weren't stripped off before verifying new signatures, so + verification always failed. + + The result of his series is then that signing both commits and tags + can now be round-tripped through both SHA-1 and SHA-256 conversions. + + Junio Hamano, the Git maintainer, replied to a patch in the series + suggesting using the `size_t` type for byte lengths, instead of + `unsigned long`, as `unsigned long` was breaking 32-bit builds. + + brian agreed and sent a + [version 2](https://lore.kernel.org/git/20210111035840.2437737-1-sandals@crustytoothpaste.net/) + of the series with Junio's fix. + + Junio replied to the cover letter of this series asking "How widely + are SHA-256 tags in use in the real world, though?", and if it was really + too late to use a header signature for tags, as was originally + planned. + + brian replied: + + > I don't know. I don't know of any major hosting platform that + supports them, but of course many people may be using them + independently on self-hosted instances. + + He also explained why he thought the solution didn't matter much, + because he'd just noticed that old Git versions don't properly strip + header signatures, so wouldn't anyway be able to verify tags or + commits with multiple signatures. + + He ended his reply saying "there's a lot more prep work (surprise) + before we get to anything interesting." To which Junio replied: + "Uncomfortably excited to hear this ;-)". + + brian [replied with an interesting summary of his in progress work](https://lore.kernel.org/git/X%2F0IaVkxqbYxKJBf@camp.crustytoothpaste.net/). + + Gábor Szeder then reported a Clang warning, while Junio suggested + more `unsigned long` to `size_t` changes. + + brian then sent a + [version 3](https://lore.kernel.org/git/20210118234915.2036197-1-sandals@crustytoothpaste.net/) + of his patch series with fixes for the issues reported by Gábor and + Junio, and then a few weeks later + [version 4](https://lore.kernel.org/git/20210211020806.288523-1-sandals@crustytoothpaste.net/) + to fix another small issue. + + This patch series is scheduled to be merged in the `master` branch + soon. + + + + +## Developer Spotlight: Taylor Blau + +* Who are you and what do you do? + + I am Taylor. I work at GitHub, where I spend most of my time + contributing to the Git project. + +* What would you name your most important contribution to Git? + + I'm still submitting many of the patches, but I think + [multi-pack reachability bitmaps](https://lore.kernel.org/git/e64504bad6e181522946a8f234e12f569bede89e.1612998106.git.me@ttaylorr.com/) + will be my most important contribution to Git so far. + + If they work, they'll allow hosting providers who rely on reachability + bitmaps more flexibility to control when and how they repack their + repository. If you want to use bitmaps, you have no choice but to + repack your repository into one enormous pack. Multi-pack reachability + bitmaps mean that you won't have to, and can instead repack your + repository however you want. + + If I'm limited to things that I have finished, I would say that the + [on-disk reverse index](https://lore.kernel.org/git/cover.1610129989.git.me@ttaylorr.com) + is another good one. But that's kind of cheating, since it's related + to multi-pack bitmaps ;). + +* What are you doing on the Git project these days, and why? + + Most of my time is spent working on multi-pack bitmaps. There are a lot + of different topics in [my fork](https://github.com/ttaylorr/git) that + all need to get merged in order to make this feature work. So, I'm + spending my time in all of the usual ways: submitting patches, responding + to review, submitting more patches, and so on. + + When I'm not doing that, I enjoy to read and review patches from other + folks on the list. I feel like there is a lot of exciting work going on + recently, and so I'm always interested. + + Every release or so I have the pleasure of writing a + ["release highlights" blog post](https://github.blog/author/ttaylorr/) + that GitHub publishes. We're still a few weeks away from a release + (at the time of writing), so it's not something that I'm working on yet, + but it will come up soon enough. + +* 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 sure :). I care a lot about performance on large repositories, + so I think that if I were in charge of such a team, that I would just + set them loose to explore the boundaries of what's possible, and push + them further. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + Gosh, I would love to get rid of `.keep` packs, or at least the + distinction between in-core and on-disk ones. They're incredibly useful, + but they are subtly different, in ways that are sort of hard to reason + about. + +* What is your favorite Git-related tool/library, outside of Git itself? + + I use [`tig`](https://jonas.github.io/tig/) often, particularly its + blame and log view. Michael Haggerty's [`git when-merged`](https://github.com/mhagger/git-when-merged) + is another indispensable tool in my workflow. + + I'm curious to try Stephen Jung's [`git absorb`](https://github.com/tummychow/git-absorb) + tool, but I haven't gotten to it yet. + + +## Releases + ++ Git [2.30.1](https://public-inbox.org/git/xmqqsg662k8p.fsf@gitster.c.googlers.com/) ++ Git for Windows [2.30.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.30.1.windows.1) ++ GitLab [13.9](https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-released/), +[13.8.4, 13.7.7 and 13.6.7](https://about.gitlab.com/releases/2021/02/11/security-release-gitlab-13-8-4-released/), +[13.8.3](https://about.gitlab.com/releases/2021/02/05/gitlab-13-8-3-released/), +[13.8.2, 13.7.6 and 13.6.6](https://about.gitlab.com/releases/2021/02/01/security-release-gitlab-13-8-2-released/), +[13.8.1](https://about.gitlab.com/releases/2021/01/26/gitlab-13-8-1-released/), +[13.7.5](https://about.gitlab.com/releases/2021/01/25/gitlab-13-7-5-released/) ++ Bitbucket Server [7.10](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.3.2](https://www.gerritcodereview.com/3.3.html#332), +[3.2.7](https://www.gerritcodereview.com/3.2.html#327), +[3.1.12](https://www.gerritcodereview.com/3.1.html#3112), +[3.0.16](https://www.gerritcodereview.com/3.0.html#3016), +[2.16.27](https://www.gerritcodereview.com/2.16.html#21627), +[2.15.22](https://www.gerritcodereview.com/2.15.html#21522) ++ GitKraken [7.5.1](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.6.3](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + +* At FOSDEM 2021 (this year the event happened in a virtual format) + there was a lightning talk [Building a Git learning game: A playful approach to version control](https://fosdem.org/2021/schedule/event/git_learning_game/) (video available) + initiated by two students who wanted to understand Git themselves... + This [Oh My Git!](https://ohmygit.org/) game + [is Open Source](https://github.com/git-learning-game/oh-my-git) and + written using the [Godot game engine](https://godotengine.org/). + There are binaries for Linux, macOS, and Windows, but currently no web + version, as the game uses real Git as a part of its backend (with some + sandboxing). + + The similar interactive online [Learn Git Branching](http://learngitbranching.js.org/) + game was mentioned in [Git Rev News Edition #30](https://git.github.io/rev_news/2017/08/16/edition-30/). + + +__Light reading__ + +* In [Getting The Most Out Of Git](https://www.smashingmagazine.com/2021/02/getting-the-most-out-of-git/) + article in Smashing Magazine, the author Tobias Günther explores some of + the less known but very useful features in Git: how to recover deleted commits, + clean up your commit history, use submodules to manage third-party code + and compose commits with precision. +* [How to Use Branches in Git – the Ultimate Cheatsheet](https://www.freecodecamp.org/news/how-to-use-branches-in-git/) + by Tobias Günther on freeCodeCamp describes how to create, rename, switch, + publish, track, delete, merge, rebase and compare branches. +* [How to Collaborate on Data Science Projects with DAGsHub](https://www.freecodecamp.org/news/collaborate-on-data-science-projects-with-dagshub/) + (and [DVC](https://dvc.org) (Data Version Control)), by Linda Ikechukwu + on freeCodeCamp. DVC was first mentioned + in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/). +* The [RefinementCodeReview](https://martinfowler.com/bliki/RefinementCodeReview.html) + post by Martin Fowler describes an alternative to the [PullRequest](https://martinfowler.com/bliki/PullRequest.html) + mechanism for code review, namely one that is triggered each time + the code is looked at rather than when the code is added to the codebase. +* In [Monorepos](https://css-tricks.com/monorepo/) Chris Coyier explains the reasoning, + pros and cons for them, moving back toward a monorepo at [CodePen](https://codepen.io/). + You can find links to articles advocating for and against monorepos, + among others, in [Git Rev News Edition #47](https://git.github.io/rev_news/2019/01/23/edition-47/). +* [Rewriting your git history, removing files permanently - cheatsheet & guide](https://blog.gitguardian.com/rewriting-git-history-cheatsheet/) + by Don Goodman-Wilson on GitGuardian blog. +* [2020 Version control best practices: Five easy ways to enhance team collaboration](https://learn.gitlab.com/version-control/version-control-best-practice) + (PDF) -- a booklet by GitLab. + + +__Git tools and sites__ + +* [DAGsHub Storage](https://dagshub.com/docs/reference/dagshub_storage/) + is an alternative (and free-to-use) [DVC](https://dvc.org) remote + that requires zero configuration. +* [Commitizen](http://commitizen.github.io/cz-cli/) is an Open Source project + that helps contributors be good Open Source citizens. It accomplishes this + by prompting them to follow commit message conventions at commit time, + asking the user fill in any required fields and automatically formatting + the commit message according to selected convention. +* [Git Gud](https://github.com/benthayer/git-gud) by Ben Thayer + is a *command line* game designed to help you learn how to use Git. + Note that there was a pretty barebone visual web-based Git simulator + [with the same name](https://nic-hartley.github.io/git-gud/) by Nic Hartley, which + got mentioned in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/), + but it is no longer available. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Taylor Blau. diff --git a/_posts/2021-03-27-edition-73.markdown b/_posts/2021-03-27-edition-73.markdown new file mode 100644 index 000000000..c72995bf9 --- /dev/null +++ b/_posts/2021-03-27-edition-73.markdown @@ -0,0 +1,217 @@ +--- +title: Git Rev News Edition 73 (March 27th, 2021) +layout: default +date: 2021-03-27 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 73 (March 27th, 2021) + +Welcome to the 73rd 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](https://git.github.io). + +This edition covers what happened during the month of February 2021. + +## Discussions + + + + + +### Support + +* [[QUESTION] Tracking HEAD changes?](https://lore.kernel.org/git/CAGgn8PdU1GE_CZdGUpJWKzygd0O+Yn2BnAFGmPfKAxFpoVoqUA@mail.gmail.com/) + + Yaron Wittenstein asked on the mailing list if there is "any + possible way to track changes to HEAD using hooks". He said he would + like to listen to events such as "pre-head-checkout" and + "post-head-checkout", but thought that it was only possible using a + file watch over the `.git/refs` directory. + + Jeff King, alias Peff, first replied that he thought there was no + better way, and that it was also required to watch `.git/HEAD`. He + also showed some code for + Linux/[inotify](https://en.wikipedia.org/wiki/Inotify) he uses to + automatically run tests against the current commit: + + ```shell + gitdir=$(git rev-parse --git-dir) + # We need delete_self to pick up changes to HEAD (since it gets renamed + # over), and "move" to pick up changes in the refs directories. + inotifywait -qq -t 60 -e delete_self -e move -r "$gitdir/HEAD" "$gitdir/refs" + ``` + + Peff also recommended using Michael Haggerty's + [git-test tool](https://github.com/mhagger/git-test) for avoiding + re-running tests against the same commits repeatedly. + + Then Peff replied to his previous email that Patrick Steinhardt also + recently (since Git v2.28.0) implemented a new + [ref-transaction hook](https://www.git-scm.com/docs/githooks#_reference_transaction) + that can get triggered by updates to the ref that HEAD is pointing at. + + Yaron replied that this seems to do the trick, except the hook + doesn't execute when switching branches. He found a work-around + though by using the post-checkout hook in addition. + + Peff said that he thought the hook would be triggered when HEAD is + updated by a branch switch, and wondered if that was a bug, a + missing feature, or something intentional in the ref-transaction + hook design. + + Patrick replied that the reason is that + [symrefs](https://git-scm.com/docs/git-symbolic-ref) are not covered + by the reference transaction mechanism itself, which existed before + he implemented the new hook, and which the hook is using + underneath. He also said that he should update the documentation to + make it clearer what is covered by the hook and what's not. + + Yaron thanked Patrick for the clarification and asked if there were + plans for the hook to be called when symrefs are updated. He also + said it didn't seem intuitive to him that the index and working dirs + are being updated, which calls the "post-index-change" hook, before + the transaction is approved, which in turn calls the "ref-transaction" hook. + + Patrick replied that he didn't have plan for the hook to support + symrefs, but wouldn't oppose such effort. About the order in which + things were happening, he said that it is the way Git currently + works and that the goal of the ref-transaction hook, which he worked + on as part of his work for GitLab, was "to catch _all_ reference + updates such that one can coordinate across multiple git nodes the + same action to assert they're moving from the same state to the same + state, regardless of whether they're doing a + [git-push](https://git-scm.com/docs/git-push), + [git-merge](https://git-scm.com/docs/git-merge) or + [git-update-ref](https://git-scm.com/docs/git-update-ref)". + + Junio Hamano, the Git maintainer, further explained that "ref + transaction is only about changes to the refs" and that "there is no + such 'transaction' that treats a series of operations like object + creation and index manipulation that may happen before a group of + refs are updated as a single unit and make it atomic." + + Meanwhile Peff replied to Patrick's first explanation about why + symrefs are not covered by the hook saying that it might be + something that could be fixed. He also said that GitHub's custom + repository replication mechanism does track symref updates, but uses + a simple lock mechanism to get the state of the symrefs, while it + uses a 3-phase commit based on custom code similar to the + ref-transaction hook for normal refs. + + Yaron then [summarized his understanding](https://lore.kernel.org/git/CAGgn8PdYsfbSE2vRunOXO1JqXoM8LxoD+5Zn74jmb9vpqDXh+Q@mail.gmail.com/) + of how things work and asked + if he was right. Peff replied that it matched his understanding. + + + +## Releases + ++ Git [2.31.0](https://public-inbox.org/git/xmqqwnu8z03c.fsf@gitster.g/), +[2.31.0-rc2](https://public-inbox.org/git/xmqqblbs19uf.fsf@gitster.c.googlers.com/), +[2.30.2 and below for CVE-2021-21300](https://public-inbox.org/git/xmqqim6019yd.fsf@gitster.c.googlers.com/), +[2.31.0-rc1](https://public-inbox.org/git/xmqqr1kwk0h9.fsf@gitster.c.googlers.com/), +[2.31.0-rc0](https://public-inbox.org/git/xmqqlfbbshza.fsf@gitster.g/) ++ Git for Windows [2.31.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.31.0.windows.1), +[2.31.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.31.0-rc2.windows.1), +[2.31.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.31.0-rc1.windows.1), +[2.31.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.31.0-rc0.windows.1), +[2.30.2(1)](https://github.com/git-for-windows/git/releases/tag/v2.30.2.windows.1) ++ Bitbucket Server [7.11](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitHub Enterprise [3.0.2](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.2), +[2.22.8](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.8), +[2.21.16](https://help.github.com/enterprise-server@2.21/admin/release-notes#2.21.16), +[3.0.1](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.1), +[2.22.7](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.7), +[2.21.15](https://help.github.com/enterprise-server@2.21/admin/release-notes#2.21.15), +[2.20.24](https://help.github.com/enterprise-server@2.20/admin/release-notes#2.20.24) ++ GitLab [13.10](https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-released/), +[13.9.4, 13.8.6, and 13.7.9](https://about.gitlab.com/releases/2021/03/17/security-release-gitlab-13-9-4-released/), +[13.9.3](https://about.gitlab.com/releases/2021/03/08/gitlab-13-9-3-released/), +[13.9.2, 13.8.5 and 13.7.8](https://about.gitlab.com/releases/2021/03/04/security-release-gitlab-13-9-2-released/), +[13.9.1](https://about.gitlab.com/releases/2021/02/23/gitlab-13-9-1-released/) ++ GitKraken [7.5.2](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.6.6](https://desktop.github.com/release-notes/), +[2.6.5](https://desktop.github.com/release-notes/), +[2.6.4](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + +* [Git clone vulnerability announced](https://github.blog/2021-03-09-git-clone-vulnerability-announced/) + by Taylor Blau on GitHub Blog, and + [A vulnerability in Git](https://lwn.net/Articles/848935/) + by Jake Edge on LWN.net. +* [Highlights from Git 2.31](https://github.blog/2021-03-15-highlights-from-git-2-31/) + by Taylor Blau on GitHub Blog. +* Congratulations to [Joey Salazar](https://jsal.home.blog/) and + [Charvi Mendiratta](https://charvi-077.github.io/) who successfully completed their + [Outreachy internship](https://www.outreachy.org/alums/) working on Git! + +__Light reading__ + +* [Optimizing git’s merge machinery, #1](https://blog.palantir.com/optimizing-gits-merge-machinery-1-127ceb0ef2a1) + and [#2](https://blog.palantir.com/optimizing-gits-merge-machinery-2-d81391b97878) + by Elijah Newren on Palantir Blog. +* [How Does Git Work?](https://www.honeybadger.io/blog/how-does-git-work/) + by Julie Kent. +* [Git is my buddy: Effective Git as a solo developer](https://mikkel.ca/blog/git-is-my-buddy-effective-solo-developer/) + by Mikkel Paulson. +* [How to Utilize Submodules within Git Repos](https://blog.bitsrc.io/how-to-utilize-submodules-within-git-repos-5dfdd1c62d09): + One Solution When the Primary Code Can be Open Source, but Specific Content Needs to be Private, + by Paige Niedringhaus on Bits and Pieces blog (a Medium site). +* [How to use .mailmap file in git repository](https://lukasmestan.com/using-mailmap-in-git-repository/) + by Lukáš Mešťan (2020). +* [What is Trunk Based Development? A Different Approach to the Software Development Lifecycle](https://www.freecodecamp.org/news/what-is-trunk-based-development/) + by Kealan Parr on freeCodeCamp. This approach was also one of those described + in [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) + by Martin Fowler, which was mentioned in [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/). +* [Improving large monorepo performance on GitHub](https://github.blog/2021-03-16-improving-large-monorepo-performance-on-github/) + by Scott Arbeit on GitHub Blog, in the Engineering section. +* [Hacking the git shell prompt](https://blog.plover.com/prog/git-prompt-hook-hack.html) + by Mark Dominus describes a hack creating a generic mechanism for abbreviating + or transforming the branch name in the prompt. +* [Boost Your Programming Skills by Reading Git's Code](https://www.freecodecamp.org/news/boost-programming-skills-read-git-code/) + by Jacob Stopak on freeCodeCamp. +* [How To Set Up Continuous Integration With Git and Jenkins](https://www.lambdatest.com/blog/how-to-setup-continuous-integration-with-git-jenkins/) + by Suparna Khamaru on LambdaTest Blog. +* [Store your Kubernetes Secrets in Git thanks to Kubeseal. Hello SealedSecret!](https://dev.to/stack-labs/store-your-kubernetes-secrets-in-git-thanks-to-kubeseal-hello-sealedsecret-2i6h) + by Aurélie Vache on Dev.to. More generic solutions for storing secrets in Git repository + were described in Git Rev News editions [#39](https://git.github.io/rev_news/2018/05/16/edition-39/) + and [#57](https://git.github.io/rev_news/2019/11/20/edition-57/), among others. + + +__Git tools and sites__ + +* [Project GITenberg](http://gitenberg.github.io/) is a Free and Open, + Collaborative, Trackable and Scriptable digital library. It leverages the + power of the Git version control system and the collaborative potential of + GitHub to make books more open. The books in this project originate from + the work of [Project Gutenberg](http://www.gutenberg.org/), a volunteer effort + to digitize and archive cultural works, mostly the full texts of + public domain books. +* [ungit](https://github.com/FredrikNoren/ungit) is a Git command-line UI + with text editor integrations, + that utilizes your web browser as graphical interface. It is intended to make + Git easier to use. In this it is somewhat similar to no longer actively developed + [Easy Git](https://people.gnome.org/~newren/eg/). + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Ævar Arnfjörð Bjarmason and Matheus +Tavares Bernardino. diff --git a/_posts/2021-04-30-edition-74.markdown b/_posts/2021-04-30-edition-74.markdown new file mode 100644 index 000000000..386c0a9e8 --- /dev/null +++ b/_posts/2021-04-30-edition-74.markdown @@ -0,0 +1,299 @@ +--- +title: Git Rev News Edition 74 (April 30th, 2021) +layout: default +date: 2021-04-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 74 (April 30th, 2021) + +Welcome to the 74th 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](https://git.github.io). + +This edition covers what happened during the month of March 2021. + +## Discussions + + + + + +### Support + +* [`--no-edit` not respected after conflict](https://lore.kernel.org/git/4442fd0a-3306-a22b-3614-e3272f8f0be5@FreeBSD.org/) + + Renato Botelho explained in an email to the mailing list that while he + was reverting multiple commits using the `--no-edit` option, there + was a conflict he resolved using + [`git mergetool`](https://git-scm.com/docs/git-mergetool). After that + though, the revert was not respecting the `--no-edit` option anymore + for the next commits, so for each of them an editor was opened for him + to review the commit messages. + + After brian m. carlson replied to him asking for the set of commands + he used or a reproduction test case, Renato provided a test case + which shows that indeed after `git revert --continue` the + `--no-edit` option, that was provided in the initial + `git revert --no-edit commit1 commit2 ... commitN` command, doesn't + seem to be taken into account anymore. + + Elijah Newren thanked Renato, confirmed he could reproduce the issue + and said he started working on a patch that fixed the issue as well + as a similar one he had found. The next day though Elijah replied to + himself saying the issue turned out to be messier than expected. + + He [provided tables](https://lore.kernel.org/git/CABPp-BEGEcws69sg6Z2=B1nihFG227mAsSx=boU3uSx2xDUEjg@mail.gmail.com/) + showing that the behavior (launching an editor or + not) could depend on a number of factors: the command (`revert` or + `cherry-pick`), the use of a terminal or not, before or after a + conflict, which option (`--edit`, `--no-edit` or no option) had been + passed. The tables also showed that Elijah had some doubts in some + cases. + + Elijah for example was not sure what should be done after a conflict + when neither `--edit` nor `--no-edit` had been specified and when there + was no terminal. It was not clear if an editor should be launched as + it was likely to fail if there was no terminal. + + Junio Hamano, the Git maintainer, replied to Elijah saying that + when there is a conflict and when reverting (instead of + cherry-picking), the default (that is, `--no-edit` is not provided) + should be to give the user a chance to explain the conflict + resolution or the reason for reverting in the commit message. If + there is no terminal though, the process is likely automated and + launching an editor might fail the operation for no good reason. + + Elijah then thanked Junio, sent a proper + [patch](https://lore.kernel.org/git/pull.988.git.git.1616742969145.gitgitgadget@gmail.com/) + to the mailing list fixing the issue and asked Renato to give it a + try. Renato replied that the patch worked indeed and thanked Elijah. + + Philip Oakley and Phillip Wood first replied to Elijah's patch, + which was quite complex, with only minor comments. Elijah and Junio + both replied to their comments. Then Elijah sent a + [version 2 of his patch](https://lore.kernel.org/git/pull.988.v2.git.git.1617070174458.gitgitgadget@gmail.com/) + that only included typo fixes and comment clarifications to address + Philip's and Phillip's suggestions. + + Johannes Schindelin, alias Dscho, replied to this new version of the + patch. He first said, as a tangent, that we should move away from + the "Unix shell script heritage", especially what he called "the + awful _let's write out one file per setting_ strategy". He would + like the project to use the JSON or the INI (like Git's own config + files) format instead. He recognized that it might not be an easy + switch though, as some users might unfortunately rely too much on + such implementation details. + + Dscho also made a number of small code suggestions. One was about + how the variable encoding of the edit related options is + checked. Another one was to get rid of an `assert()` statement that + Elijah's patch introduced. While Elijah agreed with the first one, + he disagreed about the second, which started a small discussion + about the value of `assert()` between Elijah, Junio and Dscho, with + Ævar Arnfjörð Bjarmason chiming in. Elijah eventually suggested + replacing the `assert()` statements using a new `BUG_ON()` macro. + + About Dscho's tangent that we should stop writing one file per + setting and use a standard format instead, Elijah said he was glad + talking about this because it generates a number of issues. Some of + these issues are related to the different control structures and + code duplication for different operations (like `git cherry-pick` + and `git rebase`) because of the differences in writing the + settings. + + Another issue is some wasted time in the sequencer (which is used by + both `git cherry-pick` and `git rebase`). There is unnecessary + process forking and a lot of useless disk writing (to update the + index and the working directory but also to write all the individual + control files). This started a sub-thread where Dscho, Phillip Wood, + Junio and Elijah discussed if it was actually necessary to often + write many small files to disk. The conclusion seemed to be that we + would need to check if some hooks are configured or not, so that if + they are not, we can avoid writing a lot between each commit which + is processed. Dscho said that "for example, if no `pre-commit` hook + was installed that needs to be run, there was no need to update the + worktree nor HEAD until the rebase is done". + + Meanwhile Elijah sent a + [version 3 of his patch](https://lore.kernel.org/git/pull.988.v3.git.git.1617173541301.gitgitgadget@gmail.com/) + that took into account all the suggestions Dscho had made, including the + removal of the `assert()` statement. Dscho gave his "Reviewed-by:" and + the patch has since been merged into the 'master' branch. + + +## Developer Spotlight: Yann Dirson + +* Who are you and what do you do? + + I'm Yann, and for the last few years I've been working on the Blade/Shadow + "stream a Gaming PC" service, and currently looking for the next adventure. + +* What would you name your most important contribution to Git? + + I can't say that one particular thing stands out by itself. In volume + I certainly contributed more to "third-party" tools: [Cogito][1] + initially, then [StGit][2] (which I'm happy to see has recently received + more activity and a 1.0 release), then more recently + [git-reintegrate][3]. In git.git, I've mostly contributed small patches + here and there when it itched too much, and a number of bug reports and + suggestions. + +[1]: https://en.wikipedia.org/wiki/Cogito_(software) +[2]: https://stacked-git.github.io/ +[3]: https://github.com/felipec/git-reintegrate + +* What are you doing on the Git project these days, and why? + + I've been mostly dormant there lately, and I've been a happy user all + that time, both in dayjob and in personal projects. To me that tells + a lot on the maturity of the project. + + I've started to feel a new itch regarding `git rebase -i`, when iterative work + requires to go back-and-forth between patches before finishing the rebase + (something StGit did quite well, and possibly something most users don't need). + I only posted a PoC and some ideas a [couple of weeks ago][4], and that's + likely to be my next venture into Git if time allows. + +[4]: https://lore.kernel.org/git/139173043.431119331.1615653441685.JavaMail.root@zimbra39-e7/ + +* 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? + + On my first contact with Git shortly after Linus published his first + version, one thing stood out for me as non-intuitive after using all + those former tools: the "record only the content and not by which + operation we got there" motto, which leaves to `git diff` the work of + reconstructing the "which operation" part. Yet, soon after it struck + me as probably the most brilliant aspect in Git's design. + + Today there are a handful of such operations that Git can detect, and + then use when merging to make things easier: essentially renames and + copies. Yet, so many other high-level operations can be made on code, + and are not easy enough to merge: code restructuring inducing + reindents (think Python) and symbol renaming are the first that come + to mind. + + This probably should be done as language-specific diff/merge tools, + but those tools would likely want to share a common core. Providing + such support would likely help many projects, and enable smoother + workflows. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + The current `git rebase` syntax, which feels so counter-intuitive today. + +* What is your favorite Git-related tool/library, outside of Git + itself? + + Recently the tool that has helped me most is [git-reintegrate][3], it + simplifies so much the iterative integration process with WiP + branches. It still has a couple of rough edges, but as long as + you don't use submodules and don't have to hand over the integration + task to others too often, it runs really smoothly. + +## Releases + ++ Git [2.31.1](https://lore.kernel.org/git/xmqq1rc1sf2z.fsf@gitster.g/), ++ Git for Windows [2.31.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.31.1.windows.1) ++ GitHub Enterprise [3.0.5](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.5), +[2.22.11](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.11), +[2.21.19](https://help.github.com/enterprise-server@2.21/admin/release-notes#2.21.19), +[3.0.4](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.4), +[2.22.10](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.10), +[2.21.18](https://help.github.com/enterprise-server@2.21/admin/release-notes#2.21.18), +[3.0.3](https://docs.github.com/en/enterprise-server@3.0/admin/release-notes#3.0.3), +[2.22.9](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.9), +[2.21.17](https://help.github.com/enterprise-server@2.21/admin/release-notes#2.21.17) ++ GitLab [13.11.1](https://about.gitlab.com/releases/2021/04/23/gitlab-13-11-1-released/), +[13.11](https://about.gitlab.com/releases/2021/04/22/gitlab-13-11-released/), +[13.10.3, 13.9.6, and 13.8.8](https://about.gitlab.com/releases/2021/04/14/security-release-gitlab-13-10-3-released/), +[13.10.2](https://about.gitlab.com/releases/2021/04/01/gitlab-13-10-2-released/), +[13.10.1, 13.9.5, and 13.8.7](https://about.gitlab.com/releases/2021/03/31/security-release-gitlab-13-10-1-released/) ++ Bitbucket Server [7.12](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.3.3](https://www.gerritcodereview.com/3.3.html#333), +[3.2.8](https://www.gerritcodereview.com/3.2.html#328), +[3.1.13](https://www.gerritcodereview.com/3.1.html#3113) ++ GitKraken [7.5.5](https://support.gitkraken.com/release-notes/current), +[7.5.4](https://support.gitkraken.com/release-notes/current), +[7.5.3](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.7.2](https://desktop.github.com/release-notes/), +[2.7.1](https://desktop.github.com/release-notes/), +[2.7.0](https://desktop.github.com/release-notes/) ++ TortoiseGit [2.12.0](https://tortoisegit.org/docs/releasenotes/#Release_2.12.0.0) + +## Other News + +__Events__ + +* [GitHub is announcing the Global Maintainer Summit](https://github.blog/2021-04-06-announcing-the-global-maintainer-summit/) + on June 8--9th. + + +__Various__ + +* [Technology internships meet open source in Outreachy](https://about.gitlab.com/blog/2021/04/15/outreachy-sponsorship-winter-2020/) + on GitLab's blog is about recent Outreachy interns working on Git. +* [Enhanced Productivity with Git in Visual Studio](https://devblogs.microsoft.com/visualstudio/enhanced-productivity-with-git-in-visual-studio/) + (in upcoming version 16.10). + + +__Light reading__ + +* [Optimizing git’s merge machinery, #3](https://blog.palantir.com/optimizing-gits-merge-machinery-3-2dc7c7436978) + by Elijah Newren on Palantir Blog. +* [A look under the hood: how branches work in Git](https://stackoverflow.blog/2021/04/05/a-look-under-the-hood-how-branches-work-in-git/) + by Tobias Günther on The Overflow -- the Stack Overflow blog. +* [Experiment on your code freely with Git worktree](https://opensource.com/article/21/4/git-worktree) + by Seth Kenlon (Red Hat) on Opensource.com. +* [5 commands to level-up your Git game](https://opensource.com/article/21/4/git-commands): + `git whatchanged`, `git stash`, `git worktree`, `git cherry-pick` and + [managing `$HOME` with Git](https://opensource.com/article/21/4/git-home), + by Seth Kenlon (Red Hat) on Opensource.com. +* [A practical guide to using the `git stash` command](https://opensource.com/article/21/4/git-stash) + by Ramakrishna Pattnaik on Opensource.com. +* [Scanning for secrets](https://lwn.net/Articles/851670/) in Git repositories + automatically, by Jake Edge on LWN.net. +* [How we ship code faster and safer with feature flags](https://github.blog/2021-04-27-ship-code-faster-safer-feature-flags/) + by Alberto Gimeno on GitHub Blog. + * [Feature flags](https://featureflags.io/) were one of solutions to hiding partial features + in [trunk based development](https://trunkbaseddevelopment.com/), one of the + [patterns for managing source code branches](https://martinfowler.com/articles/branching-patterns.html#continuous-integration) + in Martin Fowler's article of the same name, covered in + [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/) + and mentioned in [#73](https://git.github.io/rev_news/2021/03/27/edition-73/). +* [How to Set Up Continuous Integration for a Monorepo Using Buildkite](https://www.freecodecamp.org/news/how-to-set-up-continuous-integration-for-monorepo-using-buildkite/) + by Subash Adhikari on freeCodeCamp. +* [How to Use Git and Git Workflows -- a Practical Guide](https://www.freecodecamp.org/news/practical-git-and-git-workflows/) + by John Mosesman on freeCodeCamp. +* [Improving shell workflows with fzf](https://seb.jambor.dev/posts/improving-shell-workflows-with-fzf/) + by Sebastian Jambor. The [fzf](https://github.com/junegunn/fzf) tool was mentioned + alongside [git-fuzzy](https://github.com/bigH/git-fuzzy) (that uses it) in + [Git Rev News Edition #64](https://git.github.io/rev_news/2020/06/25/edition-64/). +* [Git email flow vs GitHub flow](https://blog.brixit.nl/git-email-flow-versus-github-flow/): + Comparing the GitHub and GitLab pull request workflow to the Git built-in email workflow, + by Martijn Braam (2020). + + +__Git tools and sites__ + +* [posh-git](http://dahlbyk.github.io/posh-git/) is a PowerShell module + which provides Git/PowerShell integration. It also provides tab completion + support for common Git commands, branch names, paths, and more. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Yann Dirson, Elijah Newren and Sven Strickroth. diff --git a/_posts/2021-05-27-edition-75.markdown b/_posts/2021-05-27-edition-75.markdown new file mode 100644 index 000000000..97123481b --- /dev/null +++ b/_posts/2021-05-27-edition-75.markdown @@ -0,0 +1,333 @@ +--- +title: Git Rev News Edition 75 (May 27th, 2021) +layout: default +date: 2021-05-27 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 75 (May 27th, 2021) + +Welcome to the 75th 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](https://git.github.io). + +This edition covers what happened during the month of April 2021. + +## Discussions + +### General + +* [Git participates in GSoC (Google Summer of Code) 2021](https://summerofcode.withgoogle.com/organizations/5908380398387200/#projects) + + The following two students have been officially accepted to work on Git + as part of the [GSoC 2021](https://summerofcode.withgoogle.com/): + + - ZheNing Hu will work on the + [Use ref-filter formats in `git cat-file`](https://summerofcode.withgoogle.com/projects/#6499923274498048) + project. He will be co-mentored by Hariom Verma and Christian + Couder. His first blog post about it [is up](https://adlternative.github.io/GSOC-Git-Blog-1/). + + - Atharva Raykar will work on the + [Finish converting submodule to builtin](https://summerofcode.withgoogle.com/projects/#4754589292691456) + project. He will be co-mentored by Shourya Shukla and Christian + Couder. His first blog posts about it are [also up](https://atharvaraykar.me/gitnotes/). + + Thanks to the students who applied and worked on micro-projects, but + couldn't be selected! We hope to continue to see you in the + community! + +* [The top 1% of commit trailers](https://lore.kernel.org/git/60ad75ac7ffca_2ae08208b@natae.notmuch/) + + Felipe Contreras posted a fun analysis of how often various commit + trailers (`reviewed-by`, `tested-by`, etc) appear in the git.git project. + + Setting aside `signed-off-by` (which all contributions must include), + the most common trailers are `acked-by` (1945 occurrences) and + `reviewed-by` (1729 occurrences), together accounting for almost half + of all trailers. + + The next 4 most common trailers give a great insight into just how + much collaboration goes on in the git.git project: `helped-by` (1336), + `reported-by` (960), `mentored-by` (379), and `suggested-by` (281). + + Perhaps most interesting is the long list of trailers that have only + been seen once, though now that this list is out there we may see more + of `deemed-obviously-correct-by`, `worriedly-acked-by`, and `cheered-on-by` + in the future. + + One can also note that this distribution roughly follows + [Zip's law](https://en.wikipedia.org/wiki/Zipf%27s_law); the 10th most + popular line ("improved-by") is about 1/10 as popular as the 1st. + + [This script](https://gist.github.com/felipec/ce491d351c88e4acbdbf6bc02a47223d) + can be used to replicate the analysis. + +### Reviews + +* [[PATCH] [GSOC] pretty: provide human date format](https://lore.kernel.org/git/pull.939.git.1619195245606.gitgitgadget@gmail.com/) + + ZheNing Hu sent a patch to the mailing list to add the new `%ah` and + `%ch` formatting options to the "pretty formats". The "pretty + formats" are the main way for users to customize the output of the + `git log`, `git show`, `git rev-list`, and `git diff-tree` commands. + + These formats are specified by the + [`--pretty[=]` or `--format=`](https://git-scm.com/docs/git-log#Documentation/git-log.txt---prettyltformatgt) + command line flags, where ``is the actual + ["pretty format"](https://git-scm.com/docs/git-log#_pretty_formats), + and can be either a "built-in format", like `oneline`, `raw`, + `short`, `medium`, etc, or `format:`, which is called a + "format string". + + These format strings work in a similar way to `printf()` formats, as + they can contain placeholders starting with a `%` character, that + will be expanded by the command. For example `%H` will be expanded + to print the commit hash, `%an` the author name, etc. + + A lot of placeholders already exist. For the author date, there are: + `%ad`, `%aD`, `%ar`, `%at`, `%ai`, `%aI` and `%as`. For the + committer date, there are the corresponding `%cd`, `%cD`, `%cr`, + `%ct`, `%ci`, `%cI` and `%cs` ones. Each pair of these placeholders uses + a different date format. For example, `%aI` and `%cI` use the "strict + ISO 8601 format". + + Formats `%ad` and `%cd`, though, are special as they use the format specified + by the `--date=` command line flag, so for example with + `--date=iso-strict`, `%ad` and `%cd` will behave in the same way as + `%aI` and `%cI`. + + ZheNing's patch added the new `%ah` and `%ch` placeholders that + would behave in the same way as `%ad` and `%cd` with + `--date=human`. The rationale for the patch being that there are + placeholders corresponding to most of the `--date=` options + except `--date=human`. + + Taylor Blau was the first to review ZheNing's patch and found it + "pretty good", as it was similar to a previous patch by René Scharfe + that added the `%as` and `%cs` placeholders for dates in the "short + date format". ZheNing acknowledged that he indeed learned from + René's patch. + + Philip Oakley, though, commented on the documentation part of the + patch suggesting to add an example similar to `YYYY-MM-DD` for the + short format. ZheNing replied that in the "human format" a date + could take many forms, so he said he would rather add links to the + documentation of the "human format". + + ZheNing then sent a + [version 2](https://lore.kernel.org/git/pull.939.v2.git.1619275340051.gitgitgadget@gmail.com/) + of his patch where he had added the links. Philip suggested further + small superficial changes to the link and the related text added in + this version though. + + Meanwhile Ævar Arnfjörð Bjarmason sent + [a small patch series](https://lore.kernel.org/git/cover-0.2-00000000000-20210425T090506Z-avarab@gmail.com/) + that made a "couple of trivial changes" to the tests related to + `%aI` and `%cI`, and at the same time suggested ZheNing to make + similar changes to the tests in his patch. + + ZheNing then sent a + [version 3](https://lore.kernel.org/git/pull.939.v3.git.1619347306291.gitgitgadget@gmail.com/) + of his patch, taking Philip's and Ævar's suggestions into account. + This patch contained a typo, though, so ZheNing sent a + [version 4](https://lore.kernel.org/git/pull.939.v4.git.1620056221874.gitgitgadget@gmail.com/) + of his patch. + + As the version 3 of the patch had already been merged to the "next" + branch before ZheNing sent the version 4, the typo got noticed by + Martin Ågren who sent + [a small patch series](https://lore.kernel.org/git/cover.1620551314.git.martin.agren@gmail.com/) + fixing this typo as well as another unrelated one. + + Eventually both ZheNing's patch and Martin's patches were merged + into the "master" branch, so that their improvements will appear in + the soon upcoming Git version v2.32.0. + + + +## Developer Spotlight: Patrick Steinhardt + +* Who are you and what do you do? + + I'm a software developer working at GitLab, more specifically in the + team working on Gitaly. Gitaly is our RPC interface to all Git + repositories, so it is the backbone to all things Git at GitLab. + + In my own free time, I love to tinker with my Gentoo-based systems and + tailor them to my own needs, which results in occasional drive-by + patches to all kinds of open source projects to scratch my own itches. + +* What would you name your most important contribution to Git? + + To me, this is the introduction of the reference-transaction hook, which + gets executed whenever a reference is about to be updated. This allows + tight control over all reference updates happening in a given repository + in a command-agnostic way. At GitLab, we use this hook to coordinate + reference updates across multiple replicas of the same repository such + that we can be sure that all nodes have the same state and move to the + same state. + + My most important contributions I'd not locate in the Git project itself + though, but instead in libgit2. While I unfortunately haven't found the + time to contribute to it lately, I've done a lot more work on libgit2 + than I did on Git. And there it's probably the initial introduction of + support for worktrees, maintenance of the CMake build system and work on + the gitconfig subsystem. + +* What are you doing on the Git project these days, and why? + + My current work is mostly focussed on tuning performance of some areas + we have found to be slow for gitlab.com. This has motivated the recent + introduction of a new `git-rev-list(1)` filter which allows to filter by + object type via `--filter=object:type=`. This makes it easy to + find for example all blobs introduced between two revisions. + + And right now I'm trying to devise a new implementation of the object + connectivity check performed by `git-receive-pack(1)` whenever a push gets + accepted on the server side. Depending on the repository's shape, the + current implementation can be a major bottleneck and take dozens of + seconds to compute even for small pushes. You may have noticed this + check when it says "Checking connectivity" on a push. + +* 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 obviously biased coming from the libgit2 project, but I'd really + love to further push the libification of Git. There has been great + progress on this front already to make internal C interfaces look more + like the typical interfaces you'd see from a linkable library. But my + dream would be to merge the efforts of Git and libgit2 such that Git + also provides an official library which can be linked against in your + own program. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + Tough question. There's many user-facing commands which could benefit + from a more consistent design, but my take is that these probably could + provide an improved user interface while still retaining backwards + compatibility. + + But what I'd really love to get rid of is the file-based reference + backend. It works reasonably well to represent references as file paths + in smallish repositories, but even there it imposes limitations which + are only a result of its implementation. It's also inefficient for + bigger repositories and does not really allow for atomic modification of + multiple references at once. There luckily is ongoing work on the + reftable backend, which fixes many of the shortcomings, but it will + likely still take some time to land. + +* What is your favorite Git-related tool/library, outside of Git itself? + + I guess the answer to that question is going to be obvious by now: + libgit2. + + +## Releases + ++ Git [2.32.0-rc1](https://public-inbox.org/git/xmqqk0nqq266.fsf@gitster.g/), +[2.32.0-rc0](https://public-inbox.org/git/xmqqh7j13kmc.fsf@gitster.g/) ++ Git for Windows [2.32.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.32.0-rc1.windows.1), +[2.32.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.32.0-rc0.windows.1) ++ GitLab [13.12](https://about.gitlab.com/releases/2021/05/22/gitlab-13-12-released/), +[13.11.4](https://about.gitlab.com/releases/2021/05/14/gitlab-13-11-4-released/), +[13.11.3](https://about.gitlab.com/releases/2021/04/30/gitlab-13-11-3-released/), +[13.11.2, 13.10.4, and 13.9.7](https://about.gitlab.com/releases/2021/04/28/security-release-gitlab-13-11-2-released/) ++ Bitbucket Server [7.13](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.4.0](https://www.gerritcodereview.com/3.4.html), +[3.3.4](https://www.gerritcodereview.com/3.3.html#334), +[3.2.10](https://www.gerritcodereview.com/3.2.html#3210), +[3.1.15](https://www.gerritcodereview.com/3.1.html#3115), +[3.2.9](https://www.gerritcodereview.com/3.2.html#329), +[3.1.14](https://www.gerritcodereview.com/3.1.html#3114) ++ GitHub Enterprise [3.0.7](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.7), +[2.22.13](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.13), +[2.21.21](https://help.github.com/enterprise-server@2.21/admin/release-notes#2.21.21), +[3.1.0](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.0), +[3.0.6](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.6), +[2.22.12](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.12), +[2.21.20](https://help.github.com/enterprise-server@2.21/admin/release-notes#2.21.20) ++ Magit [3.0.0](https://emacsair.me/2021/05/25/magit-3.0) ++ Forge [0.2.0](https://emacsair.me/2021/05/25/forge-0.2) ++ GitKraken [7.6.1](https://support.gitkraken.com/release-notes/current), +[7.6.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.8.1](https://desktop.github.com/release-notes/), +[2.8.0](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + +* Linus Torvalds was [interviewed](https://www.tag1consulting.com/blog/interview-linus-torvalds-linux-and-git) + on the Tag1 Consulting site about 30 Years Of Linux and + [about Git](https://www.tag1consulting.com/blog/interview-linus-torvalds-linux-and-git#git-distributed-version-control-). + A [part 2](https://www.tag1consulting.com/blog/interview-linus-torvalds-open-source-and-beyond-part-2) + of the interview not related to Git has also been published. +* GitHub announced that [security keys are now supported for SSH Git operations](https://github.blog/2021-05-10-security-keys-supported-ssh-git-operations/) via `ecdsa-sk` and `ed25519-sk` key types. + + +__Light reading__ + +* [Scaling monorepo maintenance](https://github.blog/2021-04-29-scaling-monorepo-maintenance/) + by Taylor Blau on GitHub Blog, with reverse indexes, multi-pack bitmaps, and geometric repacking. +* [Developing a script in small steps](https://dev.to/vkroll/common-misconception-of-beginners-51jb) + by Volker Kroll on Dev.to. +* [Plotting the source code "TODO" history of the most popular open source projects](https://schleiss.io/plotting-source-code-todos-for-open-source-projects) + by Martin Schleiss. +* [Git Push to Remote Branch - How to Push a Local Branch to Origin](https://www.freecodecamp.org/news/git-push-to-remote-branch-how-to-push-a-local-branch-to-origin/) + by John Mosesman on freeCodeCamp.org. +* [Heroku-style deployments with Docker and Git tags](https://ricardoanderegg.com/posts/git-push-deployments-docker-tags/) + (and `post-receive` hook) by Ricardo Ander-Egg Aguilar. +* [YubiKey for SSH, Login, 2FA, GPG and Git Signing](https://ocramius.github.io/blog/yubikey-for-ssh-gpg-git-and-local-login/) by Marco Pivetta (Ocramius). +* [Diff and merge CSV files in your Git client](https://paulfitz.github.io/2014/07/09/diff-merge-csv.html) + using [daff](http://paulfitz.github.io/daff/) by Paul Fitz (2014). +* [Visual Studio code editor: Eight tips for using GitLab VS Code](https://about.gitlab.com/blog/2021/05/20/vscode-workflows-for-working-with-gitlab/) + extension by Tomas Vik on GitLab Blog. +* [Top Ten Git Tips & Tricks](https://www.honeybadger.io/blog/git-tricks/) + by Julie Kent on Honeybadger blog. + + +__Git tools and sites__ + +* [Komit](https://github.com/GitSquared/komit) is a Node.js based small command line + application providing interactive prompt, designed to be run as a Git hook to + help follow the [Conventional Commit message standard](https://www.conventionalcommits.org/en/v1.0.0/). + This standard was mentioned in [Git Rev News Edition #52][rn-52] and [#54][rn-54]; + another tool that helps follow this standard is [Sailr](https://github.com/craicoverflow/sailr) + (also mentioned in [edition #52][rn-52]). +* [Flat Data](https://octo.github.com/projects/flat-data) explores how to make + it easy to work with data in Git and GitHub. The Flat Data project + incorporates three different pieces: the Flat Action (GitHub Action), the Flat Editor + VS Code extension, and the Flat Viewer website. +* [git-split-diffs](https://github.com/banga/git-split-diffs), a Node.js + command-line application, provides side-by-side split diffs with syntax + highlighting in your terminal, and can be used via `core.pager` or `pager.diff`. +* [daff: data diff](http://paulfitz.github.io/daff/) is a library and a tool for + comparing tables, producing a summary of their differences, and using such a + summary as a patch file. It is optimized for comparing tables that share a + common origin, in other words multiple versions of the "same" table. With daff, + you can also make Git diffs and merges table-aware. +* [github-csv-diff](https://github.com/wy-z/github-csv-diff) and + [CSVHub](https://github.com/Data-Liberation-Front/csvhub) are both + Chrome extensions to show CSV diffs on GitHub. +* [Semgrep](https://semgrep.dev/) is a fast, Open Source, static analysis tool + for finding bugs and enforcing code standards at editor, commit, or CI time; + rules look like the code you’re searching. + + +[rn-52]: https://git.github.io/rev_news/2019/06/28/edition-52/ +[rn-54]: https://git.github.io/rev_news/2019/08/21/edition-54/ + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Patrick Steinhardt, Andrew Ardill, +Felipe Contreras and Jonas Bernoulli. diff --git a/_posts/2021-06-27-edition-76.markdown b/_posts/2021-06-27-edition-76.markdown new file mode 100644 index 000000000..132be8d5c --- /dev/null +++ b/_posts/2021-06-27-edition-76.markdown @@ -0,0 +1,285 @@ +--- +title: Git Rev News Edition 76 (June 27th, 2021) +layout: default +date: 2021-06-27 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 76 (June 27th, 2021) + +Welcome to the 76th 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](https://git.github.io). + +This edition covers what happened during the month of May 2021. + +## Discussions + + + + + + +### Support + +* [[BUG] Unix Builds Requires Pthread Support](https://lore.kernel.org/git/009d01d74b44$9efe8a60$dcfb9f20$@nexbridge.com/) + + Not long after 2.32.0-rc0 was released, Randall S. Becker reported + to the mailing list that + [a patch series](https://lore.kernel.org/git/pull.766.v4.git.1613598529.gitgitgadget@gmail.com/) + from Jeff Hostetler, which introduced a "Simple IPC Mechanism", + broke the build for the NonStop x86 and ia64 platforms. This build + defines `NO_PTHREADS`, as supporting pthreads on these platforms is + considered to cause "a bunch of other issues". + + It seems that Jeff patch series has introduced a file, called + `ipc-unix-socket.c`, which contains a call to the + `pthread_sigmask()` function part of the pthreads library, which is + of course not linked to when `NO_PTHREADS` is defined. + + Randall suggested a "simple, but probably wrong fix" which just + surrounds the call to `pthread_sigmask()` with `#ifndef NO_PTHREADS` + and `#endif`. + + Peff, alias Jeff King, replied to Randall that usually an "async" + mechanism is used for tasks that can be performed by several workers + in parallel, and that underneath this mechanism can be implemented + both using different processes and using different threads. At build + time, depending on the availability of pthread, one or the other + implementation is selected. + + Peff couldn't tell though, if the "async" interface that the IPC + mechanism defines can actually be implemented using + processes. Anyway he proposed an improved patch to fix the build by + just removing the files implementing the mechanism from the build if + `NO_PTHREADS` if defined, similar to dealing with `NO_UNIX_SOCKETS`. + + Jeff Hostetler, who had implemented the IPC mechanism, then replied + to Peff that the mechanism was heavily threaded and that there was + no point in trying to "fake it" with processes. So he agreed with + Peff's patch, which conditionally removes it from the build. + + Peff replied to Jeff asking if he wanted to pick his patch up from + there and produce a polished patch before the 2.32.0 release. Jeff + then agreed to do that, and sent + [a more elaborate patch](https://lore.kernel.org/git/pull.955.git.1621352192238.gitgitgadget@gmail.com/) + based on Peff's patch and on some discussions about it that happened + in the meantime between Peff and Randall. + + Junio reviewed Jeff's patch and made some suggestions, which after + further discussion were integrated in + [version 2 of the patch](https://lore.kernel.org/git/pull.955.v2.git.1621520547726.gitgitgadget@gmail.com/). + + A [version 3](https://lore.kernel.org/git/pull.955.v3.git.1621535291406.gitgitgadget@gmail.com/) + soon followed to fix the build for people using CMake instead of make. + This version was merged before 2.32.0-rc1. + + +## Developer Spotlight: Han-Wen Nienhuys + +* Who are you and what do you do? + + I’m Han-Wen Nienhuys. I work at Google, where I manage the Gerrit + team. If you don’t know yet, [Gerrit](https://www.gerritcodereview.com/) + is the Git-based code review system that Google uses for large open + source projects, such as Android and Chrome. + + For a while, Shawn Pearce was my boss. I got to know him because of + previous Git adventures at Google: I created git5, a wrapper around + our internal Perforce (‘p4’) deployment as a side project. You can + still see some traces of this, if you look at the commit history of + git-p4. + +* What would you name your most important contribution to Git? + + I didn’t contribute many patches to Git directly, but here is my + biggest one so far: + + Gerrit accepts code for review through a `git push` command, and user + studies showed that Gerrit’s error messages didn’t stand out among + the verbose terminal output. I added colorization for keywords like + “ERROR” and “WARNING” to draw more attention. + +* What are you doing on the Git project these days, and why? + + Gerrit uses Git as a database, storing all review metadata + (comments, LGTMs) in Git itself, which is extremely cool, but it + also creates extremely ..interesting.. scaling problems for Git and + JGit. + + One area of scaling is the ref database: Gerrit stores both metadata + and each version of a code review in a separate ref. As a result, + large projects, such as Chrome, now have several millions of refs in + their repository. Handling those efficiently is a challenge. Shawn + designed reftable to solve these problems, and partly implemented it + in JGit, but he never got round to updating the Git project itself + to use the format. + + At the end 2019, I thought it would be an interesting and fun + project to drive that project further. I did severely underestimate + how complicated it would be to do brain surgery on Git itself, + though, so 1.5 years later, it still hasn’t merged. Working on Git + itself (as opposed to Gerrit, and managing the team) is a side + project, so progress hasn’t been as fast as I’d like it to be. + +* 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? + + Rewrite Git on top of [libgit2](https://libgit2.org/). Or even + better, rewrite it in Go. Hacking on Git is a fun trip down memory + lane, because the last time I wrote C seriously, I was half my + current age. It doesn’t feel very productive though, in part because + of limitations of the language (memory management, lack of + strings/maps/GC etc.). + + I realize that’s ambitious, and would turn off a lot of the current + contributors, however, I think much could also be gained by + structuring the program better (e.g. banish global variables, + introduce more unit tested abstraction boundaries), and that could be + achieved by rewriting parts on top of libgit2. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + The packed/loose ref backend. All of Git storage is user-accessible + (under the `.git` directory), but the packed/loose ref storage is + extra insidious, because you read/write it using `cat` and `echo`, + which invites people to break abstraction boundaries. + +* What is your favorite Git-related tool/library, outside of Git + itself? + + It’s Gerrit, of course. + +## Releases + ++ Git [2.32.0](https://public-inbox.org/git/xmqqa6o3xj2e.fsf@gitster.g/), +[2.32.0-rc3](https://public-inbox.org/git/xmqq4kegr7o3.fsf@gitster.g/), +[2.32.0-rc2](https://public-inbox.org/git/xmqq4ken75cv.fsf@gitster.g/) ++ Git for Windows [2.32.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.32.0.windows.1), +[2.32.0-rc3(1)](https://github.com/git-for-windows/git/releases/tag/v2.32.0-rc3.windows.1), +[2.32.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.32.0-rc2.windows.1) ++ Bitbucket Server [7.14](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitHub Enterprise [3.1.2](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.2), +[3.0.10](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.10), +[2.22.16](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.16), +[3.1.1](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.1), +[3.0.9](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.9), +[2.22.15](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.15), +[2.21.23](https://help.github.com/enterprise-server@2.21/admin/release-notes#2.21.23), +[3.1.0](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.0) ++ GitLab [14.0.1](https://about.gitlab.com/releases/2021/06/24/gitlab-14-0-1-released/), +[14.0](https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-released/), +[13.12.5](https://about.gitlab.com/releases/2021/06/21/gitlab-13-12-5-released/), +[13.12.4](https://about.gitlab.com/releases/2021/06/14/gitlab-13-12-4-released/), +[13.12.3](https://about.gitlab.com/releases/2021/06/07/gitlab-13-12-3-released/), +[13.12.2, 13.11.5, and 13.10.5](https://about.gitlab.com/releases/2021/06/01/security-release-gitlab-13-12-2-released/) ++ GitHub Desktop [2.9.0](https://desktop.github.com/release-notes/), +[2.8.3](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ +* [The 2021 Gerrit Community Survey results](https://docs.google.com/presentation/d/11Ivu6xtYZBYTU5e5y_lc6tni3nm9fNIUbX2VRTyTMbE/edit#slide=id.ge209b6f75c_0_1459) + have been published, showing a robust increase of the overall number of users and the adoption + of the most recent versions of [Gerrit Code Review](https://www.gerritcodereview.com). + +* [Got typos? Git 2.32 lands, finally offers way to reword commits [easily]](https://devclass.com/2021/06/07/got-typos-git-2-32-lands-finally-offers-way-to-reword-commits/). + + +__Light reading__ +* [Crypto Mining is Killing All Free CI/CD Platforms](https://dev.to/n3wt0n/crypto-mining-is-killing-all-free-ci-cd-platforms-4chc) + by Davide 'CoderDave' Benvegnù is a blog post on Dev.to + and a [video on YouTube](https://www.youtube.com/watch?v=9TOJqJSHVvI). + The platforms affected include GitLab, TravisCI, CircleCI and GitHub Actions; + the CI providers have limited their free tiers, or have to spend much effort + on combating crypto miners abusing the platform in response. + +* [Pulling GitHub into the kernel process](https://lwn.net/Articles/860607/) by Jake Edge on LWN.net + ([free link for not subscribed](https://lwn.net/SubscriberLink/860607/fdbce807fe931123/)) + describes attempts to make it possible to submit patches to the Linux kernel + via GitHub pull requests (PR). While at it, it also mentions various attempts + and tools to improve an email-based workflow. + + * For submitting patch series to the Git project via GitHub pull requests, + there is [GitGitGadget](https://gitgitgadget.github.io/), described in + [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/). + +* [A Random Walk Through Git](https://bakkenbaeck.github.io/a-random-walk-through-git/) + by Bakken & Bæck is a weird in-depth tour through Git and some of its internals, + including reflog, interactive rebase, bisect and rerere. + +* [How to never type passwords when using Git](https://dev.to/github/how-to-never-type-passwords-when-using-git-18bb) + by Michelle Mannering on Dev.to. + +* [Confusing Terms in the Git Terminology](https://dev.to/pragativerma18/confusing-terms-in-the-git-terminology-1578) + by Pragati Verma on Dev.to. + +* [Git Good - The magic of keeping a clean Git history](https://simplabs.com/blog/2021/05/26/keeping-a-clean-git-history/) + post by Chris Manson is designed to help you form a solid mental model while + working with Git both professionally and in an open source project, and how to + ensure you are following best practices to make the process easier for + everyone. + +* [Merge vs rebase](https://dev.to/emyller/merge-vs-rebase-63e) + by Evandro Myller on Dev.to. + +* [Git Log: How to Use It](https://careerkarma.com/blog/git-log/) + by James Gallagher (2020), one of Git tutorials on Career Karma blog. + +* [Fixing basic mistakes with Git](https://dev.to/abh1navv/fixing-basic-mistakes-with-git-4m4l) + by Abhinav Pandey on Dev.to. + +* [After CRUD: Intro to Git and basic workflows](https://johnmosesman.com/post/after-crud-git/) + by John Mosesman (2019). + + +__Git tools and sites__ +* [A Git history visualization page](https://git-history.jpalmer.dev/) +by Jeff Palmer <> shows "An Interactive Development History" of Git in +three columns: project and contributor statistics, relative cumulative +contributions by contributor, and aggregated commits by +contributor by month with milestone annotations. Jeff wrote +[an associated blog post](https://jpalmer.dev/2021/05/interactive-git-history/) about how +he created the visualization, and he's also looking for +feedback and ideas for milestones or features he could add. + +* [git undo: We can do better](https://blog.waleedkhan.name/git-undo/) +describes the `git-undo` tool that is +a [part of the git-branchless suite of tools](https://github.com/arxanas/git-branchless); +it can undo bad merges and rebases with ease, and even some rarer operations. +This `git undo` tool was made possible by a recent addition to Git: +the [reference-transaction hook](https://git-scm.com/docs/githooks#_reference_transaction) +(not yet present on the [GitHooks.com](https://githooks.com) site, mentioned +in [Git Rev News Edition #43](https://git.github.io/rev_news/2018/09/19/edition-43/); +the reference-transaction hook was described in [#75](https://git.github.io/rev_news/2021/03/27/edition-73/)). + + * The [GitUp](https://gitup.co/) client also supports undo/redo via snapshots, + also by adding additional plumbing on top of Git. This tool was first mentioned + in [Git Rev News #5](https://git.github.io/rev_news/2015/07/08/edition-5/). + + * The `undo` Git alias described in [Git Undo](http://megakemp.com/2016/08/25/git-undo/) + post by Enrico Campidoglio simply uses the reflog, and is less capable. This post + was mentioned in [Git Rev News #19](https://git.github.io/rev_news/2016/08/17/edition-18/). + +* [git-branchless](https://github.com/arxanas/git-branchless) is a suite of tools, +written in Rust, to help you **visualize**, **navigate**, **manipulate**, and **repair** +your commit history. It's based off of the branchless Mercurial workflows at large companies +such as Google and Facebook. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Han-Wen Nienhuys, Luca Milanesio and +Jeffrey Palmer. diff --git a/_posts/2021-07-31-edition-77.markdown b/_posts/2021-07-31-edition-77.markdown new file mode 100644 index 000000000..08f225cb4 --- /dev/null +++ b/_posts/2021-07-31-edition-77.markdown @@ -0,0 +1,191 @@ +--- +title: Git Rev News Edition 77 (July 31st, 2021) +layout: default +date: 2021-07-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 77 (July 31st, 2021) + +Welcome to the 77th 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](https://git.github.io). + +This edition covers what happened during the month of June 2021. + +## Discussions + + + +### Reviews + +* [[PATCH] builtins + test helpers: use return instead of exit() in cmd_\*](https://lore.kernel.org/git/patch-1.1-61d7e6e079-20210607T111008Z-avarab@gmail.com/) + + Ævar Arnfjörð Bjarmason sent a patch to the mailing list that + changed some `cmd_*()` functions so that they use a `return` statement + instead of `exit()`. He further said that it is legitimate for the + SunCC compiler on Solaris to complain about the exit() calls, as + they would skip any cleanup made after them. + + The `cmd_*()` functions are important in the architecture of Git, as + there is one such function for each Git "builtin" command, and the + function is called by `run_builtin()` in `git.c` to perform the + command. For example when `git log` is launched, the `cmd_log()` + function is called by `run_builtin()`. + + Felipe Contreras reviewed the patch and found it obviously correct. + + Peff, alias Jeff King, also said that it looked like simple and + obvious conversions, but he wondered what was SunCC complaining + about, especially if it didn't know about `NORETURN`, and would + complain about many other `exit()` calls. + + `NORETURN` is a special statement to tell the compiler that a + function doesn't return, but instead uses a function like `exit()` + to stop the current process. + + Phillip Wood also wondered if SunCC would complain about `die()` + calls, which use `exit()` underneath. + + Ævar then sent + [a version 2](https://lore.kernel.org/git/patch-1.1-f225b78e01-20210608T104454Z-avarab@gmail.com/) + of his patch, with no code change but explaining that SunCC actually + complains when there's no `NORETURN` while we declare a `cmd_*()` + function to return an `int`. He replied to Peff with the same + explanation and added that around half of SunCC warnings are + legitimate, and that he had already been sending miscellaneous fixes + for 15-20 of them. + + Junio Hamano, the Git maintainer, replied to the version 2 patch. + He especially had an issue with the part in the commit message that + said that directly `exit()`-ing would skip the cleanups `git.c` would + otherwise do, like closing file descriptors and issuing errors if it + failed. He considered that it was "not a crime" for the functions to + exit themselves as file descriptors are closed when we exit and "if + we do have clean-ups that are truly important, we would have + arranged them to happen in the `atexit()` handler". + + Junio anyway thought that the patch was still "a good idea because + it encourages good code hygiene". + + Ævar replied to Junio that file descriptors are indeed closed when we + exit, but the errors we could get when closing them would not be + reported. He pointed to previous commits that had been merged back + in 2007 to make sure IO errors were properly reported after the + `cmd_*()` functions return, and said that "the `atexit()` handlers + cannot modify the exit code (both per the C standard, and POSIX)". + He also discussed a bit how glibc allows `atexit()` handlers to + munge the exit code though it's not portable behavior. + + Junio replied that Ævar was right and that "we leave a final clean-up + for normal returns (i.e. when `cmd_foo()` intends to return or exit + with 0) to be done by the caller". + + The patch was later merged into the master branch and the next + version of Git will better signal IO errors, thanks to SunCC and + people running it to compile Git on Solaris machines. + + + + + +## Releases + ++ Git for Windows [2.32.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.32.0.windows.2) ++ libgit2 [1.1.1](https://github.com/libgit2/libgit2/releases/tag/v1.1.1) ++ Gerrit Code Review [3.3.5](https://www.gerritcodereview.com/3.3.html#335), +[3.2.11](https://www.gerritcodereview.com/3.2.html#3211) ++ GitHub Enterprise [3.1.3](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.3), +[3.0.11](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.11), +[2.22.17](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.17) ++ GitLab [14.1.0](https://about.gitlab.com/releases/2021/07/22/gitlab-14-1-released/), +[14.0.6](https://about.gitlab.com/releases/2021/07/20/gitlab-14-0-6-released/), +[14.0.5](https://about.gitlab.com/releases/2021/07/08/gitlab-14-0-5-released/), +[14.0.4, 13.12.8, and 13.11.7](https://about.gitlab.com/releases/2021/07/07/critical-security-release-gitlab-14-0-4-released/), +[14.0.3](https://about.gitlab.com/releases/2021/07/06/gitlab-14-0-3-released/), +[13.12.7](https://about.gitlab.com/releases/2021/07/05/gitlab-13-12-7-released/), +[14.0.2, 13.12.6, and 13.11.6](https://about.gitlab.com/releases/2021/07/01/security-release-gitlab-14-0-2-released/) ++ Bitbucket Server [7.15](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitKraken [7.7.0](https://support.gitkraken.com/release-notes/current) + +## Other News + +__Various__ +* [Tower 7 - The New Commit Experience](https://www.git-tower.com/blog/tower-mac-7) +* [NO\_COLOR](https://no-color.org/) is a proposed universal standard of + disabling colored text output in command-line software programs. The website + also documents which software has adopted this standard and when support was + added, and for projects that did not adopt this standard it tries to document + how to otherwise disable color. + + +__Light reading__ +* [How to Get Better with Git](https://www.anavela.dev/how-to-get-better-with-git) + by Ana Vela provides a list of free and paid resources to help you boost your + Git know-how. +* [Git quick tips #1: git commit --fixup](https://citizen428.net/blog/git-quick-tips-1-commit-fixup/) and + [Git quick tips #2: Working with many branches](https://citizen428.net/blog/git-quick-tips-2-working-with-many-branches/) + by Michael Kohl. +* [Git For Data Engineers](https://towardsdatascience.com/git-for-data-engineers-a8b979d8b2ab) + by Kovid Rathee: a shortish guide to source control for data engineers, + data analysts, and data scientists. +* [How to Learn Git Slowly](https://suchdevblog.com/lessons/HowToLearnGit.html) + by Samuel Faure. +* [How NOT to use Git in Practice. Ten Git usages, you should know to avoid.](https://blog.greenroots.info/how-not-to-use-git-in-practice-ten-git-usages-you-should-know-to-avoid) + by Tapas Adhikary on GreenRoots Blog. +* [Elevate your Git-fu!](https://dev.to/abhaykrishna/elevate-your-git-fu-3ip4) + by Abhay Krishna Arunachalam on DEV.to. +* [How to Collaborate on Components across Projects with Bit](https://dev.to/giteden/how-to-collaborate-on-components-across-projects-with-bit-29c3) + by Eden Ella on DEV.to. The [Bit](https://github.com/teambit/bit) project was + mentioned in [Git Rev News Edition #45](https://git.github.io/rev_news/2018/11/21/edition-45/). +* [On the Evilness of Feature Branching - A Tale of Two Teams](https://thinkinglabs.io/articles/2021/07/14/on-the-evilness-of-feature-branching-a-tale-of-two-teams.html), + one novice practising [trunk-based development](https://trunkbaseddevelopment.com/), + the other very experienced using [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/), + by Thierry de Pauw. + * 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/). +* [Things I wish Git had: Commit groups](http://blog.danieljanus.pl/2021/07/01/commit-groups/) + by Daniel Janus - to have advantages of topic branch workflow + when using "rebase and merge" workflow. +* [Git Squash Simplified](https://dev.to/pb/git-squash-simplified-3ba1) + by Pawel Borkar on DEV.to. +* [How Git Branches Work](https://www.freecodecamp.org/news/how-git-branches-work/): + Git Branches Tutorial, by Beau Carnes, on freeCodeCamp. +* [git update: the odyssey for a sensible git pull](https://felipec.wordpress.com/2021/07/05/git-update/) + by Felipe Contreras. +* [Optimizing Git’s Merge Machinery, Part IV](https://palantir.medium.com/optimizing-gits-merge-machinery-part-iv-5bbc4703d050) + by Elijah Newren on Palantir Blog. + +__Git tools and sites__ +* [diffsitter](https://github.com/afnanenayet/diffsitter) creates semantically meaningful + diffs that ignore formatting differences like spacing. It does so by computing a diff + on the AST (abstract syntax tree) of a file rather than computing the diff on the text + contents of the file. `diffsitter` uses the parsers from + the [tree-sitter](https://tree-sitter.github.io/tree-sitter) project + to parse source code. Written in Rust, it is very much a work in progress. + +* [The best 6 VS Code extensions to supercharge Git](https://dev.to/jamieswift90/the-best-vs-code-extensions-to-supercharge-git-yes-there-s-more-than-gitlens-4588) + by Jamie Swift on DEV.to. +* [GitLive](https://marketplace.visualstudio.com/items?itemName=TeamHub.teamhub) + is a Visual Studio Code extension [to see which branch your teammates are on in VS Code](https://dev.to/gitlive/how-to-see-which-branch-your-teammates-are-on-in-vs-code-cb1). + +* [Git Immersion](https://gitimmersion.com/index.html) provides a guided tour + that walks through the fundamentals of Git, inspired by the premise that to + know a thing is to do it. Another [variant of Git Immersion](http://jce-il.github.io/git-immersion/index.html) + was mentioned in [Git Rev News Edition #38](https://git.github.io/rev_news/2018/04/18/edition-38/). + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> with help from Elijah Newren. diff --git a/_posts/2021-08-31-edition-78.markdown b/_posts/2021-08-31-edition-78.markdown new file mode 100644 index 000000000..9c493dea1 --- /dev/null +++ b/_posts/2021-08-31-edition-78.markdown @@ -0,0 +1,189 @@ +--- +title: Git Rev News Edition 78 (August 31st, 2021) +layout: default +date: 2021-08-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 78 (August 31st, 2021) + +Welcome to the 78th 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](https://git.github.io). + +This edition covers what happened during the month of July 2021. + +## Discussions + + + + + +### Support + +* [Bug report: GIT_CONFIG and user.email/name](https://lore.kernel.org/git/1C6C1E49-5EC1-420D-A72A-8C50BD1931A2@getmailspring.com/) + + German Lashevich sent a bug report about an issue when using the + `GIT_CONFIG` environment variable. + + He gave an example where he sets the `user.name` and `user.email` + config variables to some values in a temporary + `/tmp/git-test/.gitconfig` config file, and then sets `GIT_CONFIG` + to point to this file. + + When he then tried to commit some changes, Git errored out with an + "Author identity unknown" error and instructions about how to set + the current account's default identity. He expected that the values + of the `user.name` and `user.email` variables set in the temporary + config file would have been taken into account. + + Peff, alias Jeff King, replied that `GIT_CONFIG` is a historical + wart that isn't used by all of Git, but only the `git config` + command, and even there `git config --file` should be used instead. + + He suggested using `GIT_CONFIG_GLOBAL` or `GIT_CONFIG_SYSTEM` which + are available since v2.32.0. They instruct Git to read a specific + file instead of the usual global (usually `/etc/gitconfig`) or + system-level (`$HOME/.gitconfig` and `$XDG_CONFIG_HOME/git/config`) + config files respectively. + + German thanked Peff saying `GIT_CONFIG_GLOBAL` was what he needed. + + Junio Hamano, the Git maintainer, replied to Peff that reading the + `GIT_CONFIG` documentation gave a misleading impression as it + didn't say that `GIT_CONFIG` was only for the `git config` command. + + Peff agreed with Junio saying that the documentation hadn't been + updated since 2007, when `GIT_CONFIG` really did impact other + commands, and that he was sending + [a small patch series](https://lore.kernel.org/git/YO9ZGTX9f1fOpTkh@coredump.intra.peff.net/) + to improve the situation. + + Taylor Blau and Martin Ågren reviewed the patches and discussed them + a bit with Peff and Junio. + + The patch series was later merged into the master branch, and the + documentation improvements are now available in the recently + released Git 2.33. + + + +## Releases + ++ Git [2.33.0](https://public-inbox.org/git/xmqq1r6touqi.fsf@gitster.g/), +[2.33.0-rc2](https://public-inbox.org/git/xmqqo8a37eim.fsf@gitster.g/), +[2.33.0-rc1](https://public-inbox.org/git/xmqq5ywigls4.fsf@gitster.g/), +[2.33.0-rc0](https://public-inbox.org/git/xmqqbl6fv2b8.fsf@gitster.g/) ++ Git for Windows [2.33.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.33.0.windows.2), +[2.33.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.33.0.windows.1), +[2.33.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.33.0-rc2.windows.1), +[2.33.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.33.0-rc1.windows.1), +[2.33.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.33.0-rc0.windows.1) ++ GitHub Enterprise [3.1.6](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.6), +[3.0.14](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.14), +[2.22.20](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.20), +[3.1.5](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.5), +[3.0.13](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.13), +[2.22.19](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.19) ++ GitLab [14.0.8](https://about.gitlab.com/releases/2021/08/26/gitlab-14-0-8-released/), +[14.2.1](https://about.gitlab.com/releases/2021/08/23/gitlab-14-2-1-released/), +[14.2](https://about.gitlab.com/releases/2021/08/22/gitlab-14-2-released/), +[14.1.3](https://about.gitlab.com/releases/2021/08/17/gitlab-14-1-3-released/), +[13.12.10](https://about.gitlab.com/releases/2021/08/10/gitlab-13-12-10-released/), +[14.1.2](https://about.gitlab.com/releases/2021/08/03/security-release-gitlab-14-1-2-released/), +[14.1.1](https://about.gitlab.com/releases/2021/07/28/gitlab-14-1-1-released/) ++ Gerrit Code Review [3.3.6](https://www.gerritcodereview.com/3.3.html#336), +[3.2.12](https://www.gerritcodereview.com/3.2.html#3212), +[3.1.16](https://www.gerritcodereview.com/3.1.html#3116), +[3.4.1](https://www.gerritcodereview.com/3.4.html#341) ++ GitKraken [7.7.2](https://support.gitkraken.com/release-notes/current), +[7.7.1](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.9.2](https://desktop.github.com/release-notes/), +[2.9.1](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ +* [Highlights from Git 2.33](https://github.blog/2021-08-16-highlights-from-git-2-33/) + by Taylor Blau on GitHub Blog. +* [Treeverse raises $23M to bring Git-like version control to data lakes](https://venturebeat.com/2021/07/28/treeverse-raises-23m-to-bring-git-like-version-control-to-data-lakes/): + [lakeFS](https://lakefs.io/). +* [GitHub has shut down its Git password authentication on August 13, 2021](https://github.blog/changelog/2021-08-12-git-password-authentication-is-shutting-down/); + you should preferably use [token-based authentication](https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/) instead; support for SSH keys continues. + + +__Light reading__ +* [Optimizing Git’s Merge Machinery, Part V](https://blog.palantir.com/optimizing-gits-merge-machinery-part-v-46ff3710633e) by Elijah Newren on Palantir Blog. +* [How to write release notes](https://drewdevault.com/2021/05/19/How-to-write-release-notes.html) + by Drew DeVault. +* [From a Single Repo, to Multi-Repos, to Monorepo, to Multi-Monorepo](https://css-tricks.com/from-a-single-repo-to-multi-repos-to-monorepo-to-multi-monorepo/) + by Leonardo Losoviz on CSS-Tricks. + * The idea of monorepos was first mentioned by this name in [Git Rev News Edition #4](https://git.github.io/rev_news/2015/06/03/edition-4/), + with [Edition #47](https://git.github.io/rev_news/2019/01/23/edition-47/) + including many links to discussions about their advantages and disadvantages. +* [Visualizing a codebase](https://next.github.com/projects/repo-visualization): + how can we automatically “fingerprint” a codebase to see its structure at a glance, + by Amelia Wattenberger on GitHub Next. +* [The History Behind Git](https://ahmedgouda.hashnode.dev/the-history-behind-git) + by Ahmed Gouda (also [on DEV.to](https://dev.to/ahmedgouda/the-history-behind-git-53ag)). +* [Getting geeky with Git](https://wanago.io/courses/getting-geeky-with-git/), + an 11 part series by Marcin Wanago. +* [New in Git: switch and restore](https://www.banterly.net/2021/07/31/new-in-git-switch-and-restore/) + by Dragos Barosan (new to the author; [`git switch`](https://git-scm.com/docs/git-switch) + and [`git restore`](https://git-scm.com/docs/git-restore) appeared in Git 2.23 in 2019). +* [A Guide to Git Stash](https://dev.to/pragativerma18/a-guide-to-git-stash-2h5d) + by Pragati Verma on DEV.to. +* [How to Fix, Edit, or Undo Git Commits (Changing Git History)](https://www.cloudsavvyit.com/13067/how-to-fix-edit-or-undo-git-commits-changing-git-history/) + by Anthony Heddings on CloudSavvy IT. +* [5 Ways to Undo Mistakes with Git](https://www.sitepoint.com/5-ways-to-undo-mistakes-with-git) + by Tobias Günther on SitePoint. +* [5 Git Tricks Every Developer Should Know](https://dev.to/shadid12/5-git-tricks-every-developer-should-know-1201) + by Shadid Haque on DEV.to. +* [Git for Managing Small Projects](https://thenewstack.io/git-for-managing-small-projects/) + by Rob "drtorq" Reilly on The New Stack, the first part in a planned series of tutorials on Git. +* [Git: Fetch and Merge, don’t Pull](https://longair.net/blog/2009/04/16/git-fetch-and-merge/), + an old blog post by Mark Longair about his tips related to fetching and merging versus pulling, + that was [discussed a long time ago on the mailing list](https://lore.kernel.org/git/alpine.DEB.1.00.0904191709220.10279@pacific.mpi-cbg.de/). +* [Best practices for writing code comments](https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/) + by Ellen Spertus about writing better code comments. + + +__Git tools and sites__ +* [lakeFS](https://lakefs.io/) is an open source tool that transforms your + object storage into a Git-like repository. It enables you to manage your + [data lake](https://aws.amazon.com/big-data/datalakes-and-analytics/what-is-a-data-lake/) + (storing _unprocessed_ data) the way you manage your code. Supports AWS S3, + Azure Blob Storage and Google Cloud Storage; works seamlessly with all + modern data frameworks such as Spark, Hive, AWS Athena, Presto, etc. + * Existing products comparable to LakeFS include tools such as + [DVC](https://dvc.org/) (first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/)), + [Pachyderm](https://www.pachyderm.com/) (first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/)), and + [Meltano](https://meltano.com/) (first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/)). + +* [`CITATION.cff`](https://citation-file-format.github.io/) files, + which use Citation File Format (CFF), are plain text files with + human- and machine-readable citation information for software (and datasets). + Code developers can include them in their repositories to let others know + how to correctly cite their software. Supported by GitHub, Zenodo and Zotero. + +* [GitUI](https://github.com/extrawurst/gitui) is a blazing fast terminal based GUI for Git + written in Rust, meant to work reliably even on large repositories. + Similar to [tig](https://jonas.github.io/tig/). + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Elijah Newren and Philip Oakley. diff --git a/_posts/2021-09-30-edition-79.markdown b/_posts/2021-09-30-edition-79.markdown new file mode 100644 index 000000000..780016aa3 --- /dev/null +++ b/_posts/2021-09-30-edition-79.markdown @@ -0,0 +1,268 @@ +--- +title: Git Rev News Edition 79 (September 30th, 2021) +layout: default +date: 2021-09-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 79 (September 30th, 2021) + +Welcome to the 79th 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](https://git.github.io). + +This edition covers what happened during the month of August 2021. + +## Discussions + +### General + +* [GSoC (Google Summer of Code) 2021 End](https://summerofcode.withgoogle.com/organizations/5908380398387200/#projects) + + Congratulations to the two students who had been accepted to work on + Git as part of the [GSoC 2021](https://summerofcode.withgoogle.com/) + as they successfully passed all the evaluations! + + - Atharva Raykar worked on the + [Finish converting submodule to builtin](https://summerofcode.withgoogle.com/projects/#4754589292691456) + project. He was co-mentored by Shourya Shukla and Christian Couder. He posted 2 final blog posts about it, + some [Reflections on Working With the Git Community](https://atharvaraykar.me/gitnotes/final-reflection) + and a [Technical Report](https://atharvaraykar.me/gitnotes/final-report). + + - ZheNing Hu worked on the + [Use ref-filter formats in `git cat-file`](https://summerofcode.withgoogle.com/projects/#6499923274498048) + project. He was co-mentored by Hariom Verma and Christian Couder and posted + [a final blog post about it](https://adlternative.github.io/GSOC-Git-Final-Blog/). + + + +### Support + +* [bug in `git fsck`?](https://public-inbox.org/git/60DF1C22020000A100042225@gwsmtp.uni-regensburg.de/) + + Last July, Ulrich Windl asked the mailing list whether `git fsck` + should be able to cleanup orphaned branches. He pointed to + [a question he asked on StackOverflow](https://stackoverflow.com/questions/68226081/how-to-recover-head-problems-in-filtered-repository) + as he wanted to get rid of obsolete branches after filtering a repo. + + `git fsck` was complaining about a branch called `bitmap-generic` + saying `notice: HEAD points to an unborn branch (bitmap-generic)`, + because that branch was pointing to a commit that didn't exist + anymore after filtering the repo, and he couldn't delete that branch + as `git branch -d` errored out with `fatal: Couldn't look up commit + object for HEAD`. + + Junio Hamano replied to Ulrich that "HEAD pointing at an unborn + branch is not even a corruption", as that's what happen to the + default branch when a repo is initialized. + + Ulrich replied that he might have been confused by `git fsck` and + suggested updating the documentation to explain what "unborn" + means. Ævar Arnfjörð Bjarmason then agreed with Ulrich that "fsck's + error messages/reporting is pretty bad". He said that he had been + working on it though. + + Meanwhile René Scharfe replied to Junio saying that `git branch -D` + (`-D` is a shortcut for `--delete --force`) should delete a branch + pointing to an unexisting commit, instead of requiring users to + first reset the branch to some known commit using + `git branch --force` and then to delete it with `git branch --delete`. + In this reply René even provided a patch called "branch: allow deleting + dangling branches with `--force`" that implemented what he suggested. + + Ulrich and René then discussed how to actually force a branch in a way + that it can then be deleted. The issue was that Ulrich tried to + force the dangling branch, using `git branch --force bitmap-generic` + when the current branch wasn't a valid one, so the dangling branch + wasn't restored to a valid commit. + + To René's patch, Junio replied that he felt the filtering process + Ulrich used shouldn't have left dangling branches hanging around in + the first place. He agreed though that it should be easy to recover + from "such a deliberate repository corruption". + + René's patch then fell through the cracks for several weeks, until + the end of August when + [René resent it](https://public-inbox.org/git/7894f736-4681-7656-e2d4-5945d2c71d31@web.de/). + + Junio replied that the test in René's patch went "against the + spirit" of a recently merged patch series by Han-Wen Nienhuys that + was preparing tests for the new `reftable` ref backend. + + The [reftable backend](https://www.git-scm.com/docs/reftable) was + initially [proposed and developed](https://lore.kernel.org/git/CAJo=hJtyof=HRy=2sLP0ng0uZ4=S-DpZ5dR1aF+VHVETKG20OQ@mail.gmail.com/) + in 2017 by Shawn Pearce. An implementation of it has then been integrated in + [JGit](https://git.eclipse.org/r/plugins/gitiles/jgit/jgit/+/refs/heads/master/Documentation/technical/reftable.md), + and Han-Wen has been working for some time on versions of this backend + for Git and libgit2. + + Junio suggested to change parts of the test that were creating or + testing refs to use higher functions to manipulate refs, instead of + directly manipulating loose ref files like + `.git/refs/heads/dangling`. + + Junio, Ævar, Han-Wen, Ulrich and René then discussed different ways + to change the test, like using the `REFFILES` test + prerequisite. They wondered if such a dangling ref could also happen + with the reftable backend, and it seemed that this could indeed + happen. + + Han-Wen suggested the ref-store test-helper's `update-ref` command + to manipulate refs instead. Ulrich proposed implementing a new + `--disarm-safety-belt` option to disable checks for testing + purposes. Ævar suggested a workaround using an alternate object + directory. + + Meanwhile Ævar commented a bit on René's resent patch. And René + replied to the comments, especially noting that `git tag -d` would + delete a dangling tag even without `--force`. + + René then sent [a version 2](https://public-inbox.org/git/325d64e9-8a31-6ba0-73f2-5e9d67b8682f@web.de/) + of his resent patch with an updated test that was now + independent from any ref backend. + + Junio, Ævar and René discussed the patch a bit more, after which René sent + [a version 3](https://public-inbox.org/git/c192f438-2eaf-c098-9fe4-c03a9d36cbd0@web.de/) + with a few more improvements to the test. + + As this version of the patch has since been merged into the master + branch, Git will soon allow to delete dangling branches more easily. + +## Developer Spotlight: Josh Steadmon + +* Who are you and what do you do? + + I'm a Software Engineer at Google, and I work on a team dedicated to + Git. Outside of work, I'm a husband and a new dad, which doesn't leave + me much time for anything else :). + + Git is actually my first experience as a professional developer. Up + until I joined the Git team in 2018, my career had been in system + administration and reliability engineering. + +* What would you name your most important contribution to Git? + + Probably the addition of fuzz tests. Not so much due to impact so far + (although it has found a few small bugs), but because of the opportunity + for future work in this area. If I had more time, I'd love to look into + having a proper fuzz tester for client/server communication, for + example. + +* What are you doing on the Git project these days, and why? + + Until recently, the majority of my work has been internal performance + monitoring of Git usage by Google developers. Lately I've been winding + down my work on monitoring and starting to look into improving + performance and the user experience with submodules. Only the very + beginnings of that have started to show up on-list so far. + +* 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 I'd echo my former coworker [Brandon Williams (edition 28)](https://git.github.io/rev_news/2017/06/14/edition-28/#developer-spotlight-brandon-williams), + and work on cleaning up the global state. For a new-ish developer who + doesn't have full history on all the various subsystems, it can be + difficult to follow the logic when there's lots of non-local state being + modified. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + Not so much to remove as change: I wish it was easier to move away from + SHA-1 hashes. I'm very happy that brian m. carlson has been working on + supporting SHA-256. + +* What is your favorite Git-related tool/library, outside of Git itself? + + I'm a huge fan of [git-annex](https://git-annex.branchable.com/) and use + it to keep my ever-growing pile of PDFs and ebooks synced and organized + across various devices. I also use it to archive primary sources in a + homebrew personal knowledge base. + +## Releases + ++ libgit2 [1.2.0](https://github.com/libgit2/libgit2/releases/tag/v1.2.0) ++ GitLab [13.12.12](https://about.gitlab.com/releases/2021/09/22/gitlab-13-12-12-released/), +[14.3](https://about.gitlab.com/releases/2021/09/22/gitlab-14-3-released/), +[14.2.4](https://about.gitlab.com/releases/2021/09/17/gitlab-14-2-4-released/), +[13.12.11](https://about.gitlab.com/releases/2021/09/02/gitlab-13-12-11-released/), +[14.0.10](https://about.gitlab.com/releases/2021/09/02/gitlab-14-0-10-released/), +[14.2.3](https://about.gitlab.com/releases/2021/09/01/gitlab-14-2-3-released/), +[14.2.2, 14.1.4, and 14.0.9](https://about.gitlab.com/releases/2021/08/31/security-release-gitlab-14-2-2-released/) ++ Bitbucket Server [7.16](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitHub Enterprise [3.1.8](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.8), +[3.0.16](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.16), +[2.22.22](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.22), +[3.2.0](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.0), +[3.1.7](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.7), +[3.0.15](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.15), +[2.22.21](https://help.github.com/enterprise-server@2.22/admin/release-notes#2.22.21) ++ GitKraken [8.0.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.9.3](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ +* [3 Reasons to Upgrade Git For The First Time Ever](https://dev.to/swyx/3-reasons-to-upgrade-git-2bj3) + by swyx on DEV.to. +* [Emacs discusses web-based development workflows](https://lwn.net/Articles/867956/) + by Jake Edge on LWN.net. + + +__Light reading__ +* [Optimizing Git’s Merge Machinery, Part VI](https://blog.palantir.com/optimizing-gits-merge-machinery-6-7bf887a131d8) by Elijah Newren on Palantir Blog, the final in the series. +* [Ship / Show / Ask: A modern branching strategy](https://martinfowler.com/articles/ship-show-ask.html) + by Rouan Wilsenach on martinFowler.com, showing different ways of doing + Continuous Integration with a Pull Request workflow, and explaining when + to use which method. +* [GitHub merges 'useless garbage' says Linus Torvalds (as new NTFS support added to Linux kernel 5.15)](https://www.theregister.com/2021/09/06/github_merges_useless_garbage_says/) + by Tim Anderson in The Register. +* [How to Protect Your Private Email Addresses in Git & GitHub?](https://www.geeksforgeeks.org/how-to-protect-your-private-email-addresses-in-git-github/) + on GeeksforGeeks (GitHub specific with respect to hiding your email while + still counting your contributions). +* [Advanced Git Workflow Tips](https://blog.jetbrains.com/dotnet/2021/09/13/advanced-git-workflow-tips/) + by Khalid Abuhakmeh on JetBrains' The .NET Tools Blog, additionally explaining + how to perform the actions from [Rider](https://www.jetbrains.com/rider/)’s .NET IDE UI. +* [Increasing developer happiness with GitHub code scanning](https://github.blog/2021-09-07-increasing-developer-happiness-github-code-scanning/) + by Sam Partington on the GitHub Blog; the examples use the Go language. + [GitHub code scanning](https://github.blog/2021-09-07-increasing-developer-happiness-github-code-scanning/) + uses the [CodeQL](https://securitylab.github.com/tools/codeql/) semantic code analysis engine. +* [GitHub Workflow, Merge and Rebase](https://dev.to/aarondski/github-workflow-merge-and-rebase-1cig), + actually more about Git than about GitHub, by AaronDski on DEV.to. +* [How to Use Git Hooks For Commit Automation](https://www.cloudsavvyit.com/14036/how-to-use-git-hooks-for-commit-automation/) + by Anthony Heddings on CloudSavvy IT. +* [Run RuboCop on `git commit` with Overcommit Gem](https://prabinpoudel.com.np/articles/run-rubocop-on-git-commit-with-overcommit-gem/) + by Prabin Poudel on his blog. [Overcommit gem](https://github.com/sds/overcommit) + was mentioned in [Git Rev News #63](https://git.github.io/rev_news/2020/05/28/edition-63/), + along various other hook management tools. +* [Git Flow Is A Bad Idea](https://www.youtube.com/watch?v=_w6TwnLCFwA) video by Dave Farley of Continuous Delivery. + An interesting perspective on the Git branching model. Worth reflecting on the underlying assumptions + and management approaches that make Git branches such a bad idea, in that particular context. +* [Full Git Tutorial](https://www.youtube.com/watch?v=58zsLtwzL60). Basics for the new user. + Leap to Part 7 for the `Git Log Fully Explained`. + + +__Git tools and sites__ +* [Glean](https://glean.software/): System for collecting, deriving and querying facts about source code. +* [5 JetBrains plugins to upgrade the built-in Git support to the next level!](https://dev.to/anotherdevuser/5-jetbrains-plugins-to-upgrade-the-builtin-git-support-to-the-next-level-3ojf) + by Thomas Scott on DEV.to. A similar list for Visual Studio Code was + presented in [Git Rev News Edition #77](https://git.github.io/rev_news/2021/07/31/edition-77/). +* [GitHub Web Editor: FREE VSCode in the browser](https://dev.to/github/vscode-in-the-browser-for-free-github-web-editor-k4h) + by Davide 'CoderDave' Benvegnù on DEV.to, about the lightweight code editor, + based on Visual Studio Code (VSCode), that is a part of [GitHub Codespaces](https://dev.to/github/github-codespaces-ga-any-good-reviewed-and-tested-3e62). + The GitHub Codespaces project was mentioned in [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/). + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Josh Steadmon, Elijah Newren and +Philip Oakley. diff --git a/_posts/2021-10-31-edition-80.markdown b/_posts/2021-10-31-edition-80.markdown new file mode 100644 index 000000000..121348d51 --- /dev/null +++ b/_posts/2021-10-31-edition-80.markdown @@ -0,0 +1,364 @@ +--- +title: Git Rev News Edition 80 (October 30th, 2021) +layout: default +date: 2021-10-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 80 (October 30th, 2021) + +Welcome to the 80th 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](https://git.github.io). + +This edition covers what happened during the month of September 2021. + +## Discussions + + + +### Reviews + +* [[PATCH] MyFirstContribution: Document `--range-diff` option when writing v2](https://lore.kernel.org/git/20210913194816.51182-1-chooglen@google.com/) + + Glen Choo sent a patch to the mailing list to improve the + `Documentation/MyFirstContribution.txt` tutorial, so that it + suggests using the `--range-diff` option of `git format-patch` when + sending a new v2 version of an already sent patch series. + + The `Documentation/MyFirstContribution.txt` tutorial was initially + created by Emily Shaffer in 2019, and has been a popular way for + developers to start learning how to improve Git. + + Eric Sunshine agreed with Glen's idea, but made a few comments on + some minor issues, like using `--range-diff=psuh` over `--range-diff + psuh..psuh-v2` and adding a link to the `git range-diff` + documentation. + + Junio Hamano, the Git maintainer, also replied to Glen, saying that + the tutorial should promote a slightly different workflow to work on + an updated branch. + + He suggested creating a topic branch or a lightweight tag, for example + called `psuh-v1`, that points to the old tip of the `psuh` branch, + and continuing to work on the `psuh` branch to prepare the version 2 + of a patch series, instead of creating and working on a `psuh-v2` + branch. + + He also commented that the commands given in the tutorial might not + work well when the branch corresponding to the first and second + patch series had the same commits after diverging from the `master` + branch. + + Glen agreed with Junio's suggestion, though they discussed it a bit + further. + + Bagas Sanjaya replied to Glen's initial email saying he wasn't sure + if the `--range-diff` option was necessary, but Eric disagreed + with him saying: + + "Anyone who does any serious amount of review on this project finds + it tremendously helpful to have both a prose description of the + changes ("Changes since v1..." plus a link to the previous + submission) and a mechanical range-diff or interdiff." + + Glen then sent a + [version 2 of his patch](https://lore.kernel.org/git/20210920223226.25877-1-chooglen@google.com/) + that took into account Junio's and Eric's suggestions. Especially it + recommends marking the tip of the `psuh` branch corresponding to + version 1 and continuing to work on the `psuh` branch to prepare the + version 2. + + Eric Sunshine replied to this new patch with a number of suggestions + to improve some wordings and explanations. Glen agreed with Eric's + suggestions. + + Bagas then suggested creating a `psuh-v2` branch and continuing to + work on it, but this was against what Junio had suggested earlier, + so Glen didn't agree with that. He agreed with a wording improvement + that Bagas suggested though. + + Philip Oakley chimed in to discuss some wording when the version + number would change again later to 3, 4, etc. But after further + discussion with Glen and Bagas, he agreed with the original wording. + + Glen then sent a + [version 3 of his patch](https://lore.kernel.org/git/20210922202218.7986-1-chooglen@google.com/) + taking into account Eric's and Bagas's suggestions. This version of + the patch was later merged into the `master` branch, so we can now + enjoy a better tutorial explaining an improved workflow. + + + + +## Developer Spotlight: David Aguilar + +* Who are you and what do you do? + + My name is David Aguilar and I work as a Staff Software Engineer - + Architecture Lead for a small team of devops and infrastructure + engineers at the Walt Disney Animation Studios. Outside of work I'm a + husband and a caretaker, so my time is usually pretty occupied these + days. + + Cats, art, music and mountain biking are a few of my favorite things + outside of the usual technical topics. + +* What would you name your most important contribution to Git? + + We started adopting Git as our VCS of choice relatively early in Git's + history around 2007 at Disney Animation. One of the things that I + tried to do early on was to listen to some of the loudest and most + vocal critics and get to the root of their complaints about Git at the + time. + + One of the tools that fell out of this was `git difftool`. The + criticism at the time was along the lines of, "I can't believe Git is + missing such a fundamentally basic workflow that even tkcvs / tkdifff + have". Git already had `git mergetool` for helping resolve merge + conflicts at the time, so adding support for diff workflows seemed + like a natural extension of Git's capabilities. + + The original difftool RFC patches started as a crude shell script that + drove the diff itself and handled interacting with external diff tools + directly. Feedback from the Git mailing list improved it by making it + use `git diff`'s `GIT_EXTERNAL_DIFF` functionality when it first landed in + git.git's contrib/ area. difftool eventually graduated out of contrib/ + to become a builtin tool, and its implementation was heavily + refactored so that it can share all of its tool-specific + implementation details with `git mergetool`. + + Mergetool and difftool are a small yet key part of day-to-day Git + usage for many developers and is a great example of a general internal + need that was best addressed by proposing a solution to the Git + development community so that it can be evolved and improved alongside + Git. + +* What are you doing on the Git project these days, and why? + + Beyond difftool, I'm the author and maintainer of [Git Cola](https://git-cola.github.io/), + a powerful yet simple GUI for Git [[source code](https://github.com/git-cola/git-cola/)]. + + Git Cola started as a learning project. I wanted to better learn PyQt + and Git in 2007, and creating a user interface for Git's unique and + powerful staging area features seemed like a perfect project. One of + the features I use very often is its keyboard-driven interactive + staging feature. If you've ever wanted to stage, unstage, and revert + edits at a line-by-line granularity, using a unified interface (no + need to jump between `git add -p` and `git checkout -p`) that is + keyboard-driven with vim-inspired hotkeys for power users that + understand Git and its strengths, then Git Cola might be just the tool + for you. + + Git Cola has been gradually improved over the last 14 years and is + extremely stable and capable these days. It includes everything from a + drag+drop rebase editor (itself reusable as a `GIT_SEQUENCE_EDITOR` that + is provided as a standalone `git-cola-sequence-editor` tool) and + encourages users to leverage Git's unique strengths by making it easy + for new Git users to follow Git "best practices" such as creating + fixup commits and rebasing their work. + + These days I do try to keep an eye on difftool (a big thank you to + Johannes Schindelin for rewriting difftool in C in the context of the + Git for Windows improvements) and continue to improve Git Cola. + +* If you could get a team of expert developers to work full time on + something in Git for a full year, what would it be? + + I would really like to see more effort put into getting the + ideas/improvements from the Microsoft Scalar project integrated into + Core Git. Props should go to Microsoft for working alongside the Git + project towards up-streaming this work. Focusing on the scaling + challenges that come up when working with huge repositories is an area + I am hopeful will continue to improve. Git continues to be perceived + as being "bad at binary files", and "not industrial-grade like + Perforce" by the GameDev community, and that's something that can + definitely be improved. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + Submodules are useful and serve a specific use case, but working with + them involves a lot of little paper cuts that makes them painful for + users that aren't ready to deal with their complexities. + Double-commits (having to commit in the sub and super-project) is one + of the little paper cuts that really shouldn't exist were the + capability to compose and operate on multiple repos intrinsic to Git + itself. This is by no means a simple problem. + + On the bright side, `git submodule` has been getting a lot of + attention recently. I don't think I would remove them without a + compelling replacement in their place. + + Sometimes the downsides of submodules are more so about how they are + used than how they are implemented. Whenever I encounter a project + that does `git submodule update` or `git clone` in their `make` build + process, I get a bit nervous. That's not really Git's fault, though. + + Transitioning to SHA-256 is an obvious area that would be much simpler + if it didn't have to deal with backwards compatibility. + +* What is your favorite Git-related tool/library, outside of Git itself? + + Git Cola =) + + [Git Annex](https://git-annex.branchable.com/) is a really great tool + for archival purposes and is what I use for backing up my personal + files. It'd be nice if it didn't have to exist, but I'm very happy + that it does. Git Annex has some concepts that are unique and + different from Git LFS and other solutions in this space. + + I somewhat recently wrote a Git workflow tool for myself that I call + `garden`. [Garden](https://github.com/davvid/garden/) is basically + a glorified way to operate over ad-hoc collections of Git trees. + I wrote it because I have lots of Git Annexes and other repos in + arbitrary places that I often need to iterate over and perform + custom commands or other operations on. `garden` lets me do that. + I'm not sure if anyone would ever find it useful, but I wrote + it for myself so that's okay. + + I often find myself cloning random repos, figuring out how to build + them (lots of projects have bespoke build systems), and then later + figuring out how to run and interact with the repo. I used to have a + smattering of shell scripts to build and run various projects. I now + use `garden` for holding all of these disparate bits in a single place + so that the workflows become easier to transport (and store in Git). + URLs, multiple worktrees, the remotes associated with each worktree + (useful for recreating a worktree with dozens of remotes from + contributors) and custom commands for operating in the context of the + worktrees can all be grouped together into a single "garden file" that + can be shared and reproduced on another machine. + +* Do you happen to have any memorable experience w.r.t contributing to the + Git project? If yes, could you share it with us? + + I personally learned a lot from the Git development community. The + review process is one that focuses on quality and perfection (Git + doesn't settle for "good enough") with a strong eye towards + maintainability and not breaking existing users. The Git project + teaches us to create commits that are reviewable, to make independent, + logically-separate changes, and to describe our changes well. These + principles, alongside the idea that all code should be reviewed and + collaborated on, is something that has helped transform our internal + development processes. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + If you've never built Git yourself from scratch then the quickest way + to get started is to clone the repo and run `make`. Start looking + around the code base, read the `git log` messages, and start reading + the new contributor documentation in the `Documentation/` folder. + + A lot of effort has been put into making it easier to contribute to + Git itself, but the community won't know about any of the pain points + unless you reach out and illuminate what might be blind spots in our + practices. + + Set up your mail filters and subscribe to the Git mailing list once + you're ready to start diving deeper. There is a lot of activity, but + there's also no shortage of things you can learn by reaching out and + engaging with the community. + +## Releases + ++ Git [2.33.1](https://public-inbox.org/git/xmqqczo922vm.fsf@gitster.g/) ++ Git for Windows [2.33.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.33.1.windows.1) ++ libgit2 [1.3.0](https://github.com/libgit2/libgit2/releases/tag/v1.3.0) ++ Gerrit Code Review [3.3.7](https://www.gerritcodereview.com/3.3.html#337), +[3.2.13](https://www.gerritcodereview.com/3.2.html#3213) ++ Bitbucket Server [7.17](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitHub Enterprise [3.2.1](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.1), +[3.1.9](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.9), +[3.0.17](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.17) ++ GitLab [14.4](https://about.gitlab.com/releases/2021/10/22/gitlab-14-4-released/), +[14.3.3](https://about.gitlab.com/releases/2021/10/12/gitlab-14-3-3-released/), +[14.3.2](https://about.gitlab.com/releases/2021/10/01/gitlab-14-3-2-released/), +[14.3.1, 14.2.5, and 14.1.7](https://about.gitlab.com/releases/2021/09/30/security-release-gitlab-14-3-1-released/), +[14.0.11](https://about.gitlab.com/releases/2021/09/27/gitlab-14-0-11-released/), +[14.1.6](https://about.gitlab.com/releases/2021/09/27/gitlab-14-1-6-released/) ++ GitKraken [8.1.0](https://support.gitkraken.com/release-notes/current), +[8.0.1](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.9.4](https://desktop.github.com/release-notes/) ++ Git Cola [3.11.0](http://git-cola.github.io/share/doc/git-cola/html/relnotes.html#v3-11-0) + +## Other News + +__Various__ + +* [Notes from the Git Contributors' Summit 2021, virtual, Oct 19/20](https://public-inbox.org/git/nycvar.QRO.7.76.6.2110221202430.62@tvgsbejvaqbjf.bet/t/), + a thread by Johannes Schindelin. + * One of the topics was having public "Git chalk talks", an idea which + [has now its own thread](https://public-inbox.org/git/nycvar.QRO.7.76.6.2110220950020.62@tvgsbejvaqbjf.bet/t/#u). +* [Software at Scale 35 - Maintaining Git \[for Windows\] with Johannes Schindelin](https://www.softwareatscale.dev/p/software-at-scale-35-maintaining ), a podcast. + + +__Light reading__ + +* [A 16 Year History Of The Git Init Command](https://initialcommit.com/blog/history-git-init-command) + by Jacob Stopak on Initial Commit. +* [Clean Conventional Commits](https://dev.to/sublimegeek/clean-conventional-commits-40l8) + by Jonathan Irvin on DEV.to. + * The [Conventional Commit message standard](https://www.conventionalcommits.org/) + was first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/). +* [How to Remove Git Version Tracking from a Folder](https://www.cloudsavvyit.com/14500/how-to-remove-git-version-tracking-from-a-folder/) and + [How to Delete Git Branches On Local and Remote Repositories](https://www.cloudsavvyit.com/14289/how-to-delete-git-branches-on-local-and-remote-repositories/) + by Anthony Heddings on Cloud Savvy IT. +* [Git: Moving from Master to Main](https://www.jumpingrivers.com/blog/git-moving-master-to-main/) + (as the name of the default branch), challenges faced by Jumping Rivers company; + note however that they got the origin history of Git using 'master' wrong in this article. +* [Branching Strategies in Git](https://css-tricks.com/branching-strategies-in-git/) + by Tobias Günther on CSS Tricks is a part two post in the “Advanced Git” series. + * See also [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) in [#73](https://git.github.io/rev_news/2021/03/27/edition-73/) + and [Ship / Show / Ask: A modern branching strategy](https://martinfowler.com/articles/ship-show-ask.html) in [#79](https://git.github.io/rev_news/2021/09/30/edition-79/). +* [Code Review from the Command Line](https://blog.jez.io/cli-code-review/) + by Jake Zimmerman (2018). +* [The Thing About Git](https://tomayko.com/blog/2008/the-thing-about-git) + by Ryan Tomayko (2008). + + +__Git tools and sites__ + +* [git-autofixup](https://github.com/torbiak/git-autofixup) automatically + creates fixup commits for topic branches. +* [git-foresta](https://github.com/takaaki-kasai/git-foresta) is a text-based git log graph viewer, + written in Perl, using Unicode for drawing. + It is a modified version of `git-forest` (written in Perl by Jan Engelhardt), see below. +* [hxtools](http://inai.de/projects/hxtools/) by Jan Engelhardt + is a collection of small tools and scripts, which include + `git-author-stat` (commit author statistics of a git repository), + `git-blame-stat` (per-line author statistics), + `git-revert-stats` (reverting statistics), and + `git-forest` (display the commit graph). +* [Lab](https://github.com/zaquestion/lab) is a tool that wraps Git, + making it simple to clone, fork, and interact with repositories + [on GitLab](https://gitlab.com/gitlab-org/ecosystem-stage/lab), + including seamless workflows for creating merge requests, issues and snippets. + It was inspired by and is similar to the [hub](https://github.com/github/hub) + tool that does the same for GitHub. + * [GLab](https://glab.readthedocs.io/) for GitLab, and + [gh](https://github.com/cli/cli) for GitHub are more interactive + command line tools, that do not aim to be familiar to a `git` and to leverage it. +* [The Advanced Git Kit](https://www.git-tower.com/learn/git/advanced-git-kit) + is a 10 part video course for free from makers of the [Tower](https://www.git-tower.com/) Git client. +* [GoGit](https://github.com/opencodeiiita/GoGit) is a project under OpenCode'21 + that aims to improve the Git and GitHub skills of the contributors by completing some tasks. + The tasks are being specified in the Issues section of the project's GitHub repo. +* [GitHub Minesweeper](https://profy.dev/project/github-minesweeper) by Profy + is a GitHub bot to learn a professional Git and GitHub workflow. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Johannes Altmanninger and David Aguilar. diff --git a/_posts/2021-11-29-edition-81.markdown b/_posts/2021-11-29-edition-81.markdown new file mode 100644 index 000000000..527816152 --- /dev/null +++ b/_posts/2021-11-29-edition-81.markdown @@ -0,0 +1,219 @@ +--- +title: Git Rev News Edition 81 (November 29th, 2021) +layout: default +date: 2021-11-29 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 81 (November 29th, 2021) + +Welcome to the 81st 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](https://git.github.io). + +This edition covers what happened during the month of October 2021. + +## Discussions + + + +### Reviews + +* [[PATCH 0/3] Fun with cpp word regex](https://lore.kernel.org/git/pull.1054.git.1633589461.gitgitgadget@gmail.com/) + + Johannes Sixt sent a small patch series about improving C++ (also + called 'cpp') support in the userdiff mechanism. This mechanism is + used by Git to generate diffs that are customized to specific + programming languages (like C, shell, Perl, MATLAB, etc.) or markup + languages (like HTML, Markdown, TeX, etc.). + + Especially one of the patches splits the regex that was matching all + the numbers into 3 different regexes: + + - one for floating point numbers that begin with a decimal point, + - one for decimal and octal integers as well as other + floating point numbers, and + - one for hexadecimal and binary integers. + + The result is that expressions like `1+2`, `1.5-e+2+f` and `.l` are + not considered numbers any more and are properly parsed for diff + purposes in C++ files. + + Another patch in the series allows single-quote characters as digit + separators according to the C++17 standard, like in `3.141'592'654` + or `0xdead'beaf`. + + The third and last patch prevents the `<=>` generalized comparison + operator (also called 'spaceship' operator) introduced in C++20 from + being split into `<=` and `>`. + + Ævar Arnfjörð Bjarmason replied to Johannes suggesting to add a + few tests in the `t/t4034/cpp/` directory, where test files for the + cpp userdiff mechanism reside. + + Johannes agreed with Ævar and sent a + [second version](https://lore.kernel.org/git/pull.1054.v2.git.1633720197.gitgitgadget@gmail.com/) + of his patch series. This series included 2 new patches that + improved existing tests and added new tests for problematic behavior + that the other patches were fixing. + + Ævar commented on this series saying that it was much improved, but + it could perhaps be even better if: + + - the C++ support was split up from the C support, + + - some tests were added first, before the behavior was changed, + and + + - some tests could be added for code comments, as he wondered if + tokens that often occur in natural language, like `"` and `&`, + were still correctly handled when they appeared in code comments. + + Johannes agreed with the second point, but wasn't interested in + working on the others. + + Ævar and Johannes discussed a bit further if it was worth doing + something for code comments, but Johannes concluded that it wasn't. + + Johannes then sent a + [third version](https://lore.kernel.org/git/pull.1054.v3.git.1633885384.gitgitgadget@gmail.com/) + of his patch series. In this new version test cases for single-quote + characters as digit separators and the `<=>` generalized comparison + operator were moved to a new commit before the commits supporting + these features. + + Later on, Johannes [noticed](https://lore.kernel.org/git/a5a05e33-3ad9-e78c-69c0-a466eadeffec@kdbg.org/) + that the single-quote character as digit separator is problematic + and requires a more sophisticated implementation. For example, as + implemented the character literal `'.'` would be split into `'.` + and `'`. The support for digit separators was eventually reverted. + + This patch series was then merged into the master branch, so that + Git 2.34 that was recently released has better support for C++ in + diffs. + + + + + +## Releases + ++ Git [2.34.0](https://public-inbox.org/git/xmqq8rxpgwki.fsf@gitster.g/), +[2.34.0-rc2](https://public-inbox.org/git/xmqq4k8kzuz2.fsf@gitster.g/), +[2.34.0-rc1](https://public-inbox.org/git/xmqqsfwc4yne.fsf@gitster.g/), +[2.34.0-rc0](https://public-inbox.org/git/xmqqwnlve57e.fsf@gitster.g/) ++ Git for Windows [2.34.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.34.0.windows.1), +[2.34.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.34.0-rc2.windows.1), +[2.34.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.34.0-rc1.windows.1), +[2.34.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.34.0-rc0.windows.1) ++ Bitbucket Server [7.18](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitHub Enterprise [3.3.0](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.0), +[3.2.3](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.3), +[3.1.11](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.11), +[3.0.19](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.19), +[3.2.2](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.2), +[3.1.10](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.10), +[3.0.18](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.18) ++ GitLab [14.5](https://about.gitlab.com/releases/2021/11/22/gitlab-14-5-released/) +[14.1.8](https://about.gitlab.com/releases/2021/11/15/gitlab-14-1-8-released/), +[14.4.2](https://about.gitlab.com/releases/2021/11/08/gitlab-14-4-2-released/), +[14.0.12](https://about.gitlab.com/releases/2021/11/05/gitlab-14-0-12-released/), +[13.12.15](https://about.gitlab.com/releases/2021/11/03/gitlab-13-12-15-released/), +[14.4.1, 14.3.4, and 14.2.6](https://about.gitlab.com/releases/2021/10/28/security-release-gitlab-14-4-1-released/) ++ Gerrit Code Review [3.4.2](https://www.gerritcodereview.com/3.4.html#342), +[3.3.8](https://www.gerritcodereview.com/3.3.html#338), +[3.2.14](https://www.gerritcodereview.com/3.2.html#3214), +[2.16.28](https://www.gerritcodereview.com/2.16.html#21628) ++ GitKraken [8.1.1](https://support.gitkraken.com/release-notes/current) + +## Other News + +__Various__ + +* Derrick Stolee and Lessley Dennington [talk about the future of Git at scale](https://www.youtube.com/watch?v=pXdabSCz4JA). +* [Highlights from Git 2.34](https://github.blog/2021-11-15-highlights-from-git-2-34/) + by Taylor Blau on GitHub Blog, and + [Git 2.34 sets new merge default, speeds things up for monorepo users](https://devclass.com/2021/11/17/version-control-git-2_34/) + by Julia Schmidt on Dev Class. +* [Require pull requests without requiring reviews](https://github.blog/changelog/2021-11-10-require-pull-requests-without-requiring-reviews/) on GitHub. +* [Deprecating Atlassian account password for Bitbucket API and Git activity](https://bitbucket.org/blog/deprecating-atlassian-account-password-for-bitbucket-api-and-git-activity) + (for Git over HTTPS) on Bitbucket. + +__Light reading__ + +* [Get lazy with lazygit](https://dev.to/tahsinature/get-lazy-with-lazygit-4h37) by Tahsin on DEV.to. + [Lazygit](https://github.com/jesseduffield/lazygit) was first mentioned in [Git Rev News Edition #42 (August 22nd, 2018)](https://git.github.io/rev_news/2018/08/22/edition-42/). +* [Should You Use HTTPS or SSH For Git?](https://www.cloudsavvyit.com/14822/should-you-use-https-or-ssh-for-git/) + by Anthony Heddings on Cloud Savvy IT. +* [How To Switch a GitHub Repository to SSH Authentication](https://www.cloudsavvyit.com/14747/how-to-switch-a-github-repository-to-ssh-authentication/) + by Anthony Heddings on Cloud Savvy IT. +* [5 Underrated [free] resources to learn Git and GitHub](https://dev.to/ifrah/5-underrated-resources-to-learn-git-and-github-4edi) + by ifrah on DEV.to. + * [GitHub Minesweeper](https://profy.dev/project/github-minesweeper) by Profy + was mentioned in [Git Rev News Edition #80 (October 30th, 2021)](https://git.github.io/rev_news/2021/10/30/edition-80/). + * [Oh My Git!](https://ohmygit.org/) game by bleeptrack and blinry + was mentioned in [Git Rev News Edition #72 (February 27th, 2021)](https://git.github.io/rev_news/2021/02/27/edition-72/). +* The “[Advanced Git](https://css-tricks.com/cherry-picking-commits-in-git/)” series + by Tobias Günther on CSS-Tricks, courtesy of the Tower Git client, + (mentioned in [Git Rev News #80](https://git.github.io/rev_news/2021/10/30/edition-80/)), + continues: + * [Better Collaboration With Pull Requests](https://css-tricks.com/better-collaboration-with-pull-requests/) + * [Merge Conflicts: What They Are and How to Deal with Them](https://css-tricks.com/merge-conflicts-what-they-are-and-how-to-deal-with-them) + * [Rebase vs. Merge: Integrating Changes in Git](https://css-tricks.com/rebase-vs-merge-integrating-changes-in-git) + * [Interactive Rebase: Clean up your Commit History](https://css-tricks.com/interactive-rebase-clean-up-your-commit-history) + * [Cherry-Picking Commits in Git](https://css-tricks.com/cherry-picking-commits-in-git) +* [How to become a Git expert!](https://dev.to/sagarbarapatre/how-to-become-a-git-expert-1jl2) + by Sagar Barapatre on DEV.to. +* [What is .gitkeep? How to Track and Push Empty Folders in Git.](https://www.freecodecamp.org/news/what-is-gitkeep/) + by Kealan Parr on freeCodeCamp. +* [How to Write Good Commit Messages with Commitlint](https://www.freecodecamp.org/news/how-to-use-commitlint-to-write-good-commit-messages/) + by Anish De on freeCodeCamp. +* [Removing a .env file from Git history](https://daily-dev-tips.com/posts/removing-a-env-file-from-git-history/) + (or any other accidentally added, committed, and pushed file) + by Chris Bongers on Daily Dev Tips. +* [The case against monorepos](https://www.infoworld.com/article/3638860/the-case-against-monorepos.html) + by Lee Atchison on Info World. + * You can find various arguments for and against monorepos in Git Rev News editions + [#4](https://git.github.io/rev_news/2015/06/03/edition-4/), [#9](https://git.github.io/rev_news/2015/11/11/edition-9/), [#47](https://git.github.io/rev_news/2019/01/23/edition-47/) (pros and cons), [#72](https://git.github.io/rev_news/2021/02/27/edition-72/), [#78](https://git.github.io/rev_news/2021/08/31/edition-78/), + not counting articles about improving the performance of large repositories, which monorepos usually are. +* [How to do pull request reviews](https://dev.to/mage_ai/how-to-do-pull-request-reviews-mm6) + by Mage company on DEV.to. +* [Git Rebase for Preventing Merge Commits](https://dev.to/jenc/git-rebase-for-preventing-merge-commits-2len) + by jen chan on DEV.to. +* [Signed git pushes](https://people.kernel.org/monsieuricon/signed-git-pushes) + by Konstantin Ryabitsev (2020). +* [DeployBot Configuration with Git LFS](https://www.cadonau.net/blog/2020/08/24/deploybot-git-lfs/) + by Markus Cadonau (2020). + + +__Git tools and sites__ + +* [`commitlint`](https://commitlint.js.org/#/) is a tool written in JavaScript and running on Node.js + (that is, an npm tool) that helps your team with adhering to a commit convention. +* [Conventional Changelog](https://github.com/conventional-changelog/conventional-changelog) + is an npm tool to generate changelogs and release notes from a project's commit messages and metadata. +* [Git Command Explorer](https://gitexplorer.com/) is a web application + to help you find the right commands you need + without digging through the web, + made by Summitech company. +* [Arlo's Commit Notation](https://github.com/RefactoringCombos/ArlosCommitNotation) + is a notation for small commit messages that shows + the risk involved in each step and the author's intention, + conveyed in the first 3 characters of the commit summary line. + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Johannes Schindelin and Johannes Sixt. diff --git a/_posts/2021-12-31-edition-82.markdown b/_posts/2021-12-31-edition-82.markdown new file mode 100644 index 000000000..cd0eb5551 --- /dev/null +++ b/_posts/2021-12-31-edition-82.markdown @@ -0,0 +1,418 @@ +--- +title: Git Rev News Edition 82 (December 30th, 2021) +layout: default +date: 2021-12-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 82 (December 30th, 2021) + +Welcome to the 82nd 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](https://git.github.io). + +This edition covers what happened during the month of November 2021. + +## Discussions + +### General + +* [Peff is taking a break from Git](https://public-inbox.org/git/YboaAe4LWySOoAe7@coredump.intra.peff.net/) + + Peff, alias Jeff King, announced on the mailing list that he is + going to take a five months break from Git starting at the end of + December. He is also stepping down from Git's PLC (Project Leadership + Committee), the entity that represents Git within + [Software Freedom Conservancy](https://sfconservancy.org/). + + Peff has been involved in the project for 15 years and has + contributed a huge number of patches as well as an enormous amount of + reviews, support and discussions. + + He also used to maintain [git-scm.com](https://git-scm.com/), the main site of the + project. It looks like Taylor Blau, who has been working at GitHub + with Peff, will take over maintaining this site. + + Along with others on the mailing list, let's thank Peff for his + contributions to Git and Git Development Community! + + + +### Support + +* [misleading message printed when worktree add fails](https://lore.kernel.org/git/CA+34VNLj6VB1kCkA=MfM7TZR+6HgqNi5-UaziAoCXacSVkch4A@mail.gmail.com/) + + Baruch Burstein posted a bug report on the mailing list saying that + he ran `git worktree add `, where `` was an + already checked-out branch, and saw a message that seemed to + indicate that the command was a success, when in fact it was not. + + Eric Sunshine replied to him asking if he saw something similar as: + + ```sh + % git worktree add ../foo bar + Preparing worktree (checking out 'bar') + fatal: 'bar' is already checked out at '.../wherever' + ``` + + Baruch replied that he actually saw the messages emitted by Git in a + different order: + + ```sh + fatal: 'master' is already checked out at 'C:/Users/bmbur/temp' + Preparing worktree (checking out 'master') + ``` + + Eric then diagnosed the following: + + > Okay, that's happening because the 'Preparing' message is sent to + > stdout, whereas the 'fatal' error is sent to stderr, and the streams + > are being flushed on Windows in a different order than what we + > typically see on Unix platforms even though the 'Preparing' message is + > actually output first by the code. + + He then proposed to have the die() function, which is emitting the + 'fatal' error, or the vreportf(), which is used by die() to emit the + 'fatal' error, flush stdout before emitting an error. This would fix + not only the issue Baruch saw, but also other similar issues in + other parts of the code. + + Randall S. Becker replied to Eric that his proposed fix was + "probably a good idea" as "there is no guarantee even in Unix + regarding stream buffer flushing". + + Eric posted [an RFC patch](https://lore.kernel.org/git/20211130043946.19987-1-sunshine@sunshineco.com/) + implementing his proposed fix. The patch added a call to + `fflush(stdout)` in vreportf() just before this function calls + `fflush(stderr)` and before it actually writes a message on stderr. + + Junio Hamano, the Git maintainer, replied to the patch wondering if + flushing stdout when it is going to a pipe talking to another + process could cause issues. He noticed that the HTTP backend code + uses vreportf() in this way, though he said that any code using + stdio "cannot precisely control when the buffered contents are + flushed anyway", so the patch might be OK. + + Jeff King, alias Peff, then started a discussion about the + possibility of arbitrary flushing causing some code to block, which might + create a deadlock, as some other code might be waiting for something + from the now blocking code. Eric suggested that this could be + addressed by flushing stdout only if stdout is attached to a + terminal, though he thought this would be "rather ugly". + + Ævar Arnfjörð Bjarmason chimed in to ask about the warning() and + error() functions that also call vreportf(), but Peff replied that + they were probably OK. + + Meanwhile Peff also replied to Eric's patch wondering if "status + messages like this go to stderr anyway". He remarked that + + > in general our approach in Git is more "if it is the main + > output of the program, it goes to stdout; if it is + > chatter or progress for the user, it goes to stderr". + + He also explained that it works consistently on glibc as "stdout to + a terminal is line buffered by default, so the 'Preparing' line is + flushed immediately". But even on Linux, without a terminal, like + when both stdout and stderr are redirected to the same file, for + example with `git worktree add ../foo bar >out 2>&1`, the output to + stderr appears before the one to stdout. + + Eric replied to Peff saying he had considered emitting the + 'Preparing' line on stderr instead of stdout, as Peff suggests, but + he thought that it's not documented and not very consistent that + this kind of output from Git should go to stderr, and also that it + could be a regression if people relied on that. He suggested adding + a fflush(stdout) to git-worktree's code and "live with that + localized ugliness". + + Peff agreed that Git has not been very consistent, but he said that + more careful reviews and "laying out guidelines could help". He also + pointed to [a previous discussion](https://lore.kernel.org/git/20110907215716.GJ13364@sigill.intra.peff.net/) + from 10 years ago where he had "laid out his mental model" about this topic. + + He also noticed that the 'Preparing' line was marked for + translation, so "not reliably machine-readable anyway". He also + pointed to [a previous commit](https://github.com/git/git/commit/68b939b2f0) + that moved some `git clone` output from stdout to stderr for similar + reasons. + + Eric then agreed with Peff about sending a different patch to move + the 'Preparing' line output to stderr and another patch to improve + documentation about this topic. Eric also noticed that this output + had been changed significantly 3 years ago without any complaints. + + He then sent [a patch](https://lore.kernel.org/git/20211201053214.2902-1-sunshine@sunshineco.com/) + to improve our documentation about this. A second version of this + patch was eventually merged to the master branch after Eric took + into account some reviews by Fabian Stelzer, Junio, Peff and Philip + Oakley to improve some wordings. + + Ævar and Junio discussed a bit further the "you shouldn't write + anything that isn't an error" view of the world, and Ævar cited the + ["chronic" utility](https://manpages.debian.org/jessie/moreutils/chronic.1.en.html). + + Eric also sent [a small patch series](https://lore.kernel.org/git/20211203034420.47447-1-sunshine@sunshineco.com/) + that moved the 'Preparing' line output to stderr and fixed a minor + problem in the `git worktree` documentation he noticed along the + way. + + This patch series started a small inconclusive discussion between + Ævar, Eric, Peff and Junio about automating the synopsis and maybe + other parts of the documentation from the code or other ways to + avoid duplication and mismatches. + + The patch series was eventually merged as is to the master branch + though. + +## Developer Spotlight: Randall S. Becker + +* Who are you and what do you do? + + I am Randall S. Becker, president of Nexbridge Inc. I have been a + software developer and architect for many decades. Aside from the + obvious SCM domain knowledge, my interests are around data structures, + performance, computability, and languages. About 10 years ago, I joined + the ITUGLIB Technical Committee, which is an Open-Source group that + maintains code for the HPE Nonstop community - the platform was + originally called Tandem Computers Inc. + +* What would you name your most important contribution to Git? + + I have been maintaining the code associated with the HPE NonStop + platform for the past six years and was key to its successful port to + both the x86 and ia64 variants of the platform. In addition, I keep an + eye out for changes that may put the port at risk and run the CI/CD + environment that builds and tests Git on the platform. + +* What are you doing on the Git project these days, and why? + + I am currently working on the `.git/config` `includeIf` function for + worktrees, planning a threaded version of the port, which is challenging + considering the nature of the platform and community. We have to + maintain compatibility with some old versions of the operating systems + that lack some more modern capabilities. The platform is an MPP + architecture without kernel level threads (yet), and the port to POSIX + threads is very messy with the operating system wrappers we have to use. + +* 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? + + There are really three areas where I would want to work. The first, most + important, is improving multi-level signing capabilities in Git to + support the software supply chain. I could leave it at that, but the + full set of requirements in various countries are not yet fully fleshed + out. Another two, purely to support the NonStop community is converting + the code written in Go (Git LFS) into C and making it part of the standard + product. The other is migrating the interpretive code to a C99-standard + code base. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + I would move directly to SHA-384 or SHA-512 and toss both SHA-1 and + SHA-256 as soon as possible. The same applies to any signing + capabilities to support 8K or higher key sizes in defense against future + hacking using the capabilities quantum computers. + +* What is your favorite Git-related tool/library, outside of Git + itself? + + This is a bit of self-promotion for my company, and I apologise for that. + We build façade-style interface facilities that allow legacy platforms, + including HPE NonStop and IBM's TSO/ISPF environments to have full Git + experiences despite the native file systems not supporting POSIX-like + hierarchies. These are Git clients that map file system attributes and + structures to and from what Git can understand. Our NonStop product was + recently added to the HPE price book. These products allow older + codebases to share in the benefits of real DevOps capabilities without + having to rely on proprietary knowledge and processes. I am the chief + architect of those products. + +* Do you happen to have any memorable experience with respect to contributing + to the Git project? If yes, could you share it with us? + + I think the most satisfying experience was the few months it took to + contribute all the code associated with the NonStop port. It was a huge + pain to maintain the separate fork even with Git's awesome merge + capabilities. Being allowed to be lazy is a dream of many developers and + cutting down the time and effort spent on each release to a simple push + of the Jenkins "Build Now" button frees up a lot of time. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + Learn about Merkle Trees and general data structures. + + I am still learning when it comes to general functional contributions. + Watching how others contribute is really crucial if you have any hope of + your contribution being accepted. + +* If there's one tip you would like to share with other Git developers, + what would it be? + + For every change you make, think about the security implications. + Think about what a hacker might do to compromise Git or an organisation + using Git before you move forward, no matter how good an idea might + seem. The last thing you want is to have your contribution show up as a + Critical Vulnerability Exposure on the NIST database. + +## Releases + ++ Git [2.34.1](https://public-inbox.org/git/xmqq7dcx1ent.fsf@gitster.g/) ++ Git for Windows [2.34.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.34.1.windows.1) ++ GitHub Enterprise [3.3.1](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.1), +[3.2.6](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.6), +[3.1.14](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.14), +[3.0.22](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.22), +[3.3.0](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.0), +[3.2.5](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.5), +[3.1.13](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.13), +[3.0.21](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.21), +[3.2.4](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.4), +[3.1.12](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.12), +[3.0.20](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.20) ++ GitLab [14.6](https://about.gitlab.com/releases/2021/12/22/gitlab-14-6-released/) +[14.5.2, 14.4.4, and 14.3.6](https://about.gitlab.com/releases/2021/12/06/security-release-gitlab-14-5-2-released/), +[14.5.1](https://about.gitlab.com/releases/2021/12/01/gitlab-14-5-1-released/), +[14.4.3](https://about.gitlab.com/releases/2021/12/01/gitlab-14-4-3-released/), +[14.3.5](https://about.gitlab.com/releases/2021/11/26/gitlab-14-3-5-released/), +[14.2.7](https://about.gitlab.com/releases/2021/11/26/gitlab-14-2-7-released/) ++ Bitbucket Server [7.19](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.5.0](https://www.gerritcodereview.com/3.5.html#350) ++ GitKraken [8.2.1](https://support.gitkraken.com/release-notes/current), +[8.2.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.9.6](https://desktop.github.com/release-notes/), +[2.9.5](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ +* [Google Summer of Code (GSoC) 2022](https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html) + is expanding to everyone 18 years or older, to different project sizes and to flexible timelines. + + +__Light reading__ + +* [Stochastic bisection in Git](https://lwn.net/Articles/877964/) + by Jonathan Corbet on LWN.net. The patches in question were + [proposed for inclusion in Git](https://lore.kernel.org/git/20211118164940.8818-1-jack@suse.cz/t/#u) + by Jan Kara. +* [Fedora revisits the Git-forge debate](https://lwn.net/Articles/877240/) + by Jake Edge on LWN.net. +* [A brief history of code search at GitHub](https://github.blog/2021-12-15-a-brief-history-of-code-search-at-github/) + by Pavel Avgustinov on GitHub Blog. +* [Working with a Monorepo](https://devblogs.microsoft.com/cse/2021/11/23/working-with-a-monorepo/), + co-authored by Claus Matzinger, Stephanie Visser and Martin Tirion; + on Microsoft's CSE Developer Blog. + You can find most recent list of pros and cons of monorepos in + [Git Rev News Edition #81](https://git.github.io/rev_news/2021/11/29/edition-81/). +* [How to Create a React Typescript Monorepo with Git Submodules](https://dev.to/alexeagleson/how-to-create-a-node-and-react-monorepo-with-git-submodules-2g83) + by Alex Eagleson on DEV.to. +* [Git Pull, for the Holidays](https://thedailywtf.com/articles/git-pull-for-the-holidays), + a song from The Daily WTF; Lyrics - Remy Porter and James Rushin, Music - James Rushin. +* [How to Reset a Single Git File and Why](https://www.makeuseof.com/git-reset-single-file/) + by Bobby Jack on MakeUseOf. +* [Merging multiple git repos with their commit history](https://domm.plix.at/perl/2021_12_git_merge_repos_with_history.html) + by Thomas Klausner (domm). Note that there might be a better, simpler solution for the problem. +* [Using the Reflog to Restore Lost Commits](https://css-tricks.com/using-the-reflog-to-restore-lost-commits/) + by Tobias Günther on CSS-Tricks is the next part of + the [Tower Git Client](https://www.git-tower.com/)'s “Advanced Git” series. +* [Git Commands Cheatsheet: Advanced (20+ Git Commands Advanced)](https://dev.to/aashiya123/git-commands-cheatsheet-advanced-20-git-commands-advanced--35i3) + by aashiya123 on DEV.to. +* [10 useful Git tips to improve your workflow](https://dev.to/yenyih/10-useful-git-tips-to-improve-your-workflow-kf1) + by Jordan Soo Yen Yih on DEV.to. +* [Top 30 Git Commands You Should Know To Master Git CLI](https://levelup.gitconnected.com/top-30-git-commands-you-should-know-to-master-git-cli-f04e041779bc) + by Tara Prasad Routray on Level Up Coding by gitconnected.com (a Medium.com blog). +* [Git scraping: track changes over time \[to a web site or a web service\] by scraping to a Git repository](https://simonwillison.net/2020/Oct/9/git-scraping/) and + [git-history: a tool for analyzing scraped data collected using Git and SQLite](https://simonwillison.net/2021/Dec/7/git-history/) + by Simon Willison on his weblog. +* [Top 5 Best Git Extensions For VS Code (You must have)](https://dev.to/thenomadevel/top-5-best-git-extensions-for-vs-code-you-must-have-40b6) + by Nomadev on DEV.to. You can find a similar list in + [Git Rev News Edition #77](https://git.github.io/rev_news/2021/07/31/edition-77/). +* [So you want Database Version Control?](https://www.dolthub.com/blog/2021-09-17-database-version-control/), + [So you want a Git Database?](https://www.dolthub.com/blog/2021-11-26-so-you-want-git-database/), and + [So you want Git SQL?](https://www.dolthub.com/blog/2021-12-20-git-sql/) + by Tim Sehn on DoltHub Blog. [Dolt](https://www.doltdb.com/) and [DoltHub](https://www.dolthub.com/) + were mentioned in [Git Rev News Edition #62](https://git.github.io/rev_news/2020/04/23/edition-62/). + Those blog posts talk about different ways databases and version control can connect: + * version controlling database schema, aka **database migrations**: + * [Liquibase](https://www.liquibase.com/), + mentioned in [Git Rev News #60](https://git.github.io/rev_news/2020/02/19/edition-60/) + * [Redgate Deploy](https://www.red-gate.com/products/redgate-deploy/) + * [Planetscale](https://www.planetscale.com/) + * [Alembic](https://alembic.sqlalchemy.org/) for SQLAlchemy _(not mentioned in those articles)_, + mentioned in [Git Rev News #60](https://git.github.io/rev_news/2020/02/19/edition-60/) + * [Sqitch](https://sqitch.org/) _(not mentioned in those articles)_, + mentioned in [Git Rev News #60](https://git.github.io/rev_news/2020/02/19/edition-60/) + * [Entity Framework Migrations](https://docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/) _(not mentioned in those articles)_ + * [Flyway](https://flywaydb.org/) by Redgate _(not mentioned in those articles)_, + mentioned in [Git Rev News #60](https://git.github.io/rev_news/2020/02/19/edition-60/) + * [DBmaestro](https://www.dbmaestro.com/) _(not mentioned in those articles)_ + * [skeema](https://www.skeema.io/) for MySQL, MariaDB, and Percona Server _(not mentioned in those articles)_, + mentioned in [Git Rev News #60](https://git.github.io/rev_news/2020/02/19/edition-60/) + * [gh-ost](https://github.com/github/gh-ost): GitHub's online schema migration for MySQL _(not mentioned in those articles)_, + mentioned in [Git Rev News #60](https://git.github.io/rev_news/2020/02/19/edition-60/) + * version controlling queries: + * [VersionSQL](https://www.versionsql.com/) + * [DBT](https://www.getdbt.com/) (Data Build Tool) + * [Git Your SQL Together (with a Query Library)](https://caitlinhudon.com/2018/11/28/git-sql-together/) + by Caitlin Hudon (2018) _(not mentioned in those articles)_, + mentioned in [Git Rev News #46](https://git.github.io/rev_news/2018/12/19/edition-46/) + * **data versioning** (version control within schema, or **[Slowly Changing Dimension](https://en.wikipedia.org/wiki/Slowly_changing_dimension)**): + * [Noms](https://github.com/attic-labs/noms) + * [TerminusDB](https://www.terminusdb.com/) for graph or document databases; + whitepaper about TerminusDB was mentioned in [Git Rev News #60](https://git.github.io/rev_news/2020/02/19/edition-60/) + * [Dolt](https://www.dolthub.com/) for relational databases, + mentioned in [Git Rev News Edition #62](https://git.github.io/rev_news/2020/04/23/edition-62/) + * [LiteTree: SQLite with Branches](https://github.com/aergoio/litetree) which is a modification of the SQLite engine to support branching _(not mentioned in those articles)_, + mentioned in [Git Rev News #43](https://git.github.io/rev_news/2018/09/19/edition-43/) + * Git as database (with own query language): + * [GitRows](https://gitrows.com/) for JSON and CSV files + * [Git as a NoSQL database](https://www.kenneth-truyers.net/2016/10/13/git-nosql-database/) by Kenneth Truyers (2016), + mentioned in [Git Rev News #28](https://git.github.io/rev_news/2017/06/14/edition-28/) + * [Turning Git into an application database](https://nede.dev/blog/turning-git-into-an-application-database) by Peter Ruttkay-Nedecký (2019) + * SQL for querying Git repos: + * [Gitbase](https://github.com/src-d/gitbase) by source{d} aka src-d - using MySQL, + mentioned in [Git Rev News #48](https://git.github.io/rev_news/2019/02/27/edition-48/); + note that the link [on the source{d} site](https://docs.sourced.tech/gitbase) no longer works + * [MergeStat](https://github.com/mergestat/mergestat) - using SQLite + * [Gitana](https://livablesoftware.com/gitana-sql-git-repository-inspector/) + ([repo](https://github.com/SOM-Research/Gitana), [docs](http://gitanadocs.getforge.io/), [paper](https://www.researchgate.net/publication/279058070_Gitana_a_SQL-based_Git_Repository_Inspector))- using MySQL + _(not mentioned in those articles, possibly because it started as a research project)_, + mentioned in [Git Rev News #7](https://git.github.io/rev_news/2015/09/09/edition-7/) + and [#48](https://git.github.io/rev_news/2019/02/27/edition-48/) + * storing a database in Git: + * [SQLite](https://sqlite.org) where databases are files + * [gitSQL](https://github.com/gitsql) exporting flat file SQL statements of objects from the database for storage in a Git repository + + +__Git tools and sites__ + +* [BBChop](https://github.com/Ealdwulf/BBChop) is a tool in Python by Ealdwulf Wuffinga + implementing a bisection algorithm which works on intermittent bugs (experimental code). + BBChop is based on [Bayesian Search Theory](https://en.wikipedia.org/wiki/Bayesian_search_theory). +* [Soft Serve](https://github.com/charmbracelet/soft-serve) + is a self-hostable Git server for the command line, written in Go. + It is configurable with Git, you can create repos on demand with `git push`, + and you can browse repos with an SSH-accessible TUI. +* [GitLive](https://git.live/) is a proprietary extension with a free tier + for Visual Studio Code, JetBrains IDEs, and Android Studio, + providing real-time collaborative support, giving insight about what other developers in the team are working on. + It supports GitHub, Bitbucket, GitLab (including self-hosted) and Azure DevOps repository hosting services.
+ GitLive was mentioned as [VS Code extension](https://marketplace.visualstudio.com/items?itemName=TeamHub.teamhub) + in [Git Rev News Edition #77](https://git.github.io/rev_news/2021/07/31/edition-77/). + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Randall S. Becker. diff --git a/_posts/2022-01-31-edition-83.markdown b/_posts/2022-01-31-edition-83.markdown new file mode 100644 index 000000000..69ea4f0bf --- /dev/null +++ b/_posts/2022-01-31-edition-83.markdown @@ -0,0 +1,218 @@ +--- +title: Git Rev News Edition 83 (January 31st, 2022) +layout: default +date: 2022-01-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 83 (January 31st, 2022) + +Welcome to the 83rd 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](https://git.github.io). + +This edition covers what happened during the month of December 2021. + +## Discussions + + + + + +### Support + +* [Custom subcommand help handlers](https://lore.kernel.org/git/CABceR4ZW4rRWZnH0ZBkWty_H84Z4CmXque_LO+1edETEWrO8PQ@mail.gmail.com/) + + Sean Allred wrote to the mailing list saying that in his company he + is distributing a Git subcommand he named `git-foo`, which can + display its own help, but he was struggling to make this work. + + Running `git foo --help` doesn't pass `--help` to `git-foo`, but + instead it is rewritten internally in Git to `git help foo`, which + tries to find and then display a help page for `git-foo`. This + could have worked if Sean could install such a page for `git-foo` + along with the help pages for regular Git commands. + + On Windows, though, by default help pages are displayed in HTML + format instead of the 'man' or 'info' formats, and these pages + are expected to be in a Git for Windows controlled installation + directory that he'd rather not touch. + + One solution he suggested would be to not rewrite `git foo --help` + to `git help foo` if the `foo` command is not a builtin. + + Ævar Arnfjörð Bjarmason replied to this suggestion that this might + not please everyone, as `git send-email --help` and + `git annex --help` were currently expected to show the manual, even + though these commands are not builtins. + + Dscho, alias Johannes Schindelin, also replied to Sean saying that just + looking whether the command is a builtin or not might not be enough, + as Git also installs scripts or executables, and provided some + example code implementing an `is_in_git_exec_path()` function. + + Ævar and Dscho then discussed a bit if such a function was needed as + Ævar pointed that we already have a way to dump builtins, other known + commands and commands unknown to Git, using respectively: + + - `git --list-cmds=builtins` + - `git --list-cmds=main` + - `git --list-cmds=others` + + Meanwhile Erik Cervin Edin replied to Ævar's initial reply to Sean + saying that when a Git alias is configured for `foo` and it's used with + `--help`, the user is told that `foo` is an alias for another + command, and the help page for the other command is displayed. So he + suggested doing something similar for non-builtin commands that are + missing help pages. + + Erik also mentioned that using `git-foo --help` directly or + `git foo -h`, instead of `git foo --help`, would allow `git-foo` to + handle everything. + + brian m. carlson replied to Erik that for man pages it might not be + possible to distinguish a missing page from another error. He then + wondered if there is a similar environment variable as `MANPATH` for + HTML pages, as `MANPATH` on Unix systems instructs `man` to search + for pages in the directories specified in this variable. He also + suggested installing the HTML documentation alongside Git's, as it's + expected on Unix systems to have all man pages installed into the + same place. + + Junio Hamano, the Git maintainer, then agreed to this suggestion. + + Erik replied to brian and Junio that there was no standard or + convention around HTML documentation, and talked about the + `help.htmlPath` configuration variable that could be used to tell Git + where to look for HTML pages. He also suggested falling back to + searching a missing HTML page starting at the path of the command. + + The discussion continued for some time between Erik, Junio, Philip + Oakley and Dscho, especially around the topic of aliases. + + Then Junio spotted the `GIT_HTML_PATH` environment variable in the + code, and noticed that it can currently be used to specify just + one directory for HTML pages, while `MANPATH` can be a + colon-separated list of directories. So he suggested changing the + code to allow `GIT_HTML_PATH` to also be a colon-separated list of + directories. This would allow people to install HTML pages in + directories without the need of administrator rights. + + It looks like no one has yet started working on this though. + + + +## Releases + ++ Git [2.35.0](https://public-inbox.org/git/xmqqee4x3pij.fsf@gitster.g/), +[2.35.0-rc2](https://public-inbox.org/git/xmqqwniui6wd.fsf@gitster.g/), +[2.35.0-rc1](https://public-inbox.org/git/xmqq35lp68rw.fsf@gitster.g/), +[2.35.0-rc0](https://public-inbox.org/git/xmqq7db7xfgn.fsf@gitster.g/) ++ Git for Windows [2.35.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.35.0.windows.1), +[2.35.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.35.0-rc2.windows.1), +[2.35.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.35.0-rc1.windows.1), +[2.35.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.35.0-rc0.windows.1) ++ GitLab [14.7](https://about.gitlab.com/releases/2022/01/22/gitlab-14-7-released/) +[14.6.3](https://about.gitlab.com/releases/2022/01/17/gitlab-14-6-3-released/), +[14.6.2, 14.5.3, and 14.4.5](https://about.gitlab.com/releases/2022/01/11/security-release-gitlab-14-6-2-released/), +[14.6.1](https://about.gitlab.com/releases/2022/01/04/gitlab-14-6-1-released/) ++ GitHub Enterprise [3.3.2](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.2), +[3.2.7](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.7), +[3.1.15](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.15), +[3.0.23](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.23) + +## Other News + +__Various__ + +* [Highlights from Git 2.35](https://github.blog/2022-01-24-highlights-from-git-2-35/) + by Taylor Blau on GitHub Blog. +* [Linux Foundation launches Open Source Software Development, Linux, and **Git** certification](https://www.zdnet.com/article/linux-foundation-launches-open-source-software-development-linux-git-certification/), + and three new training courses on the edX platform (including + [Git for Distributed Software Development (LFD109x)](https://www.edx.org/course/git-for-distributed-development)). +* [Introducing new Git features to Visual Studio 2022](https://devblogs.microsoft.com/visualstudio/introducing-new-git-features-to-visual-studio-2022/) + by Taysser Gherfal on Microsoft Visual Studio DevBlog. + +__Light reading__ + +* [Signing Git Commits with SSH Keys](https://blog.dbrgn.ch/2021/11/16/git-ssh-signatures/) + by Danilo Bargen (available since Git version 2.34). +* [Git Overview - Computerphile](https://www.youtube.com/watch?v=92sycL8ij-U), + a video by dr Max Wilson, filmed and edited by Sean Riley. +* [Awesome Git Aliases](https://davidwalsh.name/awesome-git-aliases) and + [More Awesome Git Aliases](https://davidwalsh.name/more-awesome-git-aliases) + by Landon Schropp on Dawid Walsh Blog. +* [Git Organized: A Better Git Flow](https://render.com/blog/git-organized-a-better-git-flow) + by Annie Sexton on Render.com Blog; though a better solution would be to use interactive rebase, + as described in [comments for this article on DEV.to](https://dev.to/render/git-organized-a-better-git-flow-56go#comment-subscription). +* [No code reviews by default (to move faster)](https://www.raycast.com/blog/no-code-reviews-by-default/) + by Thomas Paul Mann of Raycast (and how it works for them). +* [How to Make a Component That Supports Multiple Frameworks in a Monorepo](https://css-tricks.com/make-a-component-multiple-frameworks-in-a-monorepo/) + by Rob Levin on CSS-Tricks. +* [How Git Works Under the Hood](https://www.freecodecamp.org/news/git-under-the-hood/) + by Faisal Albasu on freeCodeCamp. +* [Advanced Git Concepts You Should Know](https://dev.to/ruppysuppy/advanced-git-concepts-you-should-know-nle) + by Tapajyoti Bose on The Practical Dev (also known as DEV\.to). +* [How to Write Better Git Commit Messages – A Step-By-Step Guide](https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/) + by Natalie Pina on freeCodeCamp; this article talks also about the + [Conventional Commits](https://www.conventionalcommits.org/) specification, + first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/). +* [How to check commit message and branch name with git hooks without any new installation](https://dev.to/anibalardid/how-to-check-commit-message-and-branch-name-with-git-hooks-without-any-new-installation-n34), + a short article by Anibal on DEV\.to. +* [How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories](https://www.ndss-symposium.org/ndss-paper/how-bad-can-it-git-characterizing-secret-leakage-in-public-github-repositories/) + by Michael Meli, Matthew R. McNiece, Bradley Reaves in NDSS 2019; + via [the morning paper article](https://blog.acolyer.org/2019/04/08/how-bad-can-it-git-characterizing-secret-leakage-in-public-github-repositories/) + by Adrian Colyer. +* [The Pull Request Paradox: Merge Faster by Promoting Your PR](https://dzone.com/articles/the-pull-request-paradox-merge-faster-by-promoting) + Adding more context to our Pull Requests got them merged two days faster. Here's how it works. By Dan Lines. +* [What's in a Good Error Message?](https://www.morling.dev/blog/whats-in-a-good-error-message/) + Some thoughts on ensuring error messages are useful to the reader. By Gunnar Morling. +* [Let's Talk about Error Messages](https://www.codeproject.com/Articles/5322503/Lets-talk-about-Error-Messages) + More thoughts on error messages, by Brien King. + +__Git tools and sites__ + +* [git-perl-critic](https://github.com/Ovid/git-critic) - Command-line interface for the + Perl [Git::Critic](https://metacpan.org/pod/Git::Critic) module, + reporting [Perl::Critic](https://metacpan.org/pod/Perl::Critic) failures + (that is, code violating Perl best practices) only on lines changed in the current Git branch. + By Curtis "Ovid" Poe. +* [Dura](https://github.com/tkellogg/dura) is a background process that watches + your Git repositories and commits your uncommitted changes without impacting HEAD, + the current branch, or the Git index (staged files). With this tool you should not + ever lose your work if you're using Git. + Written in Rust by Tim Kellogg. +* [ResumableGitClone](https://github.com/johnzeng/ResumableGitClone) (2017) + is a Bash shell script to clone a large repo without retrying again and again, + by using a deepening shallow clone. +* [git-pull-run](https://www.npmjs.com/package/git-pull-run) is an npm package + which automatically runs commands like `npm install` when fetching changes from Git, + but only if certain files have changed. Extended version of the script presented in + [Automatically Install NPM Dependencies on Git Pull](https://dev.to/zirkelc/automatically-install-npm-dependencies-on-git-pull-bg0). +* [Husky.Net](https://github.com/alirezanet/Husky.Net) is a Git hooks manager for .NET, + among others making it possible to run linters against staged Git files. + Inspired by [husky](https://github.com/typicode/husky), + [lint-staged](https://github.com/okonet/lint-staged), + a few other tools, and by [Using C# code in your git hooks](https://kaylumah.nl/2019/09/07/using-csharp-code-your-git-hooks.html) + article by Max Hamulyák (2019). + * [lint-staged](https://github.com/okonet/lint-staged) was first mentioned in + [Git Rev News #45](https://git.github.io/rev_news/2018/11/21/edition-45/) + * [husky](https://github.com/typicode/husky) was first mentioned in + [Git Rev News #63](https://git.github.io/rev_news/2020/05/28/edition-63/) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Philip Oakley. diff --git a/_posts/2022-02-28-edition-84.markdown b/_posts/2022-02-28-edition-84.markdown new file mode 100644 index 000000000..33ba3f19e --- /dev/null +++ b/_posts/2022-02-28-edition-84.markdown @@ -0,0 +1,391 @@ +--- +title: Git Rev News Edition 84 (February 28th, 2022) +layout: default +date: 2022-02-28 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 84 (February 28th, 2022) + +Welcome to the 84th 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](https://git.github.io). + +This edition covers what happened during the month of January 2022. + +## Discussions + +### General + +* [Join us for Review Club!](https://lore.kernel.org/git/Yfl1%2FZN%2FtaYwfGD0@google.com/) + + Josh Steadmon announced that the Review Club meeting he has been + organizing at Google for a while is now open to everyone. It happens + every other Wednesday at 14:00 Pacific time (UTC-8) via Google Meet. + + The first opened meeting happened on Wednesday February 2nd and + discussed [Elijah's "In-core git merge-tree" patch series](https://lore.kernel.org/git/pull.1122.v2.git.1643479633.gitgitgadget@gmail.com/). + + Please contact Josh Steadmon at if you are + interested and want to join. + +### Reviews + +* [[PATCH] `fetch --prune`: exit with error if pruning fails](https://lore.kernel.org/git/20220127153714.1190894-1-t.gummerer@gmail.com/) + + Thomas Gummerer sent a patch so that `git fetch`, when it's used + with the `--prune` flag or its `-p` short form, will not exit with + exit status 0 anymore if pruning a ref fails. + + Pruning a ref means removing a remote tracking ref, usually a branch, + if the ref disappeared on the remote. For example, if a remote called + `origin` has a branch called `feature1`, then fetching from + `origin` will cause Git to create a remote tracking branch called + `origin/feature1` on the local machine. After the `feature1` branch + is removed on `origin`, subsequent fetches from `origin` will yield + the deletion of the local `origin/feature1` branch only if pruning is + requested. + + Thomas noted in his patch that an error message was already printed + on stderr when pruning a ref failed, but it felt like a bug that + `git fetch` was still exiting with the 0 exit status in this case, as + this could be interpreted as if no error happened. + + Thomas had looked up the commit that introduced pruning, but he + couldn't find if the exit status behavior was "an oversight or + intentional", but it felt like an oversight to him. + + Junio Hamano, the Git maintainer, agreed with Thomas about using a + non-zero exit status when ref pruning failed, but he was unsure about + which actual exit status would be emitted by the code in Thomas' patch. + + Junio also found an issue with the current code as in some cases it + appeared that -1 could be passed to `exit()`. This would result in a + 255 exit status, as exit statuses have only 8 bits and are unsigned. He + left a `#leftoverbits` mention related to this in his email, which + helps find usually small issues that should be fixed later. + + Junio also thought that is probably wasn't a good idea to error out + as soon as an error happens when pruning. It was probably best to + continue to fetch and prune as much as possible, "given that we have + already paid for the cost of discovering the refs from the other + side". + + Thomas' patch added a new regression test that was then discussed a + bit by Junio, who left another `#leftoverbits` mention related to + the fact that many tests in the test script, where Thomas added the + new test, were using an old style and might want a cleanup. + + Dscho, alias Johannes Schindelin, replied to Junio that it might + actually be confusing and unexpected for users if the fetch would + continue when pruning failed. He suggested adding a + `--prune-best-effort` option for cases where we might want the fetch + to continue as much as possible when pruning fails. + + Thomas replied to Dscho that he was unsure what the behavior should + be when writing the patch, but that exiting early "felt like the + right thing to do for the user". He said that he would be OK with + introducing `--prune-best-effort`. He wasn't sure people would + actually use it much though, as "it should be very rare that + `--prune` fails". + + Junio replied to Thomas and Dscho that "when we fetch to update + multiple refs, we do not stop at the first ref-update failure, but + try to do as much as possible and then report an error", and that + `--prune` should behave similarly. + + Thomas also replied separately about Junio's initial comment related + to the actual exit status that would be emitted after Thomas' patch. He + wondered if the exit status should always be 1 when `git fetch` fails + at pruning. + + Thomas and Dscho then discussed the new test, following Junio's + comments, and agreed on adding a comment in the code to explain what + the test was doing. + + Thomas then sent [a version 2 of his patch](https://lore.kernel.org/git/20220131133047.1885074-1-t.gummerer@gmail.com/) + with the changes that had been discussed. + + Junio reviewed this new version and decided to merge it down, so + this small improvement will be in the next Git version. + + + +## Developer Spotlight: Eric Sunshine + +_(Eric has already been interviewed in [Git Rev News #7, September 2015](https://git.github.io/rev_news/2015/09/09/edition-7/#developer-spotlight-eric-sunshine).)_ + +* Since your previous interview, have there been changes in who you + are and what you do? + + About a year after the previous interview, taking on the role of + caregiver for a family member consumed the bulk of my time to the + point that I was unable to keep up with the Git project or contribute + in any meaningful way, and was effectively absent from the project + for at least a year and a half. Since returning to the project, my + contributions have been far more scarce due to time constraints of + "real life" and a new job which I started a few years ago. + +* You were a long-time RCS, CVS, and Subversion user. Do you miss + any features of those version controls systems in Git? + + I can say without hesitation that I do not miss any features of those + older version control systems. In fact, I can report (perhaps + happily) that I have mostly forgotten how to use them. This is true + of Subversion, in particular, in which I have had to consult the + documentation to tackle even the simplest tasks the couple times I + had to use it in the last few years, despite having been a longtime + and experienced user. + +* How are your contributions to Git these days? Code contributions? + Code reviews? Others? + + In the past, I was generally able to keep up with the mailing list + and read most or all patches submitted to the project and often + provide detailed reviews, but my Git time is fairly limited these + days, so I have to be much more selective about which topics I follow + or participate in. + + Since I contributed quite a bit to the `git worktree` command (and am + perhaps an "area expert", especially since Nguyễn Thái Ngọc Duy + departed from the project), I pay particular attention to bug reports + about that command or topics touching it in some significant fashion. + In the case of a bug report, I either provide a fix for the problem + myself or help guide some other contributor. In the case of topics + which touch `git worktree`, I try to set aside time to review the + topic's patches carefully and follow along as the topic progresses. + + That aside, I also provide reviews for other topics when they fit + into my limited Git time, and answer the periodic question on the + mailing list, or interact in a discussion if I have something + meaningful to offer on the subject. + +* Are 'ability to stage changes' and 'interactive rebase' still your + favorite Git features? Or do you have new favorites? + + Yes they are, and no I do not have new favorites. + + In fact, a few years back, I started using the [`src`](http://www.catb.org/~esr/src/) + version control system for managing standalone files (which, although built + atop RCS, features a "modern" command line interface quite like Git's + and in no way like RCS's interface). Although I find `src` handy for + versioning standalone files, I always feel as if my hands are tied + when using it since it lacks the very useful features of staging + changes and rebasing interactively. + + As a consequence, aside from contributing bug fixes and enhancements + to the project, I also spent some time significantly improving the + `fast-import` and `fast-export` round trip fidelity of `src`. This + allows me to temporarily import a `src` history into Git, which gives + me access to Git's staging and interactive rebasing, and finally + convert the history back to `src`. Yes, it's a terrible kludge, and a + painful one, but at least gives me a way to take advantage of those + Git features when absolutely required. I don't use `src` often enough + presently to justify the development effort, but adding staging and + interactive rebasing to the tool directly would be on my wish list + for that project. + +* How does your mailing list workflow look like? + + I understand that some developers have special tooling set up to + improve the mailing list-centric workflow on the Git project, but I + still use a plain email client with no special provisions, and I + likely will continue with this set-up as long as it works well enough + for my simple needs. + + I do find the Git mailing list archive at + quite useful and often go spelunking through it when researching some + topic or bug report, as well as to fetch sets of patches which I may + have already deleted from my local email client. Much more recently, + I have also started taking advantage of its NNTP feed (nntp.lore.kernel.org). + +* Could you elaborate a bit about the email client you use? + + I use Gmail in the web browser almost exclusively. Lately, I have + been using Thunderbird to access the lore.kernel.org NNTP feed. + Infrequently, I use `mutt` when I need to send a patch inline within + a reply when I don't want the Gmail web interface to modify + whitespace or the formatting in general. (I also have Emacs set up + for email, thus could use it for the same purpose as `mutt`, but + never actually do so.) + + [ _Editor's note: If you're going to use Gmail in the web browser, + ensure "Plain text mode" is checked. Also, see [Gmail specific + format-patch hints](https://git-scm.com/docs/git-format-patch#_gmail)_ ] + +* What is your advice for people who want to start Git development? + Where and how should they start? + + Getting involved in the Git project can be intimidating (I know, even + after all these years, I still feel intimidated each time I submit + patches), but people on the project are generally quite friendly, and + the goal of reviewers is to help you refine your submission so that + it can eventually be accepted into the project. After all, that's why + reviewers take the time to read submissions so thoroughly and offer + (sometimes in-depth and exhaustive) comments to improve the + submission. One thing to note: people who review a lot of patches + tend (out of necessity) to be economical with their words, pointing + out just the parts of the patch which need improvement and often + forgetting to praise the parts which are done well. As such, reviews + can sometimes feel cold and off putting, but that is not the + intention. Reviewers are genuinely trying to help; they would not put + in such effort otherwise. + + A good way to learn how the project works is to subscribe to the + mailing list and read submissions from active contributors and + reviews from regular reviewers. You can learn by example via passive + observation. From a patch or patch series, you can learn not only how + a patch series should be constructed, but also how an effective + commit message is written. By reading reviews, you can learn what + reviewers are looking for and how they interact. + + To become actively involved in the project, submit a patch, even a + small one fixing a bug you found or making a minor improvement to + documentation. If you have an idea for a functionality improvement or + a new feature, send it to the mailing list. Or, if you just want to + contribute without having anything particular in mind, monitor the + mailing list for bug reports (as I did when I joined the project) and + try to devise a fix and submit it to the mailing list in the form of + a patch. + + Another way to contribute to the project is by reviewing submissions. + Reviews do not need to be extensive or elaborate. A review which + points out a minor logic flaw in a patch or highlights a + typographical error in a comment or commit message is useful. + +* If there's one tip you would like to share with other Git developers, + what would it be? + + When reviewing a patch, make it clear which of your comments you + expect the submitter to act upon and which suggestions can be left to + the discretion of the submitter. This is especially important for new + contributors who may not be able to distinguish between mandatory + changes to the patch and "it might be nice to have" changes. Also let + the submitter know that it is okay to push back on a review comment + if necessary since newcomers may not realize that doing so is an + option. + + For a submitter, try to respond to each review comment -- even if the + response is a simple "OK" or "I agree with all your comments" or "I + disagree with this comment because..." -- so that reviewers do not + feel that their effort has been wasted. + + (Oops, that's two tips, not one. Sorry.) + +* What would you name your most important contribution to Git? + + It is difficult to judge the importance of various contributions. I + may instead be able to highlight a few areas in which I have been + involved. + + Although I do not do many reviews these days, I used to be an active + reviewer, and hope that my review comments and suggestions helped + improve various submissions in at least some way. + + From an end-user perspective, perhaps the my most visible + contribution to Git has been all the work I did to improve and + enhance the `git worktree` command and multiple-worktree support in + general (though much of the praise for the mechanics of + multiple-worktree support belongs to Nguyễn Thái Ngọc Duy who + designed and originated the implementation). + + From a Git developer perspective, perhaps my most valuable(?) + contribution is the so-called `chainlint` which identifies a specific + type of problem in Git test scripts which could, if undetected, allow + a test to miss a failure and erroneously report success. + +* What are you doing on the Git project these days, and why? + + As mentioned, my Git time is limited, so my involvement is scaled + back. I do try to answer a question here or there or contribute to a + discussion if possible, and I review the periodic submission. + + Aside from contributing a few bug-fix patches and introducing the + `git worktree repair` command relatively recently, my recent focus + has been on a new and much enhanced version of the `chainlint` tool + mentioned above. Although the implementation has been complete for + well over a half year (at the time of writing), I am still trying to + find time to polish the patch series itself for submission. In the + meantime, I did manage to submit a couple other somewhat lengthy + patch series in preparation for the new `chainlint`. + +## Releases + ++ Git [2.35.1](https://public-inbox.org/git/xmqq1r0rtfw9.fsf@gitster.g/) ++ Git for Windows [2.35.1(2)](https://github.com/git-for-windows/git/releases/tag/v2.35.1.windows.2), +[2.35.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.35.1.windows.1) ++ libgit2 [1.4.1](https://github.com/libgit2/libgit2/releases/tag/v1.4.1), +[1.4.0](https://github.com/libgit2/libgit2/releases/tag/v1.4.0) ++ GitHub Enterprise [3.3.4](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.4), +[3.2.9](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.9), +[3.1.17](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.17), +[3.0.25](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.25), +[3.4.0](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.0), +[3.3.3](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.3), +[3.2.8](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.8), +[3.1.16](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.16), +[3.0.24](https://help.github.com/enterprise-server@3.0/admin/release-notes#3.0.24) ++ GitLab [14.8](https://about.gitlab.com/releases/2022/02/22/gitlab-14-8-released/) +[14.7.3](https://about.gitlab.com/releases/2022/02/14/gitlab-14-7-3-released/), +[14.7.2](https://about.gitlab.com/releases/2022/02/08/gitlab-14-7-2-released/), +[14.7.1, 14.6.4, and 14.5.4](https://about.gitlab.com/releases/2022/02/03/security-release-gitlab-14-7-1-released/) ++ GitKraken [8.3.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.9.9](https://desktop.github.com/release-notes/), +[2.9.8](https://desktop.github.com/release-notes/), +[2.9.7](https://desktop.github.com/release-notes/) ++ Tower for Mac [8.0](https://www.git-tower.com/release-notes/mac) ([What's New in Tower 8 video](https://youtu.be/US4W1lNEJCE)) + +## Other News + +__Various__ + +* How some Git fetch performance improvements were made, [part 1](https://about.gitlab.com/blog/2022/01/20/git-fetch-performance/) and + [part 2](https://about.gitlab.com/blog/2022/02/07/git-fetch-performance-2021-part-2/), by the GitLab Scalability team. +* [Include diagrams in your Markdown files with Mermaid](https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/), + automatically rendered on GitHub and possibly also in other + [CommonMark](https://commonmark.org/) implementations. +* [More ways to keep your pull request branch up-to-date](https://github.blog/changelog/2022-02-03-more-ways-to-keep-your-pull-request-branch-up-to-date/) + on GitHub. + + +__Light reading__ + +* [Cross-fork object sharing in git (is not a bug)](https://people.kernel.org/monsieuricon/cross-fork-object-sharing-in-git-is-not-a-bug) + by Konstantin Ryabitsev. +* [Getting Started with Git Bash](https://www.git-tower.com/blog/git-bash/) + by Bruno Brito on Git Tower blog. +* [Inside the Hidden Git Folder - Computerphile](https://youtu.be/bSA91XTzeuA) + by Dr Max Wilson on Computerphile channel on YouTube. + Beware a blink and you miss it error about the purpose of the `.git/logs/` folder. + A link to the previous video on the topic of Git by Dr Max Wilson can be found in + [Git Rev News Edition #83](https://git.github.io/rev_news/2022/01/31/edition-83/) + (the previous edition). +* [Protect secrets in Git with the clean/smudge filter](https://developers.redhat.com/articles/2022/02/02/protect-secrets-git-cleansmudge-filter) + by Tomer Figenblat on Red Hat Developer blog. +* [Git: Switching Unstaged Changes to a New Branch](https://css-tricks.com/git-switching-unstaged-changes-to-a-new-branch/) + two ways, by Chris Coyier on CSS-Tricks; read also featured comments. + + +__Git tools and sites__ + +* [Monorepo.tools](https://monorepo.tools/) -- Everything you need to know about monorepos, + and the tools to build them. + * [Announcing monorepo.tools](https://blog.nrwl.io/announcing-monorepo-tools-da605afbb5d5) + by Juri Strumpflohner for Nrwl. + * You can find the most recent list of pros and cons of monorepos in + [Git Rev News Edition #81](https://git.github.io/rev_news/2021/11/29/edition-81/). + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Eric Sunshine, Philip Oakley, Bruno Brito +and Josh Steadmon. diff --git a/_posts/2022-03-31-edition-85.markdown b/_posts/2022-03-31-edition-85.markdown new file mode 100644 index 000000000..45f9a8ba7 --- /dev/null +++ b/_posts/2022-03-31-edition-85.markdown @@ -0,0 +1,377 @@ +--- +title: Git Rev News Edition 85 (March 31st, 2022) +layout: default +date: 2022-03-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 85 (March 31st, 2022) + +Welcome to the 85th 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](https://git.github.io). + +This edition covers what happened during the month of February 2022. + +## Discussions + + + +### Reviews + +* [[PATCH] http API: fix dangling pointer issue noted by GCC 12.0](https://lore.kernel.org/git/patch-1.1-1cec367e805-20220126T212921Z-avarab@gmail.com/) + + Ævar Arnfjörð Bjarmason sent a patch to the mailing list to fix an + issue that appears when compiling Git with the gcc 12.0 development + branch. + + The issue is that this gcc version emits a warning on the last line + of the following code: + + ``` + int finished = 0; + + slot->finished = &finished; + ``` + + where `slot` is an instance of `struct active_request_slot` which + has an `int *finished` member. + + The warning is "storing the address of local variable ‘finished’ in + ‘*slot.finished’ [-Werror=dangling-pointer=]". + + Ævar first thought about making the `struct active_request_slot` member an + `int finished` member, so it wouldn't be a pointer anymore, and then about + removing the `int *finished` member entirely and using the + `int in_use` member instead. His patch implemented the latter. + + Taylor Blau reviewed Ævar's patch but wasn't sure about one of the + places where the `int *finished` member was removed. + + Junio Hamano also reviewed the patch and wondered if the new gcc + version was correct in flagging the code in the first place, as it + appeared that `slot->finished` wasn't used outside the function + where it's assigned the address of a local variable. + + Junio also wondered if it was correct to remove the `int *finished` + member entirely and use the `int in_use` member instead, as that + looked like reversing the patch that introduced `int *finished` + without fully explaining why it was correct to do so. + + To address the issue Junio then proposed implementing the following: + + ``` + if (slot->finished == &finished) + slot->finished = NULL; + ``` + + so that hopefully gcc would understand that the `slot->finished` + field isn't using a local address outside the current function. + + Ævar replied to Junio, that assigning `slot->finished` to `NULL` at + the end of the function would indeed quiet gcc. So he sent + [a version 2 of his patch](https://lore.kernel.org/git/patch-v2-1.1-777838267a5-20220225T090816Z-avarab@gmail.com/) + that only added `slot->finished = NULL;` at the end of the function. + + Junio wasn't sure if the change was completely correct as he said he + no longer trusted his own reading of the http code, but he agreed + that it should be merged if gcc wasn't fixed soon. + + Taylor took another look at the patch and found other functions + where `slot->finished` is assigned, so he wondered if a better fix + would be to change the `int *finished` member into a tri-state + "UNKNOWN/TRUE/FALSE enum". + + Ævar then sent [a version 3 of his patch](https://lore.kernel.org/git/patch-v3-1.1-69190804c67-20220325T143322Z-avarab@gmail.com/) + where he only improved the commit message compared to the previous + version. In the new commit message he explains why the other places + where `slot->finished` is assigned are already correct and don't + need any change. + + Taylor then agreed with Ævar's explanations, but Junio wasn't sure + about them, so he changed the commit message a bit, explaining how + we could make sure that the change to clear `slot->finished` is + correct by adding the following code before it: + + ``` + if (slot->finished) + BUG("the unconditional clearing at the end is wrong"); + ``` + + For now the patch has still not been merged into the `next` branch + as Junio hopes that gcc 12.0 will be fixed before it's actually + released. But in case it isn't, at least we are ready for it. + + + + +## Developer Spotlight: Victoria Dye + +* Who are you and what do you do? + + Hi! My name is Victoria Dye, and I work as a software developer at GitHub. I + spend a lot of my time contributing to Git & some of its downstream forks + (Git for Windows and `microsoft/git`), and _occasionally_ Git Credential + Manager (although it's been a while). I really enjoy solving tough + performance problems in software, so I'm hoping to do more of that in Git in + the not-so-distant future! + +* What would you name your most important contribution to Git? + + I haven't been contributing to Git for all that long, so it's hard to judge + the importance of anything I've done. That said, I'm pretty proud of the + work I've done around sparse index and `sparse-checkout`. It's been exciting + to contribute and see those features mature so rapidly over the past couple + months, and I hope it continues to gain traction with users looking for + better performance in Git! + +* What are you doing on the Git project these days, and why? + + My focus pretty much since I started working on Git has been on integrating + commands with sparse index. Most recently that's been `git stash`, which not + only requires its own integration, but also the integration of all the + commands it shells out to (`update-index`, `read-tree`, etc.). The goal of + these initial sparse index integrations (including those by Derrick Stolee & + Lessley Dennington) is to cover the most popular commands as reported by + users at $DAYJOB (`git add`, `git reset`, etc.), so the theoretical + performance gains of the sparse index can turn into a real improvement to + user experience. + + Beyond my own work, I'm looking forward to mentoring a GSoC contributor in + _more_ sparse index integration! It's an admittedly complicated topic, but --- + based on my own experience -- working on it can give new contributors an + incredible depth of knowledge in Git that's hard to get elsewhere. Plus, I + love mentoring developers and creating a positive environment for them, so + I'm excited to have the chance to do that here! + +* 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? + + It would be great to see the shell script-based test suite rewritten into a + unit/integration/end-to-end testing stack. The tests we have are almost + exclusively end-to-end (excepting hackery with `test-tool` or `trace2` logs + exposing internal functions to test them), so we often have incomplete + coverage of some of the trickier code paths (e.g., `unpack_trees`). And, + especially for developers that like test-driven development, it can be a + _lot_ easier working with code that has a robust unit testing suite. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + In general, I don't think there's a _feature_ that I'd want to completely + remove. Git is a fantastic tool in that it lets developers structure their + work in whatever way works best for them; something I personally don't have + a great experience with (looking at you, _submodules_) might just happen to + be someone else's favorite tool. + + However, I would absolutely remove an implementation pattern in Git itself: + shell script builtins and Git commands shelling out to other Git commands. + They're prone to bugs, difficult to troubleshoot, and can almost always be + implemented more efficiently by commonizing the code they're trying to get + out of another command. + +* What is your favorite Git-related tool/library, outside of Git itself? + + I really, really like my current setup of VSCode + + [GitLens](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens). + I used to have a bit of a "text editor is for editing text, Git command line + is for source control" attitude and avoided using any integrations between + the two, but recently I gave in and installed GitLens. I tend to heavily use + the commit history when investigating bugs & learning a new area of the + code, so the inline 'blame' and commit-message-on-hover in particular make + that process about as fast it could be. + +* What does your mailing list workflow look like? + + For submissions, I use [GitGitGadget](https://github.com/gitgitgadget/git). + It really simplifies the process of submitting to Git (especially re-rolls) + and, if anything, it prevents me from making silly mistakes with + `git send-email`. + + For everything else, I have two email inbox folders: things addressed to me + directly (submission feedback, patches I've been CC'd on) and "everything + else". For direct feedback/CCs, I try to respond within a couple days if I + think I can contribute something valuable to the discussion. The "everything + else" folder is set to "automatically mark as read" to avoid a distracting + barrage of "unread"s in my inbox, so I typically scan it a couple times a + day to stay up-to-date and check whether there's anything I can help with or + review. + +* Do you think contributing to Git has a high entry barrier? If yes, do + you have any suggestions to improve the experience for new contributors? + + In my experience, not really (at least, not so high that it excludes + would-be contributors). But I think it might seem that way because the + mailing list can be super intimidating when you're looking to get started. + + The mailing list is constantly active with complex patches and lots of + experienced developers iterating on complicated feedback, so it can be easy + to feel as though you can't contribute much to it or that your code won't + meet the project's standards. There have been efforts in the past to guide + new contributors and help them technically learn the project, but it + ultimately comes down to the first interactions someone has with the rest of + the mailing that that determines whether or not they stick with it. + + In terms of suggestions for improvement, I think it's important for + reviewers to maintain a supportive tone in even highly constructive reviews. + A lot can get lost in text communication, so sometimes it's worth explicitly + calling out your appreciation for a contribution. This is _especially_ true + for new contributors, but is just as applicable to any reviews. + + Another (more concrete) suggestion would be to make it easier for new + contributors to find appropriate "starter" features/bugs of different sizes. + Other open source projects have issue trackers with a "good first project" + tag (and, as a new contributor on other projects, I've definitely + appreciated them). Although there have been discussions about creating + public issue trackers outside the mailing list, to my knowledge nothing like + that exists yet for Git, let alone a subset for new contributors. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + If you're not coming in with a clear project or bugfix in mind, it can be + really difficult to figure out where to start. If you're in that position, + something that has helped me in the past has been to just start testing + things until they break. Read up on a command you find interesting, look for + scenarios (e.g. options, sequences) that aren't well-tested in our existing + tests, and start experimenting! Worst case, you can improve test coverage + and help us avoid issues in the future; a lot of times, though, you'll find + a bug or an opportunity to add a new option. In any event, the experience + will teach you a ton about Git and make you more comfortable with + contributing. + + And once you have a working change, don't be afraid to submit it out of fear + that it's not "good enough". The goal we all share is to make Git as good as + it can possibly be, so your contribution -- no matter how small or trivial + you think it is -- is a valuable part of what makes this project succeed. + +* If there's one tip you would like to share with other Git developers, + what would it be? + + Keep learning and trying new things! The Git development community has a + vast range of experience across its members -- from people who worked on it + since the beginning to people making their first open source contribution + ever. But it's also an easy place to get stuck in "your niche" (if you're + lucky, you get stuck with a couple of other people so you can review each + others' work). + + Of course, none of us have infinite time to spend on Git. But every once in + a while, take a minute to read a contribution from someone you don't know on + a topic you're not familiar with. Or investigate a bug report on a command + you've never worked on! Or share your idea for a process we could try (like + the Git Review Club)! Not only will you learn something new and improve + yourself as a developer, but the collaboration you foster will help all of + us improve Git in the long term. + + +## Releases + ++ libgit2 [1.4.2](https://github.com/libgit2/libgit2/releases/tag/v1.4.2) ++ GitLab [14.9.1](https://about.gitlab.com/releases/2022/03/23/gitlab-14-9-1-released/), +[14.9](https://about.gitlab.com/releases/2022/03/22/gitlab-14-9-released/), +[14.8.4](https://about.gitlab.com/releases/2022/03/16/gitlab-14-8-4-released/), +[14.8.3](https://about.gitlab.com/releases/2022/03/15/gitlab-14-8-3-released/), +[14.7.6](https://about.gitlab.com/releases/2022/03/24/gitlab-14-7-6-released/), +[14.7.5](https://about.gitlab.com/releases/2022/03/09/gitlab-14-7-5-released/), +[14.6.6](https://about.gitlab.com/releases/2022/03/02/gitlab-14-6-6-released/) ++ Gerrit Code Review [3.5.1](https://www.gerritcodereview.com/3.5.html#351), +[3.4.4](https://www.gerritcodereview.com/3.4.html#344), +[3.3.10](https://www.gerritcodereview.com/3.3.html#3310), ++ GitHub Enterprise [3.4.0](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.0), +[3.3.5](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.5), +[3.2.10](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.10), +[3.1.18](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.18) ++ GitKraken [8.3.3](https://support.gitkraken.com/release-notes/current), +[8.3.2](https://support.gitkraken.com/release-notes/current), +[8.3.1](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [2.9.12](https://desktop.github.com/release-notes/), +[2.9.11](https://desktop.github.com/release-notes/) ++ Tower for Windows [3.1](https://www.git-tower.com/release-notes/windows) ([What's New in Tower 3.1 for Windows blog post](https://www.git-tower.com/blog/gpg-windows/)) ++ Tower for Mac [8.1](https://www.git-tower.com/release-notes/mac) + + +## Other News + +__Various__ +- [Removed unencrypted Git protocol and certain SSH keys in GitHub](https://github.blog/changelog/2022-03-15-removed-unencrypted-git-protocol-and-certain-ssh-keys/) + (removed all support for DSA keys, removed legacy SSH algorithms HMAC-SHA-1 and CBC ciphers, etc.); + the motivation behind these changes can be found in the + [Improving Git protocol security on GitHub](https://github.blog/2021-09-01-improving-git-protocol-security-github/) + article on GitHub Blog. +- [SSH and Git, meet 1Password](https://blog.1password.com/1password-ssh-agent/): + you can now, among other things, enable the SSH agent in 1Password. +- [Hugging Face uses Gitaly to store Machine Learning related repos](https://discuss.huggingface.co/t/announcement-switching-our-git-infra-to-gitaly/15030). +- [GitLab is hiring to work on Gitaly](https://boards.greenhouse.io/gitlab/jobs/5949673002). + + +__Light reading__ +- [How to Really Use Git: 10 Rules to Make Git More Useful](https://hackernoon.com/how-to-really-use-git-10-rules-to-make-git-more-useful) by Bruno Brito on HackerNoon. +- [Git and GitHub for Marketing Teams](https://www.git-tower.com/blog/git-for-marketing-teams/) by Bruno Brito on Tower's blog. +- [The advantages of large, long-running pull requests](https://world.hey.com/dhh/the-advantages-of-large-long-running-pull-requests-c33d913c) by David Heinemeier Hanson on hey\.com. +- [How Do I Resolve Merge Conflicts?](https://dev.to/github/how-do-i-resolve-merge-conflicts-5438) + (without using graphical tools) by Rizèl Scarlett for GitHub, on DEV\.to. +- [How to Rename a Local or Remote Branch in Git](https://www.freecodecamp.org/news/how-to-rename-a-local-or-remote-branch-in-git/) + by Kolade Chris on freeCodeCamp. +- [Automatically Format your code on Git Commit using Husky, ESLint, Prettier in 9 minutes](https://dev.to/ruppysuppy/automatically-format-your-code-on-git-commit-using-husky-eslint-prettier-in-9-minutes-45eg) + by Tapajyoti Bose on DEV\.to and Medium. +- [How Do Git Branches Work?](https://www.cloudsavvyit.com/14038/how-do-git-branches-work/) + by Anthony Heddings on Cloud Savvy IT. +- [Teamwork & Git](https://www.youtube.com/watch?v=RzYJvSnzlMk): + Dr Max Wilson explains how teams collaborate using Git + in a video on the [Computerphile](https://www.youtube.com/channel/UC9-y-6csu5WGm29I7JiwpnA) + channel on YouTube. + - Links to previous videos in this series can be found in + [Git Rev News Edition #83](https://git.github.io/rev_news/2022/01/31/edition-83/) + and [#84](https://git.github.io/rev_news/2022/02/28/edition-84/). +- [Speeding Up Commit Graph Walks in Dolt with Materialized Ancestor Closures](https://www.dolthub.com/blog/2021-10-15-speeding-up-commit-graph-walks-with-materialized-closures/): + [Dolt](https://www.dolthub.com/) is a [version controlled SQL database](https://www.dolthub.com/blog/2021-09-17-database-version-control/), + first mentioned in [Git Rev News #62](https://git.github.io/rev_news/2020/04/23/edition-62/); + you can find more information about versioning and databases in [edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/). + + +__Git tools and sites__ +* [Kart](https://kartproject.org/) stores geospatial and tabular data in Git, + providing version control at the row and cell level. + It provides repository working copies + as GIS databases and files, + allowing one to edit them directly in common GIS software without plugins. + Support for GeoPackage, PostGIS, Microsoft SQL Server and MySQL formats. +* [split-patch](https://github.com/aleclearmind/split-patch) project consists of + the `split-patch.py` tool, which is `git add -p` on steroids for patches (`*.patch` files), + allowing to choose in which _bucket_ to put each hunk, and + the `git-split-commit` command (which can be used from interactive rebase) + which uses `split-patch.py` to split the HEAD commit into multiple commits. +* [DagsHub](https://dagshub.com/) is a web platform for data version control + and collaboration for data scientists and machine learning engineers. + The free tier provides 10 GB of DAGsHub Storage, + and allows up to 3 collaborators in private projects.
+ See also the following articles: + * [DagsHub: a GitHub Supplement for Data Scientists and ML Engineers](https://towardsdatascience.com/dagshub-a-github-supplement-for-data-scientists-and-ml-engineers-9ecaf49cc505) + by Khuyen Tran in Towards Data Science, a Medium blog. + * [DagsHub → Github for Data Science](https://towardsai.net/p/l/dagshub-%E2%86%92-github-for-data-science) + by Shubham Saboo on Towards AI blog. +* [fds](https://github.com/DAGsHub/fds) (Fast Data Science), + is a CLI for Data Scientists to version control data and code at once, + by conveniently wrapping Git and [DVC](https://dvc.org/). + * DVC (Data Version Control) was first mentioned + in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/). +* [Jujutsu](https://github.com/martinvonz/jj) (`jj`) is an experimental Git-compatible DVCS. + It combines features from Git (data model, speed), + Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), + and Pijul/Darcs (first-class conflicts), with features not found in either of them. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Victoria Dye and Bruno Brito. diff --git a/_posts/2022-04-30-edition-86.markdown b/_posts/2022-04-30-edition-86.markdown new file mode 100644 index 000000000..2cf48c566 --- /dev/null +++ b/_posts/2022-04-30-edition-86.markdown @@ -0,0 +1,283 @@ +--- +title: Git Rev News Edition 86 (April 30th, 2022) +layout: default +date: 2022-04-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 86 (April 30th, 2022) + +Welcome to the 86th 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](https://git.github.io). + +This edition covers what happened during the month of March 2022. + +## Discussions + + + +### Reviews + +* [[PATCH 0/5] Separate `--skip-refresh` from `--quiet` in `reset`, use `--quiet` internally in `stash`](https://lore.kernel.org/git/pull.1170.git.1647043729.gitgitgadget@gmail.com/) + + Victoria Dye sent a 5 patch long series to improve the following: + + - the way the `--quiet` command line options work in `git reset`, + - the way index refreshing is handled in `git reset`, and + - the way the `--quiet` and `--index` command line option work in + `git stash`. + + She had discovered issues with these features when she was working + on tests for the `git stash` sparse index integration. (See Victoria's + interview in last month's + [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/) + for information on Victoria's current work.) She found that + `--quiet` in `git stash` does not suppress all non-error output when + used with `--index`, and that this comes from `reset_head()` being + called without the internal flag corresponding to `--quiet`. + + When calling `reset_head()` with the flag set though, the index + is not refreshed, while `git stash` needs the index to be refreshed. + The underlying issue was that the internal flags related to + `--quiet` and refreshing the index were not independent. + + So the first goal with her patch series was to decouple these + behaviors, and the second goal was to allow `git stash` to + internally use `reset_head()` with the internal flag corresponding + to `--quiet` and to still refresh the index. + + To decouple the behaviors one of her patches introduced the + `--[no-]refresh` option and the corresponding `reset.refresh` config + setting to `git reset`. Derrick Stolee, who prefers to be called + just Stolee, reviewed the patch series and agreed that the changes + in that patch were "well motivated", and otherwise he found that the + "code looks great", and he mostly suggested improvements to the + tests. + + Junio Hamano, the Git maintainer, also agreed that it was a good + idea to separate refreshing from `--quiet`. + + Victoria then sent [a version 2](https://lore.kernel.org/git/pull.1170.v2.git.1647274230.gitgitgadget@gmail.com/) + of her patch series, with improvements to the tests, some commit + messages and the cover letter title. + + Junio then reviewed the patch series and mostly suggested further + improvements to the tests saying that otherwise "everything looked + good", while Stolee was happy with the series as it took into + account all his previous suggestions. + + Victoria then sent [a version 3](https://lore.kernel.org/git/pull.1170.v3.git.1647308982.gitgitgadget@gmail.com/) + of her patch series that added a few more tests and improved some + others. + + Junio and Victoria then discussed the tests a bit more, and Junio + agreed with Victoria's approach. + + Phillip Wood though chimed in a few days later saying that the + approach taken by the patch series, which consisted in still not + refreshing the index by default when `--quiet` was given, was maybe + not the best. He considered that it was a "hack" that had been + introduced for performance reasons before the sparse index feature + was introduced, and that we should take the opportunity to get rid of + it and go back to the original behavior of refreshing the index when + `--quiet` was given. + + Junio agreed with Phillip saying that "he would very much prefer to + see `--quiet` not making a contribution to the decision to refresh or + not in the longer term". He suggested introducing `--no-refresh` to + `git reset` and said he thought `reset.refresh` wasn't a good idea + as it could lead to issues for people using `git reset` in scripts. + + Victoria replied that she agreed with them but wanted to preserve as + much backward compatibility as possible. She said she would gladly + make the change if backwards-compatibility wasn't an issue. She also + asked if `reset.quiet` should be kept as it could also harm people + using `git reset` in scripts. + + As her patch series had already been merged into the `next` branch, + she would send a new series on top deprecating `reset.refresh` and + `reset.quiet`, and making refreshing the default for all modes of `git + reset`. + + Later she indeed sent the first version of + [a 4 patch long series](https://lore.kernel.org/git/pull.1184.git.1647894889.gitgitgadget@gmail.com/) + removing all instances of skipping index refresh in `git reset` + except for `--no-refresh` itself, and removing both `reset.refresh` + and `reset.quiet`. + + Phillip reviewed her new patch series suggesting to allow both + `--no-refresh` and `--refresh` as one patch of the series removed + the latter. He said that `--refresh` could be used to countermand a + previous `--no-refresh` typically when using an alias that includes + `--no-refresh`. He also discussed possible improvements to the + documentation of `--refresh` and to commit messages. + + Victoria then sent + [a version 2 of this new patch series](https://lore.kernel.org/git/pull.1184.v2.git.1648059480.gitgitgadget@gmail.com/) + taking into account Phillip's suggestions. + + Junio liked the changes and agreed to merge the series. Later + though, Phillip suggested that the short help sentence given by `git + reset -h` should be about `--no-refresh` instead of `--refresh` as this + was "the form that users will want most of the time". + + Junio agreed with Phillip's suggestion. He had already merged the + series to `next` though, so he proposed another patch on top + implementing Phillip's suggestion. Victoria tested the patch and + agreed with it. Junio replied he would merge it then. + + All these patches were indeed merged into the master branch before + the recent release of the latest Git 2.36.0, so that in this new Git + version `git reset` and `git stash` handle some of their options in + a much better way. + + + + + +## Releases + ++ Git [2.36.0](https://public-inbox.org/git/xmqqh76qz791.fsf@gitster.g/), +[2.35.3 and below as a usability fix](https://public-inbox.org/git/xmqq1qy04iqa.fsf@gitster.g/), +[2.36.0-rc2](https://public-inbox.org/git/xmqqfsmib5el.fsf@gitster.g/), +[2.35.2 and below for CVE-2022-24765 and CVE-2022-24767](https://public-inbox.org/git/xmqqv8veb5i6.fsf@gitster.g/), +[2.36.0-rc1](https://public-inbox.org/git/xmqqy20fjgpy.fsf@gitster.g/), +[2.36.0-rc0](https://public-inbox.org/git/xmqqo81gpokn.fsf@gitster.g/) ++ Git for Windows [2.36.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.36.0.windows.1), +[2.36.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.36.0-rc2.windows.1), +[2.36.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.36.0-rc1.windows.1), +[2.36.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.36.0-rc0.windows.1), +[2.35.3(1)](https://github.com/git-for-windows/git/releases/tag/v2.35.3.windows.1), +[2.35.2(1)](https://github.com/git-for-windows/git/releases/tag/v2.35.2.windows.1) ++ libgit2 [1.4.3](https://github.com/libgit2/libgit2/releases/tag/v1.4.3) ++ GitHub Enterprise [3.4.2](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.2), +[3.3.7](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.7), +[3.2.12](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.12), +[3.1.20](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.20), +[3.4.1](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.1), +[3.3.6](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.6), +[3.2.11](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.11), +[3.1.19](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.19) ++ GitLab [14.10](https://about.gitlab.com/releases/2022/04/22/gitlab-14-10-released/) +[14.9.3](https://about.gitlab.com/releases/2022/04/12/gitlab-14-9-3-released/), +[14.6.7](https://about.gitlab.com/releases/2022/04/01/gitlab-14-6-7-released/), +[14.9.2, 14.8.5, and 14.7.7](https://about.gitlab.com/releases/2022/03/31/critical-security-release-gitlab-14-9-2-released/) ++ GitKraken [8.4.0](https://support.gitkraken.com/release-notes/current) ++ GitHub Desktop [3.0.0](https://desktop.github.com/release-notes/), +[2.9.15](https://desktop.github.com/release-notes/), +[2.9.14](https://desktop.github.com/release-notes/), +[2.9.13](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + ++ [Git security vulnerability announced](https://github.blog/2022-04-12-git-security-vulnerability-announced/) + by Taylor Blau. + + [The risks of embedded bare repositories in Git](https://lwn.net/Articles/892755/) + by Jake Edge on LWN ([free link for non-subscribers](https://lwn.net/SubscriberLink/892755/a087f0c8092e873e/)). ++ [Highlights from Git 2.36](https://github.blog/2022-04-18-highlights-from-git-2-36/) + by Taylor Blau. ++ [Public open source projects are eligible for Ultimate [GitLab] tier features](https://about.gitlab.com/blog/2022/02/04/ultimate-perks-for-open-source-projects/) + by Orit Golowinski on GitLab blog. ++ [GitHub can now auto-block commits containing API keys, auth tokens](https://www.bleepingcomputer.com/news/security/github-can-now-auto-block-commits-containing-api-keys-auth-tokens/) + by Sergiu Gatlan. + + +__April Fool's__ + ++ [Make a cup of coffee with Git](https://opensource.com/article/22/4/brew-coffee-git-command) + by Moshe Zadka on opensource\.com. ++ [Announcing git snail-mail](https://drewdevault.com/2022/04/01/git-snail-mail.html) + on Drew DeVault's blog... which almost got created for real (though without `git scan-mail` it would require). + + +__Light reading__ + ++ [Securing Developer Tools: Git Integrations](https://blog.sonarsource.com/securing-developer-tools-git-integrations) + by Thomas Chauchefoin on SonarSource blog. ++ [Mac Dev Survey 2022 Results](https://www.git-tower.com/blog/mac-dev-survey-2022-results/) by Kristian Lumme on Tower's blog. ++ [Setting Up Git on Windows Subsystem for Linux](https://www.git-tower.com/blog/git-wsl/) by Bruno Brito on Tower's blog. ++ [How to Clean Up Fully Merged Feature Branches](https://www.git-tower.com/blog/how-to-clean-up-merged-feature-branches/) by Bruno Brito on Tower's blog. ++ [How to Use the Git Stash Command](https://www.freecodecamp.org/news/git-stash-commands/) + by Preethi on freeCodeCamp. ++ [Git Credential Manager: authentication for everyone](https://github.blog/2022-04-07-git-credential-manager-authentication-for-everyone/) + by Matthew John Cheetham on GitHub blog, in [Engineering](https://github.blog/category/engineering/). ++ [The friend zone: friendly forks 101](https://github.blog/2022-04-25-the-friend-zone-friendly-forks-101/) + by Lessley Dennington on GitHub blog, in [Engineering](https://github.blog/category/engineering/) and [Open Source](https://github.blog/category/open-source/). ++ [Handling messy pull-request diffstats](https://lwn.net/Articles/889760/) + by Jonathan Corbet on LWN ([free link for non-subscribers](https://lwn.net/SubscriberLink/889760/1b10fc1d270a0874/)). + + Present in the Linux kernel documentation as [maintainer/messy-diffstat.rst](https://github.com/torvalds/linux/blob/master/Documentation/maintainer/messy-diffstat.rst). ++ [Radicle: a Decentralized Alternative to GitHub for Web3](https://thenewstack.io/radicle-a-decentralized-alternative-to-github-for-web3/) + by Jake Ludington on The New Stack. [Radicle](https://radicle.xyz/) was previously mentioned in + [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/) and [#70](https://git.github.io/rev_news/2020/12/26/edition-70/). ++ [Explaining Git branches with a LEGO analogy](https://opensource.com/article/22/4/git-branches) + by Seth Kenlon on opensource\.com. ++ [Make your own Git subcommands](https://opensource.com/article/22/4/customize-git-subcommands) + by Seth Kenlon on opensource\.com. ++ [How I use the Git `for-each-ref` command for DevOps](https://opensource.com/article/22/4/git-each-ref-command) + by Evan "Hippy" Slatis on opensource\.com. ++ [My guide to understanding Git `rebase -i`](https://opensource.com/article/22/4/manage-git-commits-rebase-i-command) + by Vaishnavi R on opensource\.com. ++ [How to "Undo" Pushed Commits with Git](https://dev.to/github/how-to-undo-pushed-commits-with-git-2pe6) + by Rizèl Scarlett for GitHub on DEV. ++ [5 resources to get your Monorepo off the ground](https://dev.to/mbarzeev/5-resources-to-get-your-monorepo-off-the-ground-3mlp) + by Matti Bar-Zeev on DEV; + + first mention of monorepos in Git Rev News can be found in [edition #4](https://git.github.io/rev_news/2015/06/03/edition-4/), + + most recent mention is the [Monorepo.tools](https://monorepo.tools/) site in [edition #84](https://git.github.io/rev_news/2022/02/28/edition-84/). ++ [Use Git tactically](https://stackoverflow.blog/2022/04/06/use-git-tactically/): + How you can use micro-commits to effectively apply the [Strangler Fig pattern](https://martinfowler.com/bliki/StranglerFigApplication.html), + by Mark Seeman on The Overflow (Stack Overflow blog). ++ [The Programmer's Brain](https://www.infoq.com/presentations/reading-code/) by Felienne Hermans: Why we should be taught to 'read code'. ++ [Working on two git branches at once with git worktree](https://andrewlock.net/working-on-two-git-branches-at-once-with-git-worktree) + by Andrew Lock on andrewlock\.net. + +__Git tools and sites__ + ++ [Building Software Together](https://buildtogether.tech/) is a free online book by Greg Wilson + which aims to teach you how to be a _compassionate programmer_; + it includes two chapters about Git: + + [Chapter 7: Using Git On Your Own](https://buildtogether.tech/git-solo/) + + [Chapter 8: Using Git Together](https://buildtogether.tech/git-team/) ++ [Version Control with Git](https://swcarpentry.github.io/git-novice/index.html) + is a tutorial by the Software Carpentry Foundation. ++ [git-backup](https://github.com/ChappIO/git-backup) is a command-line tool + to pull all your GitHub and GitLab repositories for backup purposes; it doesn't require Git. ++ [gitquickbranch.c](https://dianne.skoll.ca/hacks/gitquickbranch.c) + by Dianne Skoll is a small program in C to quickly find the current branch name. ++ [delta](https://github.com/dandavison/delta) is a syntax-highlighting pager + for git, diff, and grep output. + + It is one of the tools on [Modern Unix tools](https://github.com/ibraheemdev/modern-unix) list, + which is a collection of modern/faster/saner alternatives to common unix commands. ++ [Difftastic](https://github.com/Wilfred/difftastic) + is an experimental diff tool that compares files based on their syntax. + The [manual](https://difftastic.wilfred.me.uk/) includes list of + [some other tree diffing tools available](https://difftastic.wilfred.me.uk/tree_diffing.html). ++ [Vershd](https://vershd.io/) is an [Electron-based](https://www.electronjs.org/apps?q=git) + multi-platform Git GUI, with separate views of branches and their commits, pending files and stashes, + and the ability to show in advance what's going to happen when actions are taken. + Free for, among others, personal use and educational institutions. + If only it's marketing was less FUD-ish + _("Git [...] can easily destroy days of work in just seconds and requires thousands of keyboard commands and parameters")_... ++ [Git for Professionals – Free Version Control Course](https://www.freecodecamp.org/news/git-for-professionals/): + freeCodeCamp intro by Tobias Günther with follow-on more 'Advanced Git Tutorial' sessions, all on YouTube. Plenty of useful tidbits. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Bruno Brito, Brandon Pugh, +Carlo Marcelo Arenas Belón and Philip Oakley. diff --git a/_posts/2022-05-26-edition-87.markdown b/_posts/2022-05-26-edition-87.markdown new file mode 100644 index 000000000..aa2fbb3ee --- /dev/null +++ b/_posts/2022-05-26-edition-87.markdown @@ -0,0 +1,376 @@ +--- +title: Git Rev News Edition 87 (May 26th, 2022) +layout: default +date: 2022-05-26 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 87 (May 26th, 2022) + +Welcome to the 87th 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](https://git.github.io). + +This edition covers what happened during the months of April and May 2022. + +## Discussions + +### General + +* [Git participates in GSoC (Google Summer of Code) 2022](https://summerofcode.withgoogle.com/programs/2022/organizations/git) + + The following three contributors have been officially accepted to + work on Git as part of the + [GSoC 2022](https://summerofcode.withgoogle.com/): + + - Abhradeep Chakraborty will work on the + [Reachability bitmap improvements](https://summerofcode.withgoogle.com/programs/2022/projects/UPtA6qdf) + project. He will be co-mentored by Kaartic Sivaraam and Taylor Blau. + + - Shaoxuan Yuan will work on the + [More Sparse Index Integrations](https://summerofcode.withgoogle.com/programs/2022/projects/hz4rcOUB) + project. He will be co-mentored by Derrick Stolee and Victoria Dye. + + - Jaydeep Das will work on the + [Unify ref-filters with other pretty formats](https://summerofcode.withgoogle.com/programs/2022/projects/8mYcnerl) + project. He will be co-mentored by Hariom Verma and Christian + Couder. His first blog post about it + [is up](https://jdeep.me/posts/6.d/). + + Congratulations to the selected contributors! + + 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! + +* [[ANNOUNCE] git-scm.com Heroku credits update](https://lore.kernel.org/git/YkcmtqcFaO7v1jW5@nand.local/) + + Taylor Blau announced that the Heroku credits for + [git-scm.com](https://git-scm.com), Git project's de facto homepage, + would not be provided for free by Heroku anymore. + + The Git project has so far relied on those free credits from Heroku + and free support from [Cloudflare](https://www.cloudflare.com/) to + have $0 maintenance cost for the site. + + Taylor suggested different options to deal with the change: + + - convert to a static site, so that we don't rely on Heroku and can + be hosted elsewhere hopefully for free, + + - try to reduce our Heroku bill by getting rid of some of the + services we currently use (like database and Ruby on Rails cache), + + - find a cheaper Ruby on Rails host. + + The Heroku credits amount to around $132 per month that are now + billed to Git's account at + [Conservancy](https://sfconservancy.org/), as Git is Conservancy + member, while we "figure out what to do next". + + A few days later, Taylor replied to himself saying that Dan Moore + from [FusionAuth](https://fusionauth.io/) has offered to help assist + with our hosting costs, as FusionAuth, his company, "has benefited + tremendously from Git". + + Git project funds are usually used for things like sponsoring travel + and lodging for Git Merge attendees who could not otherwise make it + in person, so helping for hosting costs is welcome. + + Sponsors for the site are listed on the + [Sponsors section of the about page](https://git-scm.com/site), + so we would just have to list FusionAuth there along with + [Cloudflare](https://www.cloudflare.com/) and + [Bonsai](https://bonsai.io/). + + Dan then replied to Taylor confirming that FusionAuth "would love to + offer [their] monetary support if it makes sense for the community". + + Both Kaartic Sivaraam and Phillip Wood thanked Dan and his company + for their offer, and agreed with Taylor that it would be a good + solution. + + Johannes Schindelin, alias Dscho, also replied to Taylor saying he + would be in favor of converting the site to a static web + site. Taylor then replied to Dscho, explaining some tasks, along + with technical details, that would need to be taken care of for the + conversion. + + Junio Hamano, Taylor and Christian Couder also discussed the idea of + proposing such conversion tasks as a future + [Outreachy](https://www.outreachy.org/) or + [GSoC](https://summerofcode.withgoogle.com) project. + + For now the Git project accepted + [FusionAuth](https://fusionauth.io/)'s generous offer, and the + [git-scm.com](https://git-scm.com) web site will continue to run + in the same way. + + + + + +## Developer Spotlight: Carlo Marcelo Arenas Belón + +* Who are you and what do you do? + + I am a Peruvian hacker who likes to argue he is also "American" to + his neighbours and accidental coworkers/friends in the USA, because + while I flew to get here, and I even crossed an ocean to do so, I + might as well have walked instead. + + To be honest, my close family and probably most of my friends in Perú + would instead call me a "characato" but I am starting to worry I am + getting slightly off-topic here. + + About "what I do", it is a little complicated; I used to call myself a + "server babysitter" until I had a real human one and realized how + inaccurate that was. I usually have a lot of computers around me and + one day realized I might become a cyborg of sorts even if none of them + is strictly connected to me, because AFAIK nobody has figured out how + to do that yet, but again I seem to be going off-topic, because I am + guessing what you really meant is either "what it says in my current + business card" or "what sort of thing I do to contribute to society + that is good enough so I have the means to pay the bills"? + + Well; due to either a series of unfortunate misunderstandings or some + bureaucratic mistake akin to the Vogon Constructor Fleet job that + demolished Earth at the beginning of the Hitchhiker's Guide to the Galaxy, I am + now open to a lot more opportunities to help you do anything, and MUST + do it for free. Hope that is a good answer, but ping me if you would + like some additional explanation. + +* What would you name your most important contribution to Git? + + None. + + I did break Git for macOS once long ago when I was trying to make it + more useful in Linux. Then, I did the same at least once for + Windows after I bought an Apple computer to make sure that + wouldn't happen again and changed my email address so no one would be + able to connect the dots. + + I might have found one bug in Windows that might have redeemed me from + that breakage after I bought a Windows computer for similar reasons + though. + + I did fix Git for Minix after I met Linus Torvalds in a Google + conference and just in spite of him not understanding a funny joke I + made (not a fault of his, I am sure, since I have such a thick accent + I sometimes can't understand myself), but I had yet to upstream the + patches, so maybe that? + + Either way, I am hoping whatever it is, it will be great and might make + my mom or my son proud, even if it is yet to come. + +* What are you doing on the Git project these days, and why? + + Scratching itches and learning from the best, aren't you? + +* 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 sure if it will take a full year, but it would be great to + have a Git conference to get everyone in a room (obviously not while + there is a pandemic, of course). + + Something less ambitious but maybe even more effective would be to get a + virtual hackathon, even though I have to admit realistically a physical + one would be even better. + + It is a shame they don't do the "Linux cruise" anymore, but it might + be also a good format at a much smaller scale and I even remember + reading somewhere that even in a cruise (which usually has terrible + internet connectivity), Git was still useful since you might as well + send patches around in USB drives. + + I guess the first thing to implement in that hackathon might be ZMODEM + transport for git push/pull, and I might be more than happy to make + sure everyone has a working cable to use if they are still lucky + enough to get a computer that has a DB9. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + The bugs, but then even those are fun to have from time to time. + +* What is your favorite Git-related tool/library, outside of Git itself? + + I don't have a favorite, but it is because I just don't know enough to have one. + Luckily you guys have this monthly "magazine" of sorts, so I might be + able to eventually find one. + + It sort of feels as exciting as when I used to go to one private + library in my hometown to read about the latest games in the computer + magazines they had that I might be able to type into that first + computer my parents got for me, that had an 8-bit CPU and 64KB of RAM + (not all of it totally usable though, as it also had a ROM with a + basic interpreter that I think used half of that), but I am not sure. + +* Do you happen to have any memorable experience w\.r\.t\. contributing to the + Git project? If yes, could you share it with us? + + Lots indeed, that is why I sometimes actively try to fix some bugs any + reasonable person would either ignore or at most report. + + My code might be a mess, but I think it is usually better than a bug, + and I get the chance to get to work and learn from people that are way + better than me at fixing them, mostly nicer as well, and especially + way more patient than I would be. + +* How does your mailing list workflow look like? + + What do you mean by workflow? + + (_Editor's note: Here, Carlo jokes about his workflow which according + to him "is a nightmare that is stitched together with masking tape"._) + +* What is your advice for people who want to start Git development? + Where and how should they start? + + My first contribution was probably a real and annoying bug that I + couldn't believe was there, so most people I presume would just + scratch that itch and go away. + + Some might fall in love with the technology, or the community and come + back like I did. + + Regardless of that, there is a lot of wisdom (and luckily for me, + incomplete features or minor bugs) which once you realize this tool is + meant to be used by developers, kind of makes sense. + + The documentation and the list content is pure gold, so take your time + to read as much of it as you can first, if possible. + + Jump straight at it and make sure all the tests and linters are quiet + and try to fight the urge to send it out until you can't improve it + further and let it go. + + Read the feedback you'd get, and try to improve it further based on + that, and iterate. Be patient and take your time. + +* If there's one tip you would like to share with other Git developers, + what would it be? + + Don't Panic. + +## Releases + ++ Git [2.36.1](https://public-inbox.org/git/xmqqczgqmv0f.fsf@gitster.g/) ++ Git for Windows [2.36.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.36.1.windows.1) ++ GitLab [15.0](https://about.gitlab.com/releases/2022/05/22/gitlab-15-0-released/) +[14.10.3](https://about.gitlab.com/releases/2022/05/16/gitlab-14-10-3-released/), +[14.10.2](https://about.gitlab.com/releases/2022/05/05/gitlab-14-10-2-released/), +[14.10.1, 14.9.4, and 14.8.6](https://about.gitlab.com/releases/2022/05/02/security-release-gitlab-14-10-1-released/) ++ Gerrit Code Review [3.3.11](https://www.gerritcodereview.com/3.3.html#3311), +[3.4.5](https://www.gerritcodereview.com/3.4.html#345), +[3.5.2](https://www.gerritcodereview.com/3.5.html#352) and +[3.6.0](https://www.gerritcodereview.com/3.6.html#360) ++ GitHub Enterprise [3.5.0](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.0), +[3.4.3](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.3), +[3.3.8](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.8), +[3.2.13](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.13), +[3.1.21](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.21) ++ GitKraken [8.5.0](https://support.gitkraken.com/release-notes/current) ++ Tower for Windows [3.2](https://www.git-tower.com/release-notes/windows) + +## Other News + + + +__Light reading__ + ++ [An overview of version control in programming](https://lemire.me/blog/2022/04/21/an-overview-of-version-control-in-programming/) + by Daniel Lemire on his blog. ++ [Revisiting the Pain: The World without Git](https://dev.to/kcdchennai/revisiting-the-pain-the-world-without-git-3jod) + by Sneh Chauhan for Kubernetes Community Days Chennai on DEV\.to. + + Compare [The Git Parable](http://tom.preston-werner.com/2009/05/19/the-git-parable.html), + by Tom Preston-Werner (2009) - the ideas behind the architecture of Git; + covered in [Git Rev News #30](https://git.github.io/rev_news/2017/08/16/edition-30/). ++ [Mastering Tower (Mac Edition)](https://www.git-tower.com/blog/mastering-tower/) by Bruno Brito on Tower's blog. ++ [Mastering Tower for Mac — 40 Tips in under 10 Minutes](https://youtu.be/OChAwMBLjnY) video by Bruno Brito. ++ [Git Commit Message Template in Terminal and VS Code](https://dev.to/abbeyperini/git-commit-message-template-in-terminal-and-vs-code-326p) + by Abbey Perini on DEV\.to. This article refers to: + + [How to Write a Git Commit Message](https://cbea.ms/git-commit/) (2014), which appeared in + [Git Rev News Edition #24](https://git.github.io/rev_news/2017/02/22/edition-24/). + + [Conventional Commits specification](https://www.conventionalcommits.org/), first appearing in + [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/). ++ [A Guide to writing Industry Standard Git Commit Message](https://dev.to/tuasegun/a-guide-to-writing-industry-standard-git-commit-message-2ohl) + by Tuasegun on DEV\.to. ++ [Your Git Commit History Should Read Like a History Book. Here’s How.](https://betterprogramming.pub/your-git-commit-history-should-read-like-a-history-book-heres-how-7f44d5df1801) + by Mirco, on Better Programming, a Medium blog (member-only story). ++ [Automatically formatting and cleaning code on commit](https://blogs.halodoc.io/automatically-formatting-and-beautifying-code-on-commit/) + by Muhammad Sibra on Halodoc. + + This article mentions [husky](https://typicode.github.io/husky/#/), + which was first included in [Git Rev News #63](https://git.github.io/rev_news/2020/05/28/edition-63/), + and [lint-staged](https://www.npmjs.com/package/lint-staged), + first mentioned in [Git Rev News #45](https://git.github.io/rev_news/2018/11/21/edition-45/). ++ [Squash \[merge\] commits considered harmful](https://dev.to/wesen/squash-commits-considered-harmful-ob1) + by Manuel Odendahl on DEV\.to. ++ [Can You Resolve Merge Conflicts Before They Happen?](https://dev.to/benjamincohen123/can-you-resolve-merge-conflicts-before-they-happen-46nd) + by Benjamin C. Baker on DEV\.to describes how to resolve merge conflicts manually, + and how one can detect potential conflicts in advance with the [GitLive](https://git.live/) extension. + GitLive was mentioned in [Git Rev News Edition #77](https://git.github.io/rev_news/2021/07/31/edition-77/) + and [#82](https://git.github.io/rev_news/2021/12/30/edition-82/). ++ [How to Resolve Merge Conflicts in Git – A Practical Guide with Examples](https://www.freecodecamp.org/news/resolve-merge-conflicts-in-git-a-practical-guide/) + by Tapas Adhikary on freeCodeCamp. ++ [Arduino and Git: Two Views](https://hackaday.com/2022/04/29/arduino-and-git-two-views/) + by Al Williams on Hackaday. ++ [Why SQLite Does Not Use Git](https://sqlite.org/whynotgit.html) but [Fossil](https://fossil-scm.org/) + (a version control system that was specifically designed and written to support SQLite). + An article about Fossil did appear in [Git Rev News Edition #11](https://git.github.io/rev_news/2016/01/13/edition-11/), + but is nowadays unavailable except through the [Internet Archive](https://web.archive.org/web/20160304055320/https://blog.kotur.org/posts/fossil-keeps-more-than-just-your-code.html). ++ [Rename rebase with git](https://edofic.com/posts/2020-04-20-rebase-rename/) (2020), + or how to perform a `git rebase` in which you rename a file without conflicts -- though + nowadays one would use [`git filter-repo`](https://github.com/newren/git-filter-repo) + instead of `git filter-branch` as in the article. + Post on Andraž Bajt's blog. ++ [Repairing a corrupt Git repo using a clone](https://edofic.com/posts/2016-02-24-git-repair/) (2016) + on Andraž Bajt's blog. + + +__Git tools and sites__ + ++ [Commit Message Editor](https://marketplace.visualstudio.com/items?itemName=adam-bender.commit-message-editor) + plugin for Visual Studio Code, by Adam Bender. + The default settings follow the Conventional Commits specification. ++ [VSCode Git Commit Message](https://marketplace.visualstudio.com/items?itemName=rioukkevin.vscode-git-commit) + plugin for Visual Studio Code, by Kévin Riouk. + An extension made to formalize git commit messages. ++ [Mergify](https://mergify.com/) is a web service for + automatizing pull requests and securing the code merge using a merge queue. + Free for open-source. + + [Merging Pull Requests Like a Pro With Mergify](https://dev.to/aniket762/merging-pull-requests-like-a-pro-with-mergify-30fa) + by Aniket Pal on DEV\.to. ++ [Mani](https://github.com/alajmo/mani) is a CLI tool that helps you manage multiple repositories. + + [mani, a CLI Tool to Manage Multiple Repositories](https://dev.to/alajmo/mani-a-cli-tool-to-manage-multiple-repositories-1eg) + by Samir Alajmovic on DEV\.to. The article includes list of + [alternatives](https://dev.to/alajmo/mani-a-cli-tool-to-manage-multiple-repositories-1eg#alternatives). ++ [Fig](https://fig.io/) adds IDE-style autocomplete (including for git, cd, ssh) + to your existing terminal (macOS Terminal, iTerm, Hyper, Tabby, Kitty, bash, zsh, ...). ++ [JSON Patch](http://jsonpatch.com/) is a format for describing changes to a JSON document + as a JSON document itself. Specified in [RFC 6902](https://datatracker.ietf.org/doc/html/rfc6902/). ++ [sqldiff.exe](https://www.sqlite.org/sqldiff.html) is a command-line utility program (Windows binary) + that displays content differences between two [SQLite](https://www.sqlite.org/) databases. ++ [Gitcoin (GTC)](https://gitcoin.co/) is a Web3 platform which combines + open-source programming projects with an Ethereum-based crypto payment system. + _In spite of its name it has no connection with Git._ + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Carlo Marcelo Arenas Belón, Bruno Brito and Luca +Milanesio. diff --git a/_posts/2022-06-30-edition-88.markdown b/_posts/2022-06-30-edition-88.markdown new file mode 100644 index 000000000..02bd0c837 --- /dev/null +++ b/_posts/2022-06-30-edition-88.markdown @@ -0,0 +1,253 @@ +--- +title: Git Rev News Edition 88 (June 30th, 2022) +layout: default +date: 2022-06-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 88 (June 30th, 2022) + +Welcome to the 88th 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](https://git.github.io). + +This edition covers what happened during the months of May and June 2022. + +## Discussions + +### General + +* [Google Summer of Code](https://summerofcode.withgoogle.com) + contributors working on Git are now in the ["Coding Period"](https://developers.google.com/open-source/gsoc/timeline#june_13) + (from June 13 to September 19) of the program and have posted at least + once on their blogs: + + - Abhradeep Chakraborty, who works on + ["Reachability bitmap improvements"](https://summerofcode.withgoogle.com/programs/2022/projects/UPtA6qdf), + has published [his latest post](https://medium.com/@abhra303/gsoc-week-2-redesign-the-table-format-829dae755a5) + on [his Medium blog](https://medium.com/@abhra303). + + - Shaoxuan Yuan, who works on ["More Sparse Index Integrations"](https://summerofcode.withgoogle.com/programs/2022/projects/hz4rcOUB) + has published [his latest post](https://ffyuanda.github.io/blog/GSoC-week-2/) + on [his website](https://ffyuanda.github.io/). + + - Jaydeep Das, who works on ["Unify ref-filters with other pretty formats"](https://summerofcode.withgoogle.com/programs/2022/projects/8mYcnerl) + has published [his latest post](https://jdeep.me/posts/10.d/) + on [his website](https://jdeep.me/posts/). + + + +### Support + +* [Bug in merge-ort (rename detection can have collisions?)](https://public-inbox.org/git/kl6lee006mle.fsf@chooglen-macbookpro.roam.corp.google.com/) + + Glen Choo reported on the mailing list that `git merge` was failing + on certain branches of a repo used at his workplace. As the repo is + a public one, Glen was able to share the full recipe to reproduce the bug. + + When following it, this error appears: + + `Assertion failed: (ci->filemask == 2 || ci->filemask == 4), function apply_directory_rename_modifications, file merge-ort.c, line 2410.` + + Glen noticed that the bug seemed to be specific to the "ort" merge + strategy, which became the default merge strategy in Git 2.34.0 + released last November. When using the "recursive" strategy, + which used to be the default merge strategy before "ort" took over, + the merge seemed to work as expected. + + Glen also tried to debug the issue by himself and found that the + reason for the assertion failure seemed to be that two files + involved in the merge were renames of each other. + + Elijah Newren, who developed the new "ort" strategy, thanked Glen + for the detailed report, and said that he found a small reproduction + recipe to simplify what's going on. He explained it with the + following sequence: + +``` +# Commit O: sub1/file, sub2/other +# Commit A: sub3/file, sub2/{other, new_add_add_file_1} +# Commit B: sub1/{file, newfile}, sub1/sub2/{other, new_add_add_file_2} +# +# In words: +# A: sub1/ -> sub3/, add sub2/new_add_add_file_1 +# B: sub2/ -> sub1/sub2, add sub1/newfile, add sub1/sub2/new_add_add_file_2 +``` + + He noted, though, that he can also trigger a different fatal error + in the "ort" strategy with a small tweak to the test setup, and can + also trigger that same other fatal error in the "recursive" strategy + with his test cases. + + He then explained that both the "ort" and "recursive" merge + strategies have code to avoid "doubly transitive [directory] + renames". Such renames happen when, for example, on one side of the + merge a directory named "A" is renamed to "B", while on the other + side "B" is renamed to "C". + + However, the code to avoid "doubly transitive [directory] renames" is + fooled when a parent directory of a directory is renamed. For + example if on one side a directory named "A" is renamed to "B", + while on the other side a leading directory of "B" is renamed to + "C". That still wouldn't be quite enough to trigger this + bug, though. It also requires adding a file into directory A on one + side and a file with the same name into directory B on the other. + + Junio Hamano, the Git maintainer, thanked Elijah for his continued + support of the merge strategy, and noticed that at least the code was + not "making a silent mismerge" in this special case, and that the + recursive strategy could be used as a fallback. + + Elijah replied that he was glad the recursive strategy worked for + Glen but noted that it didn't work with his minimal reproduction + test case, which suggests it's less reliable as a fallback than one + might hope. + + Glen then wondered if turning off rename detection could help in + case of merges with complex renames like this, but Elijah pointed + out [that might be more problematic than + helpful](https://lore.kernel.org/git/CABPp-BGN0DoSr3bcjTmGZkcoj_dSVzOgFUQ++R=_z8v=nAJsTg@mail.gmail.com/), + particularly since this case had a very large number of renames and + users tend to have difficulty correctly resolving the conflicts that + result from a lack of rename detection. However, he suggested that + if turning off rename detection was really wanted that one could use + the "resolve" strategy instead, which "is roughly the recursive strategy + minus the renames and the multiple merge base handling". + + Elijah also posted [a small patch + series](https://lore.kernel.org/git/pull.1268.git.1655871651.gitgitgadget@gmail.com/) + that adds test cases demonstrating the bug Glen found and the + related ones he found based on it, and fixes the bugs in the ort + strategy. (The recursive strategy is deprecated, and the bugs noted + here are not security critical.) + + Jonathan Tan reviewed the series and verified that it indeed fixes + Glen's test case. Calvin Wan also commented on the patch series. So + there is good hope that after a few iterations to polish the series + the bugs will be fixed soon. + + + +## Releases + ++ Git [2.37.0](https://public-inbox.org/git/xmqqy1xinf00.fsf@gitster.g/), +[2.37.0-rc2](https://public-inbox.org/git/xmqqedzg4hqj.fsf@gitster.g/), +[2.37.0-rc1](https://public-inbox.org/git/xmqqv8syloqp.fsf@gitster.g/), +[2.37.0-rc0](https://public-inbox.org/git/xmqqwndk10gg.fsf@gitster.g/) ++ Git for Windows [2.37.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.37.0.windows.1), +[2.37.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.37.0-rc2.windows.1), +[2.37.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.37.0-rc1.windows.1), +[2.37.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.37.0-rc0.windows.1) ++ Bitbucket Server [8.2](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.6.1](https://www.gerritcodereview.com/3.6.html#361) ++ GitHub Enterprise [3.5.1](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.1), +[3.4.4](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.4), +[3.3.9](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.9), +[3.2.14](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.14), +[3.1.22](https://help.github.com/enterprise-server@3.1/admin/release-notes#3.1.22) ++ GitLab [15.1](https://about.gitlab.com/releases/2022/06/22/gitlab-15-1-released/) +[15.0.3](https://about.gitlab.com/releases/2022/06/16/gitlab-15-0-3-released/), +[15.0.2](https://about.gitlab.com/releases/2022/06/06/gitlab-15-0-2-released/), +[15.0.1, 14.10.4, and 14.9.5](https://about.gitlab.com/releases/2022/06/01/critical-security-release-gitlab-15-0-1-released/) ++ GitHub Desktop [3.0.3](https://desktop.github.com/release-notes/), +[3.0.2](https://desktop.github.com/release-notes/), +[3.0.1](https://desktop.github.com/release-notes/) ++ Tower for Mac [8.3](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) ++ Tower for Windows [3.3](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) + +## Other News +__Events__ ++ [Git Merge 2022](https://github.blog/2022-06-15-git-merge-2022/) + by Lee Reilly on GitHub blog. + [Git Merge](http://git-merge.com/), the conference dedicated to bringing the Git community together, + returns on September 14-15 in Chicago, Illinois, USA. + [Call for Speakers](https://sessionize.com/git-merge-2022) is open through Sunday, July 10. + +__Various__ ++ [Highlights from Git 2.37](https://github.blog/2022-06-27-highlights-from-git-2-37/) + by Taylor Blau on GitHub's blog. ++ [v2.37.0 highlights video](https://www.youtube.com/watch?v=c1VdZq77i70) by GitKraken. ++ [How Atlassian made Git push over HTTPS faster for Bitbucket Cloud](https://www.atlassian.com/engineering/faster-git-push-over-https-for-bitbucket-cloud) + by Brent Thew on [Atlassian Engineering](https://www.atlassian.com/engineering) blog. ++ [Why We’re Sticking with Ruby on Rails at GitLab](https://thenewstack.io/why-were-sticking-with-ruby-on-rails-at-gitlab/) + by Sid Sijbrandij on The New Stack (contributed post, sponsored by GitLab). ++ [Improved verification of historic Git commit signatures \[in GitHub\]](https://github.blog/changelog/2022-05-31-improved-verification-of-historic-git-commit-signatures/) + with respect to public GPG signing keys that are expired or revoked (but not compromised). ++ [AppSmith Adds Git Support to Low-Code App Dev Framework](https://devops.com/appsmith-adds-git-support-to-low-code-app-dev-framework/) + by Mike Vizard on DevOps\.com. ++ [Improve Git monorepo performance with a file system monitor](https://github.blog/2022-06-29-improve-git-monorepo-performance-with-a-file-system-monitor/) + by Jeff Hostetler on GitHub's blog. + +__Light reading__ ++ [Improvements in git 2.37 when resolving conflicts with vimdiff](https://u92.eu/blog/git-vimdiff/) + describes a change in Git 2.37 w.r.t. vimdiff mergetool drivers. ++ [Better File Comparison with Kaleidoscope](https://www.git-tower.com/blog/kaleidoscope/) by Bruno Brito on Tower’s blog. ++ [Working with Feature Branches](https://www.git-tower.com/blog/working-with-feature-branches/) by Bruno Brito on Tower’s blog. ++ [Coming Up on Tower's Roadmap](https://www.git-tower.com/blog/coming-up-on-the-roadmap-2022/) by Bruno Brito on Tower’s blog. ++ [The Three Phases of Software Development](https://www.git-tower.com/blog/three-phases-of-software-development/) by Kristian Lumme on Tower’s blog. ++ [Best practices for Git branching](https://blogs.halodoc.io/best-practices-for-git/), + describing Git flow at Halodoc, by Ashish Anand. ++ [How to Recover a Deleted File in Git – Revert Changes After a Hard Reset](https://www.freecodecamp.org/news/how-to-recover-a-deleted-file-in-git/) + by Zaira Hira on freeCodeCamp. ++ [Git List Remote Branches](https://www.freecodecamp.org/news/git-list-remote-branches/) + by Quincy Larson on freeCodeCamp. ++ [Replacing Your Git Command Cheat Sheet With AI Command Search](https://www.warp.dev/blog/replace-git-cheat-sheet-ai-command-search) + by Jessica Wang on Warp blog; uses [Warp's AI Command search](https://docs.warp.dev/features/ai-command-search#:~:text=Press%20CTRL%2D%60%20to%20open,ENTER%20to%20generate%20the%20command.). ++ [We Put Half a Million files in One git (Mono-)Repository, Here’s What We Learned](https://canvatechblog.com/we-put-half-a-million-files-in-one-git-repository-heres-what-we-learned-ec734a764181) + by Ahn Lee in Canva Engineering Blog (a Medium-based blog). + + See also, for example, articles on [Developer Homepage of Derrick Stolee](https://stolee.dev/), + including [The Future of Git at Scale](https://www.youtube.com/watch?v=pXdabSCz4JA) 2021 presentation + ([slides](https://stolee.dev/docs/universe-2020.pdf) available), + a survey of some advanced Git features to help Git scale to the largest monorepos. ++ [Reducing the size of a git repository with git-replace](https://andrewlock.net/reducing-the-size-of-a-git-repository-with-git-replace/) + by Andrew Lock on andrewlock\.net, where repository is split into + a small "current" repository containing a minimal amount of history, and + a "history" repository containing all the commits prior to the creation of the new repository, + stitched together when needed with git-replace. ++ [How to Prevent Merge Conflicts (or at least have less of them)](https://blackgirlbytes.dev/how-to-prevent-merge-conflicts) + by Rizèl Scarlett, featured on daily.dev ([also on DEV.to](https://dev.to/github/how-to-prevent-merge-conflicts-or-at-least-have-less-of-them-109p)). + It is the last part + of 3 part [Intro to Git](https://dev.to/blackgirlbytes/series/17601) series on DEV\.to, + beginning with [How Do I Resolve Merge Conflicts?](https://dev.to/github/how-do-i-resolve-merge-conflicts-5438). ++ [People rarely use complicated git commands on the weekend, and I have the data to prove it.](https://dev.to/devteam/people-rarely-use-complicated-git-commands-on-the-weekend-and-i-have-the-data-to-prove-it-3ae2) + by Ben Halpern for The DEV Team on DEV\.to. ++ [How Git truly works](https://towardsdatascience.com/how-git-truly-works-cd9c375966f6) + by Alberto Prospero in Towards Data Science (a Medium-based blog). ++ [Sourceware – GNU Toolchain Infrastructure roadmap](https://gnu.wildebeest.org/blog/mjw/2022/06/22/sourceware-gnu-toolchain-infrastructure-roadmap/) + by Mark J. Wielaard + +__Git tools and sites__ ++ [Sourceware](https://sourceware.org/) is community run infrastructure, mailing lists, + git, bug trackers, wikis, etc. hosted in the Red Hat Open Source + [Community Infrastructure Community Cage](https://osci.io/tenants/). + Uses [shared buildbot](https://builder.sourceware.org/) for (test) automation, + and [patchwork](https://patchwork.sourceware.org/) for tracking the state of contributions; + most tests upload all results to [bunsendb](https://sourceware.org/git/bunsendb.git). + Uses mirror at SourceHut, , for web forge. ++ [unix-history-repo](https://github.com/dspinellis/unix-history-repo) is a repository + representing a reconstructed version of the Unix history from 1970 until today, + based on the currently available data. Note that this repository will be often + automatically regenerated from scratch. ++ [git-repair](http://git-repair.branchable.com/) can repair various forms of damage to Git repositories; + a complement to `git fsck`, which finds problems, but does not fix them. + It is a Haskell program, + developed as a spinoff of [git-annex](http://git-annex.branchable.com/) (for large files management). ++ [Rich Enhanced Shell History (resh)](https://github.com/curusarn/resh) + provides contextual shell history for zsh and bash, + where relevant results are based on current directory, _git repo_, exit status, and host. + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Bruno Brito, Elijah Newren, Matheus Tavares +and Johannes Schindelin. diff --git a/_posts/2022-07-31-edition-89.markdown b/_posts/2022-07-31-edition-89.markdown new file mode 100644 index 000000000..6350ced9d --- /dev/null +++ b/_posts/2022-07-31-edition-89.markdown @@ -0,0 +1,435 @@ +--- +title: Git Rev News Edition 89 (July 31st, 2022) +layout: default +date: 2022-07-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 89 (July 31st, 2022) + +Welcome to the 89th 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](https://git.github.io). + +This edition covers what happened during the month of July 2022. + +## Discussions + + + + + + +### Support + +* [[BUG?] Major performance issue with some commands on our repo's master branch](https://public-inbox.org/git/87h750q1b9.fsf@gnu.org/) + + Tassilo Horn sent a long email to the mailing list saying that while + writing the email he found a solution to his problem, and that he + tells about that solution at the end of the email. + + He then explained that he works on a quite big repo where usual + commands were all quick, but some plumbing commands invoked by + [Magit](https://magit.vc/) were "extremely slow for no obvious + reasons". + + He found that: + + `git show --no-patch --format="%h %s" "master^{commit}" --` + + took around 13 seconds, while: + + `git show --no-patch --format="%h %s" "SHD_ECORO_3_9_7^{commit}" --` + + took around 23 milliseconds. + + So there was almost a factor of 1000 difference when the same command + was launched on the master branch or on the last release branch. + + He suspected that the difference could have something to do with the + fact that there had been a lot of merges recently in master. + + The solution he found while writing the email was to comment out the + `diff.renameLimit = 10000` he had in his `~/.gitconfig` file. This + reduced the time for the first command above from 13 seconds to 150 + milliseconds. + + Tassilo wondered though why `diff.renameLimit` had such an + influence, as, when `--no-patch` is provided, no diff should be + generated. + + Tao Klerks replied to Tassilo that he used to use `git show` to get + metadata from a big repo as the command allows specifying an + arbitrary list of commits in one call which can save process + overhead on Windows. He stopped using `git show` though after it had been + reported to be slow. Instead he switched to `git log` and accepted + some process overhead, as it solved his problem. + + He found that large commits and merge commits with a + number of changes on any side were slow despite using + `--no-patch`. And Tassilo's email made him suspect that it could be + linked to rename detection. + + Tassilo replied to Tao that using `git log` also + [solved his problem](https://github.com/magit/magit/commit/d0efb5ffff0b1d4e681f08ff64afbf1ab3257230) + but that someone might want to do something to fix `git show` when + no diff was generated. + + Tao replied that he found that adding `--diff-merges=off` to the + `git show --no-patch ...` command made it perform as fast as + `git log`. So he could now combine the performance of `git log` + with passing an arbitrary list of commits that `git show` allowed. + + Peff, alias Jeff King, also replied to Tassilo that `git show` might + in some cases need underlying diffs even if `--no-patch` is + requested, while `git log` might need them too, but not when looking + at merges. Peff wondered if the code could be changed to detect when + underlying diffs aren't needed, but thought that it could make the + code "a bit brittle". + + Kyle Meyer then asked Peff if making `--no-patch` imply + `--diff-merges=off` was safe, as Tao suggested, and showed benchmarks + on the git.git repo where it was nearly 15 times faster with + `--diff-merges=off`. + + Peff replied that he wasn't sure it would be safe and gave an + example of a `git show` command using `--diff-filter=D` where the output + changes when diff merges are suppressed as the commit isn't showed + then. He suggested a mode skipping the diff when it's not shown but + always showing the commit. He said that it would require someone + verifying it does the right thing in all cases though. + + Junio Hamano, the Git maintainer, chimed in to agree with Peff that + making `--no-patch` imply `--diff-merges=off` would cause a + regression, and mentioned other `git show` options where the output + could be affected. + + Junio also elaborated on Peff's idea of a mode skipping the diff + when it's not shown but always showing the commit. He suggested an + explicit `git show --log-only` option and mentioned a few ways to + make it work regarding other options. + + Peff and Junio discussed the idea a bit more, but it doesn't look + like something will be implemented soon. + + Tassilo and Peff also discussed the `diff.renameLimit` option a bit. + It looks like Tassilo would like to set it to a high value + only in some contexts, though the current config might not be + sufficient to express that. + +## Developer Spotlight: Junio C Hamano + +* Who are you and what do you do? + + I am an open source toolsmith, who works at Open Source Program + Office (OSPO) at Google. I work as the maintainer of Git. + + +* How has your journey with Git as its maintainer been so far? + + I have worked with many contributors since 2005, and seeing so many + of them grow into excellent developers as they work on this project + was a joy. + + +* How does your work as the maintainer of the Git project look like? + + Unlike earlier days, I no longer have to be in the driver's seat to + design or implement a big feature, and luckily there are + multiple groups of people who do excellent job dreaming up new + ways to use Git and make it a reality. My best days start by + getting greeted by a surprisingly good proposal of a new feature or + optimization of an existing feature, and the entire day is spent on + reviewing them. It happens less often these days, but they still do + occasionally. + + On my normal days, I scan the mailing list for patches and + discussions. My goal is to at least open every one of incoming + messages, and read carefully at least half of the patches I pick up + to queue on the 'seen' branch, which means that I may be queuing the + other half without carefully reading, trusting the reviews already + done by other members of the community. + + I aim to finish picking up new topics, replacing existing topics, + and generally interacting with the mailing list, by around 2pm. + Then I rebuild the 'seen' topic, rewrite the latest draft of "What's + cooking" report (which is the guide to choose which topics + will go to the 'next' branch), and push out the first integration + result of the day by 4pm. After that, I merge the topics that + have cooked long enough in 'next' to 'master', and the topics that + have been adequately reviewed to 'next'. The 'seen' and 'next' + branches are rebuilt, the "What's cooking" report is rewritten, and + the second integration result of the day gets pushed out, before I + call it a day. + + +* If there's anything you would like to say to your past self, what + would that be? + + Study math and algorithms harder, perhaps. I know them well enough + to get around, but it is primarily because there are so many other + community members who are good at them that I can rely on, so I do + not have to get involved in details that are too deep for me. + + +* What would you name your most important contribution to Git? + + There are too many to list in the design and implementation of the + internals, but in the end, I think what mattered to the project most + was that I was consistently there, available to help guide the + project. + + While it may not be a particularly "important contribution", my most favorite + creation is `git rerere`. It was fun to design, work on, and (most + importantly) name it. + + +* 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 interoperability between SHA-1 and SHA-256 repositories first + comes to mind. The ingredients are almost all there, so are rough + designs. + + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + I generally think that the hacks to lie to the object layer, like + "grafts" and "replace" mechanisms, and "alternate" object store, + were not great ideas. There aren't all that many that I would + remove, but there are too many that I wish we could redo entirely + without backward compatibility issues (e.g. path ordering in the + index). + + +* What is your favorite Git-related tool/library, outside of Git itself? + + My recent favorites are Eric's "public-inbox", which powers the + https://lore.kernel.org/git mailing list archive, and Konstantin's + "b4" that helps to interact with the lore archive better. + + +* What is your advice for people who want to start Git development? + Where and how should they start? + + That depends on why they want to do so. Do they not like the way + the tool currently works and they want to change it? Are they happy + with Git but they feel they do not know enough of it and are curious + about how things work? For the former folks, the usual "scratch + your itch" advice would work well to a certain extent. For the latter + folks, their "itch" can be to try to figure out how one of their + favorite subcommand works, and then perhaps clean up or optimize + the code paths they studied. Following what our test scripts are + doing to your favorite feature may be a great way to learn them, too. + + Either way, while identifying and scratching their "itch", I'd + recommend they lurk on the mailing list for at least a few weeks, + and starting early is good. Learn by reading others' patches being + discussed, the kind of things the reviewers are interested in, and + how the development process works. See who is active and how the + discussion goes. These social conventions, how our developers work + with others, are just as important as, if not more than, technical + details. The "MyFirstContribution" document may also be a good place to + start. + + +* How does your mailing list workflow look like? + + I try not to be the first to comment on any new topic (unless the + topic gains no attention from anybody, yet it looks worth commenting + on, which sometimes happens). This is because other members of the + community may offer interesting viewpoints that I would not hear + (and think of myself) if I spoke first. + + My ideal is that a topic gets discussed without me for a few rounds + and by the time I feel like taking a look myself, it is already + quite ready, thanks to the help from competent reviewers (which + happens quite often). Then I can pick it up and queue almost + directly to 'next' (in practice, I'd first merge it to 'seen' to + ensure that there is no funny interactions with existing topics in + the first integration cycle of the day that happens before 2pm, and + then merge it down to 'next' in the second integration cycle of the + day, or perhaps the day after). + + As I cannot keep track of all the things said in the discussion on + all topics, I make heavy use of the lore archive and use the draft + of "What's cooking" report to take notes on each topic's current + status. So, the workflow is + + 1. to notice a new topic, whose merit is either obvious to see or + others reviews helped to highlight, and queue it to 'seen', + while sending comments to them, + + 2. record the topic in the "What's cooking" draft, + + 3. to observe the discussion on the topic, perhaps taking a reroll + and replacing the copy I have, + + 4. send out an updated "What's cooking", possibly the topic marked + for promotion, + + 5. go back to (3) + + until each topic graduates to 'master'. + + +* If there's one tip you would like to share with other Git + developers, what would it be? + + It is very easy to be too strongly married to your initial solution + and become blind to the merits of other approaches suggested in the + discussion by others, or accept a possible reframing of the original + problem to solve a wider problem. + + In the very early days of Git, before Linus passed the project's + maintainership to me, I also had a "competitive" manner in a bad + way. There were plenty of problems to be solved, and it felt as if + people competed to be the first to offer a solution to each of them. + When I had an idea to solve a problem that others were also + interested in, sometimes it felt like I had to "beat" + them, which meant that I had to send out patches even before they are well + reasoned and well explained enough. Luckily, being maintainer means + I no longer have to compete with others. Instead I can set the pace of + the project. After having lived in such a "competitive" way for a + few months and saw its downsides, I learned to give contributors time + to think things through and wait for counter-proposals. + + So, one "tip" is to take things slowly. Be ready to step back, take + a deep breath and take time to rethink the problem, together with + those in the discussion. You'd end up working well with the others + that way. + + +## Releases + ++ Git [2.37.1 and others](https://public-inbox.org/git/xmqqv8s2fefi.fsf@gitster.g/) ++ Git for Windows [2.37.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.37.1.windows.1) ++ libgit2 [1.5.0](https://github.com/libgit2/libgit2/releases/tag/v1.5.0), +[1.4.4](https://github.com/libgit2/libgit2/releases/tag/v1.4.4) ++ GitHub Enterprise [3.6.0](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.0), +[3.5.3](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.3), +[3.4.6](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.6), +[3.3.11](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.11), +[3.2.16](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.16), +[3.5.2](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.2), +[3.4.5](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.5), +[3.3.10](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.10), +[3.2.15](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.15) ++ GitLab [15.2.1, 15.1.4, and 15.0.5](https://about.gitlab.com/releases/2022/07/28/security-release-gitlab-15-2-1-released/) +[15.2](https://about.gitlab.com/releases/2022/07/22/gitlab-15-2-released/), +[15.1.3](https://about.gitlab.com/releases/2022/07/19/gitlab-15-1-3-released/), +[15.1.2](https://about.gitlab.com/releases/2022/07/04/gitlab-15-1-2-released/), +[15.1.1](https://about.gitlab.com/releases/2022/06/30/critical-security-release-gitlab-15-1-1-released/) ++ GitHub Desktop [3.0.5](https://desktop.github.com/release-notes/), +[3.0.4](https://desktop.github.com/release-notes/) ++ Sourcetree [4.1.9](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.1.9.html) + +## Other News + +__Various__ ++ [Contributor's Summit Registration details](https://public-inbox.org/git/YtRqU5rAOsLw5s03@nand.local/) have been posted by Taylor Blau. As usual the Summit will happen the day before the main conference day of the [Git Merge](https://git-merge.com/) and very close to it. ++ [GitLive 15.0: Offline merge conflict detection across all branches for any Git repository and more](https://blog.git.live/gitlive-15.0-offline-merge-conflict-detection-across-all-branches-for-any-git-repository) + by Agnieszka Stec. ++ Iterative\.AI, authors of the [DVC](https://dvc.org/) Data Version Control tool + (first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/)), + bring [Git-backed Machine Learning Model Registry](https://dvc.org/blog/iterative-studio-model-registry) + to [Iterative Studio](https://studio.iterative.ai/). ++ [About GIT Internals](https://lore.kernel.org/git/?q=%3Cxmqqk09xhdma.fsf%40gitster.g%3E+): Aman asked how to better understand GIT software internals. Junio (maintainer) suggested starting at the [Initial revision of "git", the information manager from hell (e83c5163, v0.99~954)](https://github.com/git/git/tree/e83c5163316f89bfbde7d9ab23ca2e25604af290). +"With only 1244 lines spread across 11 files, it is a short-read that +is completable in a single sitting for those who are reasonably +fluent in C. It does not have any frills, but the basic data +structures to express the important concepts are already there." ++ Matheus Tavares [successfully defended his Master's dissertation about parallelizing Git checkout](https://www.linkedin.com/posts/matheus-tavares-bernardino_faster-git-checkouts-on-nfs-and-ssd-with-activity-6953084366075883520-usZP/). Some of his work on this was done during [his 2019 Google Summer of Code](https://matheustavares.gitlab.io/posts/gsoc-final-report). ++ [Whatever happened to SHA-256 support in Git?](https://lwn.net/Articles/898522/): + an article by Jonathan Corbet on LWN\.net. ++ [Give Up GitHub: The Time Has Come!](https://sfconservancy.org/blog/2022/jun/30/give-up-github-launch/) + by Denver Gingerich and Bradley M. Kuhn of Software Freedom Conservancy, + (see also [Open source body quits GitHub, urges you to do the same](https://www.theregister.com/2022/06/30/software_freedom_conservancy_quits_github/) in The Register) + calls for FOSS project to migrate away from GitHub. + +__Light reading__ ++ [Introduction to Git Ops](https://www.codeproject.com/Articles/5334970/Introduction-to-GitOps): Some useful background to the Git - DevOps approach in this sponsored article. ++ [Git workflows: Best practices for GitOps deployments](https://developers.redhat.com/articles/2022/07/20/git-workflows-best-practices-gitops-deployments), + describing differences between how you manage your code in Git + and how you manage your GitOps configuration in Git. + By Christian Hernandez, GitOps Advocate, on Red Hat Developer blog. ++ [`git rebase --fork-point` considered harmful (by me)](https://commaok.xyz/post/fork-point/): The reflog lookup heuristics aren't what you thought, are they? A UX report by Josh Bleecher Snyder. ++ [Git Delete Branch How-To, for Both Local and Remote](https://www.cloudbees.com/blog/git-delete-branch-how-to-for-both-local-and-remote) with pictures, also includes deleting branches on GitHub. ++ [Git - Subtree](https://www.geeksforgeeks.org/git-subtree/): A short overview of the common replacement for Git submodule. ++ [Managing Git projects with submodules and subtrees](https://opensource.com/article/20/5/git-submodules-subtrees) (2020): + More choices. This was previously mentioned in [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/). ++ ['Turn off merge fast-forward by default'](https://betterdev.blog/turn-off-git-fast-forward-merge/): An alternative viewpoint (from Git for Windows [#3858](https://github.com/git-for-windows/git/issues/3858)) by Maciej Radzikowski on the Better Dev blog. ++ [Getting Started with Git Hooks and Husky](https://www.git-tower.com/blog/git-hooks-husky/) by Bruno Brito on Tower's blog. ++ “Codeberg” series by Flavio Poletti (@polettix), + starting with [Codeberg](https://github.polettix.it/ETOOBUSY/2022/07/05/codeberg/) + and currently ending with [Codeberg Pages - Custom domains](https://github.polettix.it/ETOOBUSY/2022/07/18/codeberg-pages-domains/), + describes the [Codeberg](https://codeberg.org/) hosting service, + which is powered by [Gitea](https://gitea.io/) software + (a fork of [Gogs](https://gogs.io/), which is written in Go). ++ [Write Better Commits, Build Better Projects](https://github.blog/2022-06-30-write-better-commits-build-better-projects/): + Learn strategies to improve and use commits to streamline your development process. + By Victoria Dye on GitHub Engineering Blog. ++ [Write Git Commit Messages That Your Colleagues Will Love](https://dev.to/simeg/write-git-commit-messages-that-your-colleagues-will-love-1757) + by Simon Egersand on DEV\.to. ++ [Why I love Tig for visualizing my Git workflows](https://opensource.com/article/22/7/visualize-git-workflow-tig) + by Sumantro Mukherjee (Correspondent, Red Hat) on OpenSource\.com. + +__Easy watching__ ++ [Git Internals - The BLOB](https://www.youtube.com/watch?v=_wj4MGuvcjc): 'A shot of code' looks at the internals of the .git folder to see exactly what goes on under the hood. ++ [Getting Comfortable with GIT](https://www.youtube.com/watch?v=aXXXiynr-4A), looking to get a deeper understanding of Git, and hopefully feeling a lot more comfortable when performing some of the more scary Git operations... says 'A shot of code'. ++ [It's Impossible to Know If You're a Good Programmer](https://www.youtube.com/watch?v=Ax4EfY9LrF4): The impostor syndrome and irrelevant code challenges. + +__Git tools and sites__ ++ [Git Signing](https://wilsonmar.github.io/git-signing/): All the details for signing commits and tags (for non-repudiation) in GitHub using GPG, Vault, Yubikey, Keybase! ++ [Git-Story](https://initialcommit.com/tools/git-story): Animate the story of your Git project, + by creating video animations (.mp4) of your commit history directly from your Git repo. + Note: arrows point in the direction of increasing time, not from commit to its parents. + + See also [How to Animate Your Git Commit History with git-story](https://www.freecodecamp.org/news/animate-your-git-repo-with-git-story/) + by Jacob Stopak on freeCodeCamp. ++ [GitHub Actions Kotlin DSL](https://github.com/krzema12/github-actions-kotlin-dsl) + ([docs](https://krzema12.github.io/github-actions-kotlin-dsl/)) + allows authoring GitHub Actions workflows for GitOps in Kotlin. + + See also [GitHub Actions DSL: a New Hope in YAML Programming Wasteland](https://dev.to/jmfayard/github-actions-a-new-hope-in-yaml-wasteland-1i9c) + by Jean-Michel Fayard on DEV\.to. ++ [jc](https://github.com/kellyjonbrazil/jc) (**J**SON **C**onvert) + is a CLI tool and Python library that converts the output of popular command-line tools and file-types + to JSON, YAML, etc... including `git log`. This allows automated processing with tools + such as [`jq`](https://stedolan.github.io/jq/), and simplifying automation scripts. ++ [GitJournal](https://gitjournal.io/) is a mobile first Markdown notes app + integrated with Git, for Android and iOS, + that can work with any Git hosting provider (via SSH). ++ [data-diff](https://github.com/datafold/data-diff) is an open-source command-line tool and Python library + by [Datafold](https://www.datafold.com/open-source-data-diff) + to efficiently diff rows across two different databases. + + See also references to [various](https://www.dolthub.com/blog/2021-09-17-database-version-control/) [blog](https://www.dolthub.com/blog/2021-11-26-so-you-want-git-database/) [posts](https://www.dolthub.com/blog/2021-12-20-git-sql/) + by Tim Sehn on DoltHub Blog about version control, Git, and databases, which appeared + in [Git Rev News Edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/). ++ [GitHacker](https://github.com/WangYihang/GitHacker) is a multithreaded tool + to detect whether a site has the `.git/` folder leakage vulnerability, and if so + restores the entire Git repository, including data from stash. + + See also [Please remove that `.git` folder](https://dev.to/jmau111/please-remove-that-git-folder-3i9a) + from directory browsing on the web server to avoid information leaks. + Don't deploy the `.git/` folder or, at least, forbid access. + By Julien Maury (jmau111) on DEV\.to and on his + [own blog](https://blog.julien-maury.dev/en/snippet/practical-git-security/). ++ [Build your own X](https://github.com/codecrafters-io/build-your-own-x) + is a compilation of well-written, step-by-step guides for re-creating our favorite technologies from scratch, + including [Build your own Git](https://github.com/codecrafters-io/build-your-own-x#build-your-own-git). + + > What I cannot create, I do not understand — Richard Feynman. + +## 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, Philip Oakley and Bruno Brito. diff --git a/_posts/2022-08-31-edition-90.markdown b/_posts/2022-08-31-edition-90.markdown new file mode 100644 index 000000000..fb0a5a4b4 --- /dev/null +++ b/_posts/2022-08-31-edition-90.markdown @@ -0,0 +1,410 @@ +--- +title: Git Rev News Edition 90 (August 31st, 2022) +layout: default +date: 2022-08-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 90 (August 31st, 2022) + +Welcome to the 90th 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](https://git.github.io). + +This edition covers what happened during the month of July 2022. + +## Discussions + + + + +### Reviews + +* [[PATCH 0/2] git(1) doc + "git help": split-out user & git format docs](https://lore.kernel.org/git/cover-0.2-00000000000-20211015T020351Z-avarab@gmail.com/) + + Last October, Ævar Arnfjörð Bjarmason sent a patch series containing + only 2 patches. The first one created a new "User-facing file + formats" section in the main Git manual page by splitting it off from + the existing "Guides" section. The reason for this was that it was a + stretch to have manual pages like "gitignore(5)" in a section called + "Guides" which otherwise contained pages like "gitcore-tutorial(7)". + + The second patch in the series created a new "Git file and wire + formats" section in the main Git manual page. Contrary to the + section created by the first patch, this one was only for internal + file and wire formats, that users were not supposed to touch, like + "gitformat-bundle(5)". + + The goal was to make the existing technical documentation, which was + in "Documentation/technical/" and available only in the HTML format, + more accessible and discoverable by moving it over into the new man + page sections and adding the corresponding `--user-formats` and + `--git-formats` option to the `git help` command. + + The documentation had to be converted when moved over as the man + page format was different from the previous technical documentation + format, but the second patch only converted "bundle-format.txt" to a + new "gitformat-bundle(5)" man page. The plan was to convert and move + over more of them later. + + Last December Ævar sent + [a version 2](https://lore.kernel.org/git/cover-v2-0.5-00000000000-20211212T194047Z-avarab@gmail.com/) + of his patch series which now contained 5 patches instead of 2 and + converted and moved over more documentation to the new man page + sections. + + The cover letter of this patch series contained the following + examples of what the new `git help` options would show: + + ``` + $ git help --user-formats + + The user-facing file formats are: + gitattributes Defining attributes per path + githooks Hooks used by Git + gitignore Specifies intentionally untracked files to ignore + gitmailmap Map author/committer names and/or E-Mail addresses + gitmodules Defining submodule properties + gitrepository-layout Git Repository Layout + + $ git help --git-formats + + Git's internal file and network formats are: + gitformat-bitmap The bitmap file format + gitformat-bundle The bundle file format + gitformat-chunk Chunk-based file formats + gitformat-commit-graph Git commit graph format + gitformat-index Git index format + gitformat-pack-protocol How packs are transferred over-the-wire + gitformat-protocol-capabilities Protocol v0 and v1 capabilities + gitformat-protocol-common Things common to various protocols + gitformat-protocol-v2 Git Wire Protocol, Version 2 + gitformat-signature Git cryptographic signature formats + ``` + + As well as for the first patch series, there was no comment on this + patch series except for one from Eric Sunshine about a possible + typo. Ævar replied to Eric agreeing to fix some wordings. + + [A version 3](https://lore.kernel.org/git/cover-v3-0.7-00000000000-20220712T195419Z-avarab@gmail.com/) + of his patch series appeared only last July on the mailing list. + Containing 7 patches, it converted and moved over even more + documentation to the new man page sections. + + Ævar soon spotted that gcc's `-fanalyzer` option complained about + some code in his patch series though. The issue was that the `git + help` code, which was matching a user requested topic with a man + page, assumed that the name of man page files started with "git" and + then dropped this prefix. This was justified as all Git man page + filenames have always started with "git", but the `-fanalyzer` + detected that things could go wrong if that was not the case. + + So a few days later Ævar sent + [a version 4](https://lore.kernel.org/git/cover-v4-0.8-00000000000-20220718T132911Z-avarab@gmail.com/) + of his patch series with only minor changes. One of them was fixing + the `-fanalyzer` complaint by adding a new patch at the beginning of + the series which would abort the current command using the `BUG()` + macro in case the man page name didn't start with "git". + + Junio Hamano, the Git maintainer, replied to Ævar suggesting a + slightly different fix for the complaint. Junio also thought that + "githooks(5)" didn't really belong into a category named + "user-formats", as a hook can be written in any language, so there + is no "format" for users to follow. Instead, he would have liked a + better name for a category that could contain both "gitignore" and + "githook" related pages. + + Junio also suggested not distinguishing between `` and + `` categories in the `git help` documentation, as at some point + we would have enough `` documents that most probably everything + not related to a specific command would become ``. + + About the "user-formats" category name, Ævar replied that he + couldn't find a better word than "format". He thought about "layout" + as there is "gitrepository-layout(5)", but found it odd. + + He also proposed using `` instead of `` or `` in + the `git help` documentation. Junio replied that he preferred `` + to `` though. + + Ævar and Junio also discussed interactions of the patch series with + patches that were worked on by others at the same time. + + A few days later Ævar then sent + [a version 5](https://lore.kernel.org/git/cover-v5-0.9-00000000000-20220721T160721Z-avarab@gmail.com/) + of his patch series which mainly renamed "user formats" and + "developer formats" to "user interfaces" and "developer interfaces". + + These changes allowed the new "user interfaces" section to also + contain the "gitcli", "gitrevisions" as well as "githook" man pages, + while the "developer interfaces" had pages called "protocol-\*" + instead of only "format-\*": + + ``` + $ ./git help --user-interfaces + User-facing repository, command and file interfaces: + attributes Defining attributes per path + cli Git command-line interface and conventions + hooks Hooks used by Git + ignore Specifies intentionally untracked files to ignore + mailmap Map author/committer names and/or E-Mail addresses + modules Defining submodule properties + repository-layout Git Repository Layout + revisions Specifying revisions and ranges for Git + + $ ./git help --developer-interfaces + File formats, protocols and other developer interfaces: + format-bundle The bundle file format + format-chunk Chunk-based file formats + format-commit-graph Git commit graph format + format-index Git index format + format-multi-pack-index The multi-pack-index file format + format-pack Git pack format + format-pack-cruft The cruft pack file format + format-signature Git cryptographic signature formats + protocol-capabilities Protocol v0 and v1 capabilities + protocol-common Things common to various protocols + protocol-http Git HTTP-based protocols + protocol-pack How packs are transferred over-the-wire + protocol-v2 Git Wire Protocol, Version 2 + ``` + + Along with other small fixes in the `git help` documentation, the + new version also didn't distinguish between `` and `` + categories anymore. + + The only comment on this version was from Eric who found a trivial + typo in a commit message. + + Anyway a few days later Ævar sent + [a version 6](https://lore.kernel.org/git/cover-v6-0.9-00000000000-20220728T164243Z-avarab@gmail.com/) + of his patch series fixing the trivial typo. + + Junio commented that the first patch in this series, which had been + added in version 4 of the patch series to fix the `-fanalyzer` + complaint, wasn't really needed. What wasn't actually needed was the + `BUG()` macro aborting everything in case the name of the man page + didn't start with "git", as it could be an unnecessary roadblock if + we ever wanted to add such man pages. + + After some further discussion, Ævar sent + [a version 7](https://lore.kernel.org/git/cover-v7-00.10-00000000000-20220802T125258Z-avarab@gmail.com/) + of his patch series. + + This series mostly removed the `BUG()` macro that had been added + previously, but in the first patch still refactored the code + dropping the "git" prefix when a user requested topic needs to be + matched with a man page. + + Junio commented about this first patch that he wasn't sure the + commit message properly described what the code was doing in case + the man page name started with something like "git-git". + + He then spotted an issue with how some changes were split into + different patches, and suggested that a man page should be split + into different pages for different topics, while two other man pages + about similar topics should be merged into one. He also mentioned + some "leftoverbits" that could be done later. + + Ævar sent + [a version 8](https://lore.kernel.org/git/cover-v8-00.12-00000000000-20220804T162138Z-avarab@gmail.com/) + of his patch series taking account Junio's suggestions, except for + one documentation page, which he decided to be converted later if + needed, so he just removed the changes converting it from the patch + series. + + Junio reviewed the series again and liked what it was doing. He + discussed further changes a bit with Ævar, but they agreed that they + could be done later in another patch series. + + Since then, version 8 of the patch series has been merged into the + master branch, so we should have a significantly improved + documentation and help system in the next Git feature release + (v2.38.0) that should be out in the first weeks of October. + + + + +## Developer Spotlight: Glen Choo + +* Who are you and what do you do? + + I'm a Software Engineer at Google on a team that works on Git. My prior + experience is comprised solely of different flavours of proprietary web + apps, so I'm constantly grateful for the opportunity to work on the + polar opposite of that :). + + The only interesting thing I do outside of work is rock climbing. + Sometimes, I wish I spent as much time rock climbing as I do working, + which probably means that I should figure out how to do both + simultaneously. + +* What would you name your most important contribution to Git? + + Hm, I've only been contributing for a short while, so it's hard for me + to call any of them important per se. The most user-visible one is + `safe.bareRepository`, but I don't think many users will use it in its + current form. If I had more time, I'd expand it into a safer default for + everyone. + +* What are you doing on the Git project these days, and why? + + Most of my work has been focused on getting submodules to work with + branches as well as general submodule cleanup work. I get a kick out of + searching "git submodule bad", nodding my head at every single complaint + and dreaming about the day I get accurate search results for "git + submodule good". + +* 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'd probably find a different way to structure the test suite so that we + could share far less state between tests, or maybe come up with a way to + visualize the setup for each test case. It would be nice to be able to + read just a single test case to understand what's happening. + + If I had 5 teams of experts and 10 years I'd lib-ify all of Git's + internals and have the Git CLI call the Git library in the same way + everyone else calls libgit2. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + I'd remove nearly all of the CLI flags and replace them with more + consistent, mnemonic flags. It's fun to be able to throw Git CLI trivia + at friends, but at some point, maybe it would be better for them to + be able to remember it themselves. + +* What is your favorite Git-related tool/library, outside of Git itself? + + I owe almost everything I know about Git to [Magit](https://magit.vc/) + (the Emacs plugin). When I was much much newer to Git, it was a safer, + friendlier, more discoverable entry point than the Git CLI. These days, it's + still an essential part of my toolbox since it vastly reduces the number of + keystrokes (I'm a really bad typist) and it gives an amazing interface + for modifying and applying diffs (I still have not touched "git add -p" + and at this point, I think it's too late to start). + + Honourable mention goes to [git-branchless](https://github.com/arxanas/git-branchless). + It does so many amazing things that I've grown to rely on, like + anonymous branches, obsolescence tracking, and history manipulation. + +* Do you happen to have any memorable experience w.r.t. contributing to + the Git project? If yes, could you share it with us? + + Jeff King, one of the most prolific contributors, took a break from the + Git project last year. I was probably one of the first people to realise + when he came back from the break because his first email on the mailing + list was a bug report comment on a bug that I created :'). + +* Could you describe your Git development toolbox? + + For reading email, I've configured an email folder for the mailing list, + which gets pulled down by [offlineimap](http://www.offlineimap.org/) + [notmuch](https://notmuchmail.org/). + I read email using notmuch-emacs, which claims to be a frontend to + notmuch, but is actually also a full-fledged MUA (just like how Emacs + claims to be a text editor, but is actually an OS). + + For reviewing patches, I apply the patches to a dedicated worktree using + [b4](https://github.com/mricon/b4). "b4 shazam" is as close to painless + as I can imagine. + + For sending patches, I wrote a bunch of scripts around "git + format-patch" and "git send-email" and organised my branches so that I + could keep track of each version I sent out. Then one day I tried + GitGitGadget, realised that it does nearly all of those things for me + for free, and those scripts have remained virtually unused since :). + I will probably never use them again once GGG learns how to base + topics on topics. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + The best place to start is to get acquainted with the mailing list and + the community. Reading the mailing list and sending a low-stakes patch + (like a doc fix or usage string fix) are pretty good ways to do this. + Folks on the mailing list tend to communicate in a distinctive style -- + it's often direct, and silence can have a different meaning from what + you're used to. I'm guessing that for most people, learning how to + communicate effectively on the mailing list is harder than the actual + technical aspects of Git development. + + I'd also recommend that newcomers fight the urge to make their v1 + patches absolutely perfect. The community is pretty accommodating to new + contributors, so once you're convinced that the codebase is better off + with your change than without, it's fine to send it out! Far more often + than not, it will lead to a positive interaction. + +* If there's one tip you would like to share with other Git developers, + what would it be? + + Assume good intent from the people you interact with. I think the + mailing list can be intimidating at times (especially to newcomers), but + if you assume good intent, then everyone suddenly seems friendlier and + feedback becomes easier to receive. And of course, remember to pay it + forward by acting with good intent. + + +## Releases + ++ Git [2.37.2](https://public-inbox.org/git/xmqqedxmfyhe.fsf@gitster.g/) ++ Git for Windows [2.37.2(2)](https://github.com/git-for-windows/git/releases/tag/v2.37.2.windows.2), +[2.37.2(1)](https://github.com/git-for-windows/git/releases/tag/v2.37.2.windows.1) ++ GitLab [15.3.1](https://about.gitlab.com/releases/2022/08/22/critical-security-release-gitlab-15-3-1-released/) +[15.3](https://about.gitlab.com/releases/2022/08/22/gitlab-15-3-released/), +[15.2.2](https://about.gitlab.com/releases/2022/08/01/gitlab-15-2-2-released/) ++ Bitbucket Server [8.3](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitHub Enterprise [3.5.4](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.4), +[3.4.7](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.7), +[3.3.12](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.12), +[3.2.17](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.17) ++ GitHub Desktop [3.0.6](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + ++ A series of posts about "Git's database internals" by Derrick Stolee + has been published on GitHub's blog site: + - [part 1](https://github.blog/2022-08-29-gits-database-internals-i-packed-object-store/) + is about how Git stores object data, + - [part 2](https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/) + is about commit history queries, + - [part 3](https://github.blog/2022-08-31-gits-database-internals-iii-file-history-queries/) + is about file history queries, + - [part 4](https://github.blog/2022-09-01-gits-database-internals-iv-distributed-synchronization/) + is about distributed synchronization, + - [part 5](https://github.blog/2022-09-02-gits-database-internals-v-scalability/) + is about scalability. ++ [The full lineup for Git Merge 2022](https://github.blog/2022-08-23-the-full-lineup-for-git-merge-2022-revealed/) + has been revealed by Lee Reilly. + + + + + +__Git tools and sites__ + ++ [prr alias 'Pull request review'](https://github.com/danobi/prr) by + Daniel Xu allows "offline reviews and inline comments" to Github + PRs. + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Glen Choo, Carlo Marcelo Arenas Belón +and Johannes Schindelin. diff --git a/_posts/2022-09-30-edition-91.markdown b/_posts/2022-09-30-edition-91.markdown new file mode 100644 index 000000000..cf6539b65 --- /dev/null +++ b/_posts/2022-09-30-edition-91.markdown @@ -0,0 +1,464 @@ +--- +title: Git Rev News Edition 91 (September 30th, 2022) +layout: default +date: 2022-09-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 91 (September 30th, 2022) + +Welcome to the 91st 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](https://git.github.io). + +This edition covers what happened during the month of September 2022. + +## Discussions + + +### General + +* [Git Merge conference](https://git-merge.com/) and Contributor's Summit + + The Git Merge conference happened + [on September 14th and 15th](https://git-merge.com/#schedule). + On the afternoon of the first day there were optional workshops and + the Git Contributor's Summit, while the main conference took place on + the second day. + + As usual [the topics](https://docs.google.com/spreadsheets/d/1QhkUkYvqtGJtN7ViiTmrfcP3s0cXgqyAIACRD5Q24Mg) + that were discussed during the Contributor's Summit were proposed + and voted on before the summit started. The discussions started + with the topics with the most votes. + + Taylor Blau sent [an email](https://lore.kernel.org/git/YzXvMRc6X60kjVeY@nand.local/) + summarizing what happened and asking for feedback, followed by an own + email thread for each topic that had a note-taker, starting with the + topic's broken-out notes. + +* [Gerrit User Summit](https://www.eventbrite.com/e/gerrit-user-summit-2022-tickets-424995963367) 2022 + + Gerrit User Summit is the event that brings together Gerrit and JGit + maintainers, contributors and users, as an opportunity to network face-to-face and + share news and experiences. It is now back on the 10-11 November 2022 + in hybrid mode with a physical venue in [London at CodeNode](https://g.page/codenodeuk?share) + and online. + + The summit is going to be recorded and published on the [GerritForge YouTube](https://tv.gerritforge.com) + channel, together with roundtables and discussions between the community + members. + + + +### Support + +* [rev-parse: `--` is sometimes a flag and sometimes an arg?](https://lore.kernel.org/git/CAO_RewbD+BJd1hPKCmCNM8wYBSUmZ2TuOoy6t1up1CT-rbn4DA@mail.gmail.com/) + + Tim Hockin sent an email to the mailing list containing a series of + `git rev-parse` commands with some arguments that he ran on the + command line, along with their results and his comments. + + First he ran `git rev-parse unknown-tag`, which errored out after + printing `unknown-tag`. The error message said that `unknown-tag` is + an ambiguous argument and suggested to use `--` to separate paths + from revisions. + + So he tried `git rev-parse unknown-tag --`, which just errored saying + that `unknown-tag` was a bad revision, as expected. + + Unfortunately when he then tried `git rev-parse HEAD --`, there was + no error, as expected, but instead of printing only the SHA1 hash + corresponding to HEAD, the command also printed `--` on its own line + after the SHA1 hash. + + This made Tim wonder why `--` was treated as a regular argument. He + looked at Git source code and said that it seemed intentional to + treat it that way, but he didn't understand the reason. + + Junio Hamano, the Git maintainer, replied that `git rev-parse` was + mostly a "plumber" command designed to be used by higher level + "porcelain" commands. By default, it should be able to "parse" + command line arguments, and then dump them all to its output after + translating "revs" into raw object names (SHA1 hashes). + + As `--` is a valid option for "porcelain" commands or scripts that + would use `git rev-parse` to parse their command line arguments, it + makes sense for `git rev-parse` to just pass `--` along. + + Tim then asked if there was "a more friendly way" to do what he + wanted to achieve. But Junio replied that it wasn't clear what Tim + actually wanted to do. + + Tim replied that his goal was to convert a string that could contain + a tag name, a branch name, or a SHA1 hash (abbreviated or not) into + a canonical SHA1. + + Junio suggested using `git rev-parse --verify `, as it would + either convert `` into an object ID (a SHA1 hash by + default), or it would error out. Junio also mentioned that + [the "EXAMPLES" section](https://git-scm.com/docs/git-rev-parse#_examples) + has more elaborate examples. + + brian m. carlson chimed in to say that `git rev-parse --verify ` + would print a full object ID whether it exists in the repo or not, if + `` already contains one (for example, the all-zeros object ID). + He suggested using `git rev-parse --verify ^{object}` if Tim + wanted to also verify that the object exists. + + Tim thanked brian and Junio saying that their answer helps a lot. + +## Developer Spotlight: Jeff King (alias Peff) + +* Who are you and what do you do? + + My given name is Jeff, but most people call me Peff. Even in real life. + I've been working on Git since early 2006. For a while it was for fun + and to scratch my own itches (and maybe to avoid doing my school work), + but I joined GitHub in 2011, where my job was mostly about improving + Git. I stopped being a full-time employee earlier this year, but I'm + still working a few hours a week on Git. + +* How has your journey been as a long-time Git contributor? Do you + happen to have any memorable experience w.r.t. contributing to the + Git project? + + One thing I've found with contributing to Git is that it sneaks up on + you over time. + + I still remember one moment in 2008 or 2009. In my mind, Git was + something I did to procrastinate on "real" work. Shawn Pearce was + organizing an in-person meeting of developers, and emailed me + specifically to say that I was one of the core developers and should + consider coming. I was really confused. Wasn't this just a thing I did + in my spare time? But running `git shortlog` showed that I was one of + the top few contributors. That really changed my mindset; I realized I + was part of a larger community, and that it was something I did care + about. + + And I have that same sense looking at how far Git has come. Day to day + (and especially when you're fixing a bug in code from 2005) it can seem + like nothing changes. But when I look back over the span of 10 or 15 + years, I'm amazed at the progress. Not just in terms of features in Git, + but at the overall development process. The way we work and communicate + has matured so much in that time. Some of that is from technical tools + (new Git features, new internal APIs and data structures to avoid whole + classes of bugs), but some of it is in what the people do. In my opinion, + our standards for testing and commit messages have gone up considerably + over the years. + +* Git Merge got over a few days ago. Any takeaways from the conference + that you would like to share? + + To me, the most important part of Git Merge is making connections + between developers. I'm not convinced that sticking 30 people in a room + is the best way to have a technical discussion, and the real work later + happens solo, or on the list. But I think seeing people in person, and + especially chatting with them over lunch, etc, is so helpful to that + later work. We all know intellectually that there's another person on + the end of every email, but I think having met them face to face helps + us empathize at a more gut level. + + Of course, there were some talks, too. I tend to prefer the more + technical ones, but being so involved in Git development, there doesn't + tend to be anything too surprising for me there. I thought the talks + from Taylor and Elijah were nice dives into new technical material + (though they both also have great blog posts that go even deeper!). + Martin's Jujutsu talk gave a lot of food for thought on different ways + for people to interact with Git. + +* Could you share a few words regarding your experience while you were + a member of the Git PLC? + + I was the person who led the initial effort in 2010 to join Software + Freedom Conservancy. We had gotten some money for the project as part of + Google's Summer of Code program. It was being passed around like a hot + potato (between countries, even!) as somebody took responsibility for + handling GSoC each year. I don't even want to think of what we were + _supposed_ to do with it, tax-wise, but we knew it would be better with + some actual structure. So that led to us joining, which led to the PLC + as committee in control of the project as an entity (and the money), and + that led to handling more assets (the git-scm.com domain, donated + hosting agreements from various places, the trademark). + + Since the Conservancy entity isn't directly related to code development, + being on the PLC is long periods of nothing, punctuated by big threads + full of boring non-coding stuff. Some of it is fun-ish, like handing out + travel funds so people can come to Git Merge. Some of it I found very + tedious, like discussing trademark enforcement, or code of conduct + issues. I was happy to serve on the PLC for many years, but I'm also + happy that other people are doing that work now. + +* What would you name your most important contribution to Git? + + I think my biggest contribution is not any one thing, but rather being + there for all of the things. There's hardly a C file in the repository + that I haven't touched at some point, and when fixing a bug I'd often + try to find solutions we could apply to the whole code base (e.g., + improving an API to be less error-prone and using it consistently in + other callers). + + I do sometimes work on bigger features. One of the earliest things I did + after starting at GitHub was overhaul our HTTP authentication and + introduce the credential-helper protocol. I occasionally see other tools + using a similar protocol, proving that it was either a great idea, or a + seductively bad one! + +* What are you doing on the Git project these days, and why? + + One of my favorite things in Git is to wake up, read an email on the + list that says "why does Git do X when I say Y?", dig it down to some + bug or missing feature, and end up with a nice, tidy patch by lunchtime. + Of course it doesn't always go that way, but I do often enjoy these + little fixes. It's like solving a puzzle. + + I also have a backlog of half-finished ideas. Some of them are garbage + that I'll probably throw away, but many of them just need a little + polishing. One of them is more tunable knobs for repacking (which has + been in use on GitHub's servers for a few years already!), and another + is handling negative commit timestamps (so we can finally import + pre-1970 Apollo code). + +* 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? + + Arguably I had that already, so maybe past work speaks for itself. Or + maybe I squandered it. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + Trees should be sorted in order strictly by name, rather than + directories sorting as if "/" was appended. It's a little thing, I know, + but it's one of the few things that's really impossible to fix because + it's baked so deep into Git's logical model. + +* What is your favorite Git-related tool/library, outside of Git + itself? + + Definitely [`tig`](https://jonas.github.io/tig/). Its "blame" functionality, + and especially the "re-blame from parent" feature, are so useful. I almost + never run a bare `git blame`. + +* What is your toolbox for interacting with the mailing list and + for developing Git itself? + + I read the mailing list via mutt. I keep a local archive which I index + with notmuch. I used to actually subscribe to the list, but these days I + just pull the archive every few minutes from lore.kernel.org's + public-inbox Git repository. + + I do all of my development with a fairly vanilla vim setup. I have a few + niceties, like terminal hotkeys to cut and paste object hashes, and a + vim function to inline output from a Git command (like converting hashes + into `--format=reference`). + + I try to share my scripts when they're not too gross or specific to my + workflows. An example there is [`contrib/git-jump`](https://github.com/git/git/tree/master/contrib/git-jump). + I keep some other Git-specific scripts in the [meta branch](https://github.com/peff/git/tree/meta) + which I check out as the directory `Meta` inside my Git repository (I + stole the name from Junio, who has a similar tree of scripts). I use it + to rebase my topics and make my daily-driver build of Git. There's + probably not much of use there for most people, but some of it has led + to useful features (e.g., our test suite's `--stress` option started as + a script there, though SZEDER Gábor did all the heavy lifting to + integrate it). + +* What is your advice for people who want to start Git development? + Where and how should they start? + + There are a lot of ways to get involved in open source, but I think the + best one is scratching your own itch. Pick something you want the tool + to do, and work on it. That's probably harder with Git these days than + it was when I started, just because the system is larger and more + complex, and so much of the low-hanging fruit has already been picked. + + A similar way is just reading the list and looking for bug reports. Once + you learn about a problem, then it becomes your itch. + + Of course it's fine to start work on a much larger project if you like. + But following my "sneaks up on you" philosophy from above, if you work + on enough small things, you will eventually find yourself quite + comfortable with the code base, and able to work on larger things. + +* If there's one tip you would like to share with other Git + developers, what would it be? + + Re-read your emails before sending! Obviously it's nice to catch typos + and other simple proofreading errors. But it's also a final chance to + make sure you are saying what you want clearly and concisely, and that + you understand what the other person is saying. + + I can't count the number of times that I've almost sent out a very + confused explanation in a commit message, and upon re-reading realized + that not only was there a better way to explain it, but a better way to + write the code. It's also one of the reasons I like writing verbose + commit messages. Trying to justify the decisions you've made in writing + a patch is often the moment you realize that your arguments are weak. + + Likewise, there have been many times when I'm about to respond to + somebody along the lines of "I think you're wrong, and here's why". And + upon re-reading I realize that I did not understand their point in the + first place. Of course if everybody remains polite, then hopefully the + error works its way to a shared understanding eventually. But besides + saving everybody time, catching a misunderstanding before sending means + you're wrong on the Internet one less time! + + Of course, ending the interview with this tip gives an almost certain + probability that I have a typo somewhere above. So maybe one more tip: + be humble. And remember to have fun. Oops, that's two tips. + + +## Releases + ++ Git [2.38.0-rc2](https://public-inbox.org/git/xmqqzgek1q1p.fsf@gitster.g/), +[2.38.0-rc1](https://public-inbox.org/git/xmqqk05wz2si.fsf@gitster.g/), +[2.38.0-rc0](https://public-inbox.org/git/xmqqczbwkpt8.fsf@gitster.g/), +[2.37.3](https://public-inbox.org/git/xmqqzgflk211.fsf@gitster.g/) ++ Git for Windows [2.38.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.38.0-rc2.windows.1), +[2.38.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.38.0-rc1.windows.1), +[2.38.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.38.0-rc0.windows.1), +[2.37.3(1)](https://github.com/git-for-windows/git/releases/tag/v2.37.3.windows.1) ++ Bitbucket Server [8.4](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitHub Enterprise [3.6.2](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.2), +[3.5.6](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.6), +[3.4.9](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.9), +[3.3.14](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.14), +[3.2.19](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.19), +[3.6.1](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.1), +[3.5.5](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.5), +[3.4.8](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.8), +[3.3.13](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.13), +[3.2.18](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.18) ++ GitLab [15.4](https://about.gitlab.com/releases/2022/09/22/gitlab-15-4-released/) +[15.3.3](https://about.gitlab.com/releases/2022/09/05/gitlab-15-3-3-released/), +[15.3.2, 15.2.4 and 15.1.6](https://about.gitlab.com/releases/2022/08/30/critical-security-release-gitlab-15-3-2-released/) ++ GitHub Desktop [3.0.8](https://desktop.github.com/release-notes/), +[3.0.7](https://desktop.github.com/release-notes/) ++ Tower for Mac [9.0](https://www.git-tower.com/release-notes/mac) ([What’s New in Tower 9 video](https://youtu.be/CuCCGSlBkis)) ++ Tower for Windows [3.4](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) + +## Other News + +__Various__ + ++ [SSH commit verification now supported](https://github.blog/changelog/2022-08-23-ssh-commit-verification-now-supported/) + in GitHub. ++ [1Password now allows you to set up and use SSH keys to sign Git commits](https://blog.1password.com/git-commit-signing/). + + See also [SSH and Git, meet 1Password](https://blog.1password.com/1password-ssh-agent/), + mentioned in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [New options for controlling the default commit message when merging a pull request](https://github.blog/changelog/2022-08-23-new-options-for-controlling-the-default-commit-message-when-merging-a-pull-request/) + via web interface in GitHub. ++ [Merge commits now created using the merge-ort strategy](https://github.blog/changelog/2022-09-12-merge-commits-now-created-using-the-merge-ort-strategy/) + on GitHub. ++ [35,000 code repos not hacked—but clones flood GitHub to serve malware](https://www.bleepingcomputer.com/news/security/35-000-code-repos-not-hacked-but-clones-flood-github-to-serve-malware/), + and [GitHub blighted by “researcher” who created thousands of malicious projects](https://nakedsecurity.sophos.com/2022/08/04/github-blighted-by-researcher-who-created-thousands-of-malicious-projects/). ++ [Gerrit Code Review v3.7.0 release plan](https://www.gerritcodereview.com/2022-09-29-gerrit-3.7-release-plan.html) has been published. + + +__Light reading__ + ++ [Scaling Git's garbage collection](https://github.blog/2022-09-13-scaling-gits-garbage-collection/) + by Taylor Blau on GitHub Blog: a tour of recent work to re-engineer Git's garbage collection process + to scale to GitHub's largest and most active repositories. ++ [A primer on Roaring bitmaps: what they are and how they work](https://vikramoberoi.com/a-primer-on-roaring-bitmaps-what-they-are-and-how-they-work/) + by Vikram Oberoi. + + Adding support for [Roaring Bitmaps](https://roaringbitmap.org/) to Git was a part of + [Reachability bitmap improvements](https://summerofcode.withgoogle.com/programs/2022/projects/UPtA6qdf) + Google Summer of Code 2022 project by Abhradeep Chakraborty, see for example their + [GSoC Final Report](https://medium.com/@abhra303/gsoc-final-report-feaaacfae737) on their Medium blog. ++ [Enable Gitsign Today and Start Signing your Commits](https://dev.to/erikaheidi/enable-gitsign-today-and-start-signing-your-commits-2gda) + with so called _keyless signing_, that is signing that relies on ephemeral keys. + Article by Erika Heidi on DEV\.to. ++ [Switching git back to GPG signing](https://sethmlarson.dev/blog/switching-git-back-to-gpg-signing) + from SSH key signing, by Seth Michael Larson on his own blog. + + See also [Signing Git Commits with SSH Keys](https://blog.dbrgn.ch/2021/11/16/git-ssh-signatures/), + mentioned in [Git Rev News Edition #83](https://git.github.io/rev_news/2022/01/31/edition-83/). ++ [Git signatures with SSH certificates](https://mjg59.dreamwidth.org/60916.html) + by Matthew Garrett on his Dreamwidth journal. ++ [Merging two GitHub repositories without losing commit history](https://hacks.mozilla.org/2022/08/merging-two-github-repositories-without-losing-commit-history/) + by Schalk Neethling on Mozilla Hacks blog; a simpler solution might be to use the `git subtree` command, + or use the `subtree` merge strategy, or the `ort` merge strategy with `subtree[=]` strategy option. ++ [.gitignore File – How to Ignore Files and Folders in Git](https://www.freecodecamp.org/news/gitignore-file-how-to-ignore-files-and-folders-in-git/) + by Dionysia Lemonaki on freeCodeCamp. ++ [SSH Tips and Tricks](https://carlosbecker.com/posts/ssh-tips-and-tricks/) + by Carlos Alexandro Becker, including how to avoid having to touch Yubikey. ++ [Do (not) Self-Host your repos](https://weblog.masukomi.org/2022/09/24/do-and-dont-self-host-your-repos/) + by Kay Rhodes (@masukomi), explaining pros and cons of self hosting, with a simple suggestion on what to do. ++ [The Git Commands I Use Every Day](https://dev.to/wadecodez/the-git-commands-i-use-every-day-5g17) + by Wade Zimmerman on DEV\.to, + originally [published at devmap.org](https://devmap.org/the-git-commands-i-use-every-day-5277f90ab743), a Medium blog. ++ [Git Best Practices – How to Write Meaningful Commits, Effective Pull Requests, and Code Reviews](https://www.freecodecamp.org/news/git-best-practices-commits-and-code-reviews/) + by Grant Weatherston on freeCodeCamp. ++ [Error: src refspec master does not match any – How to Fix in Git](https://www.freecodecamp.org/news/error-src-refspec-master-does-not-match-any-how-to-fix-in-git/) + by Dillion Megida on freeCodeCamp. ++ [Rewrite your git history in 4 friendly commands](https://whitep4nth3r.com/blog/rewrite-git-history/), + making the git history of a demo project to start (again) with an _"Initial commit"_. + By Salma Alam-Naylor on whitep4nth3r.com (also [on DEV\.to](https://dev.to/whitep4nth3r/rewrite-your-git-history-in-4-friendly-commands-an9)). ++ [Fixing Some Bugs in My GitHub Profile Generator](https://blog.urth.org/2022/08/14/fixing-some-bugs-in-my-github-profile-generator/) + by Dave Rolsky on his House Absolute(ly Pointless) blog, + among others on how to use [`linguist-generated` gitattribute](https://github.com/github/linguist/blob/master/docs/overrides.md) + to exclude generated files from languages statistics. ++ [Things I wish everyone knew about Git (Part I)](https://blog.plover.com/prog/git/tips.html) + and [(Part II)](https://blog.plover.com/prog/git/tips-2.html) + by Mark Dominus (陶敏修) on The Universe of Discourse blog. ++ [Why We Built an Open Source ML (Machine Learning) Model Registry with git](https://thenewstack.io/why-we-built-an-open-source-ml-model-registry-with-git/) + by Dmitry Petrov of [Iterative.AI](https://iterative.ai/) (authors of DVC, CML and MLEM) + on The New Stack. + + See [Git-backed Machine Learning Model Registry to bring order to chaos](https://iterative.ai/blog/iterative-studio-model-registry), + mentioned in [Git Rev News Edition #89](https://git.github.io/rev_news/2022/07/31/edition-89/). ++ [Git – Comparing Visual Studio 2022 with MeGit/EGit and SourceTree](https://www.codeproject.com/Articles/5338960/Git-Comparing-Visual-Studio-2022-with-MeGit-EGit-a) + by Mark Pelf on CodeProject. ++ [Kaleidoscope + Tower: the perfect Git setup](https://blog.kaleidoscope.app/2022/08/03/kaleidoscope-and-tower/) by Florian Albrecht. ++ [How we built Tower 3 for Windows](https://www.git-tower.com/blog/how-we-built-tower-3-for-windows/) by Kristian Lumme on Tower’s blog. ++ [Mastering Google (for Developers)](https://www.git-tower.com/blog/mastering-google-developers/) by Bruno Brito on Tower's blog. ++ [10 Useful Git Commands You Should Know](https://www.git-tower.com/blog/10-useful-git-commands/) by Bruno Brito on Tower's blog. ++ [Git Interview Questions - The essential list, including answers](https://www.git-tower.com/learn/git/faq/git-interview-questions), + a part of Git Tower's [Git FAQ](https://www.git-tower.com/learn/git/faq) + (with tips for the Tower Git client). ++ [Semantic Diff for SQL](https://github.com/tobymao/sqlglot/blob/main/posts/sql_diff.md) by Iaroslav Zeigerman; + implementation discussed in this post is now a part of the [SQLGlot](https://github.com/tobymao/sqlglot/) library. + + + + +__Git tools and sites__ + ++ [b4](https://b4.docs.kernel.org/en/stable-0.10.y/index.html): has gained + [contributor oriented features](https://b4.docs.kernel.org/en/stable-0.10.y/contributor/overview.html), + like `b4 send` to send patch series to a mailing list; see + [Konstantin Ryabitsev's announce](https://lore.kernel.org/git/20220919145445.ifpjcah44pql2erl@meerkat.local/). ++ [Gitsign](https://github.com/sigstore/gitsign): Keyless Git signing with + [Sigstore](https://www.sigstore.dev/), with your own GitHub / OIDC (OpenID Connect) identity. + Written in Go. ++ [`ghq`](https://github.com/x-motemen/ghq) provides a way to organize remote repository clones, + like `go get` does; for example when cloning it makes a directory under a specific root directory. + Written in Go. ++ [Revup](https://github.com/Skydio/revup) provides command-line tools that allow developers + to iterate faster on parallel changes and reduce the overhead of creating and maintaining code reviews; + it creates multiple independent chains of branches for you in the background + and then creates and manages GitHub pull requests for all those branches. + Written in Python. ++ [`git-of-theseus`](https://github.com/erikbern/git-of-theseus) is a set of scripts to + analyze how a Git repo grows over time. + + See [The half-life of code & the ship of Theseus](https://erikbern.com/2016/12/05/the-half-life-of-code.html) + by Erik Bernhardsson (2016). ++ [git_dash](https://github.com/darul75/git_dash) is a command-line shell script + for generating a Git metrics dashboard directly in your terminal. ++ [GitHub does dotfiles](https://dotfiles.github.io/): Your unofficial guide to dotfiles on GitHub. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Peff (Jeff King), Bruno Brito and +Luca Milanesio. diff --git a/_posts/2022-10-31-edition-92.markdown b/_posts/2022-10-31-edition-92.markdown new file mode 100644 index 000000000..67a7f7dd0 --- /dev/null +++ b/_posts/2022-10-31-edition-92.markdown @@ -0,0 +1,249 @@ +--- +title: Git Rev News Edition 92 (October 26th, 2022) +layout: default +date: 2022-10-26 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 92 (October 26th, 2022) + +Welcome to the 92nd 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](https://git.github.io). + +This edition covers what happened during the month of October 2022. + +## Discussions + +### General + +* [Git participated in GSoC (Google Summer of Code) 2022](https://summerofcode.withgoogle.com/programs/2022/organizations/git) + + The following contributors have successfully passed their final + evaluation and published a final report: + + - Shaoxuan Yuan worked on the + [More Sparse Index Integrations project](https://ffyuanda.github.io/blog/GSoC-final-blog/) + project. He was co-mentored by Derrick Stolee and Victoria Dye. + + - Abhradeep Chakraborty worked on the + [Reachability bitmap improvements](https://medium.com/@abhra303/gsoc-final-report-feaaacfae737) + project. He was co-mentored by Kaartic Sivaraam and Taylor Blau. + + Also Siddharth Asthana successfully participated in GSoC 2022 for + GitLab (instead of Git) and contributed to Git as part of his work on the + [Add Support for Mailmap](https://gitlab.com/groups/gitlab-org/-/epics/8765) + project. He was co-mentored by John Cai and Christian Couder. + + Congratulations to these contributors and their mentors! + + +### Reviews + +* [[PATCH] fuzz: add basic fuzz testing for git command](https://lore.kernel.org/git/pull.1351.git.1663078962231.gitgitgadget@gmail.com/) + + Arthur Chan sent a patch to add basic fuzz testing to Git. The patch + added a set of helper functions in some `fuzz-cmd-base.{h,c}` files + and a demonstration entry point (called fuzzing target) for + [LibFuzzer](https://llvm.org/docs/LibFuzzer.html) or similar tools + to inject fuzzed data into `git status` in a `fuzz-cmd-status.c` + file. + + Ævar Arnfjörð Bjarmason replied to Arthur. He suggested coding style + improvements to better match our style as well as taking a look at + the infrastructure code we already have for fuzzing. He also + wondered if existing code - that is, APIs for file generation and + the shell-based infrastructure in the `t/` directory - could not + be used for fuzzing, too. + + Arthur replied that he couldn't find existing infrastructure code + for fuzzing and that he was confused about avoiding the `system`(3) + calls as they were needed to reset the state of the repo after each + round of fuzzing, and the LLVM oss-fuzz library required such + resetting logic to be included in the C code. + + Junio Hamano, the Git maintainer, also replied to Arthur saying + that, before adding new fuzzing infrastructure, existing one should + be moved into a new `fuzz/` directory. Junio also suggested some + coding style improvements and commented on possible performance and + correctness issues. + + Arthur replied to Junio that he implemented the suggested changes in + a version 2 of the patch that he was preparing, and then sent this + [version 2](https://lore.kernel.org/git/pull.1351.v2.git.1663349383852.gitgitgadget@gmail.com/) + to the mailing list. + + This version of this patch indeed moved some existing + `fuzz-commit-graph.c`, `fuzz-pack-headers.c` and `fuzz-pack-idx.c` + files into a new `oss-fuzz` directory. The patch still added the new + fuzzing infrastructure that was in the previous version, though a lot + of the issues that had been pointed out were fixed. + + Junio replied that it was better to have the "cleaning up of + existing stuff" and "addition of new stuff" split into two separate + patches instead of having everything in the same one. + + Arthur agreed to split the move of the existing fuzzing + infrastructure into + [a separate preparatory patch](https://lore.kernel.org/git/pull.1353.git.1663355009333.gitgitgadget@gmail.com/) + called "fuzz: reorganise the path for existing oss-fuzz fuzzers" + that he later sent to the mailing list. + + Junio reviewed the preparatory patch and found that some changes to + the `.gitignore` file were likely missing. He also asked how the + fuzzing should be launched. + + Arthur replied agreed that changing the `.gitignore` file was needed + and said that he got privately in touch with people from + [oss-fuzz targeting Git](https://github.com/google/oss-fuzz/tree/master/projects/git) + who had implemented the existing fuzzing. He also said that a + Dockerfile and build script prepared for Git would launch the + fuzzing. + + Arthur then sent a + [version 2 of the preparatory patch](https://lore.kernel.org/git/pull.1353.v2.git.1663457311149.gitgitgadget@gmail.com/) + with a few small fixes and the `.gitignore` changes that Junio + suggested. Soon after he sent a + [version 3](https://lore.kernel.org/git/pull.1353.v3.git.1663542495094.gitgitgadget@gmail.com/) + with very minor changes compared to version 2. + + Ævar replied to this new version suggesting some commit message + improvements to better explain the patch purpose as well as creating + `oss-fuzz/.gitignore` instead of changing the `.gitignore` file at + the root of the repository. + + Arthur sent a + [version 4](https://lore.kernel.org/git/pull.1353.v4.git.1663598215154.gitgitgadget@gmail.com/) + with the suggested changes. + + Junio commented a bit on how to make sure people get CC'ed in the + emails sent by [GitGitGadget](https://gitgitgadget.github.io/) but + was happy with the patch itself, which has since been merged into the + `master` branch. + + We are looking forward to even more fuzzing infrastructure + improvements in the near future. + + + + + +## Releases + ++ Git [2.38.1 and others](https://public-inbox.org/git/xmqq4jw1uku5.fsf@gitster.g/), +[2.38.0](https://public-inbox.org/git/xmqqmtacu8bw.fsf@gitster.g/) ++ Git for Windows [2.38.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.38.1.windows.1), +[2.38.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.38.0.windows.1) ++ GitHub Enterprise [3.7.0](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.0), +[3.6.3](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.3), +[3.5.7](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.7), +[3.4.10](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.10), +[3.3.15](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.15), +[3.2.20](https://help.github.com/enterprise-server@3.2/admin/release-notes#3.2.20) ++ GitLab [15.5.1](https://about.gitlab.com/releases/2022/10/24/gitlab-15-5-1-released/) +[15.5](https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/), +[15.4.3](https://about.gitlab.com/releases/2022/10/19/gitlab-15-4-3-released/), +[15.4.2](https://about.gitlab.com/releases/2022/10/03/gitlab-15-4-2-released/), +[15.4.1, 15.3.4, and 15.2.5](https://about.gitlab.com/releases/2022/09/29/security-release-gitlab-15-4-1-released/) ++ Bitbucket Server [8.5](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.4.6](https://www.gerritcodereview.com/3.4.html#346), +[3.5.3](https://www.gerritcodereview.com/3.5.html#353), +[3.6.2](https://www.gerritcodereview.com/3.6.html#362) ++ GitHub Desktop [3.1.2](https://desktop.github.com/release-notes/), +[3.1.1](https://desktop.github.com/release-notes/), +[3.1.0](https://desktop.github.com/release-notes/) ++ Tower for Windows [4.0](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) ([blog post](https://www.git-tower.com/blog/tower-windows-4/)) + +## Other News + +__Events__ + ++ The recorded talks of Git Merge 2022 [are now live](https://www.youtube.com/playlist?list=PL0lo9MOBetEGEAs1D28ExRQONnX-uZ3Wf). ++ The summary of Git Merge 2022 can be found in the + [Git Merge 2022 – that’s a wrap!](https://github.blog/2022-10-21-git-merge-2022-mission-report/) + blog post by Lee Reilly on the GitHub Blog. + + +__Various__ + ++ [Git security vulnerabilities announced](https://github.blog/2022-10-18-git-security-vulnerabilities-announced/) + (CVE-2022-39253, and CVE-2022-39260) that affect Git's [`--local` clone optimization](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---local) + (important when cloning with `--recurse-submodules` from untrusted repositories) + and [`git shell`'s interactive command mode](https://git-scm.com/docs/git-shell#_interactive_useA). + Fixed in Git 2.38.1. ++ [Highlights from Git 2.38](https://github.blog/2022-10-03-highlights-from-git-2-38/) + by Taylor Blau on the GitHub Blog. + + See also [Git 2.38 Adds Microsoft's "Scalar" Repository Management Tool](https://www.phoronix.com/news/Git-2.38-Released) + by Michael Larabel on Phoronix. ++ [Cybernews research team discovered millions of `.git` folders exposed to public](https://cybernews.com/security/millions-git-folders-exposed/). ++ A [Code Review Handbook](https://www.sledgeworx.io/code-review-handbook/) published by Sledgeworx Software. + + +__Light reading__ + ++ [Setting Up GPG on Windows (The Easy Way)](https://www.git-tower.com/blog/setting-up-gpg-windows/) by Bruno Brito on Tower’s blog. ++ [Our Favorite Tower Features](https://blog.kaleidoscope.app/2022/10/18/our-l33t-tower-features/) by Florian Albrecht on Kaleidoscope's blog. ++ [The Story of Scalar](https://github.blog/2022-10-13-the-story-of-scalar/) + by Derrick Stolee and Victoria Dye on the GitHub Blog. ++ Literally the smallest changeset possible created: + [Fix: remove a ZERO WIDTH NO-BREAK SPACE in front of an inline literal](https://github.com/spyder-ide/spyder-docs/pull/332). ++ [VS Code "Timeline" feature — Your local version control system](https://www.amitmerchant.com/vs-code-timeline-your-local-version-control-system/) + by Amit Merchant. ++ [Turn around your Git mistakes in 17 ways](https://dev.to/smitterhane/turn-around-your-git-mistakes-in-17-ways-2mn1) + by Smitter hane on DEV\.to. ++ [GitHub's Missing Merge Option](https://tylercipriani.com/blog/2022/09/30/githubs-missing-merge-option/) + by Tyler Cipriani, explaining the conflict between team “`git log` should be clean” vs. team + “`git log` should have an accurate history” and the consequences for GitHub users. ++ [Take advantage of Git rebase](https://about.gitlab.com/blog/2022/10/06/take-advantage-of-git-rebase/) by Christian Couder on the GitLab blog. ++ [Speed up your monorepo workflow in Git](https://about.gitlab.com/blog/2022/09/06/speed-up-your-monorepo-workflow-in-git/) by + John Cai on the GitLab blog. + + See also [Scaling Git’s garbage collection](https://github.blog/2022-09-13-scaling-gits-garbage-collection/), + mentioned in [Git Rev News #91](https://git.github.io/rev_news/2022/09/30/edition-91/) and + [Scaling monorepo maintenance](https://github.blog/2021-04-29-scaling-monorepo-maintenance/), mentioned + in [Git Rev News #75](https://git.github.io/rev_news/2021/05/27/edition-75/). + + + +__Git tools and sites__ + ++ [`focus`](https://github.com/twitter/focus) is a tool to manage + [Git sparse checkouts](https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/) + derived from the [Bazel](https://bazel.build/) build graph. ++ Goblet is a Git proxy server that caches repositories for read access, + which is intended to be used as a library. + Created at Google as 20% project (with glue code for googlesource.com) + as [google/goblet](https://github.com/google/goblet), + and also used in a modified form at Canva + as [canva-public/goblet](https://github.com/canva-public/goblet). + + A different [Goblet](https://pythonhosted.org/goblet/) + _was_ some time ago a web frontend for Git repositories in Python, + using libgit2 and Flask; the [seveas/goblet](https://github.com/seveas/goblet) + repository has been archived by the owner. ++ [`nb`](https://xwmx.github.io/nb/) is a command line and local web + note-taking, bookmarking, archiving, and knowledge base application + with Git-backed versioning and syncing. ++ The [Git Reference](https://git.github.io/git-reference/) site is meant to be a + quick reference for learning and remembering the most important and commonly + used Git commands, but it can also be used as a tutorial. Every page will also + link to more in-depth Git documentation. ++ [email + git = <3: Learn to use email with Git!](https://git-send-email.io/) + is a guide to contributing to email-driven projects like the Linux kernel, PostgreSQL, or Git. + Covers various operating systems and distributions. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Johannes Schindelin and Bruno Brito. diff --git a/_posts/2022-11-30-edition-93.markdown b/_posts/2022-11-30-edition-93.markdown new file mode 100644 index 000000000..63ea171a0 --- /dev/null +++ b/_posts/2022-11-30-edition-93.markdown @@ -0,0 +1,306 @@ +--- +title: Git Rev News Edition 93 (November 30th, 2022) +layout: default +date: 2022-11-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 93 (November 30th, 2022) + +Welcome to the 93rd 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](https://git.github.io). + +This edition covers what happened during the month of October 2022. + +## Discussions + + + +### Reviews + +* [[PATCH] archive: add --recurse-submodules to git-archive command](https://lore.kernel.org/git/pull.1359.git.git.1665597148042.gitgitgadget@gmail.com/) + + Heather Lapointe sent a patch to the mailing list that + enabled `git archive` to also include submodule contents in the + archives it produces. + + She said she was inspired by + [a GitHub issue more than 160 upvotes](https://github.com/dear-github/dear-github/issues/214) + and thought the implementation wouldn't be too difficult as most of + the plumbing was already in place. + + One of the trickier parts was changing the `read_tree()` function to + support other repos than the current one by not using the + `the_repository` global variable. + + Heather soon sent + [a version 2 patch series](https://lore.kernel.org/git/pull.1359.v2.git.git.1665660960.gitgitgadget@gmail.com/). + This patch series contained only 2 patches. The first one was + identical to the one previously sent, while the second one fixed a + submodule traversal bug in `read_tree()` introduced by the first + patch. + + René Scharfe replied to Heather, noticing that the cover letter of + the patch series had a TODO list with a number of items, most of + which seemingly already addressed. As the stats in the cover letter + showed 16 files changed, 269 insertions, and 96 deletions, he said it + was a bit much for a few patches, and suggested splitting them. + + Heather replied to René that the TODO list came from GitGitGadget. + And René found that this tool was using an + [HTML-to-text converter](https://github.com/html-to-text/node-html-to-text) + that [doesn't handle checkboxes nicely by default](https://github.com/html-to-text/node-html-to-text/issues/260). + René and Heather then discussed how to split the patches, and a bit + how the first patch was implemented. + + Heather then sent + [a version 3 of her patch series](https://lore.kernel.org/git/pull.1359.v3.git.git.1665973401.gitgitgadget@gmail.com/) + that split her previous patch series into 8 patches. + + Junio Hamano, the Git maintainer, along with Glen Choo, Jonathan + Tan, Phillip Wood and Ævar Arnfjörð Bjarmason all commented on some + of the patches in this series and suggested small improvements. + + The Review Club [selected this patch series](https://lore.kernel.org/git/kl6l35bbsubq.fsf@chooglen-macbookpro.roam.corp.google.com/) + to be reviewed by participants on Wednesday October 26, and + participants generally agreed that "this is a really well-structured + and easy-to-follow series :)" and that "as far as new contributions go, + this is really good". + + Unfortunately it looks like Heather has been swamped with her own + work and didn't have time to send a new version yet. Hopefully + though we will get this very requested feature soon. + + As a side effect of the discussion, [GitGitGadget formats checkboxes nicely now](https://github.com/gitgitgadget/gitgitgadget/pull/1128). + + + +## Developer Spotlight: Bagas Sanjaya + +* Who are you and what do you do? + + I'm Bagas Sanjaya. I'm currently unemployed (due to my autistic condition + that makes working formally isn't the nice option for me). + +* What would you name your most important contribution to Git? + + Adding the `INSTALL_STRIP` variable when installing Git from source (with + help from other Git developers due to lack of coding experience). + +* For the benefit of the readers, is it possible for you to elaborate a + bit on what the `INSTALL_STRIP` variable would help them with? + + Typically users install Git from binary package provided by the + distribution. For those who wish to install from source, they can + install build-time dependencies first, then simply do `make && make install`. + However, it will install Git binaries with debugging info, which + can take a lot of space. In addition, many Unix systems have `install(1)` + that has an option to automatically strip debugging info during + installation. That's why `INSTALL_STRIP` is introduced; if supported, + users can run `make INSTALL_STRIP=-s install` to install + stripped binaries. + +* What are you doing on the Git project these days, and why? + + I'm mostly translating po strings in recent days. Otherwise I'm hacking + on Linux kernel documentation. + +* 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? + + As an autistic man, I'd like to meet developers who can accommodate my + special needs (often different from neurotypical people) so that I + can thrive my living. + +* It is good to know that you would like to meet compassionate developers. + Is it possible for you expand a bit on what you would like to change / + enhance in Git when you get a team of such developers for a year? + + I think more on communication. Sure, communicating with email makes life + easier for autistic developers (less physical interaction). However, + autistic people have different ways of communicating. For me, I need + a lot of time to process the information from a mailing list and formulate + the wording (which is due to comorbid ADHD). Thus, the community + expectation should have been adapted to individual needs, e.g. by being + more explicit on explanation of code of conduct when a new developer + is contributing. If he/she doesn't understand the CoC, he/she can + proactively ask the community about points that he/she doesn't understand. + + In summary, besides adaptation from the community, there must be + initiatives from developers themselves. + +* What is your favorite Git-related tool/library, outside of Git + itself? + + Gitea. I deployed the server application to the LXD instance on my + laptop as repository mirror when I push my favorite repos there. + +* You have experience translating for Git. Is there something that + could be done differently to aid with the translation effort? + + I think we need something like self-hosted Weblate to enable anyone + with translation skills to easily submit translated strings. But honestly + deploying one is tricky; I tried to deploy Weblate but couldn't get strings + from Git source code to be available for translation on the interface. + +* How does your mailing list workflow look like? + + Simplicistic. After configuring `git send-email` to send through outgoing + relay of your mail provider and your email clients to send plain text + email, unaltered (no line wrapping, intact tabs and spaces), you can + contribute by sending patches with the former and reviewing with the + latter. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + You need to find a joy in application development. If it doesn't makes + you enjoy, you may need to take a break or find something else. + +* If there's one tip you would like to share with other Git + developers, what would it be? + + As autistic, special interest fascinates me. You need to find one + in this project, while staying up-to-date with the general picture. + + +## Releases + ++ Git [2.39.0-rc0](https://public-inbox.org/git/xmqqr0xum8tn.fsf@gitster.g/) ++ Git for Windows [2.39.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.39.0-rc0.windows.1) ++ GitLab [15.6](https://about.gitlab.com/releases/2022/11/22/gitlab-15-6-released/) +[15.5.4](https://about.gitlab.com/releases/2022/11/14/gitlab-15-5-4-released/), +[15.4.5](https://about.gitlab.com/releases/2022/11/14/gitlab-15-4-5-released/), +[15.5.3](https://about.gitlab.com/releases/2022/11/08/gitlab-15-5-3-released/), +[15.5.2, 15.4.4, and 15.3.5](https://about.gitlab.com/releases/2022/11/02/security-release-gitlab-15-5-2-released/) ++ Bitbucket Server [8.6](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.4.7](https://www.gerritcodereview.com/3.4.html#347), +[3.4.8](https://www.gerritcodereview.com/3.4.html#348), +[3.5.4](https://www.gerritcodereview.com/3.5.html#354), +[3.6.3](https://www.gerritcodereview.com/3.6.html#363), +[3.7.0](https://www.gerritcodereview.com/3.7.html#370) ++ GitHub Enterprise [3.7.1](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.1), +[3.6.4](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.4), +[3.5.8](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.8), +[3.4.11](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.11), +[3.3.16](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.16), +[3.7.0](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.0) ++ GitKraken [8.10.3](https://help.gitkraken.com/gitkraken-client/current/#version-8-10-3), +[8.10.2](https://help.gitkraken.com/gitkraken-client/current/#version-8-10-2) ++ Tower for Mac [9.1](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) + +## Other News + +__Various__ + ++ Shaoxuan Yuan, + [who participated in the GSoC 2022](https://ffyuanda.github.io/blog/GSoC-final-blog/), + is looking for a full time internship from mid-June 2023 to October + 2023 or a part-time one starting now. See + [his resume](https://github.com/git/git.github.io/files/9995808/Resume_Shaoxuan_Yuan.pdf) + for more information. + +__Light reading__ + ++ [Working with stacked branches in Git is easier with `--update-refs`](https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/) + (an option which was included in Git 2.38, in October 2022) + by Andrew Lock on his blog, \.NET Escapades. ++ [Bringing revsets to Git](https://blog.waleedkhan.name/bringing-revsets-to-git/) + by Waleed Khan (@arxanas) describes how one can use the + [git-branchless](https://github.com/arxanas/git-branchless) suite of tools + (mentioned in [Git Rev News Edition #76](https://git.github.io/rev_news/2021/06/27/edition-76/) + and [#90](https://git.github.io/rev_news/2022/08/31/edition-90/)) + and [Mercurial's revset notation](https://www.mercurial-scm.org/repo/hg/help/revsets) + to form complex queries about a repo, display their results (for example in a graph view), + rebase changes using "patch-stack" workflow, and improve testing. ++ [Sapling: Source control that’s user-friendly and scalable](https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/) + by Durham Goode on Engineering at Meta (Facebook) blog. + At this point, only the client side of the system has been released.
+ You can find some comments about it at: + + [Meta's Sapling source-code management system](https://lwn.net/Articles/915104/) on LWN.net. + + [Sapling: A new source control system with Git-compatible client](https://news.ycombinator.com/item?id=33612410&utm_term=comment) on Hacker News. ++ [Git evolve: tracking changes to changes](https://lwn.net/Articles/914041/) + ([free preview link](https://lwn.net/SubscriberLink/914041/fcffc20089b907b0/)) + by Jonathan Corbet on LWN.net. ++ [Using gitStream for 'Continuous Merge': automatically approving safe PRs, + assigning reviewers, estimating review time, and more](https://blog.jakelee.co.uk/using-gitstream-to-improve-pr-workflow/) + by Jake Lee on his blog. ++ [My favorite Git tools](https://opensource.com/article/22/11/git-tools) + by Dwayne McDaniel on Opensource\.com. ++ [Git concepts in less than 10 minutes](https://opensource.com/article/22/11/git-concepts) + by Dwayne McDaniel on Opensource\.com. ++ [#gitPanic - Interactive Rebase](https://dev.to/abbeyperini/gitpanic-interactive-rebase-48fe) + by Abbey Perini on DEV\.to (part of the [gitPanic series](https://dev.to/abbeyperini/series/20421)). ++ [Top 12 Advanced Git Commands To Know](https://blog.openreplay.com/top-dozen-advanced-git-commands-to-know/) + by El-Glory Oriabure on OpenReplay blog, with admittedly some pretty basic commands + in there. ++ [Light Git repository checkout](https://github.polettix.it/ETOOBUSY/2022/10/26/light-git-pwc/) + with [`git sparse-checkout`](https://www.git-scm.com/docs/git-sparse-checkout) + by Flavio Poletti (@polletix) on his ETOOBUSY blog. ++ [The Perfect Commit](https://simonwillison.net/2022/Oct/29/the-perfect-commit/) + by Simon Willison on his Weblog. ++ [New Git guidelines: We have switched to Conventional Commits](https://happy-coding.visuellverstehen.de/posts/new-git-guidelines-we-have-switched-to-conventional-commits-1p0c) + by Malte Riechmann for visuellverstehen on the Happy Coding blog. + (post is also available on [DEV.to](https://dev.to/visuellverstehen/new-git-guidelines-we-have-switched-to-conventional-commits-1p0c)). + The [Conventional Commits](https://www.conventionalcommits.org/) specification + was first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/). ++ [How to Write the Perfect Commit Message](https://www.git-tower.com/blog/how-to-write-the-perfect-commit-message/) by Bruno Brito on Tower’s blog. ++ [Why You Should Use a Git Client](https://dev.to/brunobrito/why-you-should-use-a-git-client-2dpe) by Bruno Brito on dev.to. ++ Jakub Kozłowski [tweeted](https://twitter.com/kubukoz/status/1590135952886075393) + that Git conflict markers are parsed as valid Scala code, though you need to add some + appropriate [definitions](https://gist.github.com/kubukoz/894b049b5c1747f17c1e052754640b32), + now available as a [scala-git-markers library](https://github.com/polyvariant/scala-git-markers), + for it to run ;-). Explained in more detail in his [video on YouTube](https://www.youtube.com/watch?v=rSk_mea4U1E). + +__Easy watching__ ++ [Understanding Git Flow](https://www.youtube.com/watch?v=HrA_BbWUKRk): A look at the operations of Git Flow through the Flying Logic visualisation of the branches and release process. The channel also has Git visualisations of Collaboration, merge and rebase, detached HEAD, and 'What's a DAG'. + +__Git tools and sites__ + ++ [Sapling SCM](https://sapling-scm.com/) is a scalable, user-friendly + source control system that supports cloning and interacting with Git repositories, + and can be used by individual developers to work with GitHub + and other Git hosting services. ++ [Stacked Git](https://stacked-git.github.io/), **StGit** for short, + is an application for managing Git commits as a stack of patches + (with its first release in 2005, it is almost as old as Git itself). + StGit was mentioned by Yann Dirson in the [Git Rev News Edition #74](https://git.github.io/rev_news/2021/04/30/edition-74/) + developer spotlight. ++ [Mergify](https://github.com/brooksdavis/mergify) is a tool + to merge changes from a branch one commit at a time, + most useful when merging changes to a highly diverged fork of a project. + + Note that there is also [Mergify.com](https://mergify.com/), mentioned in + [Git Rev News Edition #87](https://git.github.io/rev_news/2022/05/26/edition-87/), + a web service free for open-source projects for automatizing pull requests + and securing the code merge using a merge queue. ++ [git-mergify-rebase](https://github.com/CTSRD-CHERI/git-mergify-rebase) + is a replacement for mergify, written using `git rebase` for better performance, + supporting most of features of the original. ++ [Nx](https://nx.dev/) is a next generation build system for Node\.js, + with first class monorepo support and various integrations. + Listed in the tools section of [monorepo.tools](https://monorepo.tools/), + a site mentioned in [Git Rev News Edition #84](https://git.github.io/rev_news/2022/02/28/edition-84/). ++ [gitStream](https://gitstream.cm/) by LinearB is a GitHub app + that aims to improve the pull request review process. ++ [tweets](https://github.com/diracdeltas/tweets) + is @bcrypt's janky twitter "replacement", + using Git commit messages and GitHub for "microblogging"; + see the [announcement on Twitter](https://twitter.com/bcrypt/status/1588416861552582657) ;-). + Written as set of Bash scripts and a Makefile. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Bagas Sanjaya, Bruno Brito, Glen Choo and René Scharfe. diff --git a/_posts/2022-12-31-edition-94.markdown b/_posts/2022-12-31-edition-94.markdown new file mode 100644 index 000000000..9c4db2373 --- /dev/null +++ b/_posts/2022-12-31-edition-94.markdown @@ -0,0 +1,405 @@ +--- +title: Git Rev News Edition 94 (December 31st, 2022) +layout: default +date: 2022-12-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 94 (December 31st, 2022) + +Welcome to the 94th 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](https://git.github.io). + +This edition covers what happened during the months of November 2022 and December 2022. + +## Discussions + +### General + +* [What's cooking in git.git (Nov 2022, #05; Tue, 22)](https://lore.kernel.org/git/xmqqfseargo4.fsf@gitster.g/) + + Junio Hamano, the Git maintainer, sent one of his usual "What's + cooking in git.git" emails to the mailing list. At the beginning of + the email though he thanked everybody for "successfully concluding + the 'bus factor' exercise". + + It was indeed the first time in a few years that he temporarily + handed over the maintainership of the project to someone else, in + this case Taylor Blau, as he was having a vacation. It's called a + 'bus factor' exercise as it's supposed to make a transition smoother + in case the current maintainer would be "hit by a bus". + + The [previous "What's cooking in git.git" email](https://lore.kernel.org/git/Y3g95OYdwzq2OP3z@nand.local/) + had been sent a few days before by Taylor, who also thanked + everyone, as he saw that Junio was back online again. + + + +### Support + +* [Git Bug Report: out of memory using `git tag`](https://lore.kernel.org/git/CABYbkvP=fMmaFUD3bQbeQ-XKiMSP6g-u0p7Vq1Qt_K5=D5WJ+A@mail.gmail.com/) + + Martin Englund sent a bug report to the Git mailing list saying that + after creating a signed tag using a ssh-agent key, he ran the + following command that should have shown the body part of the tag + contents: + + `git tag -l --format '%(contents:body)' v0.6.1` + + But instead of displaying anything, the command crashed with: + + `fatal: Out of memory, malloc failed (tried to allocate 18446744073709551266 bytes)` + + Peff, alias Jeff King, thanked Martin for the report and said he had + found the function where the crash happened and the reason why it + happened. He also provided minimal reproduction instructions as well + as the commit that introduced the bug, and he put the author of that + commit in CC of his email. + + Philippe Blain, the author of the commit, thanked Peff for the + information and said he would try to find a fix for the bug. + + Peff replied to Philippe that after sleeping on the issue, he fully + understood what happened. He said there were actually two closely + related bugs and he was sending 2 patches to fix them both. + + The [first patch](https://lore.kernel.org/git/Y2IfT0UFJ7H%2FmHMz@coredump.intra.peff.net/) + was a fix for cases where there was no blank line between the + subject of a tag and the signature in it, and when the signature + also contained no blank line. Such signatures could be generated by + ssh. + + In such cases the code wasn't properly detecting the start of the + signature and was instead using the end of the commit. When + computing the signature length, this would give a negative value, + which was then converted to a huge value as the variable for the + signature length used an unsigned type. In turn when allocating + memory for the signature, this would lead to the crash as it wasn't + possible to allocate the requested amount of memory for it. + + The [second patch](https://lore.kernel.org/git/Y2IfwL96Ku%2FdGuJR@coredump.intra.peff.net/) + fixed a similar bug that occurred when there was a blank line in the + signature but not before it, and this blank line ended with both the + CR (Carriage Return) and LF (Line Feed) characters instead of only + the latter. + + In that case, the start of the signature was also not properly + detected, so a negative value was assigned to the variable for the + signature length, which led to a crash when allocating memory for + the signature. + + Both patches are very well explained in long commit messages. This + prompted Elijah Newren to reply to Peff joking about the fact that + Peff's patches didn't set new records for the ratio of commit + message lines to changed code, as a previous patch from Elijah + contained 96 lines of explanation to describe a one-line fix. + + In the same spirit, Peff replied to Elijah providing a script to + find the commit with the highest ratio between lines of explanations + in the commit message and the lines in the patch. He said that the + script would show "a few in the 100's". + + Ævar Arnfjörð Bjarmason then replied to Peff contesting the method + used in Peff's scripts and suggesting computing "the Levenshtein + distance of the pre- and post-image", and then using that distance + to commit message length instead of the previous ratio, which would + find other winners. + + Elijah ended this subthread of discussion about the biggest comment + to code ratio in a commit in the Git repo with: + + "Hehe, my offhand joke started a contest over the whimsical question of + who's the most long-winded. I think my work here is done. :-)" + + Eric Sunshine, after reviewing Peff's patches, commented that they + were well explained and that he found no suggestion to improve on + them. + + Philippe agreed with Eric that the patches were very well explained + and asked Peff about the case where there would be both no blank + line and lines terminated with both CR and LF in the tag. Peff then + confirmed that this would be properly handled by his first patch. + + Taylor Blau, who was handling the maintainer's role in the project + at that time, as Junio Hamano was having a vacation, also agreed + that the patches were very well explained, and agreed to take + them. The patches were then merged and part of the Git v2.39.0 + feature release. + +## Developer Spotlight: ZheNing Hu + +* Who are you and what do you do? + + My name is ZheNing Hu, and I am a participant in the GSOC 2021 + Git community. Currently I am interning at Alibaba (China). + +* What would you name your most important contribution to Git? + + When I used `git shortlog --author="ZheNing Hu"` to look at the patches + I contributed, I was ashamed to find that my patches are quite small and + simple, because I'm more of a Git learner right now 😄. + + If I had to pick one, I'd say it's adding the `--trailer` option to `git commit`. + It is very convenient to add something like "Signed-off-by", "Reviewed-by" + at the end of the commit message. + +* What are you doing on the Git project these days, and why? + + Recently I've been working on [implementing a `--scope` option for `git diff`](https://lore.kernel.org/git/pull.1398.v3.git.1669723221.gitgitgadget@gmail.com/) + and other Git commands. It tries to limit the scope of the file path to the + [sparse specification](https://github.com/git/git/blob/7c2ef319c52c4997256f5807564523dfd4acdfc7/Documentation/technical/sparse-checkout.txt#L73). + + The reason I wanted to implement this feature is that I was researching + how monorepo users collaborate and discovered that `git pull` might download + Git objects outside of the sparse specification. Meanwhile, Elijah Newren + is contributing the [technical documentation of git-sparse-checkout](https://git-scm.com/docs/sparse-checkout) + [ [source](https://github.com/git/git/blob/7c2ef319c52c4997256f5807564523dfd4acdfc7/Documentation/technical/sparse-checkout.txt) ], + the article details how other Git commands should properly recognize + sparse-checkout, and suggests implementing the `--scope` option, which + I think will solve the problem I encountered above, so I hope to implement it. + + This patch was put on hold by me for a while, as no one seemed to review it. + +* 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'd like to have a well-developed concurrency model on the Git server side. + See ["Question: How to execute git-gc correctly on the git server"](https://lore.kernel.org/git/CAOLTT8Tt3jW2yvm6BRU3yG+EvW1WG9wWFq6PuOcaHNNLQAaGjg@mail.gmail.com/) + for more details. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + `git checkout`. It can be used to switch branches or restore working tree files, + I think these two functions are somewhat coupled. I don't know if `git switch` and + `git restore` would be perfect replacements for it. + +* What is your favorite Git-related tool/library, outside of + Git itself? + + [scalar](https://git-scm.com/docs/scalar). Now I really like to use scalar to + download Git repositories to save time. + +* Do you happen to have any memorable experience w.r.t. contributing to + the Git project? If yes, could you share it with us? + + Mainly during GSOC, my mentor Christian Couder and many people in the Git + community helped me, and I learned how to participate in open source for the + first time. It was a great experience to be brave and discuss technology with + people from all over the world. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + GitGitGadget. It has a clean commit process, and it runs GitHub action to + help me find out if my patch is buggy before committing to the community. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + 1. First become its user + 2. Understand its principles through the documentation + 3. Read the source code to understand the general structure of the project + 4. Understand some sub-modules of the project by solving some problems + 5. Learn from others with an open mind + +* If there's one tip you would like to share with other Git + developers, what would it be? + + Stay curious about technology. + + +## Releases + ++ Git [2.39.0](https://public-inbox.org/git/xmqqlencspnl.fsf@gitster.g/), +[2.38.2](https://public-inbox.org/git/xmqqv8miv7qj.fsf@gitster.g/), +[2.39.0-rc2](https://public-inbox.org/git/xmqq7cz59o6y.fsf@gitster.g/), +[2.39.0-rc1](https://public-inbox.org/git/xmqqedtlynq8.fsf@gitster.g/) ++ Git for Windows [2.39.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.39.0.windows.2), +[2.39.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.39.0.windows.1), +[2.39.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.39.0-rc2.windows.1), +[2.39.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.39.0-rc1.windows.1) ++ GitHub Enterprise [3.7.2](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.2), +[3.6.5](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.5), +[3.5.9](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.9), +[3.4.12](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.12), +[3.3.17](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.17) ++ GitLab [15.7](https://about.gitlab.com/releases/2022/12/22/gitlab-15-7-released/) +[15.6.3](https://about.gitlab.com/releases/2022/12/16/gitlab-15-6-3-released/), +[15.5.6](https://about.gitlab.com/releases/2022/12/08/gitlab-15-5-6-released/), +[15.6.2](https://about.gitlab.com/releases/2022/12/02/gitlab-15-6-2-released/), +[15.6.1, 15.5.5 and 15.4.6](https://about.gitlab.com/releases/2022/11/30/security-release-gitlab-15-6-1-released/) ++ GitKraken [9.0.0](https://help.gitkraken.com/gitkraken-client/current/) ++ Sourcetree [4.2.1](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.1.html) ++ git-assembler [1.3](https://lore.kernel.org/git/87tu2927yt.fsf@wavexx.thregr.org/) + + +## Other News + +__Various__ + +* Siddharth Asthana, + [who worked on Git during his GSoC 2022 for GitLab](https://summerofcode.withgoogle.com/archive/2022/projects/yaKP2iJK), + is looking for a 6-month Engineering internship, either full-time + starting from mid-July 2023 or part time starting now. See + [his resume](https://github.com/git/git.github.io/files/10180136/Siddharth_Asthana_Resume.pdf) + for more information. +* [Highlights from Git 2.39](https://github.blog/2022-12-12-highlights-from-git-2-39/) + by Taylor Blau on GitHub Blog. +* [Put `glab` at your fingertips with the GitLab CLI](https://about.gitlab.com/blog/2022/12/07/introducing-the-gitlab-cli/) + by Kai Armstrong on GitLab Blog. +* [Andrew Morton's first pull request](https://lwn.net/Articles/895689/) + by Jonathan Corbet on LWN\.net (from May 2022). + * [Git Rev News Edition 14 (April 20th, 2016)](https://git.github.io/rev_news/2016/04/20/edition-14/) + mentioned, when describing discussions at the Git Contributor Summit + (part 1, about big repos and big files), that Andrew Morton uses (used?) + [quilt](https://savannah.nongnu.org/projects/quilt) + to maintain his "-mm" kernels, and that he sent patches by email. + +__Light reading__ + +* [Billions of unnecessary files in GitHub](https://dev.to/szabgab/billions-of-unnecessary-files-in-github-i85) + and Git repositories in general, due to missing or lacking + [`.gitignore`](https://git-scm.com/docs/gitignore) + files. Article by Gabor Szabo on DEV\.to (also known as The Practical Dev). + There is also some good information in the comments. +* [What are your git aliases?](https://dev.to/imjoseangel/what-are-your-git-aliases-43om) + by Jose Angel Munoz on DEV\.to. +* [How to Close a Pull Request - Merge Commit vs Squash vs Rebase on GitHub](https://leonardomontini.dev/close-pr-strategy-merge-commit-squash-rebase/) + by Leonardo Montini. +* [What is GitOps?](https://about.gitlab.com/topics/gitops/) on GitLab. + * The topic of GitOps was mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/), + [#43](https://git.github.io/rev_news/2018/09/19/edition-43/), + [#61](https://git.github.io/rev_news/2020/03/25/edition-61/), + [#62](https://git.github.io/rev_news/2020/04/23/edition-62/), + and [#89](https://git.github.io/rev_news/2022/07/31/edition-89/) +* [GitOps viewed as part of the Ops evolution](https://about.gitlab.com/blog/2021/07/12/gitops-as-the-evolution-of-operations/) + by Viktor Nagy o GitLab Blog (2021). +* [A meta talk about Git strategies](https://dev.to/mortenolsen/deployment-confidence-with-git-4b0b) + for deployment (GitOps-like), by Morten Olsen on DEV\.to. +* [Rebases in Git and why you shouldn't be afraid of them](https://how-to.dev/rebases-in-git-and-why-you-shouldnt-be-afraid-of-them) + by Marcin Wosinek for [How to dev](https://how-to.dev/) + (also [reposted on DEV\.to](https://dev.to/how-to-dev/rebases-in-git-and-why-you-shouldnt-be-afraid-of-them-1fb5)). +* [Take advantage of Git rebase](https://about.gitlab.com/blog/2022/10/06/take-advantage-of-git-rebase/) + by Christian Couder on GitLab Blog. +* [Split a commit into 2 commits with `git rebase`](https://dev.to/thelarkinn/split-a-commit-into-2-commits-with-git-rebase-31ee) + by Sean Larkin on DEV\.to. +* [Minimum Viable Git for Trunk-based Development](https://blog.trunk.io/minimum-viable-git-for-trunk-based-development-81a5da7a77a7) + by Eli Schleifer on [trunk.io](https://trunk.io/) blog (a Medium-based blog). + * [Trunk Based Development](https://trunkbaseddevelopment.com/) + was mentioned directly in [Git Rev News Edition #24](https://git.github.io/rev_news/2017/02/22/edition-24/) + and [#73](https://git.github.io/rev_news/2021/03/27/edition-73/). + * [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/), + describes Trunk-Based Development in the section + [Looking at some branching policies](https://martinfowler.com/articles/branching-patterns.html#LookingAtSomeBranchingPolicies). +* [Benefits of Using Pull Requests for Collaboration and Code Review](https://developer.nvidia.com/blog/benefits-of-using-pull-requests-for-collaboration-and-code-review/) + by Fatos Morina on NVIDIA Developer Technical Blog. +* [How to revert a merge commit then merge again](https://dev.indooroutdoor.io/how-to-revert-a-merge-commit-and-then-merge-again) + by Jb Rocher on his blog + ([also on DEV\.to](https://dev.to/jbrocher/how-to-revert-a-merge-commit-then-merge-again-hoo)). +* [Git worktree](https://github.polettix.it/ETOOBUSY/2022/11/22/git-worktree/) + by Flavio Poletti (@polettix) on his ETOOBUSY blog. +* [Git Notes: Git's Coolest, Most Unloved Feature](https://tylercipriani.com/blog/2022/11/19/git-notes-gits-coolest-most-unloved-feature/) + by Tyler Cipriani on his blog. + * You can find various uses of the _Git notes_ feature mentioned in Git Rev News: + [marking test suite successes](http://who-t.blogspot.de/2015/07/using-git-notes-for-marking-test-suite.html) + in [#6](https://git.github.io/rev_news/2015/08/05/edition-6/), + and [maintaining a high quality change log](https://harrow.io/blog/effortlessly-maintain-a-high-quality-change-log-with-little-known-git-tricks/) + in [#34](https://git.github.io/rev_news/2017/12/20/edition-34/). + * [git-appraise](https://github.com/google/git-appraise), + a distributed code review system for Git repos using git notes + was mentioned in [Git Rev News Edition #11](https://git.github.io/rev_news/2016/01/13/edition-11/). +* [Learn Git: 3 commands to level up your skill](https://opensource.com/article/22/11/advanced-git-commands) + by Dwayne McDaniel on Opensource\.com. +* [Code version best practices with clean commit formats](https://blogs.halodoc.io/code-version-best-practices-with-clean-commit-formats/), + following [Angular commit convention guidelines](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit), + by Chaitanya S. on Halodoc blog. + * [Conventional Commit specification](https://www.conventionalcommits.org/) + was first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/). + * [commitlint](https://commitlint.js.org/#/) was first mentioned + in [Git Rev News Edition #81](https://git.github.io/rev_news/2021/11/29/edition-81/), + [Commitizen](http://commitizen.github.io/cz-cli/) + in [#72](https://git.github.io/rev_news/2021/02/27/edition-72/), + [Husky](https://github.com/typicode/husky) + in [#63](https://git.github.io/rev_news/2020/05/28/edition-63/), + and [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog) + in [#81](https://git.github.io/rev_news/2021/11/29/edition-81/). +* [Resolving Merge Conflicts with Visual Studio Code](https://leonardomontini.dev/merge-conflict-vscode/) + by Leonardo Montini (also [on This is Learning DEV\.to blog](https://dev.to/this-is-learning/resolving-merge-conflicts-with-visual-studio-code-1mn1)). +* [30+ Commonly Asked Git Interview Questions](https://www.interviewbit.com/git-interview-questions/) + on InterviewBit. + +* [Extremely Linear Git History](https://westling.dev/b/extremely-linear-git), + where first commit in a repo hash a hash that starts with `0000000`, + the second commit is `0000001`, the third is `0000002`, and so on + is possible with [extremely-linear](https://github.com/zegl/extremely-linear) + (aka `git linearize`) tool. Article and tool by Gustav Westling. ☺ + * [Git Rev News Edition #24](https://git.github.io/rev_news/2017/02/22/edition-24/) + mentions in passing the [git-sham](https://bitbucket.org/tpettersen/git-sham) tool, + which can be used to produce subsequent commits with SHA-1 identifiers + beginning with subsequent numbers - but the tool doesn't seem to exist anymore at its original URL. + + + + +__Git tools and sites__ + +* [git-credential-oauth](https://github.com/hickford/git-credential-oauth) + is a Git credential helper that securely authenticates to GitHub, + GitLab, BitBucket and other forges using OAuth. +* [semantic-release](https://github.com/semantic-release/semantic-release) + ([documentation](https://semantic-release.gitbook.io/semantic-release/)) + is a fully automated version management and package publishing Node\.js tool. +* [Release Please](https://github.com/googleapis/release-please) is a Node\.js tool that + automates CHANGELOG generation, the creation of GitHub releases, + and version bumps for your projects; it does so by parsing your Git history + and looking for [Conventional Commit](https://www.conventionalcommits.org/) messages. +* [gitignore.io](https://www.toptal.com/developers/gitignore/) by Toptal + is a service that creates useful `.gitignore` files for your project. + * [github/gitignore](https://github.com/github/gitignore) + is GitHub's collection of `.gitignore` file templates. + * Atlassian's Bitbucket has a [`.gitignore` tutorial](https://www.atlassian.com/git/tutorials/saving-changes/gitignore). + * GitLab provides a [.gitignore API](https://docs.gitlab.com/ee/api/templates/gitignores.html) + on all tiers. + * [gig](https://github.com/hackrslab/gig), + a Node\.js command-line tool for quickly setting up `.gitignore` files, + which uses GitHub's gitignore repository for gitignore templates, + was mentioned in [Git Rev News Edition #6](https://git.github.io/rev_news/2015/08/05/edition-6/). + * [.gitignore Generator](https://marketplace.visualstudio.com/items?itemName=piotrpalarz.vscode-gitignore-generator) + extension for _Visual Studio Code_, which uses the gitignore.io API, + was mentioned in [Git Rev News Edition #57](https://git.github.io/rev_news/2019/11/20/edition-57/). +* [Diffchecker.com](https://www.diffchecker.com/) is an online service that + will compare text to find the difference between two text files; there is also + an option for comparing [images](https://www.diffchecker.com/image-compare/), + [PDFs](https://www.diffchecker.com/pdf-compare/), + and [spreadsheets](https://www.diffchecker.com/excel-compare/) in `xls`/`xlsx`/`xlsm`/`xlsb`, `csv`, `txt`, `dif`, and `ods` formats. + There are also commercial Diffchecker Pro service and Diffchecker Desktop apps. +* [OpenGitOps](https://opengitops.dev/) is a set of open-source standards, + best practices, and community-focused education to help organizations + adopt a structured, standardized approach to implementing GitOps. + * [GitOps.tech](https://www.gitops.tech/), a similar site that aggregates the essence of GitOps + (and includes free [GitOps: Cloud-native Continuous Deployment](https://leanpub.com/gitops) + e-book, published via Leanpub), was mentioned in passing in + [Git Rev News Edition #62](https://git.github.io/rev_news/2020/04/23/edition-62/). +* [Semantic Versioning Specification (SemVer)](https://semver.org/) + is a simple set of rules and requirements that dictate + how version numbers are assigned and incremented. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from ZheNing Hu, Philip Oakley, Junio Hamano and +Mirth Hickford. diff --git a/_posts/2023-01-31-edition-95.markdown b/_posts/2023-01-31-edition-95.markdown new file mode 100644 index 000000000..4d197137d --- /dev/null +++ b/_posts/2023-01-31-edition-95.markdown @@ -0,0 +1,381 @@ +--- +title: Git Rev News Edition 95 (January 31st, 2023) +layout: default +date: 2023-01-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 95 (January 31st, 2023) + +Welcome to the 95th 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](https://git.github.io). + +This edition covers what happened during the months of December 2022 and January 2023. + +## Discussions + + + + + +### Support + +* [Question: How to execute git-gc correctly on the Git server?](https://lore.kernel.org/git/CAOLTT8Tt3jW2yvm6BRU3yG+EvW1WG9wWFq6PuOcaHNNLQAaGjg@mail.gmail.com/) + + ZheNing Hu asked about how he could run `git gc` correctly on his + own Git server. He seemed to be afraid by + [the `git gc` documentation](https://git-scm.com/docs/git-gc) + saying that there is a risk of failures and repository corruption + when the command is run concurrently with other Git processes. + + He said that he + [read about `git gc --cruft`](https://github.blog/2022-09-13-scaling-gits-garbage-collection/) + which could overcome these issues, but that he was still using Git + v2.35 on his server while `--cruft` was introduced in v2.38. + + He also wondered if there was a need for `git gc` to set a + repository level lock blocking most or all other Git operations, + and what these operations -- especially `git clone` and `git push` -- + should do or report when hitting this lock. + + Ævar Arnfjörð Bjarmason replied that running `git gc` on a "live" + repo was always racy, but the odds of corrupting the repo were + becoming very small when the value of the `gc.pruneExpire` config + option was increased. He said that the default setting for this + option, 2 weeks, was "more than enough for even the most paranoid + user". + + About `--cruft`, Ævar thought that its purpose was not only to avoid + possible repo corruption, but also to allow more aggressive gc + (garbage collection). + + He also wondered if this question was about large hosting sites like + GitHub and GitLab, where `git gc` is run on live repos, and + suggested not to worry in this case, but to take backups. + + Jeff King, alias Peff, replied to Ævar saying he was "a bit less + optimistic" about the corruption risk decreasing when + `gc.pruneExpire` was increased because there was no atomic view of + the ref namespace. So renaming a branch for example was risky + because it could be seen as removing a branch and adding a different + one by any concurrent process. Such a process could be another `push`, + not just a `gc`. + + Peff also said that using `--cruft` was not so much about avoiding + corruption, but about keeping cruft objects out of the main pack to + reduce the cost of lookups and bitmaps, and about avoiding to + explode a lot of old objects into loose objects, which could be very + bad for performance. + + Ævar replied to Peff discussing further when corruption was likely + or not to happen, which issues `--cruft` could help with, and a + patch he sent in the past to reduce possible corruption. He also + suggested running `git gc` on the least busy hours of the day. + + Later Taylor Blau replied to Ævar and Peff discussing `--cruft` in + the context of single-pack bitmaps or multi-pack (MIDX) bitmaps, and + also in the context of GitHub. + + In the meantime, Michal Suchánek replied to Ævar's first email + asking what the 2 week default expiration time applied to. He also + said that he got corrupted repos with less than 100 users "and some + scripting" which went away when `gc` was disabled. + + Peff replied to Michal, saying that the expiration time applied to + the `mtime` on the object file (or the pack containing it), and + confirmed that it was "far from a complete race-free solution". + + ZheNing also replied to Michal saying that he preferred "no error at + all" to a "small probability of error". + + Michal replied to Peff listing some workflows that are more likely + to lead to a corrupt repo, like deleting branches but pushing other + branches that are variants of these branches, and different people + pushing files from the same external source. + + Peff confirmed that these workflows were indeed risky, and detailed + a bit further how the race conditions can happen. + + ZheNing then replied to Peff asking if there was "an easy and poor + performance" way like a lock on a repository to avoid for example + concurrent `push` and `gc` processes. + + Ævar replied that there was no such way but that we should have + one. He explained that it could perhaps be done using hooks, + [like 'pre-receive' and 'post-receive'](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks), + when we were sure that all relevant operations were going through + these hooks. (For example no local branch deletion should be + possible.) + + ZheNing and Michal discussed a bit further the details related to + how a repo corruption can happen with concurrent `push` and `gc` + processes, and how that could possibly be avoided. + +## Developer Spotlight: Teng Long + +* Who are you and what do you do? + + My work is related to R&D efficiency tools development at Alibaba Cloud. + Our team have currently built a code hosting service as codeup.aliyun.com + which provides free and high-quality code services for Chinese developers + on the public cloud. In addition, I used to be a Gerrit contributor, because + I wrote Java for nearly 10 years, and this process made me almost forget + the C language, LOL. + + For the contributions of Git community, apart from me, Jiang Xin (the Git + localization coordinator), ZheNing Hu, and Chen BoJun are also in the team. + +* What would you name your most important contribution to Git? + + First of all, I know Git for some years, but I'm new in the community, + because Git's technical depth is obvious which involves algorithms, + operating systems, testing techniques, etc. Also, Git has many + subcommands, which makes the implementation of Git itself involve + many aspects, and I think it is difficult for a new contributor to understand + everything, but long-term participation may make you an expert in one + aspect of Git. Sadly, my time devoted to the Git community is actually + limited. + + I contributed a feature last year to allow the `git ls-tree` subcommand + to support the `--format` option which let you print out the result as you + want, this is helpful for some automated tools or scripted work I think. If + you want to know about it further, a better way is to read [the blog by + Taylor Blau](https://github.blog/2022-04-18-highlights-from-git-2-36/#tidbits). + +* What are you doing on the Git project these days, and why? + + I've been following the evolution of the `bundle-uri` feature recently, I think + the idea of this feature is great and attractive. If used properly, it can not + only improve the speed of code download in some scenarios, but also + reduce the load on the server. + + I'm also reading about algorithms related code (like bitmap, multi-pack bitmap, + bloom-filter), as I want to know some details about the combination of Git and + algorithms. I think it's interesting. + +* 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? + + We all know that it can be a pain in terms of resource load and cost to + provide large-scale Git services. I hope to be able to solve the problem + with Git's storage and computing coupling to let Git be better + to integrate with cloud-native architecture. Like, should it be possible + to store the refs, loose objects and packs on a Distributed Database？ + + I think this is one of the future development direction of the Git + architecture, starting from lower cost and cloud friendliness. If you want to + do these tasks based on Git, you may need to make the internal related + implementations more adaptable, which requires a lot of professional work + I think. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + Maybe introduce a new option `--branches` in `git push` to replace `--all`. + Option `--all` means to push all branches, `--tags` means to push all tags, but + many people misunderstand it (at least those around me), because they think + `--all` means to push `all` the branches and tags together. In fact, I made an [RFC + patch](https://public-inbox.org/git/20221205133525.60464-1-tenglong.tl@alibaba-inc.com/) + before, hoping to support the `--branches` parameter in the first step, and + I'll consider following up with this patch. + +* What is your favorite Git-related tool/library, outside of + Git itself? + + I prefer [git-repo](https://github.com/alibaba/git-repo-go) which supports + doing code reviews or pull requests on the client, just like using a native + Git subcommand. + +* Do you happen to have any memorable experience w.r.t. contributing to + the Git project? If yes, could you share it with us? + + Still memorable when my first commit was merged in, even though it was + a small fix. This process made me understand that contributing to Git is + completely different from other workflows, and the process and results both + feel good. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + First, I use [https://public-inbox.org/git/?q=a%3Adyroneteng](https://public-inbox.org/git/?q=a%3Adyroneteng) + to check if there is any new mails related to me. + + Then, I've been using `git format-patch` to create patchsets and `git send-email` + to post them, and `git am` for local reviews. I don't know if there's a better + way, but it seems to be enough for me. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + Contributing to Git is not an easy task, after all, you are working with + other excellent contributors in the community, but continuous understanding + and participation may make you an expert in a certain direction. + +* If there's one tip you would like to share with other Git + developers, what would it be? + + I think it would be "get used to the process of contribution slowly". + + The review process is sometimes frustrating, but most of the suggestions by + reviewers are still valuable; you can learn a lot from the process, then you + can better participate in the next contribution. + + +## Releases + ++ Git [2.39.1 and others](https://public-inbox.org/git/xmqq7cxl9h0i.fsf@gitster.g/) ++ Git for Windows [2.39.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.39.1.windows.1) ++ libgit2 [1.5.1](https://github.com/libgit2/libgit2/releases/tag/v1.5.1) ++ GitLab [15.8](https://about.gitlab.com/releases/2023/01/22/gitlab-15-8-released/) +[15.7.5, 15.6.6, and 15.5.9](https://about.gitlab.com/releases/2023/01/17/critical-security-release-gitlab-15-7-5-released/), +[15.7.3](https://about.gitlab.com/releases/2023/01/11/gitlab-15-7-3-released/), +[15.7.2](https://about.gitlab.com/releases/2023/01/09/security-release-gitlab-15-7-2-released/), +[15.7.1](https://about.gitlab.com/releases/2023/01/05/gitlab-15-7-1-released/) ++ Bitbucket Server [8.7](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitHub Enterprise [3.7.4](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.4), +[3.6.7](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.7), +[3.5.11](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.11), +[3.4.14](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.14), +[3.3.19](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.19), +[3.7.3](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.3), +[3.6.6](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.6), +[3.5.10](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.10), +[3.4.13](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.13), +[3.3.18](https://help.github.com/enterprise-server@3.3/admin/release-notes#3.3.18) ++ GitKraken [9.0.1](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.1.5](https://desktop.github.com/release-notes/), +[3.1.4](https://desktop.github.com/release-notes/) + +## Other News + +__Various__ + +* [Git security vulnerabilities announced](https://github.blog/2023-01-17-git-security-vulnerabilities-announced-2/) + that affect versions 2.39 and older. Fixes were authored by engineers from + the [GitLab Security Research Team](https://about.gitlab.com/handbook/security/threat-management/security-research/), + as well as GitHub Engineers, and members of the git-security mailing list. + * Two of three vulnerabilities were found as part of an audit of the Git codebase + conducted by [X41](https://x41-dsec.de/). This audit was sponsored by the + [Open Source Technology Improvement Fund (OSTIF)](https://ostif.org/). + X41 have also published information about this + [Security Audit of Git](https://x41-dsec.de/security/research/news/2023/01/17/git-security-audit-ostif/). + * [Git security audit: Inside the hunt for - and discovery of - CVEs](https://about.gitlab.com/blog/2023/01/24/git-security-audit/) + by Joern Schneeweisz on GitLab Blog. + * [This Week In Security: Git Deep Dive, Mailchimp, And SPF](https://hackaday.com/2023/01/20/this-week-in-security-git-deep-dive-mailchimp-and-spf) + by Jonathan Bennett on Hackaday, and + [A security audit of Git](https://lwn.net/Articles/921067/) brief on LWN\.net. +* [GitHub Sponsors will stop supporting PayPal](https://github.blog/changelog/2023-01-23-github-sponsors-will-stop-supporting-paypal/), + starting on February 23, 2023. +* GitHub is [sunsetting Subversion support](https://github.blog/2023-01-20-sunsetting-subversion-support/). + On January 8, 2024, GitHub will remove support for Subversion. +* [XetHub raises $7.5M for its Git-based data collaboration platform](https://techcrunch.com/2023/01/09/xethub-raises-7-5m-for-its-git-based-data-collaboration-platform/) + by Frederic Lardinois on TechCrunch. + + +__Light reading__ + +* [Beyond Git: The other version control systems developers use](https://stackoverflow.blog/2023/01/09/beyond-git-the-other-version-control-systems-developers-use/) + by Ryan Donovan on The Overflow (stackoverflow\.blog). +* [Never write a commit message again (with the help of GPT-3)](https://zura.wiki/post/never-write-a-commit-message-again-with-the-help-of-gpt-3/) + by Roger Zurawicki on his blog _(though read the proposed commit message before accepting it, please)_. +* [Sending a kernel patch with b4 (part 1)](https://people.kernel.org/monsieuricon/sending-a-kernel-patch-with-b4-part-1) + by Konstantin Ryabitsev (sending patch with [b4](https://git.kernel.org/pub/scm/utils/b4/b4.git) + is described in [Contributor overview](https://b4.docs.kernel.org/en/stable-0.11.y/contributor/overview.html) + section of the tool documentation). + * [Introducing b4 and patch attestation](https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation) + was mentioned in [Git Rev News Edition #61](https://git.github.io/rev_news/2020/03/25/edition-61/). +* [The GitHub Silverware Drawer Dilemma, Or: Finding Active Repository Forks](https://hackaday.com/2023/01/08/the-github-silverware-drawer-dilemma-or-finding-active-repository-forks/) + by Maya Posch on Hackaday points to projects that help to find the most active fork. +* [7 Git articles every open source practitioner should read](https://opensource.com/article/23/1/git-articles) + by AmyJune Hineline from RedHat on OpenSource\.com. +* [Understanding Git through images](https://dev.to/nopenoshishi/understanding-git-through-images-4an1) + by kataoka_nopeNoshishi on DEV\.to. +* [Querying the GitHub archive with the ClickHouse Playground](https://til.simonwillison.net/clickhouse/github-explorer) + by Simon Willison on Simon Willison’s TILs (Today I've Learned). + +* [7 tips for improving your productivity with Git](https://blog.genezini.com/p/7-tips-for-improving-your-productivity-with-git/) + by Daniel Genezini on his "It works on my machine" blog + (also [on DEV\.to](https://dev.to/dgenezini/7-tips-for-improving-your-productivity-with-git-ajg)). +* [Fix that damn Git Unsafe Repository](https://weblog.west-wind.com/posts/2023/Jan/05/Fix-that-damn-Git-Unsafe-Repository) + by Rick Strahl on Rick Strahl's Weblog. +* [Mastering the Art of Writing Effective Git Commit Messages](https://dev.to/ashishxcode/mastering-the-art-of-writing-effective-github-commit-messages-5d2p) + by Ashish Patel on DEV\.to. +* [11 tips for writing a good Git commit message](https://opensource.com/article/22/12/git-commit-message) + by AmyJune Hineline from RedHat on OpenSource\.com. +* [20 Git Commands you (probably) didn't know about](https://dev.to/lissy93/20-git-commands-you-probably-didnt-know-about-4j4o) + by Alicia Sykes on DEV\.to. +* [How to Checkout a Remote Git Branch](https://www.howtogeek.com/864263/how-to-checkout-a-remote-git-branch/) + by Dave McKay on How-To Geek; + though the article misses the DWIM `git checkout ` trick, + and does not mention the newer `git switch ` command as alternative to `git checkout `. +* [Git tutorials - understanding of rebase and merge](https://dev.to/bitethecode/git-tutorials-understanding-of-rebase-and-merge-2cg4) + by Joonhyeok Ahn (Joon) on DEV\.to is the final part in the 4 part + [Git Cookbook](https://dev.to/bitethecode/series/20767) series. + +* [Golang (and thus `git-lfs`) is evil on shitty networks](https://withinboredom.info/blog/2022/12/29/golang-is-evil-on-shitty-networks/) + on the Somewhere Within Boredom blog _(may be fixed by the time you are reading this)_. + + + +__Git tools and sites__ + +* [Git-Sim: Visually Simulate Git Operations In Your Own Repos](https://initialcommit.com/blog/git-sim). + Run a one-liner `git-sim` command in the terminal, + for example `git-sim reset HEAD^` or `git-sim merge dev`, + to generate a custom Git command visualization (.jpg, .mp4) from your repository. + Written in Python, available as [package on PyPI](https://pypi.org/project/git-sim/). +* [heatwave](https://github.com/james-stoup/heatwave) + is a tool to visualize your Git commits with a heat map in the terminal, + similar to how GitHub's heat map looks. + Written in Python, also available as [package on PyPI](https://pypi.org/project/heatwave/). +* [git-stats](https://github.com/IonicaBizau/git-stats) is a similar tool + to visualize local git statistics, including GitHub-like contributions calendars. + Written in JavaScript + HTML, available as [npm.js package](https://www.npmjs.com/package/git-stats). + * Note that [Git-Stats](https://gitstats.me/), also known as GitStats\.me, + is an unrelated open-source GitHub contribution analyzer as a web service, + which was mentioned in [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/). +* [scmrepo](https://github.com/iterative/scmrepo) by Iterative + is a SCM wrapper and [fsspec](https://filesystem-spec.readthedocs.io/ "fsspec: Filesystem interfaces for Python") filesystem for Git for use in [DVC](https://dvc.org/ "Data Version Control · DVC"). + Works with multiple backends: pygit2 (libgit2), Dulwich, and GitPython. + * DVC (Data Version Control) was first mentioned in + [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/). +* [gptcommit](https://github.com/zurawiki/gptcommit) is a + git prepare-commit-msg [hook](https://git-scm.com/docs/githooks) + for authoring commit messages with the GPT-3 language model. Written in Rust.
+ Note: you need to ensure you have sufficient credits in your OpenAI account to use it. +* There are a few software forges working on implementing ForgeFed and/or ActivityPub federation. + [ForgeFed](https://notabug.org/peers/forgefed) (formerly GitPub) is a federation protocol + for forge services, first mentioned in [Git Rev News Edition #69](https://git.github.io/rev_news/2020/11/27/edition-69/) in 2020. + * [Vervis](https://vervis.peers.community/repos/WvWbo/source) is a project hosting + and management application, with a focus on software projects and decentralization. + Self-hosted on the instance. Supports Git and Darcs, + and [ForgeFed/ActivityPub federation](https://vervis.peers.community/repos/WvWbo/source/FEDERATION.md). + It is currently very much a work in progress. Written in Haskell. + * [ForgeFlux](https://forgeflux.org/) is [API-space software forge](https://github.com/forgeflux-org/website/blob/master/content/about/index.md) + federation with ForgeFed for Gitea, Sourcehut, GitLab, and GitHub. + Repositories are (also) [hosted on GitHub](https://github.com/forgeflux-org). + Note: the project homepage on seems to be down at the time of writing. + * [Forgefriends](https://forgefriends.org/) is a [self-hosted](https://lab.forgefriends.org/forgefriends/forgefriends) + forge federation project, which purpose is to allow every Free Software developer + to use their favorite forge to contribute to software projects hosted on other forges. + Forgefriends is written in Go to share code with Gitea, + and synchronization is done via the W3C ActivityPub protocol. + It is currently in pre-alpha stage. + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Teng Long. diff --git a/_posts/2023-02-28-edition-96.markdown b/_posts/2023-02-28-edition-96.markdown new file mode 100644 index 000000000..c605c8c80 --- /dev/null +++ b/_posts/2023-02-28-edition-96.markdown @@ -0,0 +1,252 @@ +--- +title: Git Rev News Edition 96 (February 28th, 2023) +layout: default +date: 2023-02-28 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 96 (February 28th, 2023) + +Welcome to the 96th 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](https://git.github.io). + +This edition covers what happened during the months of January and February 2023. + +## Discussions + + + + + + +### Support + +* [Bug?: `ORIG_HEAD` incorrect after reset during `git-rebase -i`](https://lore.kernel.org/git/CA+JQ7M-ynq1cLN-3ZodXae=x-H5k7Ab6uPBwUFhG+kgtOvCgtA@mail.gmail.com/) + + Erik Cervin Edin sent an email to the mailing list with steps to + reproduce a behavior that he didn't like. The steps consisted of an + interactive rebase during which a commit was edited and a reset which + was performed while editing the commit. + + After editing, `git rebase --continue` finished the rebase. But then + Erik expected `ORIG_HEAD` to point to the tip + of the rebased branch before the rebase, while instead it pointed to + the `HEAD` before the reset. + + `ORIG_HEAD` is one of the pseudo-references that some Git commands + use, like `FETCH_HEAD`, `MERGE_HEAD`, and a few others. + + Phillip Wood replied to Erik saying that it was expected that `git + reset` would change `ORIG_HEAD` to `HEAD` just before it was + performed. He suggested using the reflog with something like + `branch-name@{1}` where `branch-name` is the branch being + rebased and the `@{1}` part indicates the previous entry in the + reflog for the branch. + + Erik replied that he knew about the reflog but just expected + `ORIG_HEAD` to be reset to `.git/rebase-merge/orig-head` at the end of + the rebase. `.git/rebase-merge/orig-head` is an internal file that + stores the tip of the branch before a rebase operation. + + Philippe Blain replied to Erik that he just hit the same bug. He + also said that he was confused by the rebase documentation and supplied + the series of commands he used to get hit. + + Phillip Wood replied to both Erik and Philippe Blain that if we + changed the behavior to make `ORIG_HEAD` point to the tip of the + branch before it was rebased, some people might not be happy as they + might expect `git reset` to have changed `ORIG_HEAD`. Other people + might expect on the contrary that `ORIG_HEAD` was always set to the + tip of the branch before the rebase when the rebase stopped, which + would mean that `git rebase --continue` would always need to make + sure `ORIG_HEAD` fulfilled that expectation. + + Phillip said he thought the situation was confusing and he didn't + see a way to make it clearer. + + Philippe Blain agreed that some people might rely on the current + behavior and said he would send documentation updates to make things + clearer. + + He then sent + [a patch series](https://lore.kernel.org/git/pull.1456.git.1673120359.gitgitgadget@gmail.com/) + consisting of small changes to the documentation of a number of + commands: `cherry-pick`, `merge`, `rebase` and `reset`, as well as + to the [documentation about Git revisions](https://git-scm.com/docs/gitrevisions). + + Junio Hamano, the Git maintainer, commented on some wordings, which + after short discussions led Philippe to send + [a version 2 of his series](https://lore.kernel.org/git/pull.1456.v2.git.1673356521.gitgitgadget@gmail.com/) + with very few changes. + + This version was accepted and later merged into the master branch. + + + +## Releases + ++ Git [2.40.0-rc0](https://public-inbox.org/git/xmqq7cw6yfpt.fsf@gitster.g/), +[2.39.2 and friends](https://public-inbox.org/git/xmqqr0us5dio.fsf@gitster.g/) ++ Git for Windows [2.39.2(1)](https://github.com/git-for-windows/git/releases/tag/v2.39.2.windows.1) ++ libgit2 [1.6.1](https://github.com/libgit2/libgit2/releases/tag/v1.6.1), +[1.5.2](https://github.com/libgit2/libgit2/releases/tag/v1.5.2) ++ Bitbucket Server [8.8](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.5.5](https://www.gerritcodereview.com/3.5.html#355), +[3.6.4](https://www.gerritcodereview.com/3.6.html#364), +[3.7.1](https://www.gerritcodereview.com/3.7.html#371) ++ GitHub Enterprise [3.7.6](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.6), +[3.6.9](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.9), +[3.5.13](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.13), +[3.4.16](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.16), +[3.8.0](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.0), +[3.7.5](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.5), +[3.6.8](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.8), +[3.5.12](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.12), +[3.4.15](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.15) ++ GitLab [15.9.1](https://about.gitlab.com/releases/2023/02/24/gitlab-15-9-1-released/) +[15.9](https://about.gitlab.com/releases/2023/02/22/gitlab-15-9-released/), +[15.8.2, 15.7.7 and 15.6.8](https://about.gitlab.com/releases/2023/02/14/critical-security-release-gitlab-15-8-2-released/), +[15.8.3](https://about.gitlab.com/releases/2023/02/14/gitlab-15-8-3-released/), +[15.8.1](https://about.gitlab.com/releases/2023/01/31/security-release-gitlab-15-8-1-released/) ++ GitKraken [9.1.1](https://help.gitkraken.com/gitkraken-client/current/), +[9.1.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.1.8](https://desktop.github.com/release-notes/), +[3.1.7](https://desktop.github.com/release-notes/), +[3.1.6](https://desktop.github.com/release-notes/) ++ tig [2.5.8](https://github.com/jonas/tig/releases/tag/tig-2.5.8) ++ Tower for Mac [9.2](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) ++ Tower for Windows [4.2](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) ([blog post](https://www.git-tower.com/blog/tower-win-4-2/)) + +## Other News + +__Various__ +* The Git project has been accepted as + [a Mentor Organization](https://summerofcode.withgoogle.com/programs/2023/organizations/git) + for Google Summer of Code (GSoC) 2023. We could still add project ideas to + [our idea page](https://git.github.io/SoC-2023-Ideas/) and volunteers to (co-)mentor are still welcome. +* [GitLab Improves Merge Requests, GitOps Functionality and More](https://www.infoq.com/news/2023/02/gitlab-15-3-through-15-8-release/) + by Matt Saunders on InfoQ, about versions 15.3 through 15.8. +* [Git archive generation meets Hyrum's law](https://lwn.net/Articles/921787/) + by Jonathan Corbet on LWN\.net (affecting Git and GitHub). + + +__Light reading__ +* [Will GitOps Change Software Development Forever?](https://www.analyticsinsight.net/will-gitops-change-software-development-forever/) + by Harshini on Analytics Insight. +* [Git signoff and signing like a champ](https://dev.to/janderssonse/git-signoff-and-signing-like-a-champ-41f3) + by Josef Andersson on DEV\.to. +* [How to Merge a Git Feature Branch with a Squash Commit](https://dev.to/esaraviam/how-to-merge-a-git-feature-branch-with-a-squash-commit-8af) + by Luis Esteban Saravia M on DEV\.to.
+ This is an alternative to repeatedly using the `squash` command of the [interactive rebase](https://git-scm.com/docs/git-rebase#_interactive_mode). +* [Why I love GitLens in my VsCode - Part 1](https://blog.delpuppo.net/why-i-love-gitlens-in-my-vscode-part-1), + [Part 2](https://blog.delpuppo.net/why-i-love-gitlens-in-my-vscode-part-2), + and [Part 3](https://blog.delpuppo.net/why-i-love-gitlens-in-my-vscode-part-3) + by Luca Del Puppo on his blog.
+ Also available [on DEV\.to](https://dev.to/this-is-learning/why-i-love-gitlens-in-my-vscode-part-1-5cmp). +* [Data versioning](https://danmackinlay.name/notebook/data_versioning.html), + a rough work-in-progress notebook by Dan MacKinlay. + Includes descriptions of + * [Data Version Control (DVC)](https://dvc.org/) (first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/)), + * [Dolt](https://www.dolthub.com/), which is a [version controlled SQL database](https://www.dolthub.com/blog/2021-09-17-database-version-control/) + (first mentioned in [Git Rev News Edition #62](https://git.github.io/rev_news/2020/04/23/edition-62/)), + * [Pachyderm](https://www.pachyderm.com/) (first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/)), + * [git-annex](http://git-annex.branchable.com/) - not targeted specifically at data science + (first mentioned in passing in [Git Rev News #3](https://git.github.io/rev_news/2015/05/13/edition-3/)), + * [DataLad](https://www.datalad.org/), + * [Go Get Data (ggd)](https://gogetdata.github.io/) from the genomics community; + it seems to be a lighter version of Pachyderm, + * [Splitgraph](https://www.splitgraph.com/docs/getting-started/introduction), + which works on top of PostgreSQL, + * [Sno](https://sno.earth/) to store geospatial and tabular data in Git
+ (see also [Kart](https://kartproject.org/), mentioned in [Git Rev News #85](https://git.github.io/rev_news/2022/03/31/edition-85/), + _which is not listed in this notebook_). + + The notebook also mentions + [Pangeo Forge](https://github.com/pangeo-forge/roadmap) (like Conda Forge, but for data), + [Intake](https://intake.readthedocs.io/en/latest/index.html) (lightweight package for finding, investigating, loading and disseminating data), and + [Flat Data](https://githubnext.com/projects/flat-data) - formerly GitHub OCTO + (to bring working sets of data to your repositories, based on the + [“Git scraping” approach pioneered by Simon Willison](https://simonwillison.net/2020/Oct/9/git-scraping/) + (mentioned in [Git Rev News Edition #68](https://git.github.io/rev_news/2020/10/30/edition-68/))).
+ See also [Git Rev News #82](https://git.github.io/rev_news/2021/12/30/edition-82/), + which mentions tools for version controlling database schemas, version controlling queries, + data versioning, etc. -- all taken from articles on DoltHub Blog. +* [The Git source code audit, viewed as a Rust programmer](https://litchipi.github.io/infosec/2023/01/24/git-code-audit-viewed-as-rust-programmer.html) + by Litchi Pi (Tim); the audit itself was mentioned in [Git Rev News #95](https://git.github.io/rev_news/2023/01/31/edition-95/). +* [An Easy git Workflow](https://dev.to/ovid/an-easy-git-workflow-4gm0) + by Curtis “Ovid” Poe on DEV\.to.
+ Also available as [Easy Git Workflow](https://ovid.github.io/articles/easy-git-workflow.html) (2020) + on [(Technical) Articles by Ovid](https://ovid.github.io/articles.html). + + +* [The technology behind GitHub’s new code search](https://github.blog/2023-02-06-the-technology-behind-githubs-new-code-search/) + by Timothy Clem in the Engineering section of the GitHub Blog. +* [Mobile Price Classification: An Open Source Data Science Project with Dagshub](https://hackernoon.com/mobile-price-classification-an-open-source-data-science-project-with-dagshub) + by Davis David (@davisdavid) on HackerNoon. + * The workflow described in this article uses + [DVC](https://dvc.org/) (first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/)), + [DAGsHub](https://dagshub.com/) (first mentioned in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/)), + MLflow, and the Streamlit library. +* [FAIR data pipeline: provenance-driven data management for traceable scientific workflows](https://royalsocietypublishing.org/doi/full/10.1098/rsta.2021.0300); + an open access research article in Volume 380, Issue 2233 + of Philosophical Transactions of The Royal Society A + ([DOI:10.1098/rsta.2021.0300](https://doi.org/10.1098/rsta.2021.0300)). + + +__Easy watching__ +* [Move Commits Between Branches in Git](https://www.youtube.com/watch?v=0pzFGXvemvA) + by Leonardo Montini, also known as Dev Leonardo.
+ You can read the accompanying [Move Commits Between Branches in Git - 3 Different Methods](https://dev.to/this-is-learning/move-commits-between-branches-in-git-3-different-methods-22bb) + article on DEV\.to (for This is Learning), 5th part of the + [git better - Improve your git skills](https://dev.to/balastrong/series/21372) series. + + +__Git tools and sites__ +* [**conventional:** comments](https://conventionalcomments.org/) are a set of conventions + to make code review comments to be easy to grok and grep. + * This can be considered a companion to [Conventional Commits](https://www.conventionalcommits.org/) specification, + first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/). +* [Flipt](https://www.flipt.io/) is an [open source](https://github.com/flipt-io/flipt), + self-hosted feature flag solution. + * [Feature Flags](https://featureflags.io/) or [Feature Toggles](https://martinfowler.com/articles/feature-toggles.html) + are a technique that allows to modify system behavior without changing code. + They are often used with [Trunk Based Development](https://trunkbaseddevelopment.com/), + as described in [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) + by Martin Fowler, which was mentioned in [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/). +* [git-workflow](https://github.com/Ovid/git-workflow) + by Curtis “Ovid” Poe is a simplified subset of the Git tools used by + [All Around the World](https://allaroundtheworld.fr/) company for software development. + It provides three new commands: `git refresh`, `git pushback` and `git done`. +* [Git-Heat-Map](https://github.com/jmforsythe/Git-Heat-Map) + is a tool to visualize a Git repository by diff activity using a treemap chart. +* [Diff/merge tools](https://danmackinlay.name/notebook/diffing.html) and + [Git GUIs](https://danmackinlay.name/notebook/git_guis.html) - notebooks + of Dan MacKinlay. +* [Git tricks](https://danmackinlay.name/notebook/git.html): + Dan MacKinlay's notes and links, not intended to be tutorial. +* [Awesome CLI Apps](https://github.com/agarrharr/awesome-cli-apps) + is a curated list of command line apps, including the ones + [for Version Control](https://github.com/agarrharr/awesome-cli-apps#version-control). +* [Automerge 2.0](https://automerge.org/blog/automerge-2/) + is a [CRDT](https://crdt.tech/), or "Conflict-free Replicated Data Type", + that one can use to implement real-time collaboration for an application, + which is focused on optimizing editing of plaintext. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Bruno Brito. diff --git a/_posts/2023-03-31-edition-97.markdown b/_posts/2023-03-31-edition-97.markdown new file mode 100644 index 000000000..9f9b425cc --- /dev/null +++ b/_posts/2023-03-31-edition-97.markdown @@ -0,0 +1,260 @@ +--- +title: Git Rev News Edition 97 (March 31st, 2023) +layout: default +date: 2023-03-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 97 (March 31st, 2023) + +Welcome to the 97th 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](https://git.github.io). + +This edition covers what happened during the months of February 2023 and March 2023. + +## Discussions + + + + + +### Support + +* [Bug report: symbolic-ref --short command echos the wrong text while use Chinese language](https://lore.kernel.org/git/CAGF3oAcCi+fG12j-1U0hcrWwkF5K_9WhOi6ZPHBzUUzfkrZDxA@mail.gmail.com/) + + Mengzi Yi (孟子易) sent a bug report to the mailing list saying that + when a Chinese name like 测试-加-增加-加-增加 was given to a branch, + then calling `git symbolic-ref --short HEAD` on that branch didn't + result in the right output (for example 测试-� instead of maybe 测试-加). + + Peff, alias Jeff King, replied saying that he couldn't reproduce the + issue on Linux and wondered if it was related to using MacOS as its + HFS+ filesystem might do some Unicode normalization. He said that it + might alternatively be related to the shortening code in + `shorten_unambiguous_ref()` treating the names as bytes instead of + characters. Another possibility he mentioned was that the shortening + code, which used `scanf()`, was assuming that the resulting string + could not be longer than the input, but that this might be wrong + when some Unicode normalization and locale were used. + + Eric Sunshine replied to Peff saying he was able to reproduce the + bug on MacOS 10.13 (while Mengzi used MacOS 13.2), but that it + didn't appear to be related to HFS+ Unicode normalization as on disk + the bytes of the branch name he got were the same as what Peff got + on Linux. + + Peff replied to Eric asking if he could test a patch that would add + debug output and allocate twice as much memory for the shortened + name that would store the output from `scanf()` than for the input + of that function. Peff said the debug output on his Linux machine + showed that the input was 39 bytes long while the output was 28. + + Eric tested Peff's patch and initially reported 39 and 9 for the + input and output respectively. When setting `LANG=zh-CN.UTF-8`, he + got the same input and output lengths as Peff though, which pointed + to `scanf()` being indeed the culprit. + + Junio Hamano, the Git maintainer, replied to Eric's findings saying + "Well, that's ... criminal." and wondering if setting `LANG` to + `$ANY_VALID_ONE.UTF-8` would work the same way. + + This made Eric realize that the `zh-CN` language code he used was + invalid (it should have been `zh_CN`, so with an underscore + character instead of a dash). Eric anyway found out that using valid + LANG codes like `en_US`, `fr_FR`, `de_DE`, `ru_RU` and `zh_CN` resulted + in the 测试-? truncated output, while using `LANG=C` yielded the correct + 测试-加-增加-加-增加 output. + + Junio, Peff and Eric discussed these results further, wondering what + `scanf()` on MacOS could be doing wrong. Then Peff suggested + replacing the call to this function with some manual parsing, and + sent a sample in-email patch to do that. + + Eric tested Peff's patch and reported that it looked correct, worked + nicely and fixed the issue. He also agreed with the approach of + getting rid of `scanf()` calls in general. + + Peff then sent + [a regular small patch series](https://lore.kernel.org/git/Y+vVFFCRem6t4IGM@coredump.intra.peff.net/) + based on his previous patch, which fixed a leak and made the changes + easier to follow. + + Junio and Eric reviewed the series and then discussed with Peff a bug + Junio found in it. Then Peff sent + [a version 2](https://lore.kernel.org/git/Y+z3MtgayoXsxaHA@coredump.intra.peff.net/) + of the patch series that fixed the bug and added tests. + + Torsten Bögershausen in the meantime tried to reproduce the original + bug and discussed how to do that with Eric. He also commented on the + new tests in the version 2 of the patch series as he found that it + wasn't clear in which context the bug could appear. Junio suggested + some clarifications that were approved by others. The resulting + patches were merged and included in the recent Git v2.40.0 release. + + + +## Releases + ++ Git [2.40.0](https://public-inbox.org/git/xmqqjzzkv8xz.fsf@gitster.g/), +[2.40.0-rc2](https://public-inbox.org/git/xmqqy1o8wdgi.fsf@gitster.g/), +[2.40.0-rc1](https://public-inbox.org/git/xmqqilfknzen.fsf@gitster.g/) ++ Git for Windows [2.40.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.40.0.windows.1), +[2.40.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.40.0-rc2.windows.1), +[2.40.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.40.0-rc1.windows.1), +[2.40.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.40.0-rc0.windows.1) ++ libgit2 [1.6.3](https://github.com/libgit2/libgit2/releases/tag/v1.6.3), +[1.6.2](https://github.com/libgit2/libgit2/releases/tag/v1.6.2) ++ GitHub Enterprise [3.8.1](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.1), +[3.7.8](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.8), +[3.6.11](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.11), +[3.5.15](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.15), +[3.4.18](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.18), +[3.8.0](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.0), +[3.7.7](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.7), +[3.6.10](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.10), +[3.5.14](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.14), +[3.4.17](https://help.github.com/enterprise-server@3.4/admin/release-notes#3.4.17) ++ GitLab [15.10](https://about.gitlab.com/releases/2023/03/22/gitlab-15-10-released/) +[15.9.3](https://about.gitlab.com/releases/2023/03/09/gitlab-15-9-3-released/), +[15.9.2, 15.8.4, and 15.7.8](https://about.gitlab.com/releases/2023/03/02/security-release-gitlab-15-9-2-released/) ++ Gitea [1.19.0](https://blog.gitea.io/2023/03/gitea-1.19.0-is-released/) ++ Gerrit Code Review [3.7.2](https://www.gerritcodereview.com/3.7.html#372) ++ GitKraken [9.2.1](https://help.gitkraken.com/gitkraken-client/current/), +[9.2.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.2.0](https://desktop.github.com/release-notes/) ++ Sourcetree [4.2.2](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.2.html) ++ Tower for Windows [4.3](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) + +## Other News + +__Various__ + ++ [Highlights from Git 2.40](https://github.blog/2023-03-13-highlights-from-git-2-40/) + by Taylor Blau on GitHub Blog. ++ [public-inbox.org/git to be downgraded](https://public-inbox.org/git/20230313225507.M626677@dcvr/T/) + to a cheaper VPS. + + There is [https://lore.kernel.org/git/](https://lore.kernel.org/git/) if there are problems with the public-inbox\.org instance. ++ [Unleash your potential with GitHub Octernships: a path to a thriving tech career](https://github.blog/2023-03-06-unleash-your-potential-with-github-octernships-a-path-to-a-thriving-tech-career/) + by Arkodyuti Saha on GitHub Blog. ++ [Future-proofing Git repository maintenance](https://about.gitlab.com/blog/2023/03/20/scaling-repository-maintenance/) + by Patrick Steinhardt on GitLab blog. ++ [Notes from a video conference](https://lore.kernel.org/git/CAJoAoZm7147oH9ECr=y+OXonK5WSgc9H0b95sF7BhKjMn+oMZg@mail.gmail.com/) + on Thursday March 30 named + [libification eng discussion](https://lore.kernel.org/git/CAJoAoZ=KrnAWV3PpfBkYNs_KHFP5O2dVYOWY3jF=CM9+d89Dpg@mail.gmail.com/) + organized by Emily Shaffer are available. + +__Light reading__ + ++ [How to Improve Performance in Git: The Complete Guide](https://www.git-tower.com/blog/git-performance/) by Bruno Brito on Tower’s blog. ++ [Integrating 1Password SSH with Git (and Tower!)](https://www.git-tower.com/blog/1password-ssh-tower/) by Bruno Brito on Tower’s blog. ++ [Slice, Dice, and Squash Your Git Commit History](https://webdeveloperdiary.substack.com/p/slice-dice-and-squash-your-git-commit) + by Anthony Fung on _Diary of a Web Developer_ Substack and + [on DEV.to](https://dev.to/ant_f_dev/slice-dice-and-squash-your-git-commit-history-2dk3) + as 3rd part of [The Secret of Tidy Git Repositories Series](https://dev.to/ant_f_dev/series/22124). ++ [Git fundamentals, a complete guide](https://dev.to/leandronsp/git-fundamentals-a-complete-guide-do7) + by Leandro Proença on DEV\.to.
+ See also: + + [Git from the Bottom Up](https://jwiegley.github.io/git-from-the-bottom-up/) by John Wiegley, + mentioned in [Git Rev News Edition #2](https://git.github.io/rev_news/2015/04/05/edition-2/), + + [Git for Computer Scientists](https://eagain.net/articles/git-for-computer-scientists/) by Tommi Virtanen, + + and maybe also [Think Like (a) Git: a guide for the perplexed](https://think-like-a-git.net/) by Sam Livingston-Gray. ++ [Options to close pull requests on GitHub](https://dev.to/zdybit/3-options-to-close-pull-requests-on-github-what-2j3n) and + [Merge, squash & rebase on GitHub - pros & cons](https://dev.to/zdybit/when-to-use-particular-options-to-close-pull-requests-on-github-3ce8) + by Kacper Rychel on DEV\.to. ++ [How to Reset a File or Commit in Git](https://www.freecodecamp.org/news/git-revert-how-to-reset-a-file-or-commit/) + by Ihechikara Vincent Abba on freeCodeCamp. ++ [How atomic Git commits dramatically increased my productivity - and will increase yours too](https://dev.to/samuelfaure/how-atomic-git-commits-dramatically-increased-my-productivity-and-will-increase-yours-too-4a84) + by Samuel Faure on DEV\.to and on [Such Dev Blog](https://suchdevblog.com/lessons/AtomicGitCommits.html). ++ [Working with Git in JetBrains' Rider IDE](https://andrewlock.net/working-with-git-in-jetbrains-rider/) + by Andrew Lock on his .NET Escapades blog. ++ [GitHub Desktop 3.2 adds pull request preview – but is a GUI needed for Git?](https://devclass.com/2023/03/06/github-desktop-3-2-adds-pull-request-preview-but-is-a-gui-needed-for-git/) + by Tim Anderson on Dev Class. ++ [Best 8 Data Version Control Tools for Machine Learning 2023](https://dagshub.com/blog/best-data-version-control-tools/) + by Zoumana Keita on DagsHub Blog. + + See also links about data versioning + in [previous Git Rev News](https://git.github.io/rev_news/2023/02/28/edition-96/). ++ [A better Git workflow?](https://discourse.julialang.org/t/a-better-git-workflow/95248) + proposal by uje on the Julia Language Discourse forum. ++ [Code Commit Guidelines using Conventional Commits](https://proandroiddev.com/code-commit-guidelines-using-conventional-commits-379321ce3785) + by Pragnesh Ghoda on ProAndroidDev, a Medium blog. + + The [Conventional Commits](https://www.conventionalcommits.org) specification + was first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/). + + ++ [Empowering weak primitives: file truncation to code execution with Git](https://www.sonarsource.com/blog/empowering-weak-primitives-file-truncation-to-code-execution-with-git/) + by Thomas Chauchefoin on Sonar(Source) Blog + (note that it is not about a vulnerability in Git).
+ References the [Securing Developer Tools: Git Integrations](https://www.sonarsource.com/blog/securing-developer-tools-git-integrations/) + blog post. ++ [What the ML is up with DevSecOps and AI?](https://about.gitlab.com/blog/2023/03/16/what-the-ml-ai/) + by Taylor McCaslin on GitLab Blog. + + + +__Git tools and sites__ + ++ There are a few tools that use GPT-3 / ChatGPT Large Language Model (LLM) to + help write commit messages. Please read the proposed commit message before + accepting it, especially for more complex changes. Those tools, as far as we + understand it, do not take information from an issue tracker, or from + code review comments attached to a pull request (or contained in a specialized + tool such as Gerrit) -- so they cannot add this information to the proposed + commit message, they can only halucinate it.
+ All tools listed here require an [API key from OpenAI](https://platform.openai.com/account/api-keys). + + [OpenCommit](https://github.com/di-sukharev/opencommit) + is a GPT CLI to auto-generate impressive commits in 1 second; + it uses [Conventional Commits](https://www.conventionalcommits.org), + and can use [GitMoji](https://gitmoji.dev/). + Written as Node\.js CLI app. + + See also [OpenCommit: GPT generates impressive commits in 1 second (open-source)](https://dev.to/disukharev/opencommit-gpt-cli-to-auto-generate-impressive-commits-in-1-second-46dh) + by Dima Sukharev on DEV\.to. + + [AI Commits](https://github.com/Nutlope/aicommits) + is a CLI app (`aicommits`) that writes your Git commit messages for you with AI, + that can also be used as [`prepare-commit-msg` hook](https://git-scm.com/docs/githooks#_prepare_commit_msg). + Written as Node\.js v14+ CLI app. + + See also [AI generated Git commit messages](https://dev.to/bdougieyo/ai-generated-git-commit-messages-4j7g) + by Brian Douglas on DEV\.to. + + [`ai-commit`](https://github.com/nguyenvanduocit/ai-commit) + is a command line tool that uses [OpenAI](https://openai.com/)'s + language generation capabilities to generate + [conventional commit](https://www.conventionalcommits.org) + messages for your Git repositories. Written in Go. + + [gptcommit](https://github.com/zurawiki/gptcommit) is + a Git `prepare-commit-msg` [hook](https://git-scm.com/docs/githooks) + for authoring commit messages with [OpenAI](https://openai.com/)'s GPT-3 language model. + Written in Rust. + + Mentioned in [Git Rev News Edition #95](https://git.github.io/rev_news/2023/01/31/edition-95/); + see also [an article](https://zura.wiki/post/never-write-a-commit-message-again-with-the-help-of-gpt-3/) + about this tool there. + ++ [Planar](https://www.useplanar.com/) is a Chrome extension + that adds features used internally by big tech to speed up and simplify GitHub code review. + + See also [Planar - Add 10x features to GitHub code review](https://www.ycombinator.com/launches/ICU-planar-add-10x-features-to-github-code-review) + by Eshan Agarwal on Y Combinator (Launch YC). ++ [Git for Computer Scientists](https://eagain.net/articles/git-for-computer-scientists/) + by Tommi Virtanen is a quick introduction to Git internals for people + who are not scared by words like directed acyclic graph. ++ [Think Like (a) Git: a guide for the perplexed](https://think-like-a-git.net/) + by Sam Livingston-Gray, intended for "advanced beginners" with Git + to help them achieve some level of _Git enlightenment_. + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Bruno Brito. diff --git a/_posts/2023-04-30-edition-98.markdown b/_posts/2023-04-30-edition-98.markdown new file mode 100644 index 000000000..140b3e141 --- /dev/null +++ b/_posts/2023-04-30-edition-98.markdown @@ -0,0 +1,252 @@ +--- +title: Git Rev News Edition 98 (April 30th, 2023) +layout: default +date: 2023-04-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 98 (April 30th, 2023) + +Welcome to the 98th 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](https://git.github.io). + +This edition covers what happened during the months of March 2023 and April 2023. + +## Discussions + + + + + +### Support + +* [Suspected git grep regression in git 2.40.0](https://lore.kernel.org/git/7E83DAA1-F9A9-4151-8D07-D80EA6D59EEA@clumio.com/) + + Stephane Odul reported that running the command + + `git grep -cP '^\w+ = json.load'` + + on some files of a private repo started failing consistently with an + exit code of -11 in Git v2.40.0 while it worked with previous Git + versions. + + Bagas Sanjaya replied to Stephane asking him if he could use `git + bisect` between v2.39.0 and v2.40.0 to see which commit in Git's + history broke the feature. + + Junio Hamano, the Git maintainer, thought the issue might have been + created by a recent change in how Git uses the + [PCRE2 library](https://www.pcre.org/). This change made Git try to + run PCRE2's JIT (Just In Time) compiler on a sample pattern and fall + back to not using the JIT compiler if the attempt failed. + + Junio said it could alternatively be that the version of the PCRE2 + library linked to v2.40 had been updated compared to the one in + previous Git versions, but asked if it made a difference to disable + the JIT compiler by prefixing the pattern with `(*NO_JIT)`. + + Mathias Krause, who had worked on PCRE2 related issues recently, + replied that another commit with the subject "grep: correctly + identify utf-8 characters with \{b,w} in -P" seemed more suspect to + him as it was about both the `-P` option and the `\w` pattern. + + Looking at the diff of that commit, Mathias found that it added the + `PCRE2_UCP` flag to the PCRE2 library call when an UTF-8 locale was + used, and that PCRE2 had a `PCRE2_ERROR_UTF8_ERR9` (-11) error code + described as "5th-byte's two top bits are not 0x80" that matched + the exit code of -11 which Stephane got. + + Mathias then asked Stephane if a file in his repo might contain + invalid UTF-8 output, and suggested testing this using the following + command: + + ``` + $ iconv -f UTF-8 your_file > /dev/null && echo OK || echo "Not valid" + ``` + + Stephane replied that he created a custom pipeline to try to + reproduce the issue and found that restricting the `git grep` + command to Python files (using `'*.py'`) was a good workaround, and + that the issue was likely related to other files in "various + formats, including potentially some binaries that would definitely + not be proper UTF-8". He also noted that using `(*NO_JIT)` as + suggested by Junio prevented the issue but slowed down the command a + lot for some patterns. + + Mathias, in the meantime, was able to reproduce the error on the Git + repo. He got a segfault and also a backtrace under gdb, but the + backtrace was very short and without any debug symbols, so he + supposed that it happened in the call stack of PCRE2's JIT + compiler. Looking at the memory mapping and the instructions also + seemed to point to a JIT compiler bug. + + Mathias then reverted the commit that added the `PCRE2_UCP` flag to + the PCRE2 library call, and found that it fixed the bug, which + confirmed his earlier suspicion about that commit. + + Stephane thanked Mathias for his great work and left saying he was + happy with the workaround he had found and did not believe there was + much more he could contribute to the issue. + + Mathias replied to his previous email saying he had found "an + interesting entry in the PCRE2's changelog for version 10.35":
+ :
+ "17. Fix a crash which occurs when the character type of an invalid UTF + character is decoded in JIT." + + He concluded that it was needed to implement "yet another quirk to + handle these broken versions", and came up with an in-email patch + that was not using the `PCRE2_UCP` flag when Git was compiled to + link to a PCRE2 version lower than 10.35. He wondered though if it + was better to just revert the commit that had introduced the + `PCRE2_UCP` flag. + + Junio replied to Mathias by first thanking him for "all the + investigation and a prompt fix" and then saying that the approach in + his patch was more sensible than reverting the commit. He suggested + a small code change though. + + Mathias agreed with Junio's suggestion and sent + [a version 2 of his patch](https://lore.kernel.org/git/20230323172539.25230-1-minipli@grsecurity.net/) + that was then merged into the `master` branch. + + + +## Releases ++ Git [2.40.1 and friends](https://public-inbox.org/git/xmqqa5yv3n93.fsf@gitster.g/) ++ Git for Windows [2.40.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.40.1.windows.1) ++ libgit2 [1.6.4](https://github.com/libgit2/libgit2/releases/tag/v1.6.4) ++ GitLab [15.11](https://about.gitlab.com/releases/2023/04/22/gitlab-15-11-released/) +[15.10.4](https://about.gitlab.com/releases/2023/04/21/gitlab-15-10-4-15-9-5-released/), +[15.7.9](https://about.gitlab.com/releases/2023/04/20/gitlab-15-7-9-released/), +[15.8.6](https://about.gitlab.com/releases/2023/04/19/gitlab-15-8-6-released/), +[15.10.3](https://about.gitlab.com/releases/2023/04/14/gitlab-15-10-3-released/), +[15.10.2](https://about.gitlab.com/releases/2023/04/05/gitlab-15-10-2-released/), +[15.10.1, 15.9.4, and 15.8.5](https://about.gitlab.com/releases/2023/03/30/security-release-gitlab-15-10-1-released/) ++ Bitbucket Server [8.9](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gitea [1.19.1](https://blog.gitea.io/2023/04/gitea-1.19.1-is-released/) ++ GitHub Enterprise [3.8.2](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.2), +[3.5.16](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.16), +[3.7.9](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.9), +[3.6.12](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.12) ++ GitKraken [9.3.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.2.2](https://desktop.github.com/release-notes/), +[3.2.1](https://desktop.github.com/release-notes/) ++ git-credential-oauth [0.6.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.6.0) + +## Other News + +__Various__ ++ [Git security vulnerabilities announced](https://github.blog/2023-04-25-git-security-vulnerabilities-announced-4/): + CVE-2023-25652 and CVE-2023-29007, + and MS Windows specific CVE-2023-25815, CVE-2023-29011, and CVE-2023-29012. + By Taylor Blau on GitHub Blog. + + +__Light reading__ ++ [Git and GitHub for Designers](https://www.git-tower.com/blog/git-for-designers/) by Bruno Brito on Tower’s blog. ++ [Git-Sim 3 Month Dev Update: Community Response, New Features, & The Future](https://initialcommit.com/blog/git-sim-3-month-dev-update) + by Jacob Stopak on Initial Commit. [Git-Sim](https://github.com/initialcommit-com/git-sim) + was mentioned in [Git Rev News Edition #95](https://git.github.io/rev_news/2023/01/31/edition-95/). ++ [Smoother rebases with auto-squashing Git commits](https://andrewlock.net/smoother-rebases-with-auto-squashing-git-commits/) and + [Super-charging 'git rebase' with 'git absorb'](https://andrewlock.net/super-charging-git-rebase-with-git-absorb/) + by Andrew Lock on .NET Escapades. + [git-absorb](https://github.com/tummychow/git-absorb) + (a port of Facebook's [hg absorb](https://www.mercurial-scm.org/repo/hg/rev/5111d11b8719) extension for Mercurial) + was mentioned in passing in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/). ++ [Modeling Git Internals in Alloy, Part 1: Blobs and Trees](https://bytes.zone/posts/modeling-git-internals-in-alloy-part-1-blobs-and-trees/) + and [Modeling Git Internals in Alloy, Part 2: Commits and Tags](https://bytes.zone/posts/modeling-git-internals-in-alloy-part-2-commits-and-tags/) + by Brian Hicks on bytes.zone. + [Alloy](https://bytes.zone/posts/alloy/) is [a tool](http://alloytools.org/) + (with its own domain-specific programming language) + used for making and checking models of other software. ++ [Avoiding the merge trap](https://lwn.net/Articles/926240/) + by Jonathan Corbet on LWN.net + describes how one should explain merges in pull requests sent to Linus Torvalds. ++ [Notes on graphics programming and version control](https://tyler.cafe/graphics-and-versions) + Tyler Angert on tyler\.cafe blog. ++ [Introducing the Space Git Flow](https://blog.jetbrains.com/space/2023/04/18/space-git-flow/) + by Evgenia Verbina on JetBrains Blog. Space Git Flow is a branching strategy + similar to [Git Flow](https://blog.jetbrains.com/space/2023/04/18/space-git-flow/) + (first mentioned in [Git Rev News Edition #5](https://git.github.io/rev_news/2015/07/08/edition-5/)) + and specifically [GitHub Flow](https://docs.github.com/en/get-started/quickstart/github-flow), + used by JetBrains to develop their products including + [Space](https://git.github.io/rev_news/2020/03/25/edition-61/) development platform / software forge.
+ See also: + * [Please stop recommending Git Flow!](https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/) + by George Stocker, mentioned in [Git Rev News #61](https://git.github.io/rev_news/2020/03/25/edition-61/). + * [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) + by Martin Fowler, mentioned first in [Git Rev News #63](https://git.github.io/rev_news/2020/05/28/edition-63/). ++ [Convert git log output to JSON using jq](https://til.simonwillison.net/jq/git-log-json) + with proper escaping, on Simon Willison’s TILs (Today I've Learned). ++ [Quickly formatting a stack of commits](https://blog.waleedkhan.name/formatting-a-commit-stack/) + by Waleed Khan on Steno & PL personal blog. + It uses the `git test` command from the [git-branchless](https://github.com/arxanas/git-branchless) + suite of tools, which was first mentioned + in [Git Rev News Edition #76](https://git.github.io/rev_news/2021/06/27/edition-76/). ++ [How to Install GitQlient on Your Synology NAS](https://mariushosting.com/how-to-install-gitqlient-on-your-synology-nas/) + by Marius Bogdan Lixandru on his personal blog: Marius Hosting. ++ [Some ~~secret~~ git tricks that come in handy](https://dev.to/atordvairn/some-secret-git-tricks-that-come-in-handy-2k8i) + by raghav yadav on DEV\.to. ++ [Git banned.h: Why Git's Maintainers Have A List Of Banned Standard C Library Functions](https://initialcommit.com/blog/git-banned-functions) + by Jacob Stopak on Initial Commit. ++ [GitHub Copilot for CLI makes Terminal scripting and Git as easy as asking a question](https://dev.to/codepo8/github-copilot-for-cli-makes-terminal-scripting-and-git-as-easy-as-asking-a-question-3m81) + by Christian Heilmann on DEV\.to. + + + ++ [sqlite-history: tracking changes to SQLite tables using triggers](https://simonwillison.net/2023/Apr/15/sqlite-history/) + by Simon Willison on his Weblog. ++ [SmartCommit: A Graph-Based Interactive Assistant for Activity-Oriented Commits](https://www.cs.cmu.edu/~ckaestne/pdf/fse21_sc.pdf) \[PDF] + ([DOI:10.1145/3468264.3468551](https://doi.org/10.1145/3468264.3468551)) describes + a graph-partitioning-based interactive tool to help split tangled changesets. + The paper is accompanied by the [code for the core algorithm](https://github.com/Symbolk/SmartCommitCore) + of SmartCommit, a [demo GUI client](https://github.com/Symbolk/SmartCommit), + and [dataset and the visualization scripts](https://github.com/Symbolk/SmartCommitEvaluation-Viz) + used in the article. Since then, similar research studies have been conducted, + like [ComUnt](https://doi.org/10.1145/3545258.3545267) + and [UTango](https://doi.org/10.1145/3540250.3549171), + which cite the SmartCommit article. + + + +__Git tools and sites__ ++ [List of Free Learning Resources (In Many Languages)](https://github.com/EbookFoundation/free-programming-books) + by the Free Ebook Foundation, includes the list organized by subject, + where there are [free books about Version Control Systems](https://github.com/EbookFoundation/free-programming-books/blob/main/books/free-programming-books-subjects.md#version-control-systems), + including Git. Some of those were mentioned in Git Rev News. + This list was originally a clone of + [StackOverflow - List of Freely Available Programming Books](https://web.archive.org/web/20140606191453/http://stackoverflow.com/questions/194812/list-of-freely-available-programming-books/392926). + Has a dynamic webpage for searching the list at + . ++ [GitQlient](https://github.com/francescmm/GitQlient) is a multi-platform Git client written with Qt, + originally forked from [QGit](https://github.com/tibirna/qgit). ++ [Gut](https://gut-cli.dev/) is a user-friendly Git CLI for Windows, Mac, and GNU/Linux. + Written in Go, still in alpha stage of development. ++ [srcsnap](http://srcsnap.glitch.me/) ([repository](https://github.com/LingDong-/srcsnap)) + is a screenshot-driven version tracking tool, written using Electron. It's described in + [Srcsnap — Screenshot-Driven Version Tracking](https://www.media.mit.edu/projects/srcsnap-screenshot-driven-version-tracking/overview/) post + on [Future Sketches](https://www.media.mit.edu/groups/future-sketches/overview/) + MIT Media Lab group blog. ++ [diff2html](https://github.com/rtfpessoa/diff2html) is a JavaScript library + that generates pretty HTML diffs from `git diff` or unified `diff` output. + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Bruno Brito. diff --git a/_posts/2023-05-31-edition-99.markdown b/_posts/2023-05-31-edition-99.markdown new file mode 100644 index 000000000..0018a66c7 --- /dev/null +++ b/_posts/2023-05-31-edition-99.markdown @@ -0,0 +1,361 @@ +--- +title: Git Rev News Edition 99 (May 31st, 2023) +layout: default +date: 2023-05-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 99 (May 31st, 2023) + +Welcome to the 99th 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](https://git.github.io). + +This edition covers what happened during the months of April 2023 and May 2023. + +**To help us improve Git Rev News, please participate in our first +[Reader Survey](https://survs.com/survey/jo07oxsaom). It's up only +until our next edition, so for about one month.** + +## Discussions + + + + + +### Support + ++ [Weird behavior of `git log --before` or `git log --date-order`](https://lore.kernel.org/git/7728e059-d58d-cce7-c011-fbc16eb22fb9@cs.uni-saarland.de/) + + Thomas Bock reported an issue in + [a LibreOffice repository](https://github.com/LibreOffice/core) + where some commits from around 2010 were treated by `git log` as if + they had been created before 1980. + + Commands like `git log --before="1980-01-01"` or `git log + --date-order` both show or list some commits with an author date and + a commit date from around 2010 as if they were from before 1980. + + Thomas looked at the timestamps of the author and committer dates in + these commits, but they didn't appear to be broken, so he suspected a + Git bug. + + Peff, alias Jeff King, thanked Thomas "for providing a clear example + and reproduction recipe" and pointed out that the commits that + appeared to be from before 1980 were "malformed, but only + slightly". It appeared that their "author" and "committer" headers + contained something like: + + `Firstname Lastname> 1297247749 +0100` + + instead of simply: + + `Firstname Lastname 1297247749 +0100` + + that is, with an extra weird set of angle brackets. + + Peff also found that there were two different code paths for commit + parsing and they behaved differently when there was an extra set of + angle brackets. One, which was used to fill in the fields of a + `struct commit`, only parsed the "parents", "tree", and "committer + timestamp" fields. For that last field, it was using the + `parse_commit_date()` function which stopped at the first '>' and then + tried to parse the rest of the line as a timestamp, which failed and + returned a 0 timestamp if there was a second '>'. + + The other code path, used when the commit was displayed, called the + `split_ident_line()` function to parse the "author" and "committer" + headers, but this function was trying to find the last '>' in these + headers instead of the first one, which yielded the correct timestamp + when there were two or more '>'. + + Peff then suggested a patch to make `parse_commit_date()` behave like + `split_ident_line()` and find the last '>' instead of the first + one. He also discussed other possible ways to fix the issue, + including doing nothing as the commits were indeed malformed. + + Kristoffer Haugsbakk replied to Peff saying he was using a tool + called [`git repair`](https://git-repair.branchable.com) to try to fix + the original repo. But Peff said he wasn't sure `git repair` would be + able to fix it. He mentioned that + [`git filter-repo`](https://github.com/newren/git-filter-repo) or other + tools would be able to fix it, but would require the commit history + to be rewritten, which might not be "worth it for a minor problem + like this". + + Kristoffer replied that he gave up with `git repair` as it didn't + seem to finish, but was actually more interested in seeing if the + weird `git log` behavior went away to convince others it wasn't a + bug, rather than fixing the repo. + + Peff suggested carrying on with git-filter-repo's + `--commit-callback` option, or alternatively piping `git + fast-export` through `sed`, and then back to `git fast-import`, as he + was almost certain `git log` would properly work if the repo was + fixed. + + A few weeks later Kristoffer sent the URL of a repaired repo. He + said he couldn't use `git filter-repo`, but "`git commit-tree` + + `git replace` + `git filter-repo --force` worked". + + In the meantime, Junio Hamano, the Git maintainer, replied to Peff's + initial findings wondering which commit parsing function was used to + populate the commit-graph files where commit data is cached, as it + wouldn't be good to record broken timestamps there. + + Peff replied to Junio saying the commit-graph files are written from + the parsed "struct commit" objects which is good as we want those + cache files to always match the code that is used when they are not + available. If Peff's patch was applied to fix the parsing though, + that would mean that existing commit-graph files would need to be + manually removed, so that the fixed parsing could be used instead of + broken values stored in those files. + + Peff also discussed modifying the commit-graph code so that when a 0 + timestamp was recorded for a commit, this commit would be parsed again, but + thought it might not be worth the effort. Derrick Stolee discussed + this idea too, but agreed with Peff saying "this seems like quite a + big hammer for a small case". + + Thomas then thanked everyone for "clarifying this mystery" as the + explanations given "already helped a lot". He said that it would be + very useful to fix the parsing of the broken commits, but, if that + was considered to be too small a problem, he would like some kind of + error handling to be introduced for commits with 0 timestamps + instead of them being listed in the wrong time period. + + Peff then sent + [a first version of a small patch series](https://lore.kernel.org/git/20230422134150.GA3516940@coredump.intra.peff.net/) + to properly fix the parsing of the broken commits and to fix another + parsing bug he found in the same `parse_commit_date()` function. + + Junio reviewed Peff's patches and made a few suggestions, mostly + about code comments. Peff took them into account and sent + [a version 2 of his patch series](https://lore.kernel.org/git/20230425055244.GA4014505@coredump.intra.peff.net/) + which behaved in the same way as the previous one, but had improved + code comments. + + Phillip Wood then wondered if it would be better to not use + `strtoumax`(3) to parse timestamps as this standard C library function + is using the standard `isspace`(3) while we are using our own version + of `isspace`(3) which is different. Possible issues with strtoumax(3) + could also be related to different characters being considered + digits than in our code. This kind of issues come from the fact that + `strtoumax`(3), like many other standard C library functions, is taking + the current + [locale](https://en.wikipedia.org/wiki/Locale_(computer_software)) + into account. + + After some discussions between Peff, Phillip and Junio, Peff sent + [a version 3 of his patch series](https://lore.kernel.org/git/20230427081330.GA1461786@coredump.intra.peff.net/) + with small changes. Especially the new version makes sure Git rejects + timestamps that start with a character that we don't consider a + whitespace or a digit or the '-' character before using `strtoumax`(3) + as this was considered enough to avoid issues related to this + function. + + Phillip, Junio and Peff discussed this version a little bit more but + found it good, so it was merged and these changes will be in Git + v2.41.0 which will be released soon. + + + +## Releases + ++ Git [2.41.0-rc2](https://public-inbox.org/git/xmqqedn5fluv.fsf@gitster.g/), +[2.41.0-rc1](https://public-inbox.org/git/xmqqedncqkzf.fsf@gitster.g/), +[2.41.0-rc0](https://public-inbox.org/git/xmqqbkilvt63.fsf@gitster.g/) ++ Git for Windows [2.41.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.41.0-rc2.windows.1), +[2.41.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.41.0-rc1.windows.1), +[2.41.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.41.0-rc0.windows.1) ++ Bitbucket Server [8.10](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.5.6](https://www.gerritcodereview.com/3.5.html#356), +[3.6.5](https://www.gerritcodereview.com/3.6.html#365), +[3.7.3](https://www.gerritcodereview.com/3.7.html#373), +[3.8.0](https://www.gerritcodereview.com/3.8.html#380) ++ GitHub Enterprise [3.8.3](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.3), +[3.7.10](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.10), +[3.6.13](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.13), +[3.5.17](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.17) ++ GitLab [15.11.6](https://about.gitlab.com/releases/2023/05/24/gitlab-15-11-6-released/) +[16.0.1](https://about.gitlab.com/releases/2023/05/23/critical-security-release-gitlab-16-0-1-released/), +[16.0](https://about.gitlab.com/releases/2023/05/22/gitlab-16-0-released/), +[15.11.5](https://about.gitlab.com/releases/2023/05/19/gitlab-15-11-5-released/), +[15.11.4](https://about.gitlab.com/releases/2023/05/17/gitlab-15-11-4-released/), +[15.11.3, 15.10.7, and 15.9.8](https://about.gitlab.com/releases/2023/05/10/security-release-gitlab-15-11-3-released/), +[15.11.2, 15.10.6, and 15.9.7](https://about.gitlab.com/releases/2023/05/05/critical-security-release-gitlab-15-11-2-released/), +[15.11.1, 15.10.5, and 15.9.6](https://about.gitlab.com/releases/2023/05/02/security-release-gitlab-15-11-1-released/) ++ GitKraken [9.4.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.2.3](https://desktop.github.com/release-notes/) ++ Sourcetree [4.2.3](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.3.html) ++ Tower for Mac [9.3, 9.4](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) ([9.4 blog post](https://www.git-tower.com/blog/tower-mac-94/)) ++ git-credential-oauth [0.7.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.7.0) + +## Other News + +__Various__ + +* [GitHub code search is generally available](https://github.blog/2023-05-08-github-code-search-is-generally-available/) + by Colin Merkel on GitHub Blog. + * See also [A brief history of code search at GitHub](https://github.blog/2021-12-15-a-brief-history-of-code-search-at-github/) + in [Git Rev News Edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/), and + [The technology behind GitHub’s new code search](https://github.blog/2023-02-06-the-technology-behind-githubs-new-code-search/) + in [edition #96](https://git.github.io/rev_news/2023/02/28/edition-96/). + * [GitHub’s New Code Search is Bad for Finding Code](https://stackdiary.com/githubs-new-code-search-is-bad/) + by Alex Ivanovs on Stackdiary (complaining about lack of sort by _new_). + + +__Light reading__ + +* [Modeling Git Internals in Alloy, Part 3: Operations on Blobs and Trees](https://bytes.zone/posts/modeling-git-internals-in-alloy-part-3-operations-on-blobs-and-trees/) + by Brian Hicks on bytes\.zone continues the series of articles from [previous edition](https://git.github.io/rev_news/2023/04/30/edition-98/). +* [Why I prefer trunk-based development](https://trishagee.com/2023/05/29/why-i-prefer-trunk-based-development/) + by Trisha Gee. + * This article references [Perceived Barriers to Trunk Based Development](https://www.davefarley.net/?p=269) + by Dave Farley on his weblog (2018). + * You can find more about this workflow + on [Trunk Based Development](https://trunkbaseddevelopment.com/) site, + first mentioned in [Git Rev News Edition #24](https://git.github.io/rev_news/2017/02/22/edition-24/). + * Martin Fowler describes advantages and disadvantages of trunk-based development versus feature branches + in [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) + (biased towards better support for Continuous Integration), + mentioned first in [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/). + * For the other side of this discussion, see for example + [Working with Feature Branches](https://www.git-tower.com/blog/working-with-feature-branches/) + by Bruno Brito on Tower’s blog, mentioned in + [Git Rev News Edition #88](https://git.github.io/rev_news/2022/06/30/edition-88/). +* [5 Version-Control Systems that Game Developers Should Know About](https://thenewstack.io/5-version-control-tools-game-developers-should-know-about/) + by Sharone Zitzman on The New Stack. + Those 5 VCSs are: Git, Perforce, Plastic SCM (now Unity Version Control), SVN, + and [Diversion](https://www.diversion.dev/) (cloud SCM, in beta). +* [9 best GitHub [Android App] alternatives in 2023](https://www.androidpolice.com/best-github-alternatives/) + by Charnita Fance on Android Police. +* [Git Merge – The Definitive Guide](https://www.freecodecamp.org/news/the-definitive-guide-to-git-merge/) + by Omer Rosenbaum on freeCodeCamp. +* [Undo a [published] commit in Git](https://www.30secondsofcode.org/git/s/undo-commit-without-rewriting-history/) + by Angelos Chalaris on 30 Seconds of Code. +* [Git Best Practices – A Guide to Version Control for Beginners](https://www.freecodecamp.org/news/how-to-use-git-best-practices-for-beginners/) + by Adekola Olawale on freeCodeCamp. +* [Common Git Issues and How to Troubleshoot Them](https://dev.to/abdelrahmanallam/common-git-issues-and-how-to-troubleshoot-them-3jmd) + by Abdelrahman Mohamed Allam on DEV\.to, part of the + [Mastering Git: Essential and Advanced Commands for Developers](https://dev.to/abdelrahmanallam/series/22744) series. +* [The Power of Pre-Commit for Python Developers: Tips and Best Practices](https://dev.to/techishdeep/maximize-your-python-efficiency-with-pre-commit-a-complete-but-concise-guide-39a5) + by Deep Singh on DEV\.to. + * [Pre-Commit](https://pre-commit.com) framework for managing and maintaining + multiple multi-language pre-commit hooks (written as Python module) was first mentioned + in [Git Rev News Edition #45](https://git.github.io/rev_news/2018/11/21/edition-45/). +* [Creating effective pull requests](https://madhadron.com/programming/effective_pull_requests.html), + by madhadron (Frederick J. Ross). +* [How to Make your [Python] Code Shine with GitLab CI Pipelines](https://medium.com/semantixbr/how-to-make-your-code-shine-with-gitlab-ci-pipelines-48ade99192d1) + by fernanda rodríguez on Medium. +* [CI/CD with KiCad and GitLab](https://sschueller.github.io/posts/ci-cd-with-kicad-and-gitlab/) + by Stefan Schüller on his blog (on GitHub Pages). +* [Code review at the speed of email](https://drewdevault.com/2022/07/25/Code-review-with-aerc.html) + by Drew DeVault on Drew DeVault's blog (2022). + * See also for example [The advantages of an email-driven git workflow](https://drewdevault.com/2018/07/02/Email-driven-git.html) + by Drew DeVault, mentioned in [Git Rev News Edition #41](https://git.github.io/rev_news/2018/07/18/edition-41/). +* [Connect to multiple Git accounts of the same vendor (GitHub, Gitlab) portal](https://dev.to/mahadikrahul/connect-to-multiple-git-accounts-of-the-same-vendor-github-gitlab-portal-33l4) + by Rahul Mahadik on DEV\.to, originally guest-published at [theonetechnologies.com](https://theonetechnologies.com/blog/post/connect-to-multiple-git-accounts-of-the-same-vendor-github-gitlab-portal). +* [Database branching: three-way merge for schema changes](https://planetscale.com/blog/database-branching-three-way-merge-schema-changes): + Learn how PlanetScale uses Git-like three-way diff to resolve schema change conflicts across database branches. + Article by Shlomi Noach on PlanetScale Blog. + * You can find few tools to help version-control database schemas + in [Git Rev News Edition #60](https://git.github.io/rev_news/2020/02/19/edition-60/); + you can also find there [another article](https://github.blog/2020-02-14-automating-mysql-schema-migrations-with-github-actions-and-more/) by Shlomi Noach. + * In [Git Rev News Edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/) + you can find articles about different ways version control and databases connect, + and tools that can version control database schema (perform database migrations), + or version control queries, or version data within schema, etc. +* [Version Control Your ML (Machine Learning) Model Deployment With Git using Modelbit](https://towardsdatascience.com/version-control-your-ml-model-deployment-with-git-using-modelbit-1b3d76411436) + by Avi Chawla, published in Towards Data Science, a Medium blog. +* [GitOps - Operations by Pull Request](https://www.weave.works/blog/gitops-operations-by-pull-request) (2017) + and [What Is GitOps](https://www.weave.works/blog/what-is-gitops-really) (2018) + by Alex on Weaveworks blog. + * [Another article](https://www.weave.works/blog/kubernetes-anti-patterns-let-s-do-gitops-not-ciops) + from Weaveworks about GitOps can be found + in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/) (2018). + * You can find more about GitOps / GitDevOps on + [GitOps.tech](https://www.gitops.tech/) and [OpenGitOps](https://opengitops.dev/) sites, + first mentioned in [Git Rev News Edition #62](https://git.github.io/rev_news/2020/04/23/edition-62/) + and [#94](https://git.github.io/rev_news/2022/12/31/edition-94/), respectively. +* [4 Core Principles of GitOps](https://thenewstack.io/4-core-principles-of-gitops/) by Alex Williams, and + [GitOps as an Evolution of Kubernetes](https://thenewstack.io/gitops-as-an-evolution-of-kubernetes/) by Steven J. Vaughan-Nichols + on The New Stack. +* [Reproducible Data Dependencies for Python [with Quilt]](https://blog.jupyter.org/reproducible-data-dependencies-for-python-guest-post-d0f68293a99), + a guest post by Aneesh Karve published in Jupyter Blog (Medium-based blog). + * [DagsHub](https://dagshub.com/), a web platform for storing, versioning and managing data (data hub), + similar to [Quilt Data](https://quiltdata.com/) mentioned in this blog post, + was mentioned in various articles linked to in + [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/), + [#85](https://git.github.io/rev_news/2022/03/31/edition-85/), + [#96](https://git.github.io/rev_news/2023/02/28/edition-96/), and + tangentially in [#97](https://git.github.io/rev_news/2023/02/28/edition-96/). + * See also links about data versioning in + [Git Rev News Edition #96](https://git.github.io/rev_news/2023/02/28/edition-96/). +* [GitHub Copilot X CLI is your new GIT assistant](https://dev.to/this-is-learning/github-copilot-x-cli-is-your-new-git-assistant-1edn) + by Leonardo Montini for This is Learning, a part 3 in [GitHub Copilot X (5 Part Series)](https://dev.to/balastrong/series/23030) + on DEV\.to. Originally published at [leonardomontini.dev](https://leonardomontini.dev/copilot-x-git-cli/). + * Similar article, [GitHub Copilot for CLI makes Terminal scripting and Git as easy as asking a question](https://dev.to/codepo8/github-copilot-for-cli-makes-terminal-scripting-and-git-as-easy-as-asking-a-question-3m81) + can be found in [Git Rev News Edition #98](https://git.github.io/rev_news/2023/04/30/edition-98/). + + +* [BranchGPT: The AI-Powered Solution to Branch Names](https://stateful.com/blog/branchgpt-ai-powered-branch-names) + by Sebastian Tiedtke on Stateful\.com blog (_Tongue-in-cheek_ over the top take on AI). + + +__Easy watching and listening__ + +* [For those who just don’t Git it (The Stack Overflow Podcast | Ep. 573)](https://stackoverflow.blog/2023/05/23/for-those-who-just-dont-git-it-ep-573/) + where Pierre-Étienne Meunier, creator and lead developer + of open-source version control system [Pijul](https://pijul.org/) + (mentioned in [Git Rev News Edition #9](https://git.github.io/rev_news/2015/11/11/edition-9/), + [#24](https://git.github.io/rev_news/2017/02/22/edition-24/) and + [#38](https://git.github.io/rev_news/2018/04/18/edition-38/)), + talks about version control, functional programming, and OCaml. + + +__Git tools and sites__ + +* [Bytebase](https://www.bytebase.com/) - database schema change and version control + (the GitLab for Database DevOps): web-based collaboration workspace to help DBAs + and developers manage the database development lifecycle. +* [Quilt Data](https://quiltdata.com/) is a self-organizing data hub, + consisting of a Python API, web catalog, and backend to manage data sets in AWS S3. + The backend service is based on open-source [Quilt](https://github.com/quiltdata/quilt) + Python package ([documentation](https://docs.quiltdata.com/). + The development of [jupyterlab-quilt](https://github.com/quiltdata/jupyterlab) + extension seems to be stalled, though. +* [GitOps Principles v0.1.0](https://github.com/open-gitops/documents/blob/v0.1.0/PRINCIPLES.md) + published by [OpenGitOps](https://opengitops.dev/). +* [GIT Web Terminal](https://git-terminal.js.org/) (Git in your browser) + was created using [isomorphic-git](https://github.com/isomorphic-git/isomorphic-git) + (a pure JavaScript implementation of git for node and browsers). + Source code on GitHub: [jcubic/git](https://github.com/jcubic/git). + * [isomorphic-git](https://isomorphic-git.org/) was first mentioned in + [Git Rev News Edition #40](https://git.github.io/rev_news/2018/06/20/edition-40/). +* [schemadiff](https://vitess.io/blog/2023-04-24-schemadiff/) + is a declarative, programmatic library in Vitess + that can produce a diff in SQL format of two entities: + tables, views, or full blown database schemas. + * Compare [sqldiff.exe](https://www.sqlite.org/sqldiff.html), + which is a command-line utility program (Windows binary) + that displays content differences between two SQLite databases. + Mentioned in [Git Rev News Edition #87](https://git.github.io/rev_news/2022/05/26/edition-87/). + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Bruno Brito. diff --git a/_posts/2023-06-30-edition-100.markdown b/_posts/2023-06-30-edition-100.markdown new file mode 100644 index 000000000..8199d715e --- /dev/null +++ b/_posts/2023-06-30-edition-100.markdown @@ -0,0 +1,348 @@ +--- +title: Git Rev News Edition 100 (June 30th, 2023) +layout: default +date: 2023-06-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 100 (June 30th, 2023) + +Welcome to the 100th 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](https://git.github.io). + +This edition covers what happened during the months of May 2023 and June 2023. + + +### Some statistics about the ongoing first Git Rev News Readers Survey + +The [Git Rev News Reader Survey](https://survs.com/survey/jo07oxsaom) was announced +in the [previous edition](https://git.github.io/rev_news/2023/05/31/edition-99/) +with the goal to gather responses from the community to help improve Git Rev News. +Unfortunately, there we got only 11 responses to the survey (among 250 visits). +Compare this number to 3236 to 11498 responses to various Git User's Surveys... + +The results cannot be considered statistically significant, but here is what we have +gathered so far: + ++ Most enjoyed Git Rev News section was "Developer Spotlight (aka Interview)", + followed closely by "Discussions (General, Reviews, Support)". + Least enjoyed was the "Releases" section. ++ The order of Git Rev News section(s) agrees with readers expectations, + with the exception of the "Releases" section thought to better be near the end, + and the "Other News (aka Links)" to better be in the middle, swapping the + order of those two sections. ++ The survey gathered various interesting suggestions, among others: + + more developer (or even _user_) interviews, + + include a brief description of what is in the link, + + interviews with some authors of Git tools, + + include short articles about how to do source control and how Git is being used, + + add an *editorial* piece to start off the newsletter, + + add an index of previous Git Rev News (e.g. 'whom we interviewed'). ++ For the "Discussion" section the suggestions include adding headlines or subheadings, + having some images (e.g. diagrams or screenshots) where appropriate, + and adding a tl;dr summary to longer articles (or shortening them). ++ There was the idea of providing a simple web form to suggest contributors to be interviewed. ++ [VonC](https://stackoverflow.com/users/6309/vonc) was suggested for an interview, + and Jeff King (aka peff) and Junio C. Hamano for re-interviews. + +There will be further analysis of the responses in the future. +Thank you very much to everyone who participated in the Reader Survey. + + +## Discussions + + +### General + +- [Git participates in GSoC (Google Summer of Code) 2023](https://summerofcode.withgoogle.com/programs/2023/organizations/git) + + The following two contributors have been officially accepted to work on Git + as part of the [GSoC 2023](https://summerofcode.withgoogle.com/): + + - Kousik Sanagavarapu will work on the "[Unify ref-filter formats with other pretty formats](https://summerofcode.withgoogle.com/programs/2023/projects/rck3kmq2)" + project. Kousik will be co-mentored by Hariom Verma and Christian Couder. + Some details about his work on the project could be found in [his blog](https://five-sh.github.io/blog). + + - Shuqi Liang will work on the "[More Sparse Index Integrations](https://summerofcode.withgoogle.com/programs/2023/projects/Rkbc1Abe)" + project. Shuqi will be mentored by Victoria Dye. Further details about + the project and updates on progress can be found on [Shuqi's blog](https://cheskaqiqi.github.io/tags/GSoC/). + + Congratulations to the accepted contributors! + + Thanks also to the other contributors who applied and worked on micro-projects, + but couldn’t be selected! We hope to continue to see you in the community! + + + +### Reviews + +* [[PATCH 0/6] strbuf cleanups](https://lore.kernel.org/git/20230502211454.1673000-1-calvinwan@google.com/) + + Calvin Wan sent a 6 patch long series to clean up `strbuf` related + code. `strbuf` is a basic structure along with related functions, + implemented mostly in the "strbuf.c" and "strbuf.h" files, that is + used to manipulate character strings. + + The issue was that over time some functions with dependencies to + other code had been added into those files, and Calvin's series + wanted to get rid of these dependencies "with the goal of eventually + being able to stand up `strbuf` as a library". + + Most of the patches moved some functions to other files that were + using them, and one of them removed the use of environment + variables. + + Junio Hamano, the Git maintainer, suggested that some functions that + were moved to other files should be renamed so that they don't start + with "strbuf_" anymore, as they were not really string manipulating + functions. + + The series was also reviewed by Jeff King, Elijah Newren and Felipe + Contreras, who overall liked it. They commented on some patches + mostly to add some historical context or to ask for some + clarifications. + + Calvin sent + [a version 2 of the series](https://lore.kernel.org/git/20230503184849.1809304-1-calvinwan@google.com/) + that added a new patch at the beginning of the series to clarify the + purpose of the `strbuf` functions at the top of "strbuf.h". The other + changes in this version were small clarifications in the commit + messages of some patches or in code comments. + + Junio commented on the last patch of the series though. This patch + was supposed to remove the use of environment variables according to + its subject, but was in fact removing the dependencies of `strbuf` + functions on the `comment_line_char` global variable and adding a + new parameter to those functions instead. + + Calvin sent + [a new version of this patch](https://lore.kernel.org/git/20230503194201.2360016-1-calvinwan@google.com/) + calling it a v3 even though the other patches in the series were not + resent. Elijah reviewed this v2/v3 patch series and suggested some minor + changes in some commit messages. + + Calvin then sent + [a version 4 of the series](https://lore.kernel.org/git/20230508165728.525603-1-calvinwan@google.com/) + with the commit message changes suggested by Elijah and Junio. + + Both Eric Sunshine and Phillip Wood chimed in to comment on this + version. Eric suggested moving the comment added by the first patch + of the series further up in "strbuf.h" and making it clear that this + comment is for developers instead of mere users of the `strbuf` + functions. Phillip suggested simplifying the parameters of a + function where a new parameter was added by the last patch of the + series. + + Calvin then sent + [a version 5 of the series](https://lore.kernel.org/git/20230511194446.1492907-1-calvinwan@google.com/) + which included the suggestions made by Eric and Phillip. Eric replied + with some further small comments about the first and last patches of + the series. + + Calvin then sent + [a version 6 of the series](https://lore.kernel.org/git/20230512171429.2202982-1-calvinwan@google.com/) + with Eric's suggestions, and a few weeks later + [a version 7 of the series](https://lore.kernel.org/git/20230606194720.2053551-1-calvinwan@google.com/) + to fix a few minor issues related to the release of Git v2.41.0 in + the meantime. It looks like this series will be merged to the + 'master' branch soon though. + + + + +## Developer Spotlight: John Cai + +* Who are you and what do you do? + + My name is John Cai, and I started to contribute to the project back in 2021. I + also lead the Git team at GitLab, where we aim to improve Git and add features + that will make the lives of GitLab users and Git users better. + +* What would you name your most important contribution to Git? + + Adding a `--batch-command` mode to `cat-file` was the first feature that I + contributed to Git. It allows a single long running process to handle different + cat-file queries. Most developers wouldn't take advantage of this, but for Git + servers it's a nice feature. + +* What are you doing on the Git project these days, and why? + + Things like documentation improvements, as well as working on some small features + that will optimize the server side of things. At GitLab we are currently + developing a system that will contain many ephemeral refs, so we recently added + options to `git-pack-refs(1)` that allow the caller to specify refs to exclude + from the packed refs file. + + I still consider myself a bit of a newbie, but I love contributing however I can + since Git is such an impactful project. Further, since our team interfaces with + Git so much, I often notice opportunities for incremental improvements. Other + times, we have explicit needs to add a feature or enhancement to support + improvements to our Git data access layer in GitLab. + +* 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? + + Transition the project to a new refs backend! There have been plenty of great + discussions around this -- whether to go with the reftables backend or a new + format of the packed-refs file. Swapping out the refs backend would be a huge + undertaking, but well worth it, in my opinion. + +* What is your favorite Git-related tool/library, outside of + Git itself? + + When reviewing code, I've been using [meld](https://github.com/GNOME/meld). + I overall like the UI. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + I use GitGitGadget mostly, but also [b4](https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation) + is great for trying out patches locally. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + It can definitely be intimidating since the codebase is so storied and + technically deep. My suggestion is to just dive in and get started with + something small -- whether that be a documentation improvement or a code cleanup + marked with TODO. Also, keep an eye out for bug reports on the mailing list. + Fixing bugs also gives you experience with different parts of the code base. + + Part of my intimidation is not knowing how people on the mailing list would + respond to my contributions. Experiencing how helpful people were, and the + overall warmth of the community removed a lot of the emotional barrier of + contributing. + + Also, it's easy to read into tone in text-only communication, but the mailing + list is full of people who genuinely want to help. Don't let the fear prevent + you from contributing! You'll learn incrementally each time you send something + to the list. + +* If there's one tip you would like to share with other Git + developers, what would it be? + + Spend more time than you think you need to on crafting commit messages. It goes + a long way to clearly state the need, and how the patch addresses the need. + + Also, look for existing APIs in the codebase 😄. + + +## Other News + +__Various__ ++ [Highlights from Git 2.41](https://github.blog/2023-06-01-highlights-from-git-2-41/) + by Taylor Blau on GitHub Blog. ++ [Git 2.41 release - Here are five of our contributions in detail](https://about.gitlab.com/blog/2023/06/20/contributions-to-latest-git-release/) + by John Cai on GitLab Blog. ++ [The DVC 3.0 Stack: Beyond the Command Line](https://iterative.ai/blog/dvc-3.0-ml-experiments-data-versioning) + by Dave Berenbaum on Iterative\.ai blog. [DVC (Data Version Control)](https://dvc.org) + was first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/). ++ [Coming Up on Tower's Roadmap (2023)](https://www.git-tower.com/blog/coming-up-on-the-roadmap-2023/) + by Bruno Brito on Tower’s blog. ++ [Meet GitLab Duo, the suite of AI capabilities powering your workflows](https://about.gitlab.com/blog/2023/06/22/meet-gitlab-duo-the-suite-of-ai-capabilities/) + by David DeSanto on GitLab Blog. ++ [Crafting a better, faster GitHub Code View](https://github.blog/2023-06-21-crafting-a-better-faster-code-view/) + by Joshua Brown on GitHub Blog. + + +__Light reading__ ++ [Setting Up SSH for Commit Signing](https://www.git-tower.com/blog/setting-up-ssh-for-commit-signing/) by Bruno Brito on Tower’s blog. ++ [Applying GitOps principles to your operations](https://github.blog/2023-06-02-applying-gitops-principles-to-your-operations/) + by Chris Reddington on GitHub blog. GitOps set of practices was first mentioned + in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/); + [the previous edition (#99)](https://git.github.io/rev_news/2023/05/31/edition-99/) + includes many links about GitOps / GitDevOps. ++ [3 great Git alternatives: Fossil, Mercurial, and Subversion](https://www.infoworld.com/article/3699116/3-great-git-alternatives-fossil-mercurial-and-subversion.html) + by Serdar Yegulalp on InfoWorld. + + An article about [Fossil](https://fossil-scm.org/) did appear + in [Git Rev News Edition #11](https://git.github.io/rev_news/2016/01/13/edition-11/), + but is nowadays unavailable except through the [Internet Archive](https://web.archive.org/web/20160304055320/https://blog.kotur.org/posts/fossil-keeps-more-than-just-your-code.html). + + In [Git Rev News Edition #87](https://git.github.io/rev_news/2022/05/26/edition-87/) + you can find referenced an article about + [Why SQLite Does Not Use Git](https://sqlite.org/whynotgit.html) but Fossil. ++ [Too Much Git? Try Gitless](https://hackaday.com/2023/06/18/too-much-git-try-gitless/) + by Bryan Cockfield on Hackaday. [Gitless](http://gitless.com/) was first mentioned + in [Git Rev News Edition #20](https://git.github.io/rev_news/2016/10/19/edition-20/). ++ [How to Clean Up Your Local Repository with Git Commands](https://dev.to/this-is-learning/how-to-clean-up-your-local-repository-with-git-commands-531o) + by Emanuele Bartolesi for This is Learning on DEV\.to. ++ [Git Change Commit Message – How to Edit Commit Messages with Git Amend](https://www.freecodecamp.org/news/how-to-edit-git-commit-messages-with-git-amend/) + by Shittu Olumide on freeCodeCamp. ++ [Git: rebase VS merge (simple)](https://dev.to/kristiyan_velkov/git-rebase-vs-merge-simple-2e7e) + by Kristiyan Velkov on DEV\.to is a second part of his + [series of articles about Git](https://dev.to/kristiyan_velkov/series/23390). ++ [The Ultimate Guide to Writing Effective Commit Messages: Best Practices and Conventional Commits](https://skerritt.blog/writing-better-commit-messages/) + by Autumn Skerritt on her blog. ++ [How to use Meld as a difftool for Git?](https://dev.to/abbazs/how-to-use-meld-as-a-difftool-for-git-5ai3) + by abbazs on DEV\.to. + + +__Easy watching__ ++ [2023-06-20 GitLab Gitaly Community Office Hours](https://www.youtube.com/watch?v=INvu3C5oZWE) + on GitLab Unfiltered channel on YouTube, + showing a live coding session developing a small feature in Git + (the video is around 1 hour long, and included subtitles in English). + + +__Git tools and sites__ ++ [git-sweep](https://github.com/arc90/git-sweep) is a command-line tool + that helps you clean up Git branches that have been merged into master. + Written in Python. ++ [databooks](https://databooks.dev/) is a package and a CLI tool + to ease the collaboration between data scientists using Jupyter notebooks, + by reducing the number of git conflicts between different notebooks + and resolution of git conflicts when encountered. + + Alternatives include [nbdev](https://nbdev.fast.ai/) tool that creates + programming environment out of Jupyter notebooks + (first mentioned in [Git Rev News Edition #69](https://git.github.io/rev_news/2020/11/27/edition-69/)), + [nbdime](http://nbdime.readthedocs.io/) tool for diffing Jupyter notebooks + (first mentioned in [edition #37](https://git.github.io/rev_news/2018/03/21/edition-37/)), + and [jupytext](https://github.com/mwouts/jupytext) tool for bi-directionally converting + Jupyter notebooks to plain text files as either Markdown files or Python scripts + (also mentioned in edition #69). ++ [Awesome git addons](https://github.com/stevemao/awesome-git-addons) + is a curated list of add-ons that extend/enhance the git CLI, + though a bit out of date (last change is from October 2021). + +## Releases + ++ Git [2.41.0](https://public-inbox.org/git/xmqqleh3a3wm.fsf@gitster.g/) ++ Git for Windows [2.41.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.41.0.windows.1) ++ GitHub Enterprise [3.8.5](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.5), +[3.7.12](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.12), +[3.6.15](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.15), +[3.5.19](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.19), +[3.9.0](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.0), +[3.8.4](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.4), +[3.7.11](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.11), +[3.6.14](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.14), +[3.5.18](https://help.github.com/enterprise-server@3.5/admin/release-notes#3.5.18) ++ GitLab [16.1](https://about.gitlab.com/releases/2023/06/22/gitlab-16-1-released/) +[16.0.5](https://about.gitlab.com/releases/2023/06/16/gitlab-16-0-5-released/), +[15.11.9](https://about.gitlab.com/releases/2023/06/15/gitlab-15-11-9-released/), +[16.0.4](https://about.gitlab.com/releases/2023/06/08/gitlab-16-0-4-released/), +[16.0.3](https://about.gitlab.com/releases/2023/06/07/gitlab-16-0-3-released/), +[15.11.8](https://about.gitlab.com/releases/2023/06/07/gitlab-15-11-8-released/), +[16.0.2](https://about.gitlab.com/releases/2023/06/05/security-release-gitlab-16-0-2-released/) ++ Bitbucket Server [8.11](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitKraken [9.5.1](https://help.gitkraken.com/gitkraken-client/current/), +[9.5.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.2.6](https://desktop.github.com/release-notes/), +[3.2.5](https://desktop.github.com/release-notes/), +[3.2.4](https://desktop.github.com/release-notes/) ++ Tower for Windows [5.0](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) ([blog post](https://www.git-tower.com/blog/tower-windows-5/)) ++ Tower for Mac [10.0](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) ([blog post](https://www.git-tower.com/blog/tower-mac-10/)) ++ git-credential-oauth [0.8.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.8.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Bruno Brito and Victoria Dye. diff --git a/_posts/2023-07-31-edition-101.markdown b/_posts/2023-07-31-edition-101.markdown new file mode 100644 index 000000000..d84090d31 --- /dev/null +++ b/_posts/2023-07-31-edition-101.markdown @@ -0,0 +1,411 @@ +--- +title: Git Rev News Edition 101 (July 31st, 2023) +layout: default +date: 2023-07-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 101 (July 31st, 2023) + +Welcome to the 101st 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](https://git.github.io). + +This edition covers what happened during the months of June 2023 and July 2023. + +## Discussions + +### General + ++ [[ANNOUNCE] Virtual Contributor's Summit 2023](https://public-inbox.org/git/ZMATKIaU1A1D0wJg@nand.local/) + + Taylor Blau from GitHub announced that GitHub will host a Virtual + Contributor's Summit this year. Previously he + [announced](https://lore.kernel.org/git/ZJoDjnr+FkgrDsKA@nand.local/) + that there would be no Git Merge in-person event this year. + + The announce of the Virtual Contributor's Summit 2023 contained + links for participants to register, to suggest topics and to vote on + proposed topics. + +### Reviews + ++ [[RFC PATCH 0/8] Introduce Git Standard Library](https://public-inbox.org/git/20230627195251.1973421-1-calvinwan@google.com/) + + Calvin Wan sent a 8 patch long RFC series to the mailing list to + introduce a "Git Standard Library". This new library was intended to + be a base library for other Git libraries to build upon. + + This followed previous effort from Calvin and Elijah Newren to + cleanup [headers](https://lore.kernel.org/git/pull.1525.v3.git.1684218848.gitgitgadget@gmail.com/) + and internal APIs like the + [`strbuf` API](https://lore.kernel.org/git/20230606194720.2053551-1-calvinwan@google.com/) + to manipulate character strings and the + [git-compat-util API](https://lore.kernel.org/git/20230606170711.912972-1-calvinwan@google.com/) + to provide wrapper compatibility functions masking OS differences. + It also followed previous + [discussions about turning parts of Git into libraries](https://lore.kernel.org/git/CAJoAoZ=Cig_kLocxKGax31sU7Xe4==BGzC__Bg2_pr7krNq6MA@mail.gmail.com/) + and the ongoing + [video conferences](https://lore.kernel.org/git/CAJoAoZmBFTi5SFRuG8uh4ZyGs7pKQTYQLzZAC82zh2pMSggX3A@mail.gmail.com/) + that are regularly hosted by Google about libifying Git. + + Building Git already involves creating an internal library called + `libgit.a` that contains a lot of common code used by many Git + commands. The Git executable is then created by linking all the + object files for the Git subcommands (like `git log`) and the `git` + command itself against `libgit.a` and a few external + dependencies. The goal with the new Git Standard Library, also + called `git-std-lib.a`, and the Git libification effort is to have a + number of small independent libraries (like `object-store.a`, and + `config.a`) all using `git-std-lib.a`. These small independent + libraries would also be linked together to form `libgit.a`, which + would then be used to create the Git executable like today. The + benefit would be that "if someone wanted their own custom build of + Git with their own custom implementation of the object store, they + would only have to swap out `object-store.a` rather than do a hard + fork of Git". + + The new Git Standard Library is considered necessary for the + libification effort, because there are numerous circular and + ubiquitous dependencies that are very difficult to untangle and it + probably wouldn't be worth untangling them. As the libification + effort doesn't promise stability of interfaces though, it would + still be possible to extract some small libraries from + `git-std-lib.a` later if there is ever a need to be able to swap + them out. + + Calvin noted that a pitfall of this series was the introduction of + `#ifdef GIT_STD_LIB` preprocessor instructions to stub out some code + and hide some function headers. He asked for comments about how it + would be possible to avoid those instructions which make the code + harder to understand. He also mentioned that some of the + compatibility code in `compat/` still had dependencies outside + `git-std-lib.a`, but that it just meant that "some minor + compatibility work" might be needed in the future. + + As to the testing of the new library, he said that "the temporary test file + added by the series will be replaced with unit tests once a unit + testing framework is decided upon", pointing to the + [related discussion](https://lore.kernel.org/git/8afdb215d7e10ca16a2ce8226b4127b3d8a2d971.1686352386.git.steadmon@google.com/). + That discussion is actually an RFC patch series that in its latest + version only adds an + [asciidoc document](https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc) + explaining the plan to add a unit test framework to Git and + containing a table comparing the possible unit test frameworks that + Git could adopt. + + Victoria Dye and then Jeff Hostetler replied to the first patch in + Calvin's series saying that they didn't agree with the fact that the + Trace2 code wouldn't be in `git-std-lib.a`. They pointed out that it + should be possible to use the Trace2 tracing functions everywhere in + the Git code, even in low-level functions. Calvin replied that he + would look into possible solutions like redrawing the boundaries of + the library or stubbing out tracing in it to accommodate that need. + + Phillip Wood commented on a few patches saying he liked the idea, + but suggested that the library should also contain the code related + to [gettext](https://www.gnu.org/software/gettext/) and to some + basic data structures ("hashmap.c" and "string-list.c"). He also + suggested some improvements and a way to deal with the Trace2 issue. + + Junio Hamano, the Git maintainer, was happy that one patch removed + the dependency many files had on "config.c". He wondered though if + another patch that removed a wrapper function to remove a dependency + did the right thing, as the function had a number of callers. Glen + Choo then chimed in to suggest an alternative way to remove that + dependency and both Calvin and Junio agreed that this would be a + good way forward. + + Glen separately reported that he had trouble building the series. + Calvin clarified that the series was based on Git v2.41 and sent a + [link to the code](https://github.com/calvin-wan-google/git/tree/git-std-lib-rfc). + + Linus Arver also replied to Calvin's series by asking a number of + questions. He wondered if adding the standard library would make it + harder or not to refactor code into separate libraries or to create + separate programs that would use only some Git API, like for example + the API in "trailer.c" that helps parse commit message trailers + (e.g. "Signed-off-by: Author Name ). He asked + for more information about the tradeoffs between accepting the + circular dependencies and untangling them, and made a number of + other suggestions. + + It's not clear yet if the libification effort and the idea of a Git + Standard Library will bring a lot of changes to the code base soon, + but that could be an interesting possibility. + + + + +## Developer Spotlight: Martin Ågren + +* Who are you and what do you do? + + I'm Martin Ågren. I live in Sweden, where I spend some of my spare time + in the garden or tending to the bees to the best of my abilities. I also + enjoy reading books and listening to music (not at the same time). + +* What would you name your most important contribution to Git? + + The number of breathtaking features I've contributed is probably a + one-digit number ending in a zero. That said, I think I've contributed a + bit to the documentation by fixing some fairly ugly misrenderings, but + also by aligning the way it's formatted by the two tools we support, + asciidoc and asciidoctor. I guess we'll never know this for a fact, but + there's a chance that I've saved someone's crontab by fixing a bug that + would eat it. I'm very happy that I fixed that bug before it was ever + included in a release. + +* What are you doing on the Git project these days, and why? + + I'm mostly just tinkering. I very rarely feel like there's something + actually missing from Git. I'm mostly trying to contribute in order to + show that gratitude and to help others, without occupying too much + bandwidth. + +* 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? + + Complete the hash function transition. brian m. carlson has done a + tremendous job making sure there are these two parallel worlds, if you + want. What's missing now is making them interoperable. This is not + necessarily the biggest *problem* in current Git, but it could be + something that won't be fixed by short-term, this-quarter, + profit-maximizing actors, so if I could decree a team to work on that + without having to worry about "return on investment" and such, I'd + probably go for that. + +* If you could provide users of Git with one piece of advise, + what would it be? + + The one thought I would like to somehow convey to everyone using Git is + to commit early, commit often. Whatever crap you have ever had in your + working tree, there's an object containing it. Use `git reset --hard`, + `git rebase`, `git cherry-pick`, whatever floats your boat, you will be + able to bring it back and polish it up into a Git history that looks + like you knew what you were doing all along. + + I think this is really the point about Git: it teaches you how to + pretend to be a good programmer, and once you start thinking of shaping + your work like that, you actually might turn into one. Not because "fake + it till you make it", that's just bullshit, but because you actually + spend time approaching problems the right way and start thinking about + how you present your solution. + + Your "solution" is then not just the state of the working tree ("look! + it compiles and all the tests pass, so it must be good!"), but also how + you got there, as a series of well-motivated incremental changes. + +* What is your favorite Git-related tool/library, outside of + Git itself? + + I'm a big fan of `tig`, especially `tig blame`. I simply never use `git + blame`. If I'm allowed to count `git/contrib` as "outside of Git + itself", I'll be more than happy to recommend `git jump`. It's not + especially sexy, but I probably use it every single day and I find it + extremely helpful. + +* Do you happen to have any memorable experience w.r.t. contributing to + the Git project? If yes, could you share it with us? + + I still sometimes think back to when I posted my first patch series to + the list. Peff wrote "[...] I'm very impressed with the attention to + detail for a first-time contributor.", to which Junio replied "Yes.". + Of course, a part of even remembering that is vanity on my part, but I + do think those two sentences are fairly representative of each of their + communication styles. They also capture perfectly well the kind of + review style that I wish a lot more projects used. You know, it is + allowed to not just point out something that is wrong or could be + better. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + For the list, it's gmail.com, lore.kernel.org/git, `git am`, `git format-patch`, + and `git send-email`. I keep thinking I should set up something + more advanced, but for the limited volumes I'm handling, it's fine. For + development of Git [and other stuff], it's Vim, `git diff`, `git add -p`, + `git commit --amend`, `git rebase -i`, `git range-diff`, `tig blame`, + `git jump` (grep, merge, diff) and ... maybe that's about it. Well, `git show` + and `git log` of course. Please note the `-p` in `git add -p`. I would like + to live in a world where no-one blindly does `git add . && git commit`. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + Do something you enjoy doing. Of all the people born any given year, not + even one of them, on average, will ever become president of the United + States. Don't do open source because it could land you a nice job + somewhere, sometime. Don't do Git development because it seems like a + good investment. Do open source because you believe in it and see some + random thing that you want to contribute to. If you don't see that, + plant a flower instead and watch it grow. + + This obviously comes from someone who is privileged enough to be able to + say "don't worry, be happy" and talk in metaphors about gardening. That + said, I do think there's a difference in keeping bees and tending to + them. You shouldn't want to keep them, you should want to help them do + their thing. And if you want to help Git do its thing, great! + + Start by lurking on the mailing list to get a feel for how it works. + Then do some small improvement, and avoid growing the scope too much. + Sleep on your patch, review it yourself and iterate that process a few + times before actually sending it off. + + +## Other News + +__Various__ +- A [Git community](https://programming.dev/c/git) has been created in the programming.dev Lemmy instance. +- [Passwordless authentication is now available on GitHub.com](https://github.blog/2023-07-12-introducing-passwordless-authentication-on-github-com/) + (with [passkeys](https://www.passkeys.io/)), as a public beta. +- [Meet Smart Locks, a new way to reduce merge conflicts with Unity Version Control](https://blog.unity.com/engine-platform/unity-version-control-smart-locks) + (previously Plastic SCM). + + Locks in DVCS were [also supported](https://ericsink.com/vcbe/html/veracity_locks.html) + in SourceGear's [Veracity SCM](http://veracity-scm.com/) + (which is no longer developed, it's last version was from 2013). + + See also [Git for games: current problems and solutions](https://www.youtube.com/watch?v=K3zOhU3NdWA&list=PL0lo9MOBetEFqBue4vNcTEnkBjgIQU1Q3&index=7) + video from Git Merge 2019. + +__Light reading__ ++ [Scaling merge-ort across GitHub](https://github.blog/2023-07-27-scaling-merge-ort-across-github/) + by Matt Cooper on GitHub Blog, describing how and why GitHub have switched + from performing merges and rebases [using libgit2](https://github.blog/2015-12-15-move-fast/) + to using merge-ort for it ([available in Git since 2.33](https://github.blog/2021-08-16-highlights-from-git-2-33/#merge-ort-a-new-merge-strategy)), + and performing worktree-less rebases using the new [work-in-progress](https://public-inbox.org/git/20230407072415.1360068-1-christian.couder@gmail.com/t/#u) + [`git replay` command](https://github.com/newren/git/commits/replay). + [Merge commits were created using the merge-ort strategy](https://github.blog/changelog/2022-09-12-merge-commits-now-created-using-the-merge-ort-strategy/) + on GitHub since September 2022, as mentioned in [Git Rev News Edition #91](https://git.github.io/rev_news/2022/09/30/edition-91/). ++ [Git and Jupyter Notebooks: The Ultimate Guide](https://www.reviewnb.com/git-jupyter-notebook-ultimate-guide) + by ReviewNB. The article mentions the following tools: + + [nbdime](https://nbdime.readthedocs.io/en/latest/), + mentioned first in [Git Rev News Edition #37](https://git.github.io/rev_news/2018/03/21/edition-37/), + + [jupyterlab-git](https://github.com/jupyterlab/jupyterlab-git) extension, + described in more detail in [How to use the JupyterLab Git extension](https://blog.reviewnb.com/jupyterlab-git-extension/) + on ReviewNB Blog, + + [ReviewNB](https://www.reviewnb.com/) app for GitHub, for when + [rich notebook diffs on GitHub](https://github.blog/changelog/2023-03-01-feature-preview-rich-jupyter-notebook-diffs/) fail, + + [nbdev](https://nbdev.fast.ai/), which includes support for better Git handling for Jupyter notebooks + (see [Fix merge conflicts in jupyter notebooks](https://nbdev1.fast.ai/merge.html) for nbdev1, + and [Git-Friendly Jupyter](https://nbdev.fast.ai/tutorials/git_friendly_jupyter.html) for nbdev2), + and was mentioned in [Git Rev News Edition #69](https://git.github.io/rev_news/2020/11/27/edition-69/), + and also mentioned in [Edition #100](https://git.github.io/rev_news/2023/06/30/edition-100/) + as one of alternatives for [databooks](https://databooks.dev/) tool, + + [NBviewer](https://nbviewer.org/) and [Binder](https://mybinder.org/) services. ++ [How To Automate Your Server Database Backup Using Git](https://confidence.sh/blog/automate-your-server-database-backup/) + and cron, + by Confidence Okoghenun on his blog (also on [DEV\.to](https://dev.to/megaconfidence/how-to-automate-your-server-database-backup-using-git-2pc2)). ++ [How to Use Git Shallow Clone for Faster Repository Cloning](https://www.howtogeek.com/devops/how-to-use-git-shallow-clone-for-faster-repository-cloning/) + (and cloning only a single branch, and creating sparse blobless and treeless clones) + by Anthony Heddings on How-To Geek. + This can be useful when you want to examine Git repos with long histories, + and is also useful for Continuous Integration pipelines (CI/CD), + since the CI/CD process likely does not need to know the entire Git history. ++ [How To Undo or Reverse a Git Merge](https://www.howtogeek.com/devops/how-to-reverse-a-git-merge/) + by Anthony Heddings on How-To Geek. ++ [The Git Rebase Handbook – A Definitive Guide to Rebasing](https://www.freecodecamp.org/news/git-rebase-handbook/) + by Omer Rosenbaum on freeCodeCamp, + continuing from [Git Merge – The Definitive Guide](https://www.freecodecamp.org/news/the-definitive-guide-to-git-merge/) + mentioned in [Git Rev News Edition #99](https://git.github.io/rev_news/2023/05/31/edition-99/) + (and other posts). ++ [Mastering Git Shortcuts: A Guide to Git Aliases](https://dev.to/pradumnasaraf/mastering-git-shortcuts-a-guide-to-git-aliases-324j) + by Pradumna Saraf on DEV\.to - though the guide is limited to simple aliases, + and does not cover forcing an alias to be treated as a shell command, + or tricks that one can use for advanced handling of alias parameters. ++ [.gitattributes Best Practices](https://rehansaeed.com/gitattributes-best-practices/) + by Muhammad Rehan Saeed on his blog (2020). ++ [The Power of Git: A Guide to Collaborative Version Control](https://dev.to/opensauced/the-power-of-git-a-guide-to-collaborative-version-control-dl6) + by BekahHW for OpenSauced on DEV\.to. ++ [A Guide to Perfecting Pull Requests](https://dev.to/karaluton/a-guide-to-perfecting-pull-requests-2b66) + by Kara Luton on DEV\.to. ++ [Effective Code Reviews](https://addyosmani.com/blog/code-reviews/) + by Addy Osmani on his blog. ++ [The Gentle Art Of Patch Review](https://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/) + by Sage Sharp on their blog (2014). + + +__Easy listening__ ++ [Git with Derrick Stolee](https://podrocket.logrocket.com/git-scalar) + on PodRocket (a web development podcast from LogRocket). + + +__Git tools and sites__ ++ [Emoji-Log](https://github.com/ahmadawais/Emoji-Log) — A simple Emoji Git commit log messages spec standard. + + Similar [GitMoji](https://gitmoji.dev/) standard — an emoji guide for your commit messages, + was mentioned in [Git Rev News Edition #47](https://git.github.io/rev_news/2019/01/23/edition-47/). ++ [thefuck](https://github.com/nvbn/thefuck) + is a command line application + which corrects your previous console command. + Among others it includes series of rules for correcting mistakes when using Git + (like typos in command names, trying to `git add` an ignored file, etc.). + Written in Python. ++ New Relic [CodeStream](https://www.codestream.com/) is a free [open-source](https://github.com/TeamCodeStream/codestream) + extension for VS Code, Visual Studio, and JetBrains + (with support for more IDEs on the way) + for putting collaboration tools in the IDE: + supporting pull requests, issue management, observability, and code discussion. ++ [jupyterlab-git](https://github.com/jupyterlab/jupyterlab-git) + is a JupyterLab extension for version control using Git. ++ [ReviewNB](https://www.reviewnb.com/) is a paid GitHub and Bitbucket app + for rich diffs and commenting (including code review) for Jupyter Notebooks, + free for open source (for public repositories) and academic use: + see [pricing](https://www.reviewnb.com/#pricing). + You can request self hosted installation (distributed as Docker image). ++ [pwclient](https://github.com/getpatchwork/pwclient) is the command-line client for + the [Patchwork](http://jk.ozlabs.org/projects/patchwork/) web-based patch tracking tool. + Patchwork was mentioned in [Git Rev News Edition #20](https://git.github.io/rev_news/2016/10/19/edition-20/), + in passing in [Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/) + (as then base for [snowpatch](https://github.com/ruscur/snowpatch) CI for patches, + now also supporting GitHub Actions), + in passing in [Edition #55](https://git.github.io/rev_news/2019/09/25/edition-55/) + (as being similar to [patchew](https://github.com/patchew-project/patchew) + patch tracking and testing system), + and in passing in [Edition #88](https://git.github.io/rev_news/2022/06/30/edition-88/) + (as being used by [Sourceware](https://sourceware.org/) service). + Patchwork is used for [some Linux kernel development](https://patchwork.kernel.org/). ++ JetBrains Academy [offers a 'Master Git and GitHub in 5 Hours'](https://blog.jetbrains.com/education/2023/07/06/introduction-to-git-track/) + course [on Hyperskill](https://hyperskill.org/tracks/48) for free, + with the project-based part of the course available only for paid users (Premium). + +## Releases + ++ Git for Windows [2.41.0(3)](https://github.com/git-for-windows/git/releases/tag/v2.41.0.windows.3), +[2.41.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.41.0.windows.2) ++ libgit2 [1.7.0](https://github.com/libgit2/libgit2/releases/tag/v1.7.0) ++ GitLab [15.11.13](https://about.gitlab.com/releases/2023/07/27/gitlab-15-11-13-released/) +[16.2.1](https://about.gitlab.com/releases/2023/07/25/gitlab-16-2-1-released/), +[16.2](https://about.gitlab.com/releases/2023/07/22/gitlab-16-2-released/), +[15.11.12](https://about.gitlab.com/releases/2023/07/17/gitlab-15-11-12-released/), +[16.1.2, 16.0.7, and 15.11.11](https://about.gitlab.com/releases/2023/07/05/security-release-gitlab-16-1-2-released/), +[16.1.1, 16.0.6, and 15.11.10](https://about.gitlab.com/releases/2023/06/29/security-release-gitlab-16-1-1-released/) ++ Bitbucket Server [8.12](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ Gerrit Code Review [3.6.6](https://www.gerritcodereview.com/3.6.html#366), +[3.7.4](https://www.gerritcodereview.com/3.7.html#374), +[3.8.1](https://www.gerritcodereview.com/3.8.html#381) ++ GitHub Enterprise [3.9.1](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.1), +[3.8.6](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.6), +[3.7.13](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.13), +[3.6.16](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.16), +[3.9.0](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.0) ++ GitKraken [9.6.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.2.7](https://desktop.github.com/release-notes/) ++ Tower for Mac [10.1](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) ++ git-credential-oauth [0.9.1](https://github.com/hickford/git-credential-oauth/releases/tag/v0.9.1), +[0.9.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.9.0) ++ gitolite [v3.6.13](https://groups.google.com/g/gitolite-announce/c/Ba5yVnkf_lQ/m/xB72ygAIDQAJ) + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Eren Canpolat, Bruno Brito, +Kristoffer Haugsbakk, Junio Hamano and +Štěpán Němec. diff --git a/_posts/2023-08-31-edition-102.markdown b/_posts/2023-08-31-edition-102.markdown new file mode 100644 index 000000000..0707e6766 --- /dev/null +++ b/_posts/2023-08-31-edition-102.markdown @@ -0,0 +1,446 @@ +--- +title: Git Rev News Edition 102 (August 31st, 2023) +layout: default +date: 2023-08-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 102 (August 31st, 2023) + +Welcome to the 102nd edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of July 2023 and August 2023. + +## Discussions + + + + + +### Support + ++ [Git Privacy](https://public-inbox.org/git/CTZ9RD9RQ5UO.3OIJX50PKMIR0@anonymous/) + + Nick, alias Nicholas Johnson, asked on the Git mailing list if it + would be possible to implement an integrated feature in Git, perhaps + a config option, to obfuscate the committer and author timestamps + that are stored in commits when they are created. + + Nick is the creator of [Git Privacy](https://git.nicholasjohnson.ch/git-privacy/) + which is a repository containing + [instructions in a README.md file](https://git.nicholasjohnson.ch/git-privacy/tree/README.md) + that already helps developers obfuscate Git timestamps, and also + explains why it can be a good idea to do so. + + The instructions suggest setting the `GIT_AUTHOR_DATE` and + `GIT_COMMITTER_DATE` environment variables when committing, so that + the timestamps in these variables are recorded instead of the + current date, time and timezone. + + Nick thought that using such environment variables or other not + fully integrated mechanisms like Git hooks was too cumbersome and + asked for ideas or feedback about how to improve the situation. + + Junio Hamano, the Git maintainer, replied to Nick, saying that his + opinion was that it might not be worth implementing an integrated + feature, as using such a feature removed "half the value of keeping + your work in [a] source code management system". Especially it would + make it harder to refute possible claims that the source code + contained stolen proprietary IP (Intellectual Property). + + Nick replied that he conceded it might not be worth it to implement + his original suggestion. He said that having Git automatically + converting local time to UTC in the timestamps it records could still + be useful to avoid leaking the developer's time zone. He pointed to + [a Gerrit issue](https://git.issues.gerritcodereview.com/issues/40000039) + about this. + + Junio replied that he still thought it wasn't worth the effort as + there was not enough reason to go against Git's initial design to + store the timezone. + + Nick replied to Junio saying that storing the timezone revealed + private information about developers without much gain, and that a + config option could let users decide about doing this or not. + + This led to a separate sub-thread where Nick and Jason Pyeron + started to design a `--privacy=option1,option2` with corresponding + config variables to change the timezone, specify a date precision, + etc. brian m. carlson said he would support timezone and timestamp + tweaking options and made some technical suggestions too. + + René Scharfe chimed in on the main thread saying that + "timezone and timestamps are personal data, which may only be + collected and processed for a lawful purpose according to the GDPR", + referring to the European Union's + [General Data Protection Regulation](https://gdpr-info.eu/). + So he thought that the user should be able to control if that data + should be stored or not, and it was a usability issue if he could + not easily do that. He also noticed that `git commit` already has a + `--date=` option to change the author date and a `--signoff` + option for adding `Signed-off-by: Author Name ` + trailers. He concluded by saying "adding config options for + controlling timestamp granularity is hard to say no to". + + Nick replied that he was asking for this feature for moral reasons + not for legal ones. He took the example of the + [I2P project](https://geti2p.net/en/) which is a layer on top of + Internet to protect people's activity and location, saying that most + developers of the project don't want their timezones leaked as they + are known only under pseudonyms. + + Junio replied to René saying that the `--date=` option had + good reasons to exist. For example, the committer might be relaying + somebody else's changes, or a system clock might have an issue. He + also thought that the existing two environment variables are the + right place to draw the line, as Git developers shouldn't be + pretending to be security engineers and invent their own time + obfuscating mechanisms. + + In another email, Junio explained in more detail why it's more + important to be able to tweak the author timestamp than the + committer timestamp. He also repeated that two environment variables + were a good place for other security minded people to build on a + quality "privacy enhancing `date` command" that could also be used + outside the Git context. + + Junio replied to himself saying that a "--useless-time" option, or a + "core.uselesstime" configuration variable to make timestamps only + use UTC and be otherwise nearly meaningless could be OK though, as + they wouldn't have "privacy" in their name and wouldn't pretend to be + a quality privacy feature. He laid out how such a feature could + work, and noticed that features like `git log --since=...` wouldn't + then be expected to properly work. + + Nick agreed that such a feature shouldn't use "privacy" in its name, + and said that Junio's proposed feature would satisfy the privacy use + case he was interested in, and that he didn't want more than that. + + Theodore Ts'o then chimed in to point out that "someone still might + be able to figure out information from when a branch gets pushed to + a git repo". He mentioned that for example GitHub, GitHub actions + and integration systems could also leak information about when users + are active. + + Nick replied to Ted saying that protecting privacy had to start + somewhere, even if not all the tools were already doing it. + + Future will tell if someone will actually implement something along + the lines that have been discussed, and whether it will be a + "privacy enhancing `date` command" usable outside the Git context, + or an option integrated into Git. + +## Developer Spotlight: Calvin Wan + +* Who are you and what do you do? + + My name is Calvin Wan and I'm a Software Engineer on the Git Core team + at Google. + + I also enjoy playing poker, volleyball, and ping pong. I play the + World Series of Poker Main Event every year and one of these years I'm + hoping to make the final table 😄 + +* What would you name your most important contribution to Git? + + I'm hoping my in-flight [series for a Git Standard Library](https://public-inbox.org/git/20230810163346.274132-1-calvinwan@google.com/) + will become my most important contribution to Git...at least for now 😄 + +* What are you doing on the Git project these days, and why? + + Currently working on getting Git Standard Library merged -- to + summarize it will serve as the foundation for other libraries in Git + to be built off of. When we first embarked on this journey towards + libification, we had many reasons for doing so, most of which Emily + captured in the [initial proposal](https://lore.kernel.org/git/CAJoAoZ=Cig_kLocxKGax31sU7Xe4==BGzC__Bg2_pr7krNq6MA@mail.gmail.com/). + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + Old style submodules. Submodule development is already difficult to + work on, and having extra bits and pieces in the codebase that exist + for the sole purpose of not breaking old style submodules added an + extra layer of complexity I wish I didn't have to reason about. + +* Do you happen to have any memorable experience w.r.t. contributing to + the Git project? If yes, could you share it with us? + + Attending Git Merge 2022! I enjoyed meeting the people I had been + interacting with on list -- putting a face to the name was + particularly exciting. I also enjoyed the discussions at the + Contributor Summit and the talks that followed. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + I develop using VSCode and send my patches with `git format-patch` and + `git send-email`. For patches upstream, I use `b4 am` + `git am` to + test locally. When I reply to patches I use a script I modified from + Jonathan Tan to set up the replies for `git send-email`. For simple + replies and emails, I use Gmail's plaintext mode. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + I think there are plenty of good resources out there that others have + probably mentioned before ([Pro Git book](https://git-scm.com/book/en/v2), + [MyFirstContribution](https://git-scm.com/docs/MyFirstContribution), + [git-mentoring list](https://groups.google.com/g/git-mentoring/about)), + but the one suggestion I would have is spend less time worrying about + getting the right setup and spend more time getting your patches to list! + + +## Other News + +__Various__ ++ [Highlights from Git 2.42](https://github.blog/2023-08-21-highlights-from-git-2-42/) + by Taylor Blau on GitHub Blog. Those include + faster object traversals with reachability bitmaps, + excluding references by pattern in `git for-each-ref`, + preserving precious objects from garbage collection via `gc.recentObjectsHook`, + and other changes. ++ [Git 2.42 Released With Less Warnings For SHA-256 Usage](https://www.phoronix.com/news/Git-2.42-Released) + by Michael Larabel on Phoronix. ++ [GitLab Gitaly project now supports the SHA-256 hashing algorithm](https://about.gitlab.com/blog/2023/08/28/sha256-support-in-gitaly/) + by John Cai on GitLab Blog. + + [Gitaly](https://gitlab.com/gitlab-org/gitaly) is + an RPC interface to Git used by GitLab, + first mentioned in [Git Rev News Edition #24](https://git.github.io/rev_news/2017/02/22/edition-24/). ++ [Sourceware 25 Roadmap](https://sourceware.org/sourceware-25-roadmap.html): + roadmap for the next 25 years on \[almost] the 25th anniversary + (Sourceware came online on 6 September 1998). + + [Sourceware](https://sourceware.org/) service was first mentioned in + [Git Rev News Edition #88](https://git.github.io/rev_news/2022/06/30/edition-88/). ++ [Lazygit Turns 5: Musings on Git, TUIs, and Open Source](https://jesseduffield.com/Lazygit-5-Years-On/) + by Jesse Duffield on his Pursuit Of Laziness blog. + + [lazygit](https://github.com/jesseduffield/lazygit) is a simple [windowed] terminal UI for Git, + written in Go. It was first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/); + you can find links to other articles about this tool in [Edition #61](https://git.github.io/rev_news/2020/03/25/edition-61/) + and [#81](https://git.github.io/rev_news/2021/11/29/edition-81/). + + +__Light reading__ ++ [7 Git Mistakes a Developer Should Avoid](https://www.git-tower.com/blog/7-git-mistakes-a-developer-should-avoid/) + by Bruno Brito on Tower Blog, describing why some habits -- + committing unrelated changes together, + writing bad commit messages, + not using `.gitignore`, + leaving outdated merged-in branches, + using force push in a shared repository, + storing API keys and other secrets in a repository, + and storing large binary files -- + cause problems, and how to prevent them + (often how to do it with the help of the Tower Git client). ++ [Simplified: 8 Guidelines for Commit Message](https://dev.to/titusnjuguna/simplified-8-guidelines-for-commit-message-536g) + by Tito (titusnjuguna) on DEV\.to. ++ [Security in Code Reviews: Ensuring Secure and Robust Software Development](https://dev.to/documatic/security-in-code-reviews-ensuring-secure-and-robust-software-development-17kp) + by Jatin Sharma for Documatic, lists some common security vulnerabilities, + presents a few examples of real-world incidents, and explains how to + incorporate security into the code review process (and what the challenges are). ++ [One Git Trick for Perfect Commits](https://0ro.github.io/posts/one-git-trick-for-perfect-commits/) + by Raman Nikitsenka (0ro) on his blog (and [also on DEV\.to](https://dev.to/0ro/one-git-trick-for-perfect-commits-3728)). + The trick to avoid "fix: ..." commits littering history + is to use `git commit --fixup` and `git rebase --interactive --autosquash` + (before submitting changes). ++ [Git Config Articles: Pragmatic Suggestions for Customizing Your Git Setup from Karl Stolley](https://medium.com/pragmatic-programmers/git-config-articles-beec83c82b91) + by Margaret Eldridge in The Pragmatic Programmers on Medium. + It is a list of Git Config articles written by [Karl Stolley](https://medium.com/u/b6139288f4b6) + for The Pragmatic Programmers. ++ [Simplify Your Workflow 📈: A Guide to Standardizing Commit Messages with Husky 🐶 in Monorepos 📦](https://dev.to/harithzainudin/simplify-your-workflow-a-guide-to-standardizing-commit-messages-with-husky-in-monorepos-542l) + by Muhammad Harith Zainudin on DEV\.to. + + [Husky](https://github.com/typicode/husky), a Git hook management tool, was first mentioned in + [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/); + you can find links to other articles talking about it in + [#87](https://git.github.io/rev_news/2022/05/26/edition-87/) and + [#89](https://git.github.io/rev_news/2022/07/31/edition-89/). + + The idea of Monorepos (using a single repository for the whole codebase) + was first mentioned in [Git Rev News Edition #4](https://git.github.io/rev_news/2015/06/03/edition-4/). + You can find links to articles advocating for and against monorepos + in [Git Rev News Edition #47](https://git.github.io/rev_news/2019/01/23/edition-47/), + and a list of pros and cons of monorepos in + [Edition #81](https://git.github.io/rev_news/2021/11/29/edition-81/). + [Monorepo.tools](https://monorepo.tools/) is a place where you can find + information about monorepos and tools for handling them + (this site was first mentioned in [Git Rev News Edition #84](https://git.github.io/rev_news/2022/02/28/edition-84/)). ++ [You won’t believe how much time you will save with this Git pre-push hook](https://www.ivanmorgillo.com/2023/07/23/you-wont-believe-how-much-time-you-will-save-with-this-git-pre-push-hook/) + by Ivan Morgillo on his blog, + about integrating [Git hooks](https://git-scm.com/docs/githooks) with static code analysis tools, + such as [Detekt](https://detekt.dev/) (a static code analyzer for Kotlin), + for Android projects. ++ [Git advanced (text) diff: .odt, .pdf, .doc, .xls, .ppt](https://medium.com/@mbrehin/git-advanced-diff-odt-pdf-doc-xls-ppt-25afbf4f1105) + by Maxime Bréhin on Medium (2016) + describes how to configure [`textconv` gitattribute](https://www.git-scm.com/docs/gitattributes#_performing_text_diffs_of_binary_files) + for those files. ++ [IAMbic: Bridging the Gap Between IAM (Identity and Access Management) Changes and Version Control](https://www.noq.dev/blog/iambic-bridging-the-gap-between-iam-changes-and-version-control) + by Curtis Castrapel on Noq company blog. IAMbic detects IAM changes, + whether you're using Terraform, Cloudformation, + or directly making changes via the AWS Management Console, + and creates Git commits to represent the exact state of your IAM + in a Git repository. ++ [Delta: A new git diff tool to rock your productivity](https://dev.to/cloudx/delta-a-new-git-diff-tool-to-rock-your-productivity-2773) + by Axel Navarro for Cloud(x); on DEV\.to + (posted on 16 Jul 2020, updated on 22 May 2022). + + [Delta](https://dandavison.github.io/delta/), + a syntax-highlighting pager for git, diff, and grep output, + was first mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/). + ++ [Git Files Hidden In Plain Sight 🫥](https://tylercipriani.com/blog/2023/07/31/git-files-hidden-in-plain-sight/) + by Tyler Cipriani on his blog, + about some wonderful bad ideas, + like storing data in a repository in a way that GitHub thinks it is empty. + + +__Easy watching__ ++ [Git Hidden Gems - Enrico Campidoglio - NDC Oslo 2023](https://www.youtube.com/watch?v=WtUCZYyv-_w) + (length: 59:11).
Talks about + [04:15](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=255s) pretty logs, + [08:23](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=503s) pretty diffs, + [10:24](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=624s) staging, + [18:57](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=1137s) searching, + [22:27](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=1347s) automation, + [28:48](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=1728s) dot notation, + [33:20](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=2000s) rebase onto, + [38:24](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=2304s) reflog, and + [45:44](https://www.youtube.com/watch?v=WtUCZYyv-_w&t=2744s) rerere. ++ [Pijul: Version-Control Post-Git • Pierre-Étienne Meunier • GOTO 2023](https://www.youtube.com/watch?v=7MpdZkGj5AI): + the presentation recorded at GOTO Aarhus 2023 (length: 50:10).
+ [Pijul](https://pijul.org/) was first mentioned in + [Git Rev News Edition #9](https://git.github.io/rev_news/2015/11/11/edition-9/). + + +__Git tools and sites__ ++ [Git Tag Ops](https://github.com/iterative/gto) by Iterative\.AI + turns your Git repository into an Artifact Registry. + Together with [DVC](https://dvc.org/) (Data Version Control), + GTO serves as a backbone for Git-based [Iterative Studio Model Registry](https://dvc.org/doc/studio/user-guide/model-registry/what-is-a-model-registry). + GTO works by creating annotated Git tags in a standard format. + Written in Python. + + [DVC](https://dvc.org/) and GitOps were first mentioned in + [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/). ++ [Turtle](https://gitlab.gnome.org/philippun1/turtle) + is a graphical interface for version control intended to run on GNOME and the Nautilus file manager. + Written in Python using GTK4 and libadwaita for the GUI, + and [pygit2](https://www.pygit2.org/) for interacting with Git, + with Nautilus plugin support. + + See [TortoiseGit](https://tortoisegit.org/), + Windows Shell interface to Git, + providing overlay icons showing the file status, + and a powerful context menu for Git in a file manager. + Tracked since [Git Rev News Edition #57](https://git.github.io/rev_news/2019/11/20/edition-57/#releases). + + _Turtles_, _tortoises_, and _terrapins_ are common names + used for animals from a taxonomical order of reptiles named Testudines. ++ [Commit](https://github.com/m1guelpf/commit) + is a command palette-style Git client for blazing-fast commits. + You open it with a keyboard shortcut, write your commit, + and Commit will automatically detect which repo you've been working on. + Written using the [Tauri](https://tauri.app/) toolkit + in TypeScript and Node.js for UI, and Rust for the backend. + Inspired by [TailwindUI's Commit template](https://tailwindui.com/templates/commit). ++ [GitButler](https://docs.gitbutler.com/) (currently in _alpha_ phase) + is intended to be a Source Code Management system designed to manage your branches, + record and backup your work, be your Git client, help with your code, etc.; + focusing on everything after writing code in your editor and before sharing it on GitHub. ++ [GQL](https://amrdeveloper.github.io/GQL/) (Git Query Language) + is a query language with a syntax very similar to SQL, + with a tiny engine to perform queries on Git repositories + on the fly without the need to create database files + or convert `.git` files into any other format. + Written in Rust. + + [Gitana](https://github.com/SOM-Research/Gitana), + [first mentioned](https://livablesoftware.com/gitana-sql-git-repository-inspector/) + in [Git Rev News Edition #7](https://git.github.io/rev_news/2015/09/09/edition-7/), + exports the data contained in one or more Git repositories to a relational database, + relying on an incremental propagation mechanism that refreshes the database content + with the latest modifications in Git repositories. + Gitana has been archived in September 2022 and is not maintained anymore. + Written in Python. + + [gitbase](https://github.com/src-d/gitbase), + [first mentioned](https://www.youtube.com/watch?v=f_G1vwynxTg) + in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/), + is a SQL database interface to Git repositories (on the fly), + implementing the MySQL wire protocol. + It can be used to perform SQL queries about the Git history + and about the Universal AST (Abstract Syntax Tree) of the code itself. + Was a part of now defunct [source{d} Community Edition](https://sourced.tech/products/community-edition/), + still in _alpha_ phase. + Written in Go. + + [MergeStat](https://github.com/mergestat/mergestat) ([demo](https://www.mergestat.com/demo)) + enables SQL queries for data in Git repositories (and related sources, such as the GitHub API). + It allows you to ask questions about the history and contents of your source code. + Written in TypeScript, can use Docker Compose to run locally.
+ [mergestat-lite](https://github.com/mergestat/mergestat-lite) + is a command-line version of the tool, which runs SQL queries against local git repositories. + Written in Go.
+ MergeStat was included in _"SQL for querying Git repos"_ tools list + in [Git Rev News Edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/). + + [World of Code](https://worldofcode.org/) + is an infrastructure for study of software supply chains, + utilizing Tokyo Cabinet, custom binary storage, MongoDB, and Clickhouse + to store data, and which provides shell API + and (limited) Python API for querying data + from 173 million Git repositories on their infrastructure. + Described in an [article on arXiv from 2020](https://arxiv.org/abs/2010.16196). ++ [git-com](https://github.com/masukomi/masuconfigs/blob/master/bin/git-scripts/git-com) + by masukomi is an interactive CLI tool to help you create commit messages + that are not only readable, but follow a standardized format. + Described in [this Mastodon thread](https://fosstodon.org/@masukomi@connectified.com/110808660504633258). + Written in Bash. ++ [git-identity](https://github.com/cookiengineer/git-identity) (in Go) and + [GitID](https://github.com/InderdeepBajwa/gitid) (in TypeScript, uses Node.js) + are both tools that provide a convenient command-line interface + to manage and switch between multiple identities on a single user account. + + +## Releases + ++ Git [2.42.0](https://public-inbox.org/git/xmqqr0nwp8mv.fsf@gitster.g/), +[2.42.0-rc2](https://public-inbox.org/git/xmqqwmxwgfvr.fsf@gitster.g/), +[2.42.0-rc1](https://public-inbox.org/git/xmqqpm3ug824.fsf@gitster.g/), +[2.42.0-rc0](https://public-inbox.org/git/xmqq5y5uli4t.fsf@gitster.g/) ++ Git for Windows [2.42.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.42.0.windows.1), +[2.42.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.42.0-rc2.windows.1), +[2.42.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.42.0-rc1.windows.1), +[2.42.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.42.0-rc0.windows.1) ++ libgit2 [1.7.1](https://github.com/libgit2/libgit2/releases/tag/v1.7.1) ++ Bitbucket Server [8.13](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitHub Enterprise [3.9.4](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.4), +[3.8.9](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.9), +[3.7.16](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.16), +[3.6.18](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.18), +[3.9.3](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.3), +[3.8.8](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.8), +[3.7.15](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.15), +[3.6.17](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.17), +[3.10.0](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.0) ++ GitLab [16.3](https://about.gitlab.com/releases/2023/08/22/gitlab-16-3-released/) +[16.2.4](https://about.gitlab.com/releases/2023/08/11/gitlab-16-2-4-released/), +[16.1.4](https://about.gitlab.com/releases/2023/08/03/gitlab-16-1-4-released/), +[16.2.3](https://about.gitlab.com/releases/2023/08/03/gitlab-16-2-3-released/), +[16.2.2, 16.1.3, and 16.0.8](https://about.gitlab.com/releases/2023/08/01/security-release-gitlab-16-2-2-released/) ++ GitKraken [9.7.1](https://help.gitkraken.com/gitkraken-client/current/), +[9.7.0](https://help.gitkraken.com/gitkraken-client/current/), +[9.6.1](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.2.9](https://desktop.github.com/release-notes/), +[3.2.8](https://desktop.github.com/release-notes/) ++ git-credential-azure [0.2.2](https://github.com/hickford/git-credential-azure/releases/tag/v0.2.2), +[0.2.1](https://github.com/hickford/git-credential-azure/releases/tag/v0.2.1), +[0.2.0](https://github.com/hickford/git-credential-azure/releases/tag/v0.2.0), +[0.1.0](https://github.com/hickford/git-credential-azure/releases/tag/v0.1.0) ++ git-credential-oauth [0.10.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.10.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Calvin Wan and Štěpán Němec. diff --git a/_posts/2023-09-30-edition-103.markdown b/_posts/2023-09-30-edition-103.markdown new file mode 100644 index 000000000..ca90ddcec --- /dev/null +++ b/_posts/2023-09-30-edition-103.markdown @@ -0,0 +1,278 @@ +--- +title: Git Rev News Edition 103 (September 30th, 2023) +layout: default +date: 2023-09-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 103 (September 30th, 2023) + +Welcome to the 103rd edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of August 2023 and September 2023. + +## Discussions + +### General + +* [Git participated in GSoC (Google Summer of Code) 2023](https://summerofcode.withgoogle.com/programs/2023/organizations/git) + + The following contributors have successfully passed their final + evaluation and published a final report: + + - Shuqi Liang worked on the + [More Sparse Index Integrations](https://summerofcode.withgoogle.com/programs/2023/projects/Rkbc1Abe) + project. She was mentored by Victoria Dye. The final + report can be found on [her website](https://cheskaqiqi.github.io/2023/08/22/Final/). + + - Kousik Sanagavarapu worked on the + [Unify ref-filter formats with other --pretty formats](https://summerofcode.withgoogle.com/programs/2023/projects/rck3kmq2) + project. He was co-mentored by Christian Couder and Hariom Verma. + The final report can be found on [his website](https://five-sh.github.io/2023/08/26/the-final-report). + + Congratulations to these contributors and their mentors! + + + +### Support + +* [Fetching too many tags?](https://lore.kernel.org/git/274ec1a2152b0fd53b35c1591f5177e0b0713430@rjp.ie/) + + Ronan Pigott noticed that when he fetched from some repos, for + example from the + ["Linux Stable" repo](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux) + on [kernel.org](https://git.kernel.org/), most of the time seemed to + be spent transferring tags from the remote to the client. + + When his local repo was up-to-date and `git fetch` was used with + `--no-tags` (or its `-n` shortcut), it took less than 0.4 seconds + versus more than 1.7 seconds without it. + + He asked if there was a reason for this seemingly useless transfer of + tags even when the remote didn't have to send any commit. + + Peff, alias Jeff King, replied that "this is how the Git protocol + works". He explained that the server only lists all the refs it + knows about, and expects the client to select the refs it wants + among them. "Only the client knows what it already has." For + example, there could be new tags on the server pointing to commits + that the client already has. + + Peff also mentioned that in recent Git versions an extension of the + Git protocol allows clients to list only the refs they are + interested in, so that the server can send "a much smaller ref + advertisement". + + Ronan asked if Peff was talking about the `--negotiation-tip` + option, as some tests using this option didn't result in better + performance. + + Peff replied that `--negotiation-tip` was only useful when there are + commits that should be transferred. When histories on the client and + the server have diverged, this option helps them find a common + commit that can be the base for the commits that will be + transferred. + + Peff said the extension of the Git protocol he was talking about are + "ref-prefix" lines in Git's "v2" protocol, which is the default + protocol since Git v2.29. This protocol allows the client to speak + first and specify which ref prefixes it's interested in with these + "ref-prefix" lines. + + Setting the `GIT_TRACE_PACKET` to `1` allows one to see the packets + exchanged between the client and the server, especially the + "ref-prefix" lines when for example `git fetch --no-tags origin + master` is launched using a recent Git, or the "have" and "want" + lines when client and server have to negotiate a common commit. + + Ronan tested Peff's suggestions and thanked him as he then + understood why the tag advertisement was useful. + + + +## Other News + +__Various__ + +* [Critical GitHub Vulnerability Exposes 4,000+ Repositories to Repojacking Attack](https://thehackernews.com/2023/09/critical-github-vulnerability-exposes.html) + on The Hacker News. The vulnerability was caused by a race condition + within GitHub's repository creation and username renaming operations. +* [Nx lands $16M to build ‘monorepo’ tools for software devs](https://techcrunch.com/2023/09/25/nx-lands-16m-to-build-monorepo-tools-for-software-devs/) + by Kyle Wiggers on TechCrunch. The funding will be used to expand + [Nx](https://nx.dev/)’s fully managed product, + [Nx Cloud](https://nx.dev/nx-cloud/intro/what-is-nx-cloud), + a replacement for existing continuous integration tools, such as Jenkins, + with first class [monorepo](https://monorepo.tools/) support. +* [Harness launches Gitness, an open-source GitHub competitor](https://techcrunch.com/2023/09/21/oh-gitness-harness-launches-gitness-an-open-source-github-competitor/) + by Frederic Lardinois on TechCrunch. + + +__Light reading__ + +* [In a git repository, where do your files live?](https://jvns.ca/blog/2023/09/14/in-a-git-repository--where-do-your-files-live-/) + by Julia Evans on her blog. +* [Don’t create `.gitkeep` files, use `.gitignore` instead](https://adamj.eu/tech/2023/09/18/git-dont-create-gitkeep/) by Adam Johnson. +* [Signing Commits in Git, Explained](https://blog.gitbutler.com/signing-commits-in-git-explained/) + by Scott Chacon on [GitButler](https://gitbutler.com/) Blog. +* [Selecting the Right Git Merging Strategy: Merge Commit, Squash and Merge, or Rebase and Merge](https://akashrajpurohit.com/blog/selecting-the-right-git-merging-strategy-merge-commit-squash-and-merge-or-rebase-and-merge/) + by Akash Rajpurohit on his blog. +* [Drop git pull for fetch and rebase](https://developers.redhat.com/articles/2023/09/07/drop-git-pull-fetch-and-rebase) + by Yftach Herzog on RedHat Developer Blog, arguing that `git fetch` followed + by `git rebase` is a safer alternative (with a feature branch workflow). +* [Advanced Git Commands and Workflows: A Comprehensive Guide for Developers](https://dev.to/documatic/advanced-git-commands-and-workflows-a-comprehensive-guide-for-developers-5865) + by Matías Hernández Arellano for Documatic on DEV\.to; + covers interactive rebase, cherry-picking, `git bisect`, reflog, `git blame`, + and various Git collaboration workflows. +* [Git Delta is a Syntax Highlighting Pager for git, diff, and grep output](https://laravel-news.com/git-delta) + by Paul Redmond on Laravel News blog. [Delta](https://dandavison.github.io/delta/) + was first mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/); + there is a link to [another article about Delta](https://dev.to/cloudx/delta-a-new-git-diff-tool-to-rock-your-productivity-2773) + in [Edition #102](https://git.github.io/rev_news/2023/08/31/edition-102/). + * There is also a [Delta](https://github.com/octavore/delta) command-line diff tool + implemented in Go, with a [dead homepage](http://delta.octavore.com/) + ([archive](https://web.archive.org/web/20201108092055/http://delta.octavore.com/)), + mentioned in [Git Rev News Edition #9](https://git.github.io/rev_news/2015/11/11/edition-9/). +* [Git-Based Software Development Life-Cycle](https://nordstroem.ch/posts/2023-09-10-git-sdlc.html) + by Kris considers whether tools like + [git-appraise](https://github.com/google/git-appraise), + [git-issue](https://github.com/dspinellis/git-issue), and + [git-bug](https://github.com/MichaelMure/git-bug) + that store their information, history, and artifacts directly in the repository + can replace development tools such as + Jira (planning, issue tracking), + Confluence (wiki, documentation platform), + Bamboo (CI/CD server), + Artifactory (storing Docker images and CI/CD artifacts), and + Gerrit (code review). + * [Git Rev News Edition #43](https://git.github.io/rev_news/2018/09/19/edition-43/) + includes a list of similar tools and links related to them. + * [git-appraise](https://github.com/google/git-appraise) was first mentioned + in [Git Rev News Edition #11](https://git.github.io/rev_news/2016/01/13/edition-11/). +* [Delving Deeper into Gitamic: Power and Flexibility Beyond Statamic's Built-In Git Features](https://laravel-news.com/gitamic) + by Eric L. Barnes on Laravel News blog. + [Gitamic](https://marketplace.anystack.sh/item/gitamic) is a premium + [Statamic CMS](https://statamic.com/) add-on that allows you + to take full control of your Git workflow from within your CMS. +* [GitLab CI: 10+ Best Practices to Avoid Widespread Anti-patterns](https://dev.to/zenika/gitlab-ci-10-best-practices-to-avoid-widespread-anti-patterns-2mb5) + by Benoit COUETIL for Zenika on DEV\.to. +* [Fossil Versus Git](https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki) + on Fossil Wiki. + + + +__Easy watching__ + +* [The Git Parable: a different approach to understanding Git](https://www.youtube.com/watch?v=ANNboouhNHE), + a talk by Johan Herland for Tweag, based on Tom Preston-Werner's + [essay of the same name](https://tom.preston-werner.com/2009/05/19/the-git-parable.html) (2009) + covered in [Git Rev News #30](https://git.github.io/rev_news/2017/08/16/edition-30/). + + +__Git tools and sites__ + +* [git-credential-azure](https://github.com/hickford/git-credential-azure) is a credential helper + that authenticates to [Azure Repos](https://azure.microsoft.com/en-us/products/devops/repos). +* [git-vain](https://git.anna.lgbt/anna/git-vain) is a tool to generate + vanity hashes quickly; it can be used for example to make SHA-1 hash + of the HEAD begin with `c0ffee`. Written in Rust. Other similar tools: + * [git-vanity-sha](https://github.com/mattbaker/git-vanity-sha), written in Ruby, + mentioned in [Git Rev News Edition #39](https://git.github.io/rev_news/2018/05/16/edition-39/). + * ~~[git-sham](https://bitbucket.org/tpettersen/git-sham)~~ + (no longer available); first mentioned in + [Git Rev News Edition #4](https://git.github.io/rev_news/2015/06/03/edition-4/). +* [git-issue](https://github.com/dspinellis/git-issue) is a minimalist + decentralized issue management system based on Git, + offering (optional) bidirectional integration with GitHub and GitLab issue management. + Written as set of shell scripts. + * Similarly named [git-issues](https://github.com/duplys/git-issues), written in Python, + was mentioned in [Git Rev News Edition #43](https://git.github.io/rev_news/2018/09/19/edition-43/). +* [Cup](https://cup.flipt.io/) is an extensible server for building automation + around introspection and contributions to Git and SCMs like GitHub. + It is an active experiment into the benefits of managing an API over Git. + Written in Go by [Flipt](https://www.flipt.io/) - the open source, self-hosted + feature flag solution. + * [Flipt](https://www.flipt.io/) itself was mentioned in + [Git Rev News Edition #96](https://git.github.io/rev_news/2023/02/28/edition-96/). +* [Gitness](https://gitness.com/) by [Harness](https://www.harness.io/) + is an open-source code hosting and pipeline engine, + with source control management, Continuous Integration and Continuous Delivery, + that can be easily installed using Docker. Written in Go. + Can be considered the next generation of [Drone](https://www.drone.io/). +* [Gitopia](https://docs.gitopia.com) is the next-generation + Decentralized Code Collaboration Platform + fueled by a decentralized network and interactive token economy. + It is designed to optimize the software development process through collaboration, + transparency, and open source incentivization. + You need to have a [supported wallet](https://docs.gitopia.com/wallet-overview) + with sufficient LORE tokens to use Gitopia's services. + Pushing changes to Gitopia is done with the help of `git-remote-gitopia` helper. + * Compare with [git-ssb](https://scuttlebot.io/apis/community/git-ssb.html) + (see [git-ssb-intro](https://github.com/hackergrrl/git-ssb-intro) guide): + decentralized git repo hosting and issue tracking on secure-scuttlebutt (SSB), + mentioned in [Git Rev News Edition #26](https://git.github.io/rev_news/2017/04/19/edition-26/) + and [#40](https://git.github.io/rev_news/2018/06/20/edition-40/). + * Contrast with [ForgeFed](https://forgefed.org/) (formerly GitPub), + a federation protocol for forge services (ActivityPub extension), mentioned in + [Git Rev News Edition #69](https://git.github.io/rev_news/2020/11/27/edition-69/) + and [#95](https://git.github.io/rev_news/2023/01/31/edition-95/), + and various projects in different stages of development that implement it: + [Vervis](https://vervis.peers.community/), [Forgejo](https://forgejo.org/), + [ForgeFlux](https://forgeflux.org/), and [Forgefriends](https://forgefriends.org/). +* [Mermaid](https://mermaid.js.org/), a JavaScript-based diagramming and charting tool + that can be embedded in Markdown documents + (which [is supported on GitHub](https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/)), + now supports [Gitgraph Diagrams](https://mermaid.js.org/syntax/gitgraph.html). + + +## Releases + ++ Git for Windows [2.42.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.42.0.windows.2) ++ Gerrit Code Review [3.6.7](https://www.gerritcodereview.com/3.6.html#367), +[3.7.5](https://www.gerritcodereview.com/3.7.html#375), +[3.8.2](https://www.gerritcodereview.com/3.8.html#382) ++ GitHub Enterprise [3.10.2](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.2), +[3.10.1](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.1), +[3.9.5](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.5), +[3.8.10](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.10), +[3.7.17](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.17), +[3.6.19](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.19), +[3.10.0](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.0), +[3.9.4](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.4), +[3.8.9](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.9), +[3.7.16](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.16), +[3.6.18](https://help.github.com/enterprise-server@3.6/admin/release-notes#3.6.18) ++ GitLab [16.4](https://about.gitlab.com/releases/2023/09/22/gitlab-16-4-released/) +[16.3.4 and 16.2.7](https://about.gitlab.com/releases/2023/09/18/security-release-gitlab-16-3-4-released/), +[16.2.6](https://about.gitlab.com/releases/2023/09/12/gitlab-16-2-6-released/), +[16.3.3](https://about.gitlab.com/releases/2023/09/12/gitlab-16-3-3-released/), +[16.3.2](https://about.gitlab.com/releases/2023/09/05/gitlab-16-3-2-released/), +[16.3.1, 16.2.5, and 16.1.5](https://about.gitlab.com/releases/2023/08/31/security-release-gitlab-16-3-1-released/) ++ Bitbucket Server [8.14](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitKraken [9.8.2](https://help.gitkraken.com/gitkraken-client/current/), +[9.8.1](https://help.gitkraken.com/gitkraken-client/current/), +[9.8.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.3](https://desktop.github.com/release-notes/), +[3.3.2](https://desktop.github.com/release-notes/), +[3.3.1](https://desktop.github.com/release-notes/), +[3.3.0](https://desktop.github.com/release-notes/) ++ Tower for Windows [5.1](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) ++ git-credential-azure [0.2.3](https://github.com/hickford/git-credential-azure/releases/tag/v0.2.3) ++ git-credential-oauth [0.10.1](https://github.com/hickford/git-credential-oauth/releases/tag/v0.10.1) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Adam Johnson, Bruno Brito, Mirth Hickford +and Štěpán Němec. diff --git a/_posts/2023-10-31-edition-104.markdown b/_posts/2023-10-31-edition-104.markdown new file mode 100644 index 000000000..9959491f7 --- /dev/null +++ b/_posts/2023-10-31-edition-104.markdown @@ -0,0 +1,226 @@ +--- +title: Git Rev News Edition 104 (October 31st, 2023) +layout: default +date: 2023-10-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 104 (October 31st, 2023) + +Welcome to the 104th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of September 2023 and October 2023. + +## Discussions + +### General + ++ [Git Virtual Contributor’s Summit 2023](https://docs.google.com/document/d/1GKoYtVhpdr_N2BAonYsxVTpPToP1CgCS9um0K7Gx9gQ) + + A virtual summit happened on September 26th and 27th, where the + contributors discussed + [topics that they had previously voted on](https://docs.google.com/spreadsheets/d/1EnhmTeEqRBlEI2pMAO3oZ4rO1xEwBzYp2vS4CMtvge8). + Taylor Blau, who organized the summit, polished and then sent + [the notes that were taken during the summit](https://lore.kernel.org/git/ZRregi3JJXFs4Msb@nand.local/#r) + to the mailing list. + + +### Reviews + ++ [[PATCH] diff --stat: add config option to limit filename width](https://lore.kernel.org/git/87badb12f040d1c66cd9b89074d3de5015a45983.1694446743.git.dsimic@manjaro.org/) + + Dragan Simic sent a patch to the mailing list that added a new + `diff.statNameWidth=` configuration option. The goal with + this option was to make it possible to limit the width of the + filepath part of the "stat" output of `git diff` commands. + + For example, the "stat" output of a `git diff` command contains lines like this: + + ``` + path/to/file.txt | 11 +++++++-- + ``` + + where the "filepath" part, also called "name" or "filename" part, of + that output is `path/to/file.txt` and the "graph" part is + `11 +++++++--`. + + There were already a `diff.statGraphWidth=` configuration + option to limit the width of the graph part, and also + `--stat-name-width=` and `--stat-graph-width=` command + line options to limit the width of the name and graph part, + respectively. So it was logical to add the missing configuration + option. + + These options are especially useful for people using very large + terminals, to prevent "stat" output from using a lot of columns. + + The new `diff.statNameWidth=` was designed to be ignored by + `git format-patch` in the same way as + `diff.statGraphWidth=`, because that command already respects + the traditional 80-column standard. + + Before sending this patch, Dragan had sent + [an RFC email](https://lore.kernel.org/git/eb8f524eca3975f086715ec32a8a1fbb@manjaro.org/) + asking if such a patch would be accepted, which led to an interesting + discussion between him and Junio Hamano, the Git maintainer, about + the fact that we often cannot promise anything about a hypothetical + patch before actually seeing it on the mailing list. + + Junio reviewed the actual patch and wondered if it would be possible + to specify contradictory values for the whole width on one side and + the "name" and "graph" width on the other side. He also suggested + creating a helper function to initialize all the variables that + contain the values of the configuration options for the different + parts, as the code initializing those variables was duplicated in + the code of many Git commands. + + Dragan replied that the diff code already performed "a reasonable + amount of sanity checks and value adjustments". He wondered if + warnings should be emitted in case of contradictory settings though. + + Dragan then agreed that refactoring the code that initialized the + variables would be nice, but he proposed to do it after the current + patch would have been merged. + + Junio and Dragan agreed with doing the refactoring later and + discussed a bit deeper if more changes were needed in this patch, but + it appeared that it could be merged as is, and so it was. + + A few days later Dragan sent + [a patch to refactor the code that initialized the variables](https://lore.kernel.org/git/166396f0a98e248fc3d1236757632c5d648ddc0b.1695364961.git.dsimic@manjaro.org/). + Junio reviewed it and suggested some improvements, which Dragan + implemented in [a second version of the patch](https://lore.kernel.org/git/d45d1dac1a20699e370905b88b6fd0ec296751e7.1695441501.git.dsimic@manjaro.org/). + + This second version was also reviewed by Junio and then merged. + + + + + +## Other News + +__Various__ +* [New book “Boost Your Git DX”](https://adamchainz.gumroad.com/l/bygdx) by Git contributor Adam Johnson, covering tools and configurations to improve your command line workflow. +* [Git 2.42 release: Here are four of our contributions in detail](https://about.gitlab.com/blog/2023/10/12/contributions-to-git-2-42-release/) + by Christian Couder on GitLab Blog. + * [Highlights from Git 2.42](https://github.blog/2023-08-21-highlights-from-git-2-42/) + link can be found in [Git Rev News Edition #102](https://git.github.io/rev_news/2023/08/31/edition-102/). + +__Light reading__ ++ [Some miscellaneous git facts](https://jvns.ca/blog/2023/10/20/some-miscellaneous-git-facts/) + by Julia Evans on her blog. The facts are: + + the “index”, “staging area” and “`--cached`” are all the same thing + + the stash is a bunch of commits + + not all references are branches or tags + + merge commits aren’t empty ++ [Why Git is hard](https://roadrunnertwice.dreamwidth.org/596185.html) + by Nick Eff on his Roadrunner Twice Dreamwidth's journal, + in response to Julia Evans ending her StrangeLoop 2023 keynote talk with + “I still don’t know why Git is hard.” + + There is some discussion on the [programming.dev Lemmy instance](https://programming.dev/post/4051745) + about this post. + + Various attempts to make Git or version control easier include + [Gitless](http://gitless.com/) - first mentioned in [Git Rev News Edition #20](https://git.github.io/rev_news/2016/10/19/edition-20/), + [Jujutsu](https://github.com/martinvonz/jj) - mentioned in [#85](https://git.github.io/rev_news/2022/03/31/edition-85/), + and [EasyGit (eg)](https://github.com/dfabulich/easygit) - seems not to be actively developed. ++ [Investigating Git History](https://www.git-tower.com/blog/investigating-git-history/) + by Kristian Lumme on Tower’s blog. ++ [Measuring Git performance with OpenTelemetry](https://github.blog/2023-10-16-measuring-git-performance-with-opentelemetry/) + by Jeff Hostetler on GitHub Blog. It describes how to use open source + [Trace2](https://github.com/git/git/blob/master/Documentation/technical/api-trace2.adoc) + [receiver component (trace2receiver)](https://github.com/git-ecosystem/trace2receiver) + and [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/) + to capture and visualize telemetry from your Git commands. ++ [What is in that `.git` directory?](https://blog.meain.io/2023/what-is-in-dot-git/) + by Abin Simon on meain/blog. ++ [Versioning data in Postgres? Testing a git like approach](https://www.specfy.io/blog/7-git-like-versioning-in-postgres) + by Samuel Bodin on his Specfy Blog. ++ [Organizing multiple Git identities](https://garrit.xyz/posts/2023-10-13-organizing-multiple-git-identities) + using `.gitconfig` includes, + by Garrit Franke on Garrit's Notes blog. ++ [Linux Fu: Deep Git Rebasing](https://hackaday.com/2023/10/17/linux-fu-deep-git-rebasing/) + by Al Williams on Hackaday. ++ [Git: Rewriting History 101](https://matheustavares.gitlab.io/posts/rewriting-history-101) + by Matheus Tavares (2022). ++ [How to split off an older copy of a file while preserving git line history](https://devblogs.microsoft.com/oldnewthing/20230728-00/?p=108498) + by Raymond Chen on Microsoft's The Old New Thing DevBlog. + + His older article on [how to duplicate a file while preserving git line history](https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904) + was mentioned in [Git Rev News Edition #51](https://git.github.io/rev_news/2019/05/22/edition-51/). ++ [Embracing Database Deployments in CI/CD Practices with Git](https://thenewstack.io/embracing-database-deployments-in-ci-cd-practices-with-git/) + by Vanessa Fox from PlanetScale on TheNewStack. + + [An article](https://planetscale.com/blog/database-branching-three-way-merge-schema-changes) + about [PlanetScale branching support for MySQL](https://planetscale.com/docs/concepts/branching) + was mentioned in [Git Rev News Edition #99](https://git.github.io/rev_news/2023/05/31/edition-99/), + while PlanetScale as solution was mentioned in set of article about databases and versioning + in [Git Rev News Edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/). ++ [TypeScript Monorepo with NPM workspaces](https://www.yieldcode.blog/post/npm-workspaces/) + by Dmitry Kudryavtsev on yield code(); blog. ++ [The "Schrödinger's tree object": is it there or not?](https://matheustavares.gitlab.io/posts/empty-tree): + Matheus Tavares finds about the hard-coded empty tree object (2022). + + + +__Git tools and sites__ ++ [gittuf](https://gittuf.dev/) provides a security layer for Git + using some concepts introduced by [The Update Framework (TUF)](https://theupdateframework.io/). + Among other features it handles key management for all developers on the repository, + allows you to set permissions for repository branches, tags, files, etc.
+ gittuf is a sandbox project at the [Open Source Security Foundation (OpenSSF)](https://openssf.org/) + as part of the [Supply Chain Integrity Working Group](https://github.com/ossf/wg-supply-chain-integrity). + It is currently in _alpha_. Written in Go. ++ [trace2receiver](https://github.com/git-ecosystem/trace2receiver) project + is a [trace receiver](https://opentelemetry.io/docs/collector/trace-receiver/) component library + for an [OpenTelemetry Custom Collector](https://opentelemetry.io/docs/collector/) daemon. + It receives [Git Trace2](https://git-scm.com/docs/api-trace2#_the_event_format_target) telemetry + from local Git commands, translates it into an OpenTelemetry format, and forwards it + to other OpenTelemetry components. Written in Go as a static library component + that must be linked into an OpenTelemetry Custom Collector. ++ [git-bundle-server](https://github.com/git-ecosystem/git-bundle-server) + is a web server & management CLI to host Git bundles for use with Git's + ["bundle URIs" feature](https://git-scm.com/docs/bundle-uri). + By running this software, you can self-host a bundle server. + Written in Go, under active development. Installation on Windows is currently unsupported. ++ [Awesome GitHub Alternatives](https://github.com/ianchanning/awesome-github-alternatives) + is a list of alternatives to GitHub that by default offer Git management in some way. + All self-hosted options are free and open source, with GPL-compatibile licenses. + Not exhaustive. ++ [src (Simple Revision Control)](http://www.catb.org/esr/src/) + is RCS/SCCS reloaded with a modern UI, designed to manage single-file solo projects + kept more than one to a directory. Use it for FAQs, `~/bin` directories, config files, + and the like. Written in Python. + + Mentioned in passing in [Git Rev News Edition #46](https://git.github.io/rev_news/2018/12/19/edition-46/). + + +## Releases + ++ GitHub Enterprise [3.10.3](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.3), +[3.9.6](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.6), +[3.8.11](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.11), +[3.7.18](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.18) ++ GitLab [16.5](https://about.gitlab.com/releases/2023/10/22/gitlab-16-5-released/) ++ Bitbucket Server [8.15](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitKraken [9.9.2](https://help.gitkraken.com/gitkraken-client/current/), +[9.9.1](https://help.gitkraken.com/gitkraken-client/current/), +[9.9.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.4](https://desktop.github.com/release-notes/) ++ TortoiseGit [2.15.0](https://tortoisegit.org/download/) ++ git-credential-oauth [0.11.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.11.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Bruno Brito, Adam Johnson and Sven Strickroth. diff --git a/_posts/2023-11-30-edition-105.markdown b/_posts/2023-11-30-edition-105.markdown new file mode 100644 index 000000000..ca22847a3 --- /dev/null +++ b/_posts/2023-11-30-edition-105.markdown @@ -0,0 +1,449 @@ +--- +title: Git Rev News Edition 105 (November 30th, 2023) +layout: default +date: 2023-11-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 105 (November 30th, 2023) + +Welcome to the 105th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of October 2023 and November 2023. + +## Discussions + +### General + +- Git participates in [Outreachy's December 2023 to March 2024 round](https://www.outreachy.org/alums/2023-12/) + + Achu Luma will work on the "Move existing tests to a unit testing + framework" project. They will be mentored by Christian Couder. + + Congratulations to Luma for being selected! + + Thanks to GitLab for sponsoring this Outreachy internship! Thanks + also to the other contributors who applied and worked on + micro-projects, but couldn’t be selected! We hope to continue to see + you in the community! + + +### Reviews + ++ [[PATCH v2 0/2] Prevent re-reading 4 GiB files on every status](https://lore.kernel.org/git/20231012160930.330618-1-sandals@crustytoothpaste.net/) + + In May 2022 Jason Hatton sent + [an email to the mailing list](https://lore.kernel.org/git/CY4PR16MB1655A1F7DD8B2FABCC30C9DAAFC39@CY4PR16MB1655.namprd16.prod.outlook.com/) + about the fact that any file of a size that is an exact multiple + of 8GiB makes Git extremely slow on the repository. + + He said that he had already opened + [an issue about this on the Git for Windows issue tracker](https://github.com/git-for-windows/git/issues/3833#issuecomment-1116544918) + where Jason, Philip Oakley, brian m. carlson and Johannes + Schindelin, alias Dscho, had already discussed the issue. + + Git uses an `uint32_t` type, a 32 bit long unsigned integer, for + storing the file size in the index. This rolls over if the value is + greater than 2 to the power 32, so with file sizes over 4GiB. When + the size is exactly 4GiB or a multiple of it, like 8GiB, + the rollover makes it zero. + + A zero file size in the index has a special meaning for Git, + though. It tells Git that the file needs to be hashed again. Hashing + a file is supposed to reset its file size in the index to a non-zero + value, but with a 4GiB file size the rollover happens and the file + size is still zero. So the hashing will be performed again and again + by many different Git commands, making Git very slow. + + Jason proposed, as a solution to this problem, to detect when the + rollover would happen, and in that case set the size to 1 instead + of zero. + + Junio C Hamano, the Git maintainer, replied to Jason confirming the + issue and explaining it a bit more in detail. Jason and Junio then + discussed the issue a bit more, while Jason tested locally his + suggested fix and proposed to send a real patch to fix the issue. + + René Scharfe then chimed into the discussion asking if a value other + than one would be better and would avoid other possible issues. + Philip Oakley replied to René suggesting using 0x80000000 instead of + 1 when the rollover is detected. This would make it easier to + detect "almost all incremental and decremental changes in file + sizes", as the file size in the index helps detecting file changes. + + Jason and Philip discussed the issue a bit more and agreed that + using 0x80000000 only for exact multiples of 4GiB would likely be + the best solution. + + Philip and Carlo Marcelo Arenas Belón also tried to help Jason + properly submit a patch to the mailing list. + + Jason then sent + [a patch to the mailing list](https://lore.kernel.org/git/CY4PR16MB16552D74E064638BEC11ECB1AFC59@CY4PR16MB1655.namprd16.prod.outlook.com/) + with the changes and explanation that had been discussed. Torsten + Bögershausen, Philip and Junio reviewed it, and suggested some + improvements. Junio especially requested some tests to be added. + + After some discussions with Jason to clarify what should be + improved, Jason sent + [another version of his patch](https://lore.kernel.org/git/20220507185813.1403802-1-jhatton@globalfinishing.com/). + + It looked like Jason found an issue with the patch due to using + 0x80000000 instead of 1. René and Philip discussed it with Jason, + but there was no clear conclusion. It wasn't even clear if there was + an issue at all. But anyway the work on this stopped for more than + one year. + + Fortunately a few weeks ago, brian m. carlson sent + [a new version of Jason's patch](https://lore.kernel.org/git/20231012160930.330618-1-sandals@crustytoothpaste.net/) + along with another patch adding tests. + + These patches were reviewed by Eric Sunshine, Jeff King, alias Peff, + Junio and Jason. After some discussions it appeared that the patches + were good enough for Junio, so he decided to apply a small change + and then merge them. This issue is therefore fixed in + Git 2.43.0 released on November 20th. + + + +## Developer Spotlight: Alexander Shopov + +* Who are you and what do you do? + + I am Alexander Shopov - a backend engineer in the Amsterdam office of + Uber working on money related systems. I am a long time translator of + FOSS software to Bulgarian - I am coordinating translations of GNOME, + Translation Project and many GNU modules. Bulgarian is an Eastern + South Slavic language written in the Cyrillic alphabet. + +* What would you name your most important contribution to Git? + + I made and now maintain the Bulgarian translation of the text + interface of Git, Gitk, and Git Gui. + +* What is the typical workflow of a contributor engaged in Git + translation? + + There are 19 translations of the text interface of Git, and only 13 of + them are above 80%, so I am not sure about "typical". It is a fairly + standard workflow for a FOSS project. + + Generally one needs to do the following: + + 1. Read the translator-targeted README.md in the po directory + 2. Sync pace with the [calendar of Git releases](https://tinyurl.com/gitcal) + 3. Use the [l10n coordinator repository](https://github.com/git-l10n/git-po) + maintained by Jiang Xin who makes sure translations get integrated upstream. + + Currently the translation is a bit above 5500 messages, which is about + 40k words, 250k of characters, or about 150 pages of text. It can be + intimidating for a new translator. But you can definitely make it: be + patient and translate some messages every release, merge, publish and + repeat. Even better though harder is getting more than one person + translating. + +* Do you contribute to Git in ways other than providing translation? + If so, could you elaborate about them? + + Sadly not that much. On rare occasions I improve messages and mark + strings for translations. Perhaps that will be the way I contribute + unless I find a mentor and something that I find particularly + interesting and important for me. So if anyone is willing to mentor + me, especially in making large repos faster - [ping me](mailto:ash@kambanaria.org). + I can be a competent tester at least. + +* If you could get a team of expert developers to work full time on + something in Git for a full year, what would it be? + + Due to its enormous success, Git is being used on humongous code bases + with a crazy number of files, directories, commits and branches. + Working with repos larger than 10GB can be a bit slow. Improving the + experience would be a great thing. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + Backwards compatibility is massively important and I am thankful + developers and users are all invested in this. + + If we treat this as a hypothetical question, there are 3 things to Git: + - the command-line interface + - the wire protocol + - the storage format + + The command-line interface is gradually being improved. The wire + protocol is also a place where there are workarounds for versioning. + The storage format however is another (quite conservative and public) + API. I would remove the old versions and try to design it targeting + projects that are 10-100 times larger than the Linux kernel first. In + for a penny, in for a pound. If we break things, let us break them so + hard that bards will sing songs about us! + +* What is your favorite Git-related tool/library, outside of Git itself? + + I mainly use command line `git` plus `gitk` and `git-gui`. I do like using + the meld diff tool when I work on translations. + +* Do you happen to have any memorable experience w.r.t. contributing + to the Git project? If yes, could you share it with us? + + The initial getting to 100% translated messages was a challenge. I + decided that I should translate Git around December 2013. That was + around 2200 messages at that time and it took me about 3 releases of + Git to reach 100%. Getting to 100% was immensely hard, rewarding and + memorable. Afterwards keeping the translation at 100% was much easier. + +* Is there something you feel could be done to ease the life of + translators? + + The terminology glossary of Git is much larger than 7 years ago, and we + (the translators) should actually update `git://repo.or.cz/git-gui.git::po/glossary` + and merge it in Git. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + I don't know to be honest. If I knew I may have started already. + +* If there's one tip you would like to share with other Git + developers, what would it be? + + That would be the tip of master two years in the future. On a more + serious note - perhaps more tools for migration out of the still + existing proprietary version control systems would be helpful. + + +## Other News + +__Various__ + ++ [Highlights from Git 2.43](https://github.blog/2023-11-20-highlights-from-git-2-43/) + by Taylor Blau on GitHub Blog. Those include new `git repack` tricks + (including adjusting sparse clone filters), nicer looking reverts of reverts + with `git revert`, fixed interaction between `--subject-prefix` and `--rfc` + in `git format-patch`, custom log format options that simulate the decorations, etc. ++ [Gitea Cloud: A brand new platform for managed Gitea Instances](https://blog.gitea.com/gitea-cloud/), + designed for enterprise organizations to set up and run + their own Gitea instances more easily and efficiently. ++ [Announcing DoltgreSQL](https://www.dolthub.com/blog/2023-11-01-announcing-doltgresql/) + by Daylon Wilkins on DoltHub Blog. + + [Git-for-Data, Version-Controlled Database Dolt Gets PostgreSQL-Flavor](https://www.infoq.com/news/2023/11/DoltgreSQL-git-for-data-postgres/) + by Sergio De Simone on InfoQ. + + [Dolt](https://github.com/dolthub/dolt), a version-controlled database, + was first mentioned in [Git Rev News Edition #62](https://git.github.io/rev_news/2020/04/23/edition-62/). ++ [An Interesting CMS With Version Control is Now Open-Source!](https://news.itsfoss.com/tinacms-open-source/) + by Sourav Rudra on It's FOSS News (it's [TinaCMS](https://tina.io/)). ++ [Introducing the Space Git Subtree](https://blog.jetbrains.com/space/2023/11/21/space-git-subtree/) + by Ilia Afanasiev on The Space Blog (where Space is JetBrains' code collaboration platform). ++ [Developers can’t seem to stop exposing credentials in publicly accessible code](https://arstechnica.com/security/2023/11/developers-cant-seem-to-stop-exposing-credentials-in-publicly-accessible-code/) + by Dan Goodin on Ars Technica, and
+ [Uncovering thousands of unique secrets in PyPI packages](https://blog.gitguardian.com/uncovering-thousands-of-unique-secrets-in-pypi-packages/) + by Tom Forbes on GitGuardian Blog. ++ [14 years of JGit/EGit Code Reviews migrated to GerritHub](https://gitenterprise.me/2023/11/21/14-years-of-jgit-egit-code-reviews-migrated-to-gerrithub/) by Luca Milanesio on GerritForge Blog. + + +__Light reading__ + ++ [How I (kind of) killed Mercurial at Mozilla](https://glandium.org/blog/?p=4346) + by Mike Hommey (author of [git-cinnabar](https://github.com/glandium/git-cinnabar), + Git remote helper to interact with Mercurial repositories). ++ Julia Evans continues the series of articles about Git (started in + [Git Rev News #103](https://git.github.io/rev_news/2023/09/30/edition-103/) + with [In a git repository, where do your files live?](https://jvns.ca/blog/2023/09/14/in-a-git-repository--where-do-your-files-live-/) + and + [Git Rev News #104](https://git.github.io/rev_news/2023/10/31/edition-104/) + with [Some miscellaneous git facts](https://jvns.ca/blog/2023/10/20/some-miscellaneous-git-facts/)); + currently there are the following additional posts: + [Confusing git terminology](https://jvns.ca/blog/2023/11/01/confusing-git-terminology/), + [git rebase: what can go wrong?](https://jvns.ca/blog/2023/11/06/rebasing-what-can-go-wrong-/), + [How git cherry-pick and revert use 3-way merge](https://jvns.ca/blog/2023/11/10/how-cherry-pick-and-revert-work/), + and [git branches: intuition & reality](https://jvns.ca/blog/2023/11/23/branches-intuition-reality/). + + Julia Evans (@b0rk@jvns.ca) asked about a read-only FUSE filesystem for a Git repository + where every commit is a folder and the folder contains all the files in that commit + [on Mastodon](https://fosstodon.org/@b0rk@jvns.ca/111462737333140668), so this series may continue + (so far it led to very experimental [git-commit-folders](https://github.com/jvns/git-commit-folders) + tool from her, and [GitMounter](https://belkadan.com/blog/2023/11/GitMounter/) from + Jordan Rose being made public). + + See also [Pain in the dots](https://matthew-brett.github.io/pydagogue/pain_in_dots.html) + by Matthew Brett (part of [Notes and tutorials on git](https://matthew-brett.github.io/pydagogue/git.html)), + about the confusing difference in how two-dot and three-dot notations + behave in `git log` and `git diff`, as an addition to the Julia Evans' article + about confusing Git terminology, the [.. and ... section](https://jvns.ca/blog/2023/11/01/confusing-git-terminology/#and). ++ [How I teach Git](https://blog.ltgt.net/teaching-git/) by Thomas Broyer + on his blog (also [on DEV.to](https://dev.to/tbroyer/how-i-teach-git-3nj3)). + Inspired by Julia Evans' (renewed) interest in Git and her questions on social networks. ++ [Stacked Diffs (and why you should know about them)](https://newsletter.pragmaticengineer.com/p/stacked-diffs) + by Gergely Orosz in The Pragmatic Engineer blog. Another article about Stacked Diffs + can be found in [Git Rev News Edition #44](https://git.github.io/rev_news/2018/10/24/edition-44/). + + Compare and contrast [Ship / Show / Ask: A modern branching strategy](https://martinfowler.com/articles/ship-show-ask.html) + mentioned in [Edition #79](https://git.github.io/rev_news/2021/09/30/edition-79/). ++ [Why I Prefer Trunk-Based Development](https://koenvangilst.nl/blog/trunkbased-development) + by Koen van Gilst on his blog. + + See also [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) + in [Git Rev News Edition #73](https://git.github.io/rev_news/2021/03/27/edition-73/). ++ A bit controversial [Dependencies Belong in Version Control](https://www.forrestthewoods.com/blog/dependencies-belong-in-version-control/) + (even if it's not practical today due to Git's limitations) + by Forrest Smith on his blog. ++ [Managing My Resume with Git: A Version Control Approach](https://dev.to/dunkbing/managing-my-resume-with-git-a-version-control-approach-7hk) + by Bui Dang Binh (dunkbing) on DEV\.to. ++ [See the History of a Method with `git log -L`](https://calebhearth.com/git-method-history) + by Caleb Hearth on his blog; the post lists also a few his other articles about Git: + + [Stash only what `git commit` wouldn't commit](https://calebhearth.com/stash-what-git-wouldnt-commit). + + [Ignore refactoring commits in `git blame`](https://calebhearth.com/rubocop-git-blame). + + [Use your SSH key to sign commits](https://calebhearth.com/sign-git-with-ssh). + + See also, for example, + [Signing Git Commits with SSH Keys](https://blog.dbrgn.ch/2021/11/16/git-ssh-signatures/) + from [Git Rev News Edition #83](https://git.github.io/rev_news/2022/01/31/edition-83/). ++ [Why Git blame sucks for understanding WTF code (and what to use instead)](https://tekin.co.uk/2020/11/patterns-for-searching-git-revision-histories) + by Tekin Süleyman (2020); the author recommend "pickaxe" search with `git log -S` and + `git log -G`, or searching commit messages with `git log --grep`. ++ [How to Resolve Merge Conflicts Using the Merge Editor Feature on VS Code](https://adiati.com/how-to-resolve-merge-conflicts-using-the-merge-editor-feature-on-vs-code) + by Ayu Adiati on Ayu's Notes On Blog (also [on DEV\.to](https://dev.to/adiatiayu/how-to-resolve-merge-conflicts-using-the-merge-editor-feature-on-vs-code-pic), + as part of larger [Open-Source Series' Articles](https://dev.to/adiatiayu/series/15234)). ++ [The Ultimate "git nah" Alias](https://laravel-news.com/the-ultimate-git-nah-alias) + to throw away current changes, untracked files and rebase state, + by Paul Redmond on Laravel News. ++ [Understanding Git: The history and internals](https://graphite.dev/blog/understanding-git) + by Kenneth DuMez on the Graphite Blog (more about history and internals than about + understanding Git). See also: + + [GitHistory page in the archives of Git SCM Wiki](https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitHistory.html), + + [The Git Parable](http://tom.preston-werner.com/2009/05/19/the-git-parable.html), + by Tom Preston-Werner (2009) - the ideas behind the architecture of Git; + covered in [Git Rev News #30](https://git.github.io/rev_news/2017/08/16/edition-30/), + + Will Hay Jr.’s [The Architecture and History of Git: A Distributed Version Control System](https://medium.com/@willhayjr/the-architecture-and-history-of-git-a-distributed-version-control-system-62b17dd37742), + mentioned in [Git Rev News #46](https://git.github.io/rev_news/2018/12/19/edition-46/), + + [The History of Git: The Road to Domination in Software Version Control](https://git.github.io/rev_news/2020/02/19/edition-60/) + referenced in [Git Rev News #60](https://git.github.io/rev_news/2020/02/19/edition-60/). ++ [Tracking SQLite Database Changes in Git](https://garrit.xyz/posts/2023-11-01-tracking-sqlite-database-changes-in-git) + with an appropriate `textconv` gitattribute, by Garrit Franke on Garrit's Notes. ++ [GitHub’s all-in bet on AI may overlook Git](https://www.infoworld.com/article/3710428/githubs-all-in-bet-on-ai-may-overlook-git.html) + by Matt Asay on InfoWorld. ++ [🙏 Please Add .gitattributes To Your Git Repository](https://dev.to/deadlybyte/please-add-gitattributes-to-your-git-repository-1jld) + by Carl Saunders on DEV\.to (2020). + + A `.gitattributes` file [can be used to improve](https://github.com/github-linguist/linguist/blob/master/docs/overrides.md#using-gitattributes) + language detection on GitHub, which is using the + [Linguist](https://github.com/github-linguist/linguist) library. + + +__Easy watching and listening__ + ++ [Git Training](https://www.youtube.com/playlist?list=PL1gv5yv3DoZNIPVAlZRGPEB0fBvflO-xN) + playlist of 45 short YouTube videos by Joost De Cock + provides Git training materials for people who would like to understand + how Git works rather than try to memorize all of its commands + without knowing what they do. ++ The Real Python Podcast: + [Episode 179: Improving Your Git Developer Experience in Python](https://realpython.com/podcasts/rpp/179/) + + + +__Git tools and sites__ + ++ [gitattributes.io](https://gitattributes.io/) is a service to generate + [`.gitattributes`](https://git-scm.com/docs/gitattributes) files, + similar to [gitignore.io](https://www.toptal.com/developers/gitignore/). ++ [githistory.xyz](https://githistory.xyz/) is a service that allows to + quickly browse the history of files in any Git repo (from GitHub, GitLab, Bitbucket). + Also available as Chrome, Firefox, and Visual Studio extensions, + and as `git-file-history` command line tool (in Node.js). + Mentioned in passing in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/). ++ Josh Branchaud (jbranchaud) collected a list of + [Today I Learned (TIL) tips about Git](https://github.com/jbranchaud/til#git). ++ [`lei`](https://public-inbox.org/lei.html) is a command-line tool + for importing and searching email, regardless of whether it is from a personal mailbox + or a public-inbox instance, like [public-inbox.org](https://public-inbox.org/README.html) + or [lore.kernel.org](https://lore.kernel.org/).
+ Warning: `lei` is still in its early stages and may destroy mail. + + See also [lore+lei: part 1, getting started](https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started) + article by Konstantin Ryabitsev (2021). ++ [git-fame](https://github.com/casperdcl/git-fame): Pretty-print + Git repository collaborators sorted by contributions (includes computing + code survival). Written in Python. ++ [git-fame-rb](https://github.com/oleander/git-fame-rb) is a command-line tool + that helps you summarize and pretty-print collaborators, based on the number of contributions. + The statistics are mostly based on the output of `git blame` (counting surviving lines). + Written in Ruby. ++ [GQL (Git Query Language)](https://amrdeveloper.github.io/GQL/) + [[repo](https://github.com/AmrDeveloper/GQL)] + is a SQL-like language to perform queries on `.git` files, + with support for many SQL features + such as grouping, ordering and aggregation functions.
+ You can find more in [How I Created a SQL-like Language to Run Queries on Local Git Repositories](https://www.freecodecamp.org/news/gql-design-and-implementation/) + article by Amr Hesham on freeCodeCamp.
+ See also the following tools: + + [Gitana](https://github.com/SOM-Research/Gitana): SQL-based Project Activity Inspector + (repo archived in 2022), + first mentioned in [Git Rev News Edition #7](https://git.github.io/rev_news/2015/09/09/edition-7/). + + [gitbase](https://github.com/src-d/gitbase): SQL interface to Git repositories, written in Go; + (last release from 2019, [homepage](https://docs.sourced.tech/gitbase) is not working), + first mentioned in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/). + + [git-history](https://datasette.io/tools/git-history) is a tool + for analyzing Git history using SQLite (last release in 2021), + first mentioned in [Git Rev News Edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/). + + [MergeStat](https://github.com/mergestat/mergestat) enables SQL queries + for data in Git repositories (and related sources, such as the GitHub API). + There is also the [`mergestat-lite`](https://github.com/mergestat/mergestat-lite) + command line tool, which runs SQL queries against local Git repositories. + First mentioned in [Git Rev News Edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/). + Actively developed, mergestat-lite is written in Go. ++ [GibleFS](https://github.com/fanzeyi/giblefs) is a toy project + that maps a Git repository to a virtual filesystem, which then can be used + to access the repository at any given commit. Written in Rust, does not seem + to be actively developed. ++ The `Git/fs` binary in [Git9](https://orib.dev/git9.html) + (Git client for Plan 9 non-POSIX filesystem) + serves repository history as a file system. ++ [gitfs](https://github.com/presslabs/gitfs) is a FUSE file system + that fully integrates with Git. You can mount a remote repository's branch locally, + and any subsequent changes made to the files will be automatically committed to the remote. + Written in Python, last release in 2019. + + Note: that is not the only project named gitfs or git-fs. ++ [SlothFS](https://github.com/google/slothfs) is a FUSE filesystem + that provides light-weight, lazily downloaded, read-only checkouts + of manifest-based Git projects. It is intended for use with Android. + Written in Go, repository archived in 2022. ++ [GitMounter](https://belkadan.com/source/GitMounter/) is + a toy FUSE browser for Git repos based on [Suffusion](https://belkadan.com/source/Suffusion/). + Requires FUSE, libgit2, pkg-config, and Swift installed. + Written in Swift. + + +## Releases + ++ Git [2.43.0](https://public-inbox.org/git/xmqqzfz8l5or.fsf@gitster.g/), +[2.43.0-rc2](https://public-inbox.org/git/xmqqo7fwxn4s.fsf@gitster.g/), +[2.43.0-rc1](https://public-inbox.org/git/xmqq8r785ev1.fsf@gitster.g/), +[2.43.0-rc0](https://public-inbox.org/git/xmqqy1fgkqg1.fsf@gitster.g/), +[2.42.1](https://public-inbox.org/git/xmqq4ji4m50l.fsf@gitster.g/) ++ Git for Windows [2.43.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.43.0.windows.1), +[2.43.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.43.0-rc2.windows.1), +[2.43.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.43.0-rc1.windows.1), +[2.43.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.43.0-rc0.windows.1) ++ GitLab [16.6](https://about.gitlab.com/releases/2023/11/16/gitlab-16-6-released/), +[16.5.2](https://about.gitlab.com/releases/2023/11/14/gitlab-16-5-2-released/), +[16.5.1, 16.4.2, 16.3.6](https://about.gitlab.com/releases/2023/10/31/security-release-gitlab-16-5-1-16-4-2-16-3-6-released/) ++ Gerrit Code Review [3.6.8](https://www.gerritcodereview.com/3.6.html#368), +[3.7.6](https://www.gerritcodereview.com/3.7.html#376), +[3.8.3](https://www.gerritcodereview.com/3.8.html#383), +[3.9.0-rc6](https://www.gerritcodereview.com/3.9.html#390) ++ GitHub Enterprise [3.11.0](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.0) ++ GitKraken [9.10.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.5](https://desktop.github.com/release-notes/) ++ Tower for Windows [5.2](https://www.git-tower.com/blog/tower-windows-52/) ++ Tower for Mac [10.2](https://www.git-tower.com/blog/tower-mac-102/) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Alexander Shopov, Luca Milanesio, +Bruno Brito, and Štěpán Němec. diff --git a/_posts/2023-12-31-edition-106.markdown b/_posts/2023-12-31-edition-106.markdown new file mode 100644 index 000000000..a91d99b91 --- /dev/null +++ b/_posts/2023-12-31-edition-106.markdown @@ -0,0 +1,404 @@ +--- +title: Git Rev News Edition 106 (December 31th, 2023) +layout: default +date: 2023-12-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 106 (December 31th, 2023) + +Welcome to the 106th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of November and December 2023. + +## Discussions + + + +### Reviews + ++ [[PATCH 0/4] Switch links to https](https://lore.kernel.org/git/pull.1589.git.1695392027.gitgitgadget@gmail.com/) + + In September, Josh Soref posted a 4-patch series on the + mailing list to improve the URLs used throughout the documentation + and the code base of the project. + + The main goal was to use HTTPS instead of HTTP in the URLs to + improve user security, but along the way some patches replaced URLs + that didn't work anymore with some new ones pointing to the same + content. + + Eric Sunshine replied to Josh's patches asking why one URL was + changed from `http://json.org/` to `https://www.json.org/` instead + of just replacing `http` with `https`. Josh replied that it was + because that website was self-identifying with the latter URL using a + [meta refresh](https://en.wikipedia.org/wiki/Meta_refresh). + + In the meantime, Junio Hamano, the Git maintainer, replied to some + patches saying that it might not be worth updating some URLs, either + because it was clear from the context that they were old, or because + they were part of some code we borrowed from other projects. In some + cases, they were an argument of a Git command and still just worked, + while the meaning of the command changed a bit when `http` was + replaced with `https`. Junio liked the fact that some broken links + were fixed by the series though. + + Josh then sent a + [version 2 of his patch series](https://lore.kernel.org/git/pull.1589.v2.git.1695553041.gitgitgadget@gmail.com/). + This took into account Eric's comments as a commit message was + improved to say that some changes were made to respect a site's + self-identification. Junio's comments were also taken into account + as a number of URLs that were previously changed were now left + as-is. + + Elijah Newren and Junio commented on this new version. They both + suggested improving commit messages or the cover letter of the + series to better explain the reasons for the changes that were made. + In one case, Elijah and Josh discussed replacing the URL of a + website that seemed to be often down with a link to its content on + the [Internet Archive](https://archive.org/). + + In November, Josh then sent a + [version 3 of his patch series](https://lore.kernel.org/git/pull.1589.v3.git.1700796916.gitgitgadget@gmail.com/) + where the first and second patches had been swapped to avoid some + confusion for reviewers who would ask why some URLs weren't changed + in the first patch overlooking that the second one would change them. + + The other significant change compared to version 2 was that Josh + decided not to replace the URL of the website that was often down + saying "we'll risk users getting hacked content from an arbitrary + [MITM](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) + instead of taking archived authenticated content based on the last + time their web site was properly maintained". + + Elijah replied that he would be fine with using the archived link if + it was better justified in the commit message, but said that he also + agreed with merging the whole series as-is, as he had checked all + the links and they all looked good to him. + + Josh replied he could come back later to change the URL and preferred + the series to be merged as-is. He thanked Elijah for taking the time + to re-check every link, saying he knew exactly how tedious that is. + + Junio agreed with merging the series, which is now part of the + 'master' branch. + + + +## Community Spotlight: VonC + +_[VonC](https://stackoverflow.com/users/6309/vonc) is a +prolific contributor to the Git topic on Stack Overflow. This edition features an +interview with him. Thanks to our [survey respondents](https://git.github.io/rev_news/2023/06/30/edition-100#some-statistics-about-the-ongoing-first-git-rev-news-readers-survey) +for suggesting to interview VonC!_ + +* **Who are you and what do you do?** + + By day, I am an information technology consultant working for a computer services + company in France. By night, I am [VonC on Stack Overflow](https://stackoverflow.com/users/6309), + and I have contributed to various topics since its early days (Sept. 2008). + I do that [every single day](https://meta.stackexchange.com/q/122976/6309). + It includes answering questions about Git: [almost 16K answers](https://stackoverflow.com/search?q=user:6309+[git]) + in 15 years. + +* **What would you name your most important contribution to Git?** + + I do not contribute to Git directly, but I report on Stack Overflow + any interesting [git/git commits](https://github.com/git/git/commits/master) + which provides a new answer to old questions. + + I started in 2012 with questions like "[Squash the first two commits in Git?](https://stackoverflow.com/a/598788/6309)" + and "[How do I remove a submodule?](https://stackoverflow.com/a/16162000/6309)". + Then [1630](https://stackoverflow.com/search?page=33&tab=Newest&pagesize=50&q=user%3a6309%20%22see%20commit%22&searchOn=3) + commits followed over the next decade. + +* **Why answering questions about Git on Stack Overflow?** + + As I mentioned in "[**How to earn a million reputation on Stack Overflow: be of service to others**](https://stackoverflow.blog/2022/10/09/how-to-earn-a-million-reputation-on-stack-overflow-be-of-service-to-others/)", + by **[Ryan Donovan](https://twitter.com/RThorDonovan)**, this is a way to + give back to the community, and to learn in the process. + + I learnt Git itself even before installing it, by answering a few + questions on Stack Overflow, as I detailed in "[How'd you get started?](https://meta.stackexchange.com/a/367773/6309)". + +* **If you could get a team of expert developers to work full-time on something in Git for a full year, what would it be?** + + I mentioned in 2013/2016 the issue of [storing large files in Git repositories](https://stackoverflow.com/a/17897705/6309). + + But nowadays, I would work on the workflow side of Git, and how to make + it easier to use for beginners. I follow [GitButler](https://docs.gitbutler.com/) + and [Scott Chacon](https://twitter.com/chacon)'s work. + + > GitButler is rethinking everything between when you write code in your editor of choice and when you push that code to GitHub for review. + > Why are you making 'wip' commits when your SCM should be recording everything for you? + > Why are everyone's commit messages close to useless? + > Why is `git blame` the best way to get context on the code your team has written? + > Why can't you seamlessly transition work between computers? + +* **If you could remove something from Git without worrying about backward compatibility, what would it be?** + + `git checkout`! It is time. As I [explained in 2020](https://stackoverflow.com/questions/58003030/what-is-the-git-restore-command-and-what-is-the-difference-between-git-restor#comment115524702_58003889), + the `git switch`/`git restore` commands are "[experimental](https://github.com/git/git/commit/4e43b7ff1ea4b6f16b93a432b6718e9ab38749bd)" + in name only, and are here to stay. + +* **What is one of your most favorite features of Git?** + + Coming from CVS/SVN, one of my favorite features of Git is its powerful + branching and merging capabilities. Branches in Git are lightweight and + switching between them is fast, making it convenient to manage multiple + streams of work simultaneously (and you have [`git worktree`](https://stackoverflow.com/a/30185564/6309) + if you want to preserve your current working tree). + + I use those branches and merges with ["gitworkflow" (one word)](https://stackoverflow.com/a/57175304/6309), + using long-lived integration branches (like "`master`/`main`/`release`"), + and "ephemeral" integration branches (like "`public`/`next`/`devel`", + created for a specific release cycle, then deleted and recreated for the + next release cycle). See more at "[gitworkflow workflow](https://stackoverflow.com/a/53405887/6309)" + and "[Handle Git branching for test and production](https://stackoverflow.com/a/44470240/6309)". + +* **What is your favorite Git-related tool/library, outside of Git itself?** + + I often used [github.com/github/gitignore](https://github.com/github/gitignore) + ("**A collection of .gitignore templates**"). I have also used and promoted + [`git filter-repo`](https://github.com/newren/git-filter-repo), to + [remove large files from a Git repository](https://stackoverflow.com/a/76300821/6309). + +* **Could you brief a bit about one of your most memorable experiences with Git?** + + My first `git clone`. + + As mentioned in "[How to earn a million reputation on Stack Overflow: be of service to others](https://stackoverflow.blog/2022/10/09/how-to-earn-a-million-reputation-on-stack-overflow-be-of-service-to-others/)", + at the time I stumbled upon Git (2008/2009), I was managing big Rational + ClearCase repositories of terabytes of data. The idea of cloning a *full* (Git) + repository on my laptop was... incongruous, to say the least! + + I am aware of the debate around monorepo vs. multirepo (which sometimes + goes in hand with the debate around monolith vs. microservices), but I found + in the subsequent years that working with multiple small Git repositories was + much more manageable than working with a single large one, as I used to do + before, using huge [ClearCase VOBs](https://www.ibm.com/docs/en/rational-clearcase/9.0.0?topic=clearcase-about-vobs-versioned-objects). + +* **What is your advice for people who want to start using Git? Where and how should they start?** + + Start with understanding Git **branching**, and operations around branches + (switch, merge, rebase, cherry-pick). + + For that, I always redirect people to "[Learn Git Branching](https://learngitbranching.js.org)" + (`learngitbranching.js.org`): nothing to install, all exercises are done + directly in the browser, and it is very visual. + + I also discourage people from blindly following the "[Git Branching Model](https://nvie.com/posts/a-successful-git-branching-model/)", + where an integration branch like `develop` is merged to another integration + one like `master`. See the links above for "gitworkflow" where I explain + why one should merge to an integration branch, not from it: merging *from* + it means you are merging *everything* currently integrated into that branch. + If you want to "exclude" some of those integrated commits, that becomes a + nightmare to manage. + +* **There's a common conception that "Git is confusing". What are your thoughts about the same?** + + Right... you mean [XKCD 1597, Oct. 2015, "Git"](https://explainxkcd.com/wiki/index.php/1597:_Git). + + The level of integration of Git in IDEs (like Eclipse, IntelliJ, VSCode, ...) + has made Git more accessible to beginners. I often redirect them to a combo + VSCode + [GitLens](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens), + and that is enough to get them started. + + As long as the workflow is clearly defined, and the rebase is understood, + for [managing pull request](https://stackoverflow.com/a/44672221/6309) + (you rebase your local feature branch on top of the target branch, + before force pushing it to the remote repository, [with lease](https://stackoverflow.com/a/52937476/6309) + or [if-includes](https://stackoverflow.com/a/64627761/6309)), the users + manage to get by. The bulk of my training is about the PR (Pull Request) + workflow, which involves `git rebase` (`--onto`), and + `git push --force-with-lease `or `--force-if-includes`. + + But clarifying *why* Git exists, and where it comes from (I have younglings + who have no idea who [Linux Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) + is, and his role in the [creation of Git](https://en.wikipedia.org/wiki/Git#History)) + can help. Git comes with a certain vision of how a VCS should work, and + it has a lot to do with the way the Linux kernel is developed. + +* **If there’s one tip you would like to share with other users of Git, what would it be?** + + Stop using `git checkout`, start using `git switch`/`git restore` instead! + +_Editor's note: We hope you enjoyed this interview. We'll explore if we could +interview other such contributors who don't directly participate in the mailing +list. If you have any suggestions, you're most welcome to share them with us through +[our issue tracker](https://github.com/git/git.github.io/issues) or by writing an +email to <>._ + +## Other News + +__Various__ + ++ [Google Summer of Code 2024: Contribute to GitLab and Git to prepare](https://about.gitlab.com/blog/2023/12/20/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare/) + by Christian Couder and Nick Veenhof on GitLab Blog. ++ [Upcoming changes to repository insights [on GitHub]](https://github.blog/changelog/2023-11-29-upcoming-changes-to-repository-insights/) + on GitHub Blog. ++ [Git platform AllSpice now curries favor with enterprises](https://techcrunch.com/2023/12/05/git-allspice-enterprise-6m/) + by Christine Hall on TechCrunch. ++ [GitLab Duo Code Suggestions is generally available](https://about.gitlab.com/blog/2023/12/22/gitlab-duo-code-suggestions-is-generally-available/) + by David DeSanto on GitLab Blog. + [GitLab Code Suggestions](https://about.gitlab.com/solutions/code-suggestions/) + is an alternative to [GitHub Copilot](https://github.com/features/copilot) + and (to a lesser extent) [OpenAI ChatGPT](https://chat.openai.com/). + + +__Light reading__ + ++ Julia Evans continues her streak of Git-related blog posts with + [Mounting git commits as folders with NFS](https://jvns.ca/blog/2023/12/04/mounting-git-commits-as-folders-with-nfs/) + (and FUSE), about the experimental [git-commit-folders](https://github.com/jvns/git-commit-folders) + tool. This tool was mentioned in [previous Git Rev News](https://git.github.io/rev_news/2023/11/30/edition-105/). ++ Julia Evans also published a few comics about Git at [Wizard Zines comics](https://wizardzines.com/comics/), + for a zine on Git that she is currently writing + (these are only the most recent ones; some earlier comics made it into + [Oh Shit, Git! Recipes for getting out of git mess](https://wizardzines.com/zines/oh-shit-git/) zine): + + [every git jargon](https://wizardzines.com/comics/every-git-jargon/) + + [git discussion bingo](https://wizardzines.com/comics/git-discussion-bingo/) + + [every git command I use](https://wizardzines.com/comics/every-git-command/) + + [meet the branch](https://wizardzines.com/comics/meet-the-branch/) + + [branches have no rules](https://wizardzines.com/comics/branches-have-no-rules/) + (at least no built-in ones, though you can try to enforce some with [git hooks](https://githooks.com/)) + + [`HEAD` and heads](https://wizardzines.com/comics/head-and-heads/) + + [my rules for rebasing](https://wizardzines.com/comics/rules-for-rebasing/) ++ [Every engineer should understand git reflog](https://graphite.dev/blog/every-engineer-should-understand-git-reflog) + by Harsh Siriah on Graphite Blog. ++ [Fine-grained file differences](https://www.johndcook.com/blog/2023/12/13/fine-grained-file-differences/) + by John D. Cook on his blog. ++ [DiffDebugging](https://martinfowler.com/bliki/DiffDebugging.html) + by Martin Fowler on his blog/wiki. Page created in 2004, rewritten in 2013. ++ [Monorepo, Poly-repo, or No Repo at all? + Using Bit to make “irreversible decisions” easy to make and change.](https://blog.bitsrc.io/monorepo-poly-repo-or-no-repo-at-all-830328c7a546) + by Eden Ella on Bits and Pieces blog. + + [Bit](https://bit.dev/), a build system for composable software, + was first mentioned in [Git Rev News Edition #45](https://git.github.io/rev_news/2018/11/21/edition-45/) + (then at the old bitsrc\.io URL). + + It was mentioned again in [Git Rev News Edition #77](https://git.github.io/rev_news/2021/07/31/edition-77/) + in [How to Collaborate on Components across Projects with Bit](https://dev.to/giteden/how-to-collaborate-on-components-across-projects-with-bit-29c3) by Eden Ella on DEV\.to. ++ [Recovering Deleted Files From Your Git Working Tree](https://www.smashingmagazine.com/2023/12/recovering-deleted-files-git-working-tree/) + by Oluwasanmi Akande on Smashing Magazine. ++ [Git Grep Like a Pro: The Complete Guide](https://www.kosli.com/blog/git-grep-like-a-pro-the-complete-guide/) + by Bruce Johnston on Kosli Blog (2022). ++ [Flexible Identities in git](https://belkadan.com/blog/2020/02/Flexible-Identities-in-git/) + proposal (to avoid "deadnaming" and bury an old name while preserving a link to things done under the old name) + by Jordan Rose on -dealloc blog (2020). + + +__Easy watching__ + ++ [Git From the Bits Up](https://www.youtube.com/watch?v=mdvlu_R8EWE) + by Tim Berglund, DataStax. Recorded at [Jfokus](http://www.jfokus.com) 2016. + + +__Git tools and sites__ + ++ [dyff](https://github.com/homeport/dyff) /ˈdʏf/ is a diff tool for YAML files, + and sometimes JSON. Can be used as Git diff driver (see documentation). + Written in Go, uses MIT license. ++ [Git-LaTeXdiff](https://gitlab.com/git-latexdiff/git-latexdiff) is a tool + to graphically visualize differences between different versions of a LaTeX file. + It is a wrapper around Git and [latexdiff](https://www.ctan.org/pkg/latexdiff) + (which is present [on CTAN](https://www.ctan.org/pkg/latexdiff), Comprehensive TeX Archive Network). + `git-latexdiff` is written as a BSD-licensed Bash script, + while `latexdiff` is written in Perl (and is GPLv3-licensed). + The git-latexdiff tool was mentioned in passing in + [Git Rev News Edition #8](https://git.github.io/rev_news/2015/10/14/edition-8/). ++ [git-oops](https://github.com/jvns/git-oops) is a **very experimental** tool + allowing to undo a Git operation without having to remember the specific + invocation, in the style of the undo features in [GitUp](https://gitup.co/), [jj](https://github.com/martinvonz/jj), and [git-branchless](https://github.com/arxanas/git-branchless). + According to its author, it is meant as just a prototype serving + "as inspiration for a better tool that actually works reliably" + (see the repository README for details). Written in Python, MIT license. + Prior art includes: + + One of git-oops inspirations, the [undo command in git-branchless](https://github.com/arxanas/git-branchless/wiki/Command:-git-undo), + described in [git undo: We can do better](https://blog.waleedkhan.name/git-undo/), + which was mentioned in [Git Rev News Edition #76](https://git.github.io/rev_news/2021/06/27/edition-76/). + + A very basic and limited [Git Undo [alias]](https://megakemp.com/2016/08/25/git-undo/), + mentioned in [Git Rev News Edition #19](https://git.github.io/rev_news/2016/09/14/edition-19/) + (resets state using reflog). + + Many IDE and programming editors, their Git-related extensions/plugins, + and Git GUIs have some kind of universal "git undo". One example is + Tower Git GUI, whose undo abilities are described in + [CMD+Z for Git is Here](https://css-tricks.com/cmdz-for-git-is-here/) + (mentioned in [Git Rev News Edition #65](https://git.github.io/rev_news/2020/07/29/edition-65/)). + Contrast with tools of similar scope and/or name, but which do something different: + + [thefuck](https://github.com/nvbn/thefuck), a command line application + which corrects your previous console command (for example Git command) + if you made an error and it _didn't_ do what you wanted; + the tool was mentioned in + [Git Rev News Edition #101](https://git.github.io/rev_news/2023/07/31/edition-101/). + + [git-undo-el](https://github.com/jwiegley/git-undo-el), + a command for Emacs editor to "undo" changes to selected region of a file + through its Git history, mentioned in + [Git Rev News Edition #34](https://git.github.io/rev_news/2017/12/20/edition-34/). ++ [git-vee](https://github.com/mjdominus/git-util/blob/master/bin/git-vee) + is a shell script that prepares a brief summary of how your current branch + has diverged from a corresponding remote branch. Mentioned on + [git-vee](https://www.plover.com/misc/stop-merging/slide019.html) slide + in [Cleaner `git` history](https://www.plover.com/misc/stop-merging/slide001.html) + (also known as "Stop merging master") by Mark Jason Dominus (the author of the tool), + from 2013. ++ [Breezy](https://www.breezy-vcs.org/) is a version control system implemented in Python + with multi-format support and an emphasis on hackability. + Currently, Breezy has built-in support for the Git and Bazaar file formats and network protocols. + GPLv2 licensed. ++ [FlatGitHub](https://flatgithub.com/) or Flat View is a simple tool for exploring + flat data files in GitHub repositories. + Part of the [Flat Data](https://githubnext.com/projects/flat-data) project (formerly GitHub OCTO), + mentioned in [Git Rev News Edition #75](https://git.github.io/rev_news/2021/05/27/edition-75/) + (under old URL) and [Edition #96](https://git.github.io/rev_news/2023/02/28/edition-96/), + which in turn was based on the [“git scraping” approach pioneered by Simon Willison](https://simonwillison.net/2020/Oct/9/git-scraping/), + mentioned in [Git Rev News Edition #82](https://git.github.io/rev_news/2021/12/30/edition-82/). + See the example of [flat-demo-bitcoin-price](https://flatgithub.com/githubocto/flat-demo-bitcoin-price?filename=btc-price-postprocessed.json&sha=78b38f641f8f1ffccae733749545ea42cf5eddf9). ++ [AllSpice.io](https://allspice.io/) is a Git platform for hardware developers + (named after SPICE ("Simulation Program with Integrated Circuit Emphasis"), + a general-purpose, open-source analog electronic circuit simulator). + No free tier. ++ [typos](https://github.com/crate-ci/typos) is a source code spell checker, + which finds and corrects spelling mistakes in source code; + intended to be fast enough to run on monorepos and have few false positives, + so it can safely run unassisted, for example on PRs. Written in Rust. + + Mentioned in [Perl Advent Calendar 2023 - Elves Versus Typos](https://perladvent.org/2023/2023-12-21.html). ++ [dat](https://github.com/dat-ecosystem/dat) is a tool for peer-to-peer sharing + & live synchronization of files via command line. Part of the [dat-ecosystem](https://dat-ecosystem.org). + You can use the `dat` command line tool to share files with version control, + back up data to servers, browse remote files on demand, and automate long-term data preservation. + Written in JavaScript for running with Node.js. + + +## Releases + ++ Gerrit Code Review [3.9.1](https://www.gerritcodereview.com/3.9.html#391) ++ GitHub Enterprise [3.11.2](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.2), +[3.11.1](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.1), +[3.10.4](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.4), +[3.9.7](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.7), +[3.8.12](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.12), +[3.7.19](https://help.github.com/enterprise-server@3.7/admin/release-notes#3.7.19), +[3.11.0](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.0) ++ GitLab [16.7](https://about.gitlab.com/releases/2023/12/21/gitlab-16-7-released/), +[16.6.2, 16.5.4, 16.4.4](https://about.gitlab.com/releases/2023/12/13/security-release-gitlab-16-6-2-released/), +[16.6.1, 16.5.3, 16.4.3](https://about.gitlab.com/releases/2023/11/30/security-release-gitlab-16-6-1-released/) ++ GitKraken [9.11.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.6](https://desktop.github.com/release-notes/) ++ Sourcetree [4.2.6](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.6.html) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from VonC, Josh Soref and Štěpán Němec. diff --git a/_posts/2024-01-31-edition-107.markdown b/_posts/2024-01-31-edition-107.markdown new file mode 100644 index 000000000..a491b1ca4 --- /dev/null +++ b/_posts/2024-01-31-edition-107.markdown @@ -0,0 +1,304 @@ +--- +title: Git Rev News Edition 107 (January 31st, 2024) +layout: default +date: 2024-01-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 107 (January 31st, 2024) + +Welcome to the 107th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of December 2023 and January 2024. + +## Discussions + + + + + +### Support + +* [Git Rename Detection Bug](https://public-inbox.org/git/LO6P265MB6736043BE8FB607DB671D21EFAAAA@LO6P265MB6736.GBRP265.PROD.OUTLOOK.COM/) + + Jeremy Pridmore reported an issue to the Git mailing list. He used + [`git bugreport`](https://git-scm.com/docs/git-bugreport), so his + message looks like a filled out form with questions and answers. + + He was trying to cherry-pick changes from one repo (A) to another (B), + while both A and B came from the same original TFS server but with + different set of changes. He was disappointed though because some + files that had been moved in repo A were matched up by the rename + detection mechanism to files other than what he expected in repo B, + and he wondered if the reason for this was the new 'ort' merge + strategy described in a + [blog post by Elijah Newren](https://blog.palantir.com/optimizing-gits-merge-machinery-1-127ceb0ef2a1). + + While not obvious at first, Jeremy's primary problem specifically + centered around cases where there were multiple files with 100% + identical content. For example, originally there could have + been an `orig/foo.txt` file, while one of the descendant repos + does not have that file anymore but instead has two files, + `dir2/foo.txt` and `dir3/foo.txt`, both with contents identical + to the original `orig/foo.txt`. So, Git has to figure out which + one of `dir2/foo.txt` and `dir3/foo.txt` is the result of renaming + `orig/foo.txt`. + + Elijah replied to Jeremy explaining extensively how rename detection + works in Git. Elijah pointed out that Jeremy's problem, as + described, did not involve directory rename detection (despite + looking kind of like a directory rename detection problem). Also, + since Jeremy pointed out that the contents of the "misdetected" + renames had identical contents to what they were paired with, that + meant that only exact renames were involved. Because of these two + factors, Elijah said that the new 'ort' merge strategy, which he + implemented, and which replaced the old 'recursive' strategy, should + use the same rename detection rules as that old strategy for + Jeremy's problem. Elijah suggested adding the `-s recursive` option + to the cherry-pick command to verify this and check if it worked + differently using the old 'recursive' strategy. + + Elijah also pointed out that for exact renames in a setup like this, + other than Git giving a preference to files with the same basename, + if there are multiple choices with identical content then it will + just pick one essentially at random. + + Jeremy replied to Elijah saying that this sounded like what he was + observing. He gave some more examples, showing that when there are + multiple 100% matches, Git didn't always match up the files that he + wanted but matched files differently. Jeremy suggested that + filename similarity (beyond just basename matching) be added as a + secondary criteria to content similarity for rename detection, since + it would help in his case. + + Elijah replied that he had tried a few filename similarity ideas, + and added a "same basename" criteria for inexact renames in the + `ort` merge strategy along these lines. However, he said other + filename similarity measurements he tried didn't work out so well. + He mentioned that they risk being repository-specific (in a way + where they help with merges in some repositories but actually hurt + in others). He also mentioned a rather counter-intuitive result + that filename comparisons could rival the cost of content + comparisons, which means such measurements could adversely affect + performance and possibly even throw a monkey wrench in multiple of + the existing performance optimizations in the current merge + algorithm. + + The thread also involved additional explanations about various facts + involving rename detection. This included details about how renames + are just a hint for developers as they are not recorded, but are + instead computed from scratch in response to user commands. It also + included details about what things like "added by both" means + (namely that both sides added the same filename but with different + contents), why you never see "deleted by both" as a conflict status + (there is no conflict; the file can just be deleted), and other + minor points. + + Elijah also brought up a slightly more common case that mirrors the + problems Jeremy saw, where users could be surprised by the per-file + content similarity matching that Git does. This more general case + arises from having multiple copies of a versioned library. For + example, you may have a "base" version with a directory named + "library-x-1.7/", and a "stable" version has many changes in that + directory, while a "development" branch has removed that directory + but has added both a "library-x-1.8/" and a "library-x-1.9/" + directory which both have changes compared to "library-x-1.7/". In + such a case, if you are trying to cherry-pick a commit involving + several files modified under "library-x-1.7/", where do the changes + get applied? Some users might expect the changes in that commit to + get applied to "library-x-1.8/", while others might expect them to + get applied to "library-x-1.9/". In practice, though, it would not + be uncommon for Git to apply the changes from some of the files in + the commit to "library-x-1.8/" and changes from other files in the + commit to "library-x-1.9/". Elijah explained why this happens and + suggested a hack for users dealing with this particular kind of case + to work around rename detection. + + Philip Oakley then chimed into the discussion to suggest using + "BLOBSAME" for exact renames in the same way as "TREESAME" is used + in `git log` for history simplification. Elijah replied to Philip + that he thinks that 'exact rename' already works. Junio C Hamano, + the Git maintainer, then pointed out that "TREESAME" is a property + of commits, not trees, and suggested using words other than + "BLOBSAME" and "TREESAME" in the context of rename detection. + + Philip and Elijah discussed terminology at more length, agreeing + that good terminology can sometimes help people coming from an "old + centralised VCS" make the mind shift to understand Git's model, but + didn't find anything that would help in this case. + + Finally, Philip requested more information about how Git computes + file content similarity (for inexact rename detection), referencing + Elijah's mention of "spanhash representation". Elijah explained the + internal data structure in detail, and supported his earlier claim + that "comparison of filenames can rival the cost of file content + similarity computations". + + + +## Other News + +__Various__ ++ [The contributions GitLab's Git team made to the Git 2.43 release](https://about.gitlab.com/blog/2024/01/11/the-contributions-we-made-to-the-git-2-43-release/) + by John Cai on GitLab Blog. + + See also [Highlights from Git 2.43](https://github.blog/2023-11-20-highlights-from-git-2-43/) + by Taylor Blau on GitHub Blog, covering different changes, + included in [Git Rev News Edition #105](https://git.github.io/rev_news/2023/11/30/edition-105/). ++ GitHub has [Copilot](https://github.com/features/copilot), + GitLab has [Duo Code Suggestions](https://about.gitlab.com/solutions/code-suggestions/); + now Bitbucket has [integration with Tabnine](https://marketplace.atlassian.com/apps/1227931/tabnine-teams-for-bitbucket-cloud): + [Accelerate your development process with Tabnine AI and Bitbucket](https://community.atlassian.com/t5/Bitbucket-articles/Accelerate-your-development-process-with-Tabnine-AI-and/ba-p/2576062). + + +__Light reading__ ++ [I Taught GIT to High School Students: My Experience as Linux Day Mentor](https://blog.coluzziandrea.com/git-00-linux-day) + by Coluzzi Andrea on his blog (and also [on DEV\.to](https://dev.to/coluzziandrea/i-taught-git-to-high-school-students-3a16)). ++ [How Framer Manages Their Codebase with Tower](https://www.git-tower.com/blog/how-framer-uses-tower/) + by Bruno Brito on Tower’s blog. ++ Julia Evans continues her series of articles about Git with + [Do we think of git commits as diffs, snapshots, and/or histories?](https://jvns.ca/blog/2024/01/05/do-we-think-of-git-commits-as-diffs--snapshots--or-histories/) + and [Inside .git](https://jvns.ca/blog/2024/01/26/inside-git/) + (the latter in both a comic and a text version). ++ [Minimal contents of a .git folder](https://manuel-strehl.de/minimal_git_folder) + by Manuel Strehl on A Peculiar Zoo of Thoughts blog. ++ [Git Config Settings I Always Recommend](https://dev.to/bpugh/git-config-settings-i-always-recommend-11fa) + by Brandon Pugh on DEV\.to (and also [on his blog](https://www.brandonpugh.com/blog/git-config-settings-i-always-recommend/)); + though setting `pull.rebase` to `true` depends on whether project prefers merges or rebases, + and is very project-dependent. ++ [Git Lesson: How to Use .gitignore and .gitkeep?](https://dev.to/ritaly/git-lesson-how-to-use-gitignore-and-gitkeep-5edm) + by Rita {FlyNerd} Lyczywek on DEV\.to (translated [from original article in Polish](https://www.flynerd.pl/2024/01/gitignore-i-gitkeep.html)). ++ [Git Prom! My Favorite Git Alias](https://dev.to/technosophos/git-prom-my-favorite-git-alias-2mbd) + (to fetch the latest upstream HEAD and rebase your current branch on top of it) + by Matt Butcher on DEV\.to. ++ [Integrating DVC and Git LFS via libgit2 filters](https://dvc.ai/blog/dvc-git-lfs) + by Peter Rowlands on DVC AI Blog. [DVC](https://dvc.org/) (Data Version Control) + was first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/), + with links to different articles about it in + [#42](https://git.github.io/rev_news/2018/08/22/edition-42/), + [#63](https://git.github.io/rev_news/2020/05/28/edition-63/), + [#64](https://git.github.io/rev_news/2020/06/25/edition-64/), + [#72](https://git.github.io/rev_news/2021/02/27/edition-72/), + and [#100](https://git.github.io/rev_news/2023/06/30/edition-100/). ++ [Version Control for Machine Learning](https://dagshub.com/blog/version-control/) + by Nikitha Narendra on DagsHub Blog. The [DAGsHub](https://dagshub.com/) service was + first mentioned in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/); + further articles about this web platform for data version control + linked in [Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/), + [#96](https://git.github.io/rev_news/2023/02/28/edition-96/), + and [#97](https://git.github.io/rev_news/2023/03/31/edition-97/). ++ [RFC: Bridging GitHub workflows with b4](https://lore.kernel.org/tools/20231213-fluffy-roaring-capuchin-8024ac@meerkat/T/) + by Konstantin Ryabitsev on Linux kernel tools mailing list via lore.kernel.org. ++ [Jujutsu: a new, Git-compatible version control system](https://lwn.net/Articles/958468/) + by Daroc Alden on LWN\.net ([free link](https://lwn.net/SubscriberLink/958468/09ff53915f2ae020/)). + Jujutsu was first mentioned in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/); + there was also a [Jujutsu: A Git-Compatible VCS](https://www.youtube.com/watch?v=bx_LGilOuE4) + talk by Martin von Zweigbergk at Git Merge 2022, mentioned in passing + in [Git Rev News Edition #91](https://git.github.io/rev_news/2022/09/30/edition-91/). + ++ [Praise, Criticism, and Dialogue](https://rhaas.blogspot.com/2023/12/praise-criticism-and-dialogue.html) + (in open source code review process) + by Robert Haas (PostgreSQL contributor) on his Blogspot blog. ++ [Being friendly: friendly forks 101](https://github.blog/2022-04-25-the-friend-zone-friendly-forks-101/) + and [Being friendly: Strategies for friendly fork management](https://github.blog/2022-05-02-friend-zone-strategies-friendly-fork-management/) + by Lessley Dennington on GitHub Blog (2022). + + + +__Git tools and sites__ ++ [Git-RDM](https://github.com/ctjacobs/git-rdm) had intended to be + a Research Data Management (RDM) plugin for the Git version control system. + It interfaces Git with data hosting services to manage the curation of version controlled files + using persistent, citable repositories. Access to hosting services is managed with + [PyRDM library](https://pyrdm.readthedocs.io/), which supports Figshare, Zenodo, + and (in a limited fashion) DSpace-based services using SWORD protocol version 2. + Written in Python, last released in 2016. + + See also the "[Git-RDM: A research data management plugin for the Git version control system](https://joss.theoj.org/papers/10.21105/joss.00029)" + article in The Journal of Open Source Software (2016). ++ [GitVision](https://github.com/gaspardIV/gitvision) is a web tool + designed to visualize Git repositories in virtual, augmented, and 3D reality. + Developed with Vue 3 in Vite by Kacper Konecki (GaspardIV). + There is a live demo of GitVision at [gitvis.web.app](https://gitvis.web.app/), + including quite a few tiny, small, medium and large example repositories; + you can also visualize your own repository by uploading data prepared using + [GitVision script](https://github.com/GaspardIV/gitvision/tree/main/tool) + (or you can use the tool locally). + + It provides a type of 3D visualization different from the much better known + [Gource](https://gource.io/) visualization tool for source control repositories. + There the repository is displayed as a tree where the root of the repository is the center, + directories are branches and files are leaves. Contributors to the source code + appear and disappear as they contribute to specific files and directories. + + Has different purpose than [Git History.xyz](https://githistory.xyz/) + web app that allows to quickly browse the history of files in any git repo, + mentioned in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/) + and [#105](https://git.github.io/rev_news/2023/11/30/edition-105/). + + See also the [VR-Git: Git Repository Visualization and Immersion in Virtual Reality](https://opus-htw-aalen.bsz-bw.de/frontdoor/deliver/index/docId/2472/file/ICSEA22-VRGit_OberhauserCR2.pdf) (PDF) + paper by Roy Oberhauser (2022). ++ The [Visualize Git](http://git-school.github.io/visualizing-git/) web app illustrates what's going on + under the hood when you use common Git operations. You'll see what exactly is happening + to your commit graph. Powered by D3. Sources on GitHub as [git-school/visualizing-git](https://github.com/git-school/visualizing-git). + This app is quite similar to the free playground mode of + [Visualizing Git Concepts with D3](https://onlywei.github.io/explain-git-with-d3/), + first mentioned in [Git Rev News #69](https://git.github.io/rev_news/2020/11/27/edition-69/). + Compare with: + + [Learn Git Branching](https://learngitbranching.js.org/), + mentioned first in [Git Rev News Edition #30](https://git.github.io/rev_news/2017/08/16/edition-30/). + + [Git Gud](https://nic-hartley.github.io/git-gud/), a visual web-based Git simulator, + meant to help understand Git better, announced by its author Nic Hartley in + [Git Gud at git](https://dev.to/nichartley/git-gud-at-git-5d9k). + First mentioned in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/). + + [Git Gud](https://github.com/benthayer/git-gud), a command line game + designed to help you learn how to use the Git version control system. + Written in Python by Ben Thayer. First mentioned in + [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/). + + [Oh My Git!](https://ohmygit.org/), an open source game about learning Git, + written using the Godot game engine ([source](https://github.com/git-learning-game/oh-my-git)). + There was a lightning talk about this game at FOSDEM 2021: + [Building a Git learning game: A playful approach to version control](https://fosdem.org/2021/schedule/event/git_learning_game/). + First mentioned in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/). + + [Git-Sim](https://github.com/initialcommit-com/git-sim) tool (written in Python) + to visually simulate Git operations in your own repos with a single terminal command. + Described in [Git-Sim: Visually Simulate Git Operations In Your Own Repos](https://initialcommit.com/blog/git-sim) + (mentioned in [Git Rev News Edition #95](https://git.github.io/rev_news/2023/01/31/edition-95/)) + and [Git-Sim 3 Month Dev Update: Community Response, New Features, & The Future](https://initialcommit.com/blog/git-sim-3-month-dev-update) + (mentioned in [Edition #98](https://git.github.io/rev_news/2023/04/30/edition-98/)). ++ [List of git mistakes](https://gist.github.com/jvns/f7d2db163298423751a9d1a823d7c7c1) + people have listed on Mastodon, gathered by Julia Evans (@b0rk@jvns.ca). + + +## Releases + ++ GitHub Enterprise [3.11.3](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.3), +[3.10.5](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.5), +[3.9.8](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.8), +[3.8.13](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.13) ++ GitLab [16.8.1, 16.7.4, 16.6.6, 16.5.8](https://about.gitlab.com/releases/2024/01/25/critical-security-release-gitlab-16-8-1-released/), +[16.8](https://about.gitlab.com/releases/2024/01/18/gitlab-16-8-released/), +[16.7.3](https://about.gitlab.com/releases/2024/01/12/gitlab-16-7-3-released/), +[16.7.2, 16.6.4, 16.5.6](https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/) ++ Bitbucket Server [8.17](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-release-notes-872139866.html) ++ GitKraken [9.11.1](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.8](https://desktop.github.com/release-notes/), +[3.3.7](https://desktop.github.com/release-notes/) ++ Tower for Mac [10.3](https://www.git-tower.com/release-notes?show_tab=release-notes) ++ Tower for Windows [5.5](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Elijah Newren, Bruno Brito, Brandon Pugh and Štěpán Němec. diff --git a/_posts/2024-02-29-edition-108.markdown b/_posts/2024-02-29-edition-108.markdown new file mode 100644 index 000000000..6ab0b9839 --- /dev/null +++ b/_posts/2024-02-29-edition-108.markdown @@ -0,0 +1,217 @@ +--- +title: Git Rev News Edition 108 (February 29th, 2024) +layout: default +date: 2024-02-29 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 108 (February 29th, 2024) + +Welcome to the 108th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of January and February 2024. + +## Discussions + + + + + +### Support + +* [[Bug?] "`git diff --no-rename A B`"](https://lore.kernel.org/git/xmqq34uvtpob.fsf@gitster.g/) + + Junio Hamano, the Git maintainer, sent an email to the mailing list + saying that when `git diff` was used with `--no-rename` instead of + `--no-renames`, rename detection was still performed. He + wondered if that was a bug, because either `--no-rename` should be + interpreted as being a shortened form of `--no-renames`, which is + [a valid option](https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---no-renames) + and should disable rename detection, or `--no-rename` should be + rejected with an error message and termination of `git diff`. + + Dragan Simic replied to Junio that indeed, in case the option is not + recognized, an error message should be emitted. + + Jeff King, alias Peff, also replied to Junio saying he tried + `--no-foo`, which properly errored out. He then wondered if it could + be a bug in the `parse-options` code that could be confused because + `git diff` has both `--[no-]rename-empty` and `--no-renames`. As + there is an abbreviation ambiguity between `--no-rename-empty` and + `--no-renames` when `--no-rename` is used, the `parse-options` code + should not allow such an abbreviation and should error out. + + He suggested, as an alternative to fixing the bug, that a new + `--renames` option could be introduced. It would be synonymous to + `--find-renames`, which is currently the only opposite to + `--no-renames`. He proposed a patch to do that and showed that after + his patch, `--no-rename` would properly error out. + + René Scharfe replied to Peff that the issue came from a patch + written in 2019 that disabled abbreviated options when there could + be an ambiguity. The code handling abbreviations would trigger not + only if the condition guarding it was satisfied, but also if it was + reached through a `goto` statement. The patch disabling abbreviated + options only took care of the condition guarding that code, but not of + the `goto` statement. Along with these explanations, René provided a + patch fixing the bug. + + Junio thanked René for spotting the "nasty" bug and said he agreed + that the code was confusing. + + René replied to Junio with a follow-up patch removing the + `goto` statement. + + Peff also replied to René's first patch wondering if it fixed all + the possible issues, but then in a reply to himself agreed that + René's patch was indeed fixing all the issues discussed. + + Junio later merged both of René's patches, and they were part of the + recently released Git versions 2.43.2, 2.43.3 and 2.44.0. + + _Bonus reading_: ["A Case against the GO TO Statement"](https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD215.html) + by Edsger W. Dijkstra + + + +## Other News + +__Various__ + +- The Git project has been accepted as a [Mentor Organization](https://summerofcode.withgoogle.com/programs/2024/organizations/git) for Google Summer of Code (GSoC) 2024. We can still add project ideas to our [idea page](https://git.github.io/SoC-2024-Ideas/), and volunteers to (co-)mentor are still welcome. Feel free to join the discussion in [the corresponding thread](https://public-inbox.org/git/1de82b27-116a-450e-98c0-52eb65a8f608@gmail.com/). Also, feel free to spread the word about Git's participation. ++ [Highlights from Git 2.44](https://github.blog/2024-02-23-highlights-from-git-2-44/) + by Taylor Blau on GitHub Blog. ++ [GitLab's contributions to Git 2.44.0](https://about.gitlab.com/blog/2024/02/26/gitlabs-contributions-to-git-2-44-0/) + by Patrick Steinhardt on GitLab Blog. + + +__Light reading__ + ++ [Git Tips and Tricks: a 3 part series](https://blog.gitbutler.com/git-tips-and-tricks/) + by Scott Chacon on [GitButler](https://gitbutler.com/) blog, + accompanying the video from the talk + [So You Think You Know Git - FOSDEM 2024](https://www.youtube.com/watch?v=aolI_Rz0ZqY) + (available on YouTube); find the talk slides (and later the "official" video) in the [FOSDEM archive](https://fosdem.org/2024/schedule/event/fosdem-2024-3611-so-you-think-you-know-git/). + + [Git Tips 1: Oldies but Goodies](https://blog.gitbutler.com/git-tips-1-theres-a-git-config-for-that/): + conditional configs, git blame and log with line ranges (`-L`), + git blame with following, word diff, resolution reuse (`git rerere`). + + [Git Tips 2: Some Subtle New Things](https://blog.gitbutler.com/git-tips-2-new-stuff-in-git/): + git branch stuff (`--sort`, `--column`), safe force-pushing (`--force-with-lease`), + SSH commit signing, push signing, `git maintenance`. + + [Git Tips 3: Really Large Repositories and Monorepos](https://blog.gitbutler.com/git-tips-3-really-large-repositories/): + prefetching, commit graph, filesystem monitor, partial cloning, sparse checkouts, + the [scalar](https://git-scm.com/docs/scalar) tool. ++ [Git Trailers](https://alchemists.io/articles/git_trailers) by Brooke Kuhlmann. Learn how to + leverage commit metadata for powerful automations and more human-readable commit messages. ++ [More Expressive Commits with Gitmoji ☺️](https://www.git-tower.com/blog/gitmoji/) + by Bruno Brito on Tower’s blog. + + [Gitmoji](https://gitmoji.dev/) was first mentioned in [Git Rev News Edition #47](https://git.github.io/rev_news/2019/01/23/edition-47/), + though then under a [different URL](https://gitmoji.carloscuesta.me/) + (which now redirects to the current one). + + The similar [Emoji-Log](https://github.com/ahmadawais/Emoji-Log) commit log messages standard + was mentioned in [Git Rev News Edition #101](https://git.github.io/rev_news/2023/07/31/edition-101/). ++ [My Git pre-commit hook contained a footgun](https://blog.plover.com/prog/git/hook-disaster.html) + by Mark Dominus (陶敏修) on his blog (The Universe of Discourse). ++ Julia Evans continues her series of blog posts about Git with + [Dealing with diverged git branches](https://jvns.ca/blog/2024/02/01/dealing-with-diverged-git-branches/) + and [Popular git config options](https://jvns.ca/blog/2024/02/16/popular-git-config-options/). + First entry in this series can be found in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/). ++ [Git Battle: YOLO Mode vs. Clean History](https://hankadev.com/git-battle-yolo-mode-vs-clean-history/) + by Hana Klingová on her blog (and also [on DEV.to](https://dev.to/hankadev/git-battle-yolo-mode-vs-clean-history-594d)): + about usefulness of `git commit --fixup` and `rebase.autosquash`. ++ [Restore deleted/lost files with git](https://dev.to/this-is-learning/restore-deletedlost-files-with-git-3lf7) + by Leonardo Montini for This is Learning, part 6 of + [git better - Improve your git skills (6 Part Series)](https://dev.to/balastrong/series/21372). + Originally published [at leonardomontini.dev](https://leonardomontini.dev/git-restore-deleted-file/) + (includes [video version](https://youtu.be/TL_t3aOXumo)). ++ [My favourite Git commit](https://dhwthompson.com/2019/my-favourite-git-commit) (2019) + by David Thompson on his blog, + about the benefits of good commit messages (the example is a one-character change).
+ Includes links to the following recommended articles on the same topic: + + [Telling stories through your commits](https://blog.mocoso.co.uk/posts/talks/telling-stories-through-your-commits/) by Joel Chippindale (2016). + + [A branch in time](https://tekin.co.uk/2019/02/a-talk-about-revision-histories) by Tekin Süleyman (2019). ++ [Contribution experience report: Git](https://antonin.delpeuch.eu/posts/contribution-experience-report-git/) + by Antonin Delpeuch on his blog. + + +__Easy watching__ + ++ [So You Think You Know Git - FOSDEM 2024](https://www.youtube.com/watch?v=aolI_Rz0ZqY) + by Scott Chacon on YouTube, 47 minutes long (mentioned above). + + +__Git tools and sites__ + ++ [Milestoner](https://alchemists.io/projects/milestoner) by Brooke Kuhlmann. Significant updates + have been made where you can build release notes from your commit messages based on Git notes and + trailers in multiple formats: console, AsciiDoc, Markdown, and HTML. Includes automatic calculation + of your next version and automatic tagging. ++ [git-cliff](https://git-cliff.org/) is a highly customizable changelog generator + using regex-powered custom parsers that can generate changelog files for any Git repository + which follows the [conventional commits](https://www.conventionalcommits.org/) specification. + Written in Rust as a command-line application. ++ [LearnGit.io](https://learngit.io) is an upcoming resource for learning Git using videos with + motion graphics. The project is by Jack Lot who posts Git videos on + [The Modern Coder](https://www.youtube.com/@themoderncoder) YouTube channel. Jack is looking for + intermediate/advanced Git users for feedback. If interested email <>. ++ [pg-diff](https://michaelsogos.github.io/pg-diff/) is a PostgreSQL schema and data comparing tool. + Written in JavaScript by Michael Sogos. ++ [Another trivial utility: git-q](https://blog.plover.com/prog/git-q.html) by Mark Dominus + available from [mjdominus personal git-util repository](https://github.com/mjdominus/git-util) + as [`git-q`](https://github.com/mjdominus/git-util/blob/master/bin/git-q). ++ [Aho](https://github.com/djanderson/aho) is a Git implementation in AWK. + It is a _toy project_ to explore some of the internals of Git and newer features of GNU AWK (aka Gawk). + + +## Releases + ++ Git [2.44.0](https://public-inbox.org/git/xmqqbk87w164.fsf@gitster.g/), +[2.43.3](https://public-inbox.org/git/xmqqil2fw16c.fsf@gitster.g/), +[2.44.0-rc2](https://public-inbox.org/git/xmqqbk8brrj3.fsf@gitster.g/), +[2.43.2](https://public-inbox.org/git/xmqqo7cjvuht.fsf@gitster.g/), +[2.44.0-rc1](https://public-inbox.org/git/xmqqttmbvuyh.fsf@gitster.g/), +[2.44.0-rc0](https://public-inbox.org/git/xmqqo7cph7ov.fsf@gitster.g/), +[2.43.1](https://public-inbox.org/git/xmqqttmhh7ow.fsf@gitster.g/) ++ Git for Windows [2.44.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.44.0.windows.1), +[2.44.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.44.0-rc2.windows.1), +[2.44.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.44.0-rc1.windows.1), +[2.44.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.44.0-rc0.windows.1) ++ GitLab [16.9.1, 16.8.3, 16.7.6](https://about.gitlab.com/releases/2024/02/21/security-release-gitlab-16-9-1-released/), +[16.9](https://about.gitlab.com/releases/2024/02/15/gitlab-16-9-released/), +[16.8.2, 16.7.5, 16.6.7](https://about.gitlab.com/releases/2024/02/07/security-release-gitlab-16-8-2-released/) ++ Gerrit Code Review [3.7.7](https://www.gerritcodereview.com/3.7.html#377), +[3.8.4](https://www.gerritcodereview.com/3.8.html#384) ++ GitHub Enterprise [3.12.0](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.0), +[3.11.5](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.5), +[3.10.7](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.7), +[3.9.10](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.10), +[3.8.15](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.15), +[3.11.4](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.4), +[3.10.6](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.6), +[3.9.9](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.9), +[3.8.14](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.14) ++ GitKraken [9.12.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.9](https://desktop.github.com/release-notes/) ++ Sourcetree [4.2.7](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.7.html) ++ Tower for Mac [10.4](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) ++ git-credential-oauth [0.11.1](https://github.com/hickford/git-credential-oauth/releases/tag/v0.11.1) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Brooke Kuhlmann, Jack Lot, Štěpán Němec +and Bruno Brito. diff --git a/_posts/2024-03-31-edition-109.markdown b/_posts/2024-03-31-edition-109.markdown new file mode 100644 index 000000000..204081fdf --- /dev/null +++ b/_posts/2024-03-31-edition-109.markdown @@ -0,0 +1,473 @@ +--- +title: Git Rev News Edition 109 (March 31st, 2024) +layout: default +date: 2024-03-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 109 (March 31st, 2024) + +Welcome to the 109th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of February and March 2024. + +## Discussions + + + +### Reviews + +* [[PATCH] rebase: make warning less passive aggressive](https://lore.kernel.org/git/pull.1669.git.1708442603395.gitgitgadget@gmail.com/) + + Harmen Stoppels sent a patch to the mailing list that changed an + error message from "No rebase in progress?" to "No rebase in + progress". The rationale is that this error appears when one runs + `git rebase --continue` while there is no rebase going on, so there + is no reason for the question mark. + + Junio Hamano, the Git maintainer, replied to Harmen suggesting using + the imperative mood in the commit message, and saying that the + change in itself is good but that the patch shouldn't have touched + the `po/*.po` files in the project that are used for localization. + Junio also said that we could later add tests for this as it + appeared there was none. + + Michal Suchánek replied to Junio saying that it might have been OK + to touch the `po/*.po` files if the patch had updated the + translations in those files but it hadn't. + + Junio replied to Michal saying that knowing the target language was + needed before removing question marks in those files as it might not + be enough to change a question into a statement. Even if the + author of the patch knew enough, reviewers of the patch might + not, but the biggest problem was bypassing the languages teams. + + Michal replied to Junio asking what was the problem "with not + involving several language teams to remove a question mark". + + Jean-Noël Avila, who is a translator, replied that it didn't bother + him much to edit a sentence to remove a question mark and possibly + adjust it, compared to "translating again and again similar + sentences". + + This led to some confusion as Junio thought that Jean-Noël said that + the "everything in one patch" approach would help translators by not + having them translate "again and again". But Jean-Noël clarified + that he didn't consider changing a question to an assertion is + translating "again and again". He agreed that it was perfectly fine + for translators to have to do those kinds of changes. With "again + and again" he was referring to strings like "could not stat '%s'" + and then "could not stat file '%s'". + + In the meantime Patrick Steinhardt replied to Harmen's initial + message. He suggested converting the error message to start with a + lowercase letter as our guidelines for error messages recommend. + + Harmen then sent + [a version 2 of his patch](https://lore.kernel.org/git/pull.1669.v2.git.1708537097448.gitgitgadget@gmail.com/) + which didn't change any `po/*.po` file and had the error message + start with a lowercase letter. Patrick reviewed that patch and found + it good. + + Kristoffer Haugsbakk chimed into the discussion saying he had + interpreted the original error message as saying "I’m not quite sure + but it looks like you are not in the middle of a rebase?" + + Junio replied to Kristoffer saying that there are indeed examples of + "less assertive" messages in the same rebase command, like "It looks + like 'git am' is in progress. Cannot rebase." But we should be more + assertive as it could help us get valuable bug reports saying for + example "The command said I was not rebasing, but I was! Here is + what I did..." Such bug reports could help us improve how we + determine the state we are in. + + The version 2 of Harmen's patch was later merged to the 'master' + branch. + + + +## Developer Spotlight: Linus Arver + +* Who are you and what do you do? + + I'm one of those so-called "self-taught" developers. My educational + background is in English and tax law (I know, boring right?). Over a + decade ago I thought I would be a corporate attorney, but in law + school I discovered programming and fell completely in love with the + craft, and never looked back! In hindsight it was the second-best + decision I've made in life (the first being getting married to my + lovely wife four years ago). + + I said that I fell into programming during law school. But actually my + original journey started in 7th grade when I tried to pick up C++. I + remember learning control flow, structs and pointers in the first few + chapters of the book I was using, but when it came to the chapter on + OOP and classes, I could not understand why OOP was necessary. + The book I was using just explained why OOP was great, and not + why it would ever be bad. + + Of course, years later I realized that OOP is one of several + paradigms, so perhaps my instinct to question OOP as a panacea was + onto something. In high school and university I remember tinkering + with HTML and websites before smartphones became popular. What a + simpler time it was, back then! + + Fast forward to law school, where I had the idea of writing class + notes using plaintext. Soon after I had the idea of converting these + plaintext notes to prettified outlines, so I needed a way to convert + them to HTML. For better or worse, all this happened before I + discovered Emacs and Org mode (or even Markdown). + + Anyway, I first wrote a plaintext-to-HTML converter in Ruby. Then I + rewrote it in C just for fun. Then again in Haskell (using a minimal + subset of Org mode syntax). As you can see, I sort of got carried away, + haha. + + I would go on to write dozens of pet projects (rudimentary chess + engine, game modding tools, etc) where I got to write tons of code. + I've had the "ugh, did I really write this?" moment too many times to + count. I like to believe that I did the tech industry a favor by not + entering it until I was well versed in fundamental programming and + architectural concepts. 😉 + + Since those law school days I've taken an interest in learning more + languages/ecosystems (e.g., Elixir and Rust). Recently, I've taken a + renewed interest in Literate Programming. I'm toying with the idea of + using it in a somewhat large scale in a future project. It takes a ton + of work to do LP right, but in many ways it's the best possible way to + document code (case in point, the absolutely stellar documentation + standards of the TeX community, such as the glorious TikZ user + manual). + + And I believe that readability is the most important attribute when it + comes to code --- even before correctness! Because at least if the + intent of the author is clear, we can have a (fairly) easy way to fix + things to make it correct. The other way around (correct, but + unreadable code) suffers from stagnation because people become afraid + of touching it, because it's hard to understand. It becomes harder to + extend and grow, which is required of any software worth maintaining + (we call it software for a reason). + + Going back to the question (sorry for rambling a bit there), in my + $DAYJOB I work on microservices, APIs, and backend systems. + Professionally I've always been a backend/infra engineer. In my spare + time I contribute to this wonderful community! + +* What would you name your most important contribution to Git? + + I would say my contributions to the documentation come out on top. + At the end of the day, Git is meant for human consumption. + So getting a bit more polish here and there for user-facing docs is + well worth the trouble, and I am most proud of my work in this area so + far. + + If I had more time, I would overhaul the documentation to make things + easier to understand. Truly, Git has a very simple conceptual model + (thanks to the brilliance of its original author). You just have to + understand that commits come from one or more other commits (sort of + like family trees). That's it! But sadly we have a reputation of + having absolutely terrible user-facing docs, so much so that it pushed + people away to Mercurial and other more friendly VCSs. We need to fix + that. + +* What are you doing on the Git project these days, and why? + + Last year I started trying to add unit tests to the (perhaps obscure) + `git interpret-trailers` command, but this effort has morphed into + "let's also overhaul the entire subsystem around how trailers are + handled, with the aim of creating a reusable C library around it" + [ [ref 1](https://lore.kernel.org/git/pull.1563.git.1691211879.gitgitgadget@gmail.com/) ] + [ [ref 2](https://lore.kernel.org/git/pull.1632.git.1704869487.gitgitgadget@gmail.com/) ]. + + I'm afraid I've bitten off more than I can chew, but I do have a + backlog of about 60 patches that I need to get sent up for review. Not + all at once, of course haha. Hopefully I can get these sent up and + merged over the coming months. The review process can be lengthy you + see, but for good reason --- we take time to try to make sure things + are right the first time. + +* If you could get a team of expert developers to work full time on + something in Git for a full year, what would it be? + + At the risk of being unoriginal, it would be libification (see + [Calvin Wan's interview](https://git.github.io/rev_news/2023/08/31/edition-102/#developer-spotlight-calvin-wan) + from edition 102). But to be more precise, it would be the complete + banning of "shelling out" which we do in many places (where Git + spawns another Git process to do something). Instead we could + (and should) be using libraries internally inside Git's own codebase. + I believe that once we can get Git to start treating itself + as a library, that external library consumption will soon follow. + + There are many others interested in this area as Git has a massive + footprint in our industry. I hope that the many large companies that + benefit from Git can grow their roster of Git contributors. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + `git checkout`. I believe `git switch` and `git restore` replaced the + need to have `git checkout`. I believe in the "there should be only + one way to do the right thing" camp when it comes to the CLI, so I don't + like how we have multiple commands with a lot of overlap. + + I say this even though personally I've been using Git for over 15 + years and have always used `git checkout` (even after the introduction + of `git {switch,restore}`). Simplicity matters! + +* What is your favorite Git-related tool/library, outside of + Git itself? + + [Tig](https://jonas.github.io/tig/). I use it all the time, every + day. It's so good that I basically never use `git log`, unless I'm + searching through it interactively with the pager. + + Every time I see someone proudly showing off their latest "git-log" + incantation (with all its bells and whistles), I think to myself "I + guess they've never heard of `tig`". + + Being an Emacs user, I tried to get into [Magit](https://magit.vc/) + but could not get used to the keybindings that conflicted with my + Vim-styled bindings. (Yes, I use [Evil](https://github.com/emacs-evil/evil) + mode via [Doom](https://github.com/doomemacs/doomemacs) Emacs if you're + into that sort of thing.) OTOH I get so much done with the basic + `git-*` commands and `tig` that I'm rather happy with my workflow. + +* Do you happen to have any memorable experience w.r.t. contributing to + the Git project? If yes, could you share it with us? + + Nine years ago, I contributed my first patch series. I was so proud of + this work that I wrote [a blog post](https://funloop.org/post/2014-09-09-my-first-contribution-to-git.html) + about it. + + The TL;DR of that post is that anyone can contribute to Git, and + really we are a welcoming community. Junio goes out of his way to + accommodate new contributors (I admire his patience), so please, feel + free to join us! + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + So my first contribution 9 years ago was via (the traditional) + `git send-email` command. These days there is this very neat service + called [GitGitGadget](https://gitgitgadget.github.io/) that allows + you to create pull requests on GitHub and does all the housekeeping + work of keeping mailing list discussions in sync (you'll get comments + on your PR which come from mailing list responses). Plus you can get + previews of your patch series (exactly how they'll look like on the + list) before you submit it, which is always nice. + + For local Git development, honestly I don't do anything special or + unusual. One window for Emacs, one window for (re)compiling Git and + running tests, and maybe one more for Tig. From Emacs I use [notmuch](https://wiki.archlinux.org/title/Notmuch) + to browse the mailing list emails (which I sync to Gmail with + [lieer](https://github.com/gauteh/lieer)). + + I use Org mode in Emacs heavily for organizing code snippets and ideas. + + Last but not least, I use [tmux](https://github.com/tmux/tmux/wiki) to organize terminal windows and + navigate quickly across them, even if I'm not using SSH. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + The hard part is figuring out which area you want to work on. Git has + a large codebase, so I recommend starting out with documentation + changes to familiarize yourself with the current state of things. + There's always a typo or grammofix hiding in there! + + Many of our manpages read like dictionaries, when they should read + more like user guides. Some manpages have helpful "EXAMPLES" sections + to show you how to actually use various options and commands, so if + you can think of additional examples, that would be most welcome. + Getting familiar with how things work with user-facing docs should + help you understand the intent behind the large C codebase we have. + + Try to make your contributions as small as possible, but make an + effort to write good commit messages. Copy the style of veterans like + Junio, Peff (Jeff King), Christian Couder, and others I am forgetting + (sorry!) who've been doing this for a long time. + + Once your change is submitted, nag people weekly to get things moving + (yes, we need prodding occasionally). But also don't get offended if + there are a lot of review comments for seemingly small things --- + we're just trying to maintain a certain level of quality. Git is used + by almost everyone in the software industry, so it's important for us + to keep a high bar for quality, that's all. + +* If there's one tip you would like to share with other Git + developers, what would it be? + + Junio has been our maintainer for nearly two decades. It's a tough job and + somehow he's kept going at it all this time. Still, let's do our best + to help make his job easier, because honestly we are truly lucky to + have someone of his caliber lead our project. + + More concretely, this means helping out with code reviews. If you're + not sure which ones to review, see the "What's Cooking" emails that + Junio sends out regularly to look for patches that need help from + reviewers. They are commented as "Needs review" or "Comments?", so + they're easy enough to spot. + + Cheers! + + +## Other News + + + +__Light reading__ + +* Julia Evans continues her series of blog posts about Git with + [How HEAD works in git](https://jvns.ca/blog/2024/03/08/how-head-works-in-git/) and + [The "current branch" in git](https://jvns.ca/blog/2024/03/22/the-current-branch-in-git/). + The first entry in this series of blog posts can be found + in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/). +* [Keeping repository maintainer information accurate](https://github.blog/2024-03-04-keeping-repository-maintainer-information-accurate/): + ensuring that the [CODEOWNERS file](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) + is up to date with the help of tools like [cleanowners](https://github.com/github/cleanowners). + By Zack Koppert on GitHub Blog. +* [De Programmatica Ipsum, Issue #66: Version Control - Twenty Years Is Nothing](https://deprogrammaticaipsum.com/twenty-years-is-nothing/) + by Adrian Kosmaczewski. +* [Git Worktrees and GitButler](https://blog.gitbutler.com/git-worktrees/): + How do Git worktrees help you work on more than one branch at the same time, + and how does that differ from virtual branches in GitButler? + Written by Scott Chacon on GitButler Blog. +* [Fixing up [a series of] Git [commits] with Autosquash](https://blog.gitbutler.com/git-autosquash/) + by Scott Chacon on GitButler Blog. +* [Advanced git commands every senior software developer needs to know](https://optimizedbyotto.com/post/advanced-git-commands/) + by Otto Kekäläinen on Optimized by Otto blog. +* [Five Ways to Be More Productive with Git](https://laravel-news.com/five-ways-to-be-more-productive-with-git) + by Paul Redmond on Laravel News blog. The blog post lists + a few useful Git aliases, setting up a commit template, using password manager for SSH keys + (that can be used for signing commits), making use of the GitHub CLI tool (`gh`), + and configuring `mergetool` and `difftool`. +* [Git: programmatic staging](https://choly.ca/post/git-programmatic-staging/) + (with the help of the [`expect`](https://linux.die.net/man/1/expect) tool, + or with [`grepdiff`](https://linux.die.net/man/1/grepdiff)) + by Ilia Choly on Choly's Blog. The author uses described technique + as a cleanup step after rewriting/refactoring code using automatic tools, + such as [Semgrep](https://semgrep.dev/), [ast-grep](https://ast-grep.github.io/), + LLMs (Large Language Models) such as ChatGPT, and one-off scripts. + * [Semgrep](https://semgrep.dev/) was mentioned in [Git Rev News Edition #75](https://git.github.io/rev_news/2021/05/27/edition-75/); + you can test it with [Semgrep Playground](https://semgrep.dev/playground/new). + * [Another article](https://choly.ca/post/semgrep-autofix-llm/) + by the same author mentions other similar tools, namely + [CodeQL](https://codeql.github.com/) (mentioned in passing + in [Git Rev News Edition #79](https://git.github.io/rev_news/2021/09/30/edition-79/)), + and [Comby](https://comby.dev/). It also talks about the newly created + [`semgrepx`](https://github.com/icholy/semgrepx) tool for rewriting `semgrep` matches + using externals tools (such as Datasette's [`llm`](https://llm.datasette.io/) CLI tool + and Python library). +* [Unleashing the Power of Git Bisect](https://dzone.com/articles/unleashing-the-power-of-git-bisect) + by Shai Almog on DZone (DevOps Zone). +* [Moving Code from One Repository to Another Using Git Patch](https://joelcolaco.hashnode.dev/moving-code-from-one-repository-to-another-using-git-patch) + by Joel Colaco on his blog - though a better solution would be to use + `git format-patch` and `git am` (or alternates and `git cherry-pick`). +* [Extremely Linear Git History](https://westling.dev/b/extremely-linear-git), + with first commit in a repo having a hash that starts with `0000000`, + the second commit is `0000001`, and so on; written by Gustav Westling + on his blog (2022). +* [Witty.rb - A very simple Ruby Script demonstrating how to parse a Git index file (`.git/index`)](https://gist.github.com/Chubek/1fa1c037d280dfc7952676cb4ee89e11). + Published as Gist by Chubak Bidpaa. +* [Dr. Git-Love or: How I Learned to Stop Worrying and Love the Rebase](https://escodebar.github.io/trainings/git/meetup/#/) + are HTML slides for Git training course by Pablo Vergés (escodebar). + +- [Toy/demo: using ChatGPT to summarize lengthy LKML threads (b4 integration)](https://lore.kernel.org/all/20240227-flawless-capybara-of-drama-e09653@lemur/t/#u) + thread on Linux kernel mailing list, started by Konstantin Ryabitsev. + + +__Easy watching__ + +* [So You Think You Know Git Part 2 - DevWorld 2024](https://www.youtube.com/watch?v=Md44rcw13k4) + by Scott Chacon on GitButler YouTube channel, continues the + [FOSDEM version](https://www.youtube.com/watch?v=aolI_Rz0ZqY) of the talk, + which was mentioned in the [previous Git Rev News](https://git.github.io/rev_news/2024/02/29/edition-108/). + [DevWorld Git Slides](https://blog.gitbutler.com/devworld-git-slides/) + are available on GitButler Blog. + + +__Git tools and sites__ + +* [extremely-linear](https://github.com/zegl/extremely-linear), also known as `git-linearize`, + is a tool to create commits with SHA-1 identifier beginning with `0000000` for the first commit, + `0000001` for the second, `0000002` for the third, and so on. This tool uses + [lucky_commit](https://github.com/not-an-aardvark/lucky-commit), + which inserts invisible whitespace characters at the end of the commit message + until it gets a SHA-1 (or SHA-256) hash with the desired prefix. + * Compare and contrast with [git-vain](https://git.anna.lgbt/anna/git-vain) + (mentioned in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/)) + and [git-vanity-sha](https://github.com/mattbaker/git-vanity-sha) + (mentioned in [Git Rev News Edition #39](https://git.github.io/rev_news/2018/05/16/edition-39/)), + tools to generate vanity hashes (for example to make the SHA-1 hash of HEAD begin with `c0ffee`). +* [Nosey Parker](https://github.com/praetorian-inc/noseyparker/) is a command-line program + that finds secrets and sensitive information in textual data and Git history. + Written in Rust, under Apache 2.0 license. +* [gitu](https://github.com/altsem/gitu) - a TUI Git client inspired by Magit. + Written in Rust, under MIT license. +* [Vim-Flog](https://github.com/rbong/vim-flog) is a powerful Git branch viewer for Vim. + Requires Neovim or Vim with Lua support. +* [gcd](https://github.com/davvid/gcd) - Git worktree navigator, + lets you quickly navigate to Git worktrees on your filesystem, + and to directories within your current worktree. + Written as a set of shell functions to be sourced into `~/.zshrc` or `~/.bashrc`. +* [grepdiff](https://pkg.go.dev/rsc.io/grepdiff) is a command-line tool that reads unified diffs + from the files passed as arguments (or standard input), and prints a reduced diff + containing only the hunks matching a regular expression. Written in Go. +* [Gitstr](https://github.com/fiatjaf/gitstr) is a tool to send and receive Git patches + over [Nostr][], using [NIP-34](https://github.com/nostr-protocol/nips/pull/997). + * Compare and contrast with [git-ssb](https://scuttlebot.io/apis/community/git-ssb.html) + (see [git-ssb-intro](https://github.com/hackergrrl/git-ssb-intro) guide): + decentralized Git repo hosting and issue tracking on Secure-ScuttleButt (SSB), + mentioned in [Git Rev News Edition #26](https://git.github.io/rev_news/2017/04/19/edition-26/) + and [#40](https://git.github.io/rev_news/2018/06/20/edition-40/). + +[Nostr]: https://nostr.com/ "A decentralized social network with a chance of working" + + +## Releases + ++ libgit2 [1.8.0](https://github.com/libgit2/libgit2/releases/tag/v1.8.0) ++ Gerrit Code Review [3.7.8](https://www.gerritcodereview.com/3.7.html#378), +[3.9.2](https://www.gerritcodereview.com/3.9.html#392) ++ GitHub Enterprise [3.12.1](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.1), +[3.11.7](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.7), +[3.10.9](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.9), +[3.9.12](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.12), +[3.8.17](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.17), +[3.12.0](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.0), +[3.11.6](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.6), +[3.10.8](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.8), +[3.9.11](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.11), +[3.8.16](https://help.github.com/enterprise-server@3.8/admin/release-notes#3.8.16) ++ GitLab [16.10.1, 16.9.3, 16.8.5](https://about.gitlab.com/releases/2024/03/27/security-release-gitlab-16-10-1-released/), +[16.10](https://about.gitlab.com/releases/2024/03/21/gitlab-16-10-released/), +[16.9.2](https://about.gitlab.com/releases/2024/03/06/security-release-gitlab-16-9-2-released/) ++ GitKraken [9.13.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.3.12](https://desktop.github.com/release-notes/), +[3.3.11](https://desktop.github.com/release-notes/), +[3.3.10](https://desktop.github.com/release-notes/) ++ Tower for Windows [6.0](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) ([Release blog post](https://www.git-tower.com/blog/tower-windows-6/)) ++ Tower for Mac [10.5](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) ++ git-credential-azure [0.3.0](https://github.com/hickford/git-credential-azure/releases/tag/v0.3.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Linus Arver, Eric Sunshine, +Ghanshyam Thakkar, Kristoffer Haugsbakk, +Štěpán Němec, Junio Hamano and Bruno Brito. diff --git a/_posts/2024-04-30-edition-110.markdown b/_posts/2024-04-30-edition-110.markdown new file mode 100644 index 000000000..fecc2120e --- /dev/null +++ b/_posts/2024-04-30-edition-110.markdown @@ -0,0 +1,309 @@ +--- +title: Git Rev News Edition 110 (April 30th, 2024) +layout: default +date: 2024-04-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 110 (April 30th, 2024) + +Welcome to the 110th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of March and April 2024. + +## Discussions + +### General + +* [What's cooking in git.git (Mar 2024, #05; Tue, 19)](https://lore.kernel.org/git/xmqqil1iqi37.fsf@gitster.g/) + + In March, Junio Hamano, the Git maintainer, sent one of the usual + "What's cooking in git.git" emails that describe the current state + of the patch series that might be merged into the development + branches (mostly "master", "next", and "seen"). + + The patch series are listed in these emails along with some related + information in a custom format, including the following elements: + + - a title line, for example: + + > * bl/cherry-pick-empty (2024-03-11) 7 commits + + where `bl` are the initials of the author, and `cherry-pick-empty` + the series title, + + - a patch list, for example: + + > - cherry-pick: add `--empty` for more robust redundant commit handling + > - cherry-pick: enforce `--keep-redundant-commits` incompatibility + > - sequencer: do not require `allow_empty` for redundant commit options + > - sequencer: treat error reading `HEAD` as unborn branch + > - rebase: update `--empty=ask` to `--empty=stop` + > - docs: clean up `--empty` formatting in git-rebase (1) and git-am (1) + > - docs: address inaccurate `--empty` default with `--exec` + + - a description, for example: + + > "cherry-pick" told to keep redundant commits needs to be allowed to + > create empty commits to do its job, but it required the user to + > give the `--allow-empty` option, which was unnecessary. Its UI has + > also been tweaked a bit. + + - a status, for example: + + > Comments? + + - a source, for example: + + > source: <20240119060721.3734775-2-brianmlyles@gmail.com> + + Some of the above elements, like the description, are also + automatically used to create the release notes that Junio prepares + and sends when he creates a new release. + + Brian Lyles replied to Junio that the description of the patch + series used as an example above, which Brian had sent, was "a little + out-of-date". He suggested a different wording for it, and said that + he was going to send a version 4 of his patch series. + + Junio said that the wording suggestion for the description was + very much appreciated, and wondered if the project could adopt a + better workflow where contributors could write a short description + at the top of the cover letter of their patch series and if that + description could then be picked up automatically by some tools to appear + in Junio's "What's cooking in git.git" emails. + + Brian Lyles agreed that improving the process could be a + good idea. He mentioned a strategy used by other projects, namely + adding an entry in a "CHANGELOG.NEXT.md" file for each + important commit. At release time, all the entries in that + file would be moved into a standard "CHANGELOG.md" file. He then + showed how the entry in the "CHANGELOG.NEXT.md" file would look like + for his series as an example. + + Junio replied by summarizing the current process related to these + descriptions and pointing to the + ["Documentation/howto/maintain-git.adoc" file](https://github.com/git/git/blob/master/Documentation/howto/maintain-git.adoc), + which describes his workflow and says that maintaining these topic + descriptions is his responsibility as the project maintainer. He + then mentioned some downsides of giving that responsibility to the + patch series authors. + + One downside is that the description might be harder to read because + the authors "inevitably are biased by the importance of their own + work ;-)". Another one is that the description might not be as + consistent as when they are all written by the same person. Coming + up with some description is also "a good opportunity" for the + maintainer to find what is still unclear after reading the patches + and the cover letter. Junio agreed that "the distribution of burden is + certainly attractive" though. + + Brian replied that he thought the author should still write + something and that at least he was willing to do it. He also + suggested having guidelines, like for commit messages, to help + authors and reviewers standardize the style of these descriptions. + + In the meantime, in a separate email, Junio also pointed out that a + "CHANGELOG.NEXT.md" file would make merges more difficult compared + to having the description in the cover letter. + + To that Brian agreed, and proposed writing a patch to the + "Documentation/SubmittingPatches" file to document that the + description can be written in the cover letter. + + Junio replied by proposing a patch to that file himself. Brian + commented that the description might need "some specific heading, + phrase, or other structured text" to mark it appropriately, making + it easy to notice and extract. + + Dragan Simic joined the discussion saying that writing the + description should not be a strict requirement and then agreed with + Junio's patch. Max Gautier also chimed in, agreeing with Brian and + Dragan about using a format to mark the description. Dragan replied + that adding an example of such a formatted description in the patch + Junio suggested would be good. + + Junio replied to Brian that he preferred starting "with a + lightweight process that does not burden participants with too much + red tape", so something like "When the first paragraph of the + message looks like an entry in the Release Notes, it is used as + such", as he thought that the Release Notes style was "distinct + enough" as to "not require any further marking". + + As Junio's patch was then merged, it's now + [officially possible to write a short description](https://github.com/git/git/blob/v2.45.0-rc1/Documentation/SubmittingPatches#L462-L472) + in patches or cover letters. This description might then be used + as-is in the "What's cooking in git.git" emails and in the release + notes. + + + + + + + +## Other News + +__Various__ + +* [Highlights from Git 2.45](https://github.blog/2024-04-29-highlights-from-git-2-45/) + by Taylor Blau on GitHub Blog. +* [What’s new in Git 2.45.0?](https://about.gitlab.com/blog/2024/04/30/whats-new-in-git-2-45-0/) + by Patrick Steinhardt on GitLab Blog. +* Adam Johnson’s book “Boost Your Git DX” + [has been updated](https://adamj.eu/tech/2024/04/04/bygdx-update/) with ten + new pages of content. This book was mentioned in + [Git Rev News Edition #104](https://git.github.io/rev_news/2023/10/31/edition-104/). + +__Light reading__ + +* Julia Evans continues her series of blog posts about Git, preparing for a new Git zine, + with [Notes on git's error messages](https://jvns.ca/blog/2024/04/10/notes-on-git-error-messages/). + There are also [Some Git poll results](https://jvns.ca/blog/2024/03/28/git-poll-results/) + (which are, as admitted by the author, highly unscientific, and might not be representative). + The first entry in this series of blog posts can be found in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/), + and it continues since, edition after edition so far. +* [Modern Git Commands and Features You Should Be Using](https://martinheinz.dev/blog/109) + by Martin Heinz on his blog. The list includes `git switch`, `git restore`, + `git sparse-checkout`, `git worktree`, and (not new) `git bisect`. +* [Learn Git Fundamentals – A Handbook on Day-to-Day Development Tasks](https://www.freecodecamp.org/news/learn-git-basics/) + by Samyak Jain on freeCodeCamp. +* [Navigating the Stormy Waters of Git Merge Conflicts: A Guide for basic git conflicts](https://dev.to/kadea-academy/navigating-the-stormy-waters-of-git-merge-conflicts-a-complete-guide-38n9) + by Jomagene for KADEA ACADEMY on DEV\.to. +* [The guide to Git I never had.](https://glasskube.dev/guides/git/) + under Philip Miglinci's byline, as Glasskube's guide to Git + (also [on DEV\.to](https://dev.to/glasskube/the-guide-to-git-i-never-had-1450), + by Jake Page for Glasskube). +* [How to get somebody fired using Git](https://dev.to/mauroaccorinti/how-to-get-somebody-fired-using-git-31if) + (or: how to NOT use Git), by Mauro Accorinti on DEV\.to. +* [What Happens on GitLab When You do `git push`?](https://nanmu.me/en/posts/2022/what-happens-on-gitlab-when-you-do-git-push/) + by Li Zhennan, on the personal blog. +* [Radicle: peer-to-peer collaboration with Git](https://lwn.net/Articles/966869/), an + article by Lars Wirzenius on LWN\.net. + * [Radicle](https://radicle.xyz/) was first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/), then in [Edition #70](https://git.github.io/rev_news/2020/12/26/edition-70/). + There was also an [article about Radicle from The New Stack](https://thenewstack.io/radicle-a-decentralized-alternative-to-github-for-web3/) + in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/). + * Compare with [ForgeFed](https://notabug.org/peers/forgefed) (formerly GitPub), + a federation protocol for software forges, mentioned in [Git Rev News Edition #69](https://git.github.io/rev_news/2020/11/27/edition-69/). + * There is also [gitstr (`git str`)](https://github.com/fiatjaf/gitstr), a tool to send and receive Git patches + over [Nostr](https://nostr.com/), using [NIP-34](https://github.com/nostr-protocol/nips/pull/997) + (mentioned in [Git Rev News Edition #109](https://git.github.io/rev_news/2024/03/31/edition-109/)), + and [`git-ssb`](https://scuttlebot.io/apis/community/git-ssb.html) + (see the [git-ssb-intro](https://github.com/hackergrrl/git-ssb-intro) guide), a + decentralized Git repo hosting and issue tracking on [Secure-ScuttleButt (SSB)](https://www.scuttlebutt.nz/) + (mentioned in [Git Rev News Edition #26](https://git.github.io/rev_news/2017/04/19/edition-26/) + and [#40](https://git.github.io/rev_news/2018/06/20/edition-40/)). +* [Git as debugging tool](https://lucasoshiro.github.io/posts-en/2023-02-13-git-debug/) + by Lucas Seiki Oshiro on his GitHub Pages-powered personal blog (2023). + + +__Easy watching__ + +* [re:bass](https://www.youtube.com/watch?v=S9Do2p4PwtE) by Dylan Beattie [4:34]. + If Git was music, what would it sound like? + An original composition inspired by the Git version control system. + + +__Git tools and sites__ + +* [`git bisect-find`](https://gitlab.com/kevincox/git-bisect-find) is + a simple command to find where to start your bisection. Written in Rust. + * See also [Announcing `git bisect-find`](https://kevincox.ca/2024/04/19/git-bisect-find/) + by Kevin Cox on his blog. +* [`git-cz`](https://github.com/streamich/git-cz) is a command-line tool + to help you make semantic Git commits. Written in JavaScript for Node.js. + Can be installed standalone, or with [Commitizen](https://commitizen-tools.github.io/commitizen/) + (which was mentioned in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/)). + Has non-interactive mode; is configurable (for example turning off emoji). +* [`ydiff`](https://github.com/ymattw/ydiff) is a term based tool + to view _colored, incremental diff_ in a version controlled workspace + (supports Git, Mercurial, Perforce and Subversion so far) + or from stdin, with _side by side_ (similar to `diff -y`) and _auto pager_ support. + Written in Python. (Its [`cdiff`](https://github.com/amigrave/cdiff) fork appears to be unmaintained.) +* [`gws`](https://github.com/StreakyCobra/gws) is a text user interface colorful helper + to manage workspaces composed of Git repositories. Written in Bash. +* [Giftless](https://giftless.datopian.com/) ([GitHub repo](https://github.com/datopian/giftless)) + is a Python implementation of a [Git LFS](https://git-lfs.com/) Server. + It is designed with flexibility in mind, to allow pluggable storage backends, + transfer methods and authentication methods. +* [`gil`](https://github.com/chronoxor/gil) (git links tool) is a tool to manage + complex recursive repository dependencies with cross references and cycles. + This tool provides a solution to the _git recursive submodules dependency_ problem. + Written in Python. +* [`git subrepo`](https://github.com/ingydotnet/git-subrepo) "clones" an external Git repo + into a subdirectory of your repo. It is an alternative to `git submodule` and `git subtree`. + The subrepo history is _squashed_ into a single commit that contains the reference information. + Recommended as replacement for the (no longer maintained) [Git STree](https://deliciousinsights.github.io/git-stree/) + project. +* [`tomono`](https://github.com/hraban/tomono): Multi- to Monorepo Migration, + is a script that merges multiple independent tiny repositories into a single “[monorepo](https://monorepo.tools/)”. + Every original repo is moved into its own subdirectory, branches with the same name are all merged. + * Can be considered the reverse of [splitsh/lite](https://github.com/splitsh/lite) tool, whose goal is + to make splitting a monolithic repository to read-only standalone repositories easy and fast + (mentioned in [Git Rev News: Edition #16](https://git.github.io/rev_news/2016/06/15/edition-16/)). +* [`gitdm`](https://github.com/npalix/gitdm) (the "git data miner") + is the tool that Greg KH and Jonathan Corbet have used + to create statistics on where kernel patches come from. + Written in Python. Original at git://git.lwn.net/gitdm.git +* [`lolcommits`](https://github.com/lolcommits/lolcommits): Git-based selfies for software developers. + `lolcommits` takes a snapshot with your webcam every time you execute `git commit`, + and archives a lolcat style image with it (image with embedded caption). + Written in Ruby, requires a webcam and ImageMagick installed. + See also [Lolcommits from around the world!](https://github.com/lolcommits/lolcommits/wiki/Lolcommits-from-around-the-world%21) + page on the project Wiki. +* [Steve's Jujutsu Tutorial](https://steveklabnik.github.io/jujutsu-tutorial/introduction/introduction.html). + * [Jujutsu (`jj`)](https://github.com/martinvonz/jj) is a version control system + first mentioned in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/); + additionally, links to the [LWN.net article](https://lwn.net/Articles/958468/) + and the [Jujutsu: A Git-Compatible VCS](https://www.youtube.com/watch?v=bx_LGilOuE4) + talk about this version control system at Git Merge 2022 can be found in + [Git Rev News Edition #107](https://git.github.io/rev_news/2024/01/31/edition-107/). +* [Awesome Git](https://github.com/dictcp/awesome-git) + is a curated list of amazingly awesome Git tools, resources and shiny things. +* [Awesome Git Hooks](https://github.com/compscilauren/awesome-git-hooks) + is a curated list of easy-to-use Git hooks for automating tasks during Git workflows. + + +## Releases + ++ Git [2.45.0](https://public-inbox.org/git/xmqq8r0ww0sj.fsf@gitster.g/), +[2.45.0-rc1](https://public-inbox.org/git/xmqq4jbqzo3j.fsf@gitster.g/), +[2.45.0-rc0](https://public-inbox.org/git/xmqqcyqljmuu.fsf@gitster.g/) ++ Git for Windows [2.45.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.45.0.windows.1), +[2.45.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.45.0-rc1.windows.1), +[2.45.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.45.0-rc0.windows.1) ++ GitHub Enterprise [3.12.2](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.2), +[3.11.8](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.8), +[3.10.10](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.10), +[3.9.13](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.13) ++ GitLab [16.11.1, 16.10.4, 16.9.6](https://about.gitlab.com/releases/2024/04/24/patch-release-gitlab-16-11-1-released/), +[16.11](https://about.gitlab.com/releases/2024/04/18/gitlab-16-11-released/), +[16.10.3, 16.9.5, 16.8.7](https://about.gitlab.com/releases/2024/04/15/gitlab-16-10-3-released/), +[16.10.2, 16.9.4, 16.8.6](https://about.gitlab.com/releases/2024/04/10/patch-release-gitlab-16-10-2-released/) ++ Gerrit Code Review [3.8.5](https://www.gerritcodereview.com/3.8.html#385), +[3.9.3](https://www.gerritcodereview.com/3.9.html#393), +[3.9.4](https://www.gerritcodereview.com/3.9.html#394) ++ GitHub Desktop [3.3.14](https://desktop.github.com/release-notes/), +[3.3.13](https://desktop.github.com/release-notes/) ++ tig [2.5.9](https://github.com/jonas/tig/releases/tag/tig-2.5.9) ++ git-credential-oauth [0.11.2](https://github.com/hickford/git-credential-oauth/releases/tag/v0.11.2) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Junio Hamano, Štěpán Němec, Kristoffer Haugsbakk, +Dragan Simic and Adam Johnson. diff --git a/_posts/2024-05-31-edition-111.markdown b/_posts/2024-05-31-edition-111.markdown new file mode 100644 index 000000000..bcf1f1325 --- /dev/null +++ b/_posts/2024-05-31-edition-111.markdown @@ -0,0 +1,346 @@ +--- +title: Git Rev News Edition 111 (May 31st, 2024) +layout: default +date: 2024-05-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 111 (May 31st, 2024) + +Welcome to the 111th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of April and May 2024. + +## Discussions + +### General + +* [[GSoC] Welcoming our 2024 contributors and thanking our applicants](https://public-inbox.org/git/406aa31f-4ea0-496c-aeb6-443be86385c0@gmail.com/) + + The Git project was accepted in the + [Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/) + this year again, and 3 applicants were selected: + + - Jialuo She will work on the + ["Implement consistency check for refs" project](https://summerofcode.withgoogle.com/programs/2024/projects/ukm4PTEF) + mentored by Karthik Nayak and Patrick Steinhardt. He already + started posting on [his blog](https://luolibrary.com/categories/GSoC-2024/), + and will push his work to his [Git repo](https://github.com/shejialuo/git). + + - Ghanshyam Thakkar will work on the + ["Move existing tests to a unit testing framework" project](https://summerofcode.withgoogle.com/programs/2024/projects/e9C4rhrv) + mentored by Kaartic Sivaraam and Christian Couder. He already + started posting on [his blog](https://spectre10.github.io/posts/), + and will push his work to his [Git repo](https://github.com/spectre10/git). + + - Chandra Pratap will work on the + ["Move and improve reftable tests in the unit testing framework" project](https://summerofcode.withgoogle.com/programs/2024/projects/tlh611d7) + mentored by Patrick Steinhardt and Christian Couder. He already + started posting on [his blog](https://chand-ra.github.io/), + and will push his work to his [Git repo](https://github.com/Chand-ra/git). + + Congratulations to them, and thanks a lot to all the applicants who + worked on Git and submitted proposals! It was tough to choose from + multiple potential contributors, all of them good in their own + respect. + +* [Git Merge conference](https://public-inbox.org/git/Zj0JyL1b+g1G3zWx@nand.local/) and Contributor's Summit + + Taylor Blau from GitHub announced that Git Merge 2024 is happening + in-person on September 19th and 20th in Berlin. It is being co-hosted + by GitHub and [GitButler](https://gitbutler.com/). + + The talks are scheduled on September 19th and the birds of a feather + are scheduled on September 20th. Registration is yet to open. + + The announcement welcomes calls for proposals, ideas on the format, + topics for discussions, venue setup, and applications for financial + assistance. + +### Reviews + ++ [[PATCH 0/3] color: add support for 12-bit RGB colors](https://lore.kernel.org/git/20240429164849.78509-1-dev+git@drbeat.li/) + + Beat Bolli sent a patch series consisting of 3 patches to add 12 bit RGB + color support to the color parsing code. That code is used + especially when parsing configuration files, as + [a lot of configuration options](https://git-scm.com/docs/git-config#Documentation/git-config.txt-coloradvice) + allow users to customize how Git colorizes its output. + + Before Beat's patch series, the code supported the following: + - fixed strings, like `normal`, `blue`, `red`, etc, + - 256-color-modes from the terminal, like `[1;38;5;254;48;5;255m` , and + - 24-bit color values in the form `#RRGGBB`. + + With Beat's patch, it also supports 12-bit colors in the form + `#RGB`, where in both the 24-bit and 12-bit forms, `R`, `G` and `B` + are hexadecimal digits for the red, green and blue components of the + color respectively. + + The first patch in the series fixed a typo. The second patch added + tests for invalid non-hexadecimal characters in `#RRGGBB` + values. + + The last patch added support for the `#RGB` form and mentioned in + its commit message that such a shortened 12 bit form is already + supported in Cascading Style Sheets (CSS). When used in CSS, each of + the hexadecimal digits in this form is duplicated to convert the + color to 24 bits, and the same duplication is performed in Beat's + patch. For example `#f1b` specifies the same color as `#ff11bb`. + + Junio Hamano, the Git maintainer, replied to Beat's third patch + saying that it looked good. Junio noticed that a wrong `#0xFF0000` + value in a code comment was converted to the right `#FF0000` value + by removing `Ox`. He wondered if there were instances of the same + mistake in our documentation. Beat replied that it was the only + place he found such a mistake. + + Taylor Blau then reviewed the patch series and said it looked "very + nice". Jeff King, alias Peff, also reviewed Beat's series and + commented on the third patch. Looking at the tests that checked the + rejection of invalid values, Peff wondered what would happen if + values like "#1", "#12", "#1234" were passed. Junio replied to Peff + that such values would be worth covering in the tests but doing that + in a separate cleanup patch outside this series would be fine. + + Then Junio replied to himself and suggested adding such tests in the + second patch of the series which already added tests for invalid + values. Junio even sent a 'fixup!' patch to add these tests to the + second patch. Peff replied that this 'fixup!' patch looked good. + + Beat then sent a + [version 2 of his series](https://lore.kernel.org/git/20240502110331.6347-1-dev+git@drbeat.li/) + that incorporated Junio's patch. Both Junio and Peff approved of it, + so it was later merged into the 'master' branch. + + + +## Developer Spotlight: Beat Bolli + +* Who are you and what do you do? + + I'm a software engineer currently working in an Integration Engineer role + for the Swiss government. When I'm not coding, I read, ride any of my three + bikes or play the guitar or electric bass. + +* What would you name your most important contribution to Git? + + I'm more a drive-by contributor. There are no big issues that I work on. + For example, my very first commit was "just" a spelling correction. + + The biggest contribution in terms of the number of commits was a cleanup of + the test scripts that eliminated redundant processes in long pipelines. + + Other topics that come to mind are the strict ISO date format, the + "copy commit reference" menu item in [gitk](https://git-scm.com/docs/gitk), + and some cleanups to get a warning-free compile with `-pedantic`. + +* What are you doing on the Git project these days, and why? + + As explained in the previous answer, I mostly see small things that I try + to improve, like [recently adding the 12-bit RGB color format](#reviews). + +* If you could get a team of expert developers to work full time on + something in Git for a full year, what would it be? + + Honestly, I'm pretty content with the state of Git. I've been using Git since + 2009 and I guess I got used to its idiosyncrasies (but see the next question!). + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + There are too many different options and/or subcommands to remove things. + Compare `git remote remove`, `git branch (-d/-D)`, `git rm` (for files). + I understand that these are different situations but from time to time I + have to really think about which is the right syntax in a given case. + +* What is your favorite Git-related tool/library, outside of + Git itself? + + First, I'm a fan of the command line, so Git itself does over 80% of what + I need. Next up are [tig](https://jonas.github.io/tig/) and [vim-fugitive](https://github.com/tpope/vim-fugitive). + I also use a comprehensive set of Git-related shell aliases that improve + my efficiency. + +* Do you happen to have any memorable experience w.r.t. contributing to + the Git project? If yes, could you share it with us? + + Nothing out of the ordinary, but then I'm old-school and have no problems + with an email-based workflow. My first commits were accepted without much + fanfare, and this encouraged me to continue to submit things. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + I follow the mailing list on [lore.kernel.org](https://lore.kernel.org/git/), and + have also subscribed to the NNTP feed in Thunderbird. For submitting patches I + have configured a few send-email options, probably like everyone else who + contributes. I do most of my development on a Mac mini in [iTerm2](https://iterm2.com/) + and Vim. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + First, don't think you're not good enough. By following [SubmittingPatches](https://git-scm.com/docs/SubmittingPatches) + and the rest of the [beginner's documentation](https://git-scm.com/docs/MyFirstContribution), + everyone can contribute. I experience the "mood" on the mailing list as very + supportive and helpful. + +* If there's one tip you would like to share with other Git + developers, what would it be? + + Just a tiny pet peeve of mine: `sizeof` is not a function 😉 + + +## Other News + +__Various__ + ++ [Securing Git: Addressing 5 new vulnerabilities](https://github.blog/2024-05-14-securing-git-addressing-5-new-vulnerabilities/) + fixed in v2.45.1, by Johannes Schindelin on GitHub Blog. + The main theme of fixes in v2.45.1 is to improve the security of cloning Git repositories. + + +__Light reading__ + ++ [A beginner's guide to the Git reftable format](https://about.gitlab.com/blog/2024/05/30/a-beginners-guide-to-the-git-reftable-format/) + (available since the [release of Git 2.45.0](https://about.gitlab.com/blog/2024/04/30/whats-new-in-git-2-45-0/)). + Article by Patrick Steinhardt on GitLab Blog. ++ Julia Evans has just [published her new Git zine](https://jvns.ca/blog/2024/04/25/new-zine--how-git-works-/), + “[How Git Works](https://wizardzines.com/zines/git/)”. + She [counted](https://fosstodon.org/@b0rk@jvns.ca/112519150131306917) + that she apparently wrote 28,000 words of blog posts while writing the zine. + These posts were covered here, starting from [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/), + and continuing, edition after edition, until [the previous edition #110](https://git.github.io/rev_news/2024/04/30/edition-110/).
+ As a companion to this zine, there is a little [git cheat sheet](https://wizardzines.com/git-cheat-sheet.pdf) (PDF) freely available. + + Julia Evans had also published the “[Oh Shit, Git](https://wizardzines.com/zines/oh-shit-git/)” zine in 2018; + as she [describes](https://fosstodon.org/@b0rk@jvns.ca/112338598244430472): + “Oh Shit, Git” is about how to get out of Git messes, while + “How Git Works” explains why those messes happen in the first place. + + The [Oh Shit, Git!?!](http://ohshitgit.com/) website by Katie Sylor-Miller + was first mentioned in [Git Rev News Edition #19](https://git.github.io/rev_news/2016/09/14/edition-19/). ++ [Securing Git repositories with gittuf](https://lwn.net/Articles/972467/) + by Joe Brockmeier on LWN\.net is a report of a talk by Aditya Sirish A Yelgundhalli and Billy Lynch + at Open Source Summit North America (OSSNA). + The video of the talk [is available on YouTube](https://www.youtube.com/watch?v=eCSeIEdMbCw). + [Gittuf](https://gittuf.dev/) was mentioned + in [Git Rev News Edition #104](https://git.github.io/rev_news/2023/10/31/edition-104/). ++ [Clone arbitrary single Git commit](https://blog.hartwork.org/posts/clone-arbitrary-single-git-commit/) + by Sebastian Pipping on Hartwork Blog. Inspired by GitHub Action [`actions/checkout`](https://github.com/actions/checkout). ++ [Reverting File Changes in Git: A Comprehensive Guide](https://dev.to/mochafreddo/reverting-file-changes-in-git-a-comprehensive-guide-80i) + by Geoffrey Kim on DEV\.to. ++ [What is Git? GitHub beginner’s guide to version control](https://github.blog/2024-05-27-what-is-git-our-beginners-guide-to-version-control/) + by Kedasha Kerr on GitHub Blog. ++ [Signed Git commits with Sigstore, Gitsign and OpenID Connect (OIDC)](https://buildkite.com/blog/securing-your-software-supply-chain-signed-git-commits-with-oidc-and-sigstore) + by James Healy on Buildkite Blog. + [Sigstore](https://www.sigstore.dev/) and [Gitsign](https://github.com/sigstore/gitsign) + tools for keyless Git signing were both mentioned + in [Git Rev News Edition #91](https://git.github.io/rev_news/2022/09/30/edition-91/). ++ [Understanding the Stacked Pull Requests Workflow](https://www.git-tower.com/blog/stacked-prs/) by Bruno Brito on Tower's blog. + There have been various approaches to adding stacks to Git workflows: + + [Stacked Git](https://stacked-git.github.io/) (aka StGit) was mentioned in + [Git Rev News Edition #17](https://git.github.io/rev_news/2016/07/20/edition-17/), + [#21](https://git.github.io/rev_news/2016/11/16/edition-21/), + and [#74](https://git.github.io/rev_news/2021/04/30/edition-74/), + and finally presented as a tool in [#93](https://git.github.io/rev_news/2022/11/30/edition-93/). + + Stacked diffs were discussed in [Stacked Diffs Versus Pull Requests](https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/) + (mentioned in [Git Rev News Edition #44](https://git.github.io/rev_news/2018/10/24/edition-44/)) + and [Stacked Diffs (and why you should know about them)](https://newsletter.pragmaticengineer.com/p/stacked-diffs) (mentioned + in [#105](https://git.github.io/rev_news/2023/11/30/edition-105/)). + + [Working with stacked branches](https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/) + was mentioned in [Git Rev News Edition #93](https://git.github.io/rev_news/2022/11/30/edition-93/). ++ [How short can Git abbreviate?](https://blog.cuviper.com/2013/11/10/how-short-can-git-abbreviate/) + by Josh Stone on his WordPress-based blog (2013). + + +__Easy watching__ + ++ [Securing Git Repositories with Gittuf](https://www.youtube.com/watch?v=eCSeIEdMbCw) - + Aditya Sirish A Yelgundhalli, New York University & Billy Lynch, Chainguard. + A 30 minute long video on The Linux Foundation channel on YouTube. + + +__Git tools and sites__ + ++ [KSDB](https://lwn.net/ksdb/) is the LWN\.net kernel source database, a site + which can answer a wide range of questions about the Linux kernel's development history. ++ The [Kernel.org Transparency Log Monitor](https://tlog.linderud.dev/) + webpage is a monitor of the kernel.org transparency log for git-receive operations. + Among others, it tracks signed pushes (compare with [gittuf](https://gittuf.dev/)). + Runs [kernel.org-git-verifier](https://github.com/Foxboron/kernel.org-git-verifier). + + There is also the [Gitolite transparency log](https://korg.docs.kernel.org/gitolite/transparency-log.html), + with git-receive operations published at the [transparency-logs/gitolite/git](https://git.kernel.org/pub/scm/infra/transparency-logs/gitolite/git/) + repositories in [the public-inbox v2 format](https://public-inbox.org/public-inbox-v2-format.html). + [Gitolite](http://gitolite.com/gitolite/) was first mentioned in + [Git Rev News Edition #17](https://git.github.io/rev_news/2016/07/20/edition-17/) + and [#22](https://git.github.io/rev_news/2016/12/14/edition-22/). ++ [Sigstore Rekor](https://github.com/sigstore/rekor) is meant to + provide an immutable tamper resistant ledger of metadata + generated within a software project's supply chain. + It enables software maintainers and build systems to record and query + signed metadata. + Can be run as part of [Sigstore](https://sigstore.dev/) or on its own. ++ [Quickhook](https://github.com/dirk/quickhook/) is a Git hook runner designed for speed. + Written in Go. ++ [etckeeper](https://etckeeper.branchable.com/) is a collection of tools + to let `/etc` be stored in a Git repository, and use Git + to review or revert changes that were made to `/etc`. + Written as shell scripts (with some plugins in Python). ++ [Dangit, Git!?!](https://dangitgit.com/en) has the same contents, only without swears, + as the [Oh Shit, Git!?!](https://ohshitgit.com/) website + (first mentioned in [Git Rev News Edition #19](https://git.github.io/rev_news/2016/09/14/edition-19/)). + + +## Releases + ++ Git [2.45.1 and friends](https://public-inbox.org/git/xmqqv83g4937.fsf@gitster.g/) + (2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4) ++ Git for Windows [2.45.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.45.1.windows.1) ++ libgit2 [1.8.1](https://github.com/libgit2/libgit2/releases/tag/v1.8.1) ++ GitLab [17.0.1, 16.11.3, 16.10.6](https://about.gitlab.com/releases/2024/05/22/patch-release-gitlab-17-0-1-released/), +[17.0](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/), +[16.9.8](https://about.gitlab.com/releases/2024/05/09/gitlab-16-9-8-released/), +[16.11.2, 16.10.5, 16.9.7](https://about.gitlab.com/releases/2024/05/08/patch-release-gitlab-16-11-2-released/) ++ Gerrit Code Review [3.10.0](https://www.gerritcodereview.com/3.10.html#3100), +[3.7.9](https://www.gerritcodereview.com/3.7.html#379), +[3.8.6](https://www.gerritcodereview.com/3.8.html#386), +[3.9.5](https://www.gerritcodereview.com/3.9.html#395) ++ GitHub Enterprise [3.12.4](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.4), +[3.11.10](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.10), +[3.10.12](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.12), +[3.9.15](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.15), +[3.13.0](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.0), +[3.12.3](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.3), +[3.11.9](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.9), +[3.10.11](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.11), +[3.9.14](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.14) ++ GitKraken [10.0.1](https://help.gitkraken.com/gitkraken-client/current/), +[10.0.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.0](https://desktop.github.com/release-notes/), +[3.3.18](https://desktop.github.com/release-notes/), +[3.3.17](https://desktop.github.com/release-notes/), +[3.3.16](https://desktop.github.com/release-notes/), +[3.3.15](https://desktop.github.com/release-notes/) ++ TortoiseGit [2.16.0](https://tortoisegit.org/download/) ++ Git Cola [4.7.1](https://github.com/git-cola/git-cola/releases/tag/v4.7.1) ++ Garden [1.5.0](https://github.com/garden-rs/garden/releases/tag/v1.5.0) ++ Tower for Mac [11.0](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) ([blog post](https://www.git-tower.com/blog/tower-mac-11/)) ++ Tower for Windows [7.0](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) ++ tig [2.5.10](https://github.com/jonas/tig/releases/tag/tig-2.5.10) ++ git-credential-oauth [0.11.3](https://github.com/hickford/git-credential-oauth/releases/tag/v0.11.3) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Beat Bolli, Sven Strickroth, David Aguilar, +Bruno Brito and Štěpán Němec. diff --git a/_posts/2024-06-30-edition-112.markdown b/_posts/2024-06-30-edition-112.markdown new file mode 100644 index 000000000..b7d8bdcec --- /dev/null +++ b/_posts/2024-06-30-edition-112.markdown @@ -0,0 +1,278 @@ +--- +title: Git Rev News Edition 112 (June 30th, 2024) +layout: default +date: 2024-06-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 112 (June 30th, 2024) + +Welcome to the 112th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of May and June 2024. + +## Discussions + + + +### Reviews + +* [[RFC PATCH] docs: document upcoming breaking changes](https://lore.kernel.org/git/fc1a9fa03de7330f79dc56b0f2712834cb236b5a.1715070296.git.ps@pks.im/) + + Patrick Steinhardt sent an RFC patch to the mailing list that + created a new "UpcomingBreakingChanges.md" document. The goal of the + document was to inform users and developers of deprecations and + breaking changes, and to encourage discussion of the direction of + the project regarding these topics in advance. + + Patrick noted that the changes listed in the document, along with + links to mailing list threads where they had been discussed, were a + work in progress with controversial and missing items, and that he + didn't want to push for a Git 3.0 release with the listed changes + soon. + + The idea for that new document had been discussed previously + [in a thread about a patch series from Patrick](https://lore.kernel.org/git/ZjiL7vu5kCVwpsLd@tanuki/) + that introduced subcommands like `get`, `set`, etc, in `git config`. + In that thread, after Patrick asked if we wanted to introduce a + document to keep track of upcoming removals for a potential Git 3.0 + release, Junio Hamano, the Git maintainer, replied to Patrick that + in a few of his ["What's cooking" emails](https://lore.kernel.org/git/?q=s%3A%22What%27s+cooking+in+git.git%22) + before the Git 2.44.0 release, he had written: + + > It may not be a bad idea to reflect on what technical debt and UI + > warts we have accumulated so far to see if we have enough of them to + > start planning for a breaking Git 3.0 release (or, of course, keep + > incrementally improve the system, which is much more preferable -- + > continuity and stability is good). + + So Junio was happy that "somebody has bit it ;-)" and suggested a + number of topics that could be added to the document Patrick wanted + to create. This started a discussion about the possibility of + deprecating some features, such as the `restore`, `switch`, + `submodules` and `worktrees` subcommands. + + In the RFC patch to add the document, Patrick mentioned some of the + topics suggested by Junio, but not others that seemed controversial + in the previous discussion. + + Johannes Schindelin, alias Dscho, replied to Patrick's RFC patch + saying he loved it. Dscho also gave his opinion about the topics, + and suggested to deprecate or remove additional rarely used + features. + + Junio replied to Patrick's patch suggesting to add features that we + don't want to drop and why, and to mention that we deprecate but, + for backward compatibility, rarely remove old ways to do things. + Patrick agreed to Junio's suggestion and proposed a "superseded" + section for the features we don't want to drop. + + Dragan Simic, who had participated in the discussions of the preceding + `git config` thread, repeated that he didn't want to see any of + `git restore`, `git switch` or `git checkout` deprecated, which + Patrick agreed shouldn't be done. + + Phillip Wood, replying to Patrick's patch, asked if the document + should track the progress of some unfinished work, like the config + based hooks implementation. Patrick said he was planning on + creating a separate document for long running projects, projects + already discussed, and also small or micro projects, with the + additional intent to help newcomers looking for something to work on. + + Justin Tobler also replied to Patrick's patch suggesting adding the + removal of double dot and triple dot syntax (".." and "...") from + `git diff` to the document. This was discussed by Junio and Patrick + but, as it would need a lot more work, Patrick decided to not add it + to the document for now. + + Patrick then sent a + [version 2 of his patch](https://lore.kernel.org/git/2ef53ff98b12fe9373a15ec3a795235f040d9049.1715667067.git.ps@pks.im/) + adding a section about features "that are _not_ to be + deprecated" and proposing some further deprecations, while withdrawing + the `$GITDIR/hooks` directory deprecation proposal. + + Karthik Nayak replied to the patch version 2, listing a number of + commands not mentioned in the document that do similar things, which + might indicate that some of them could be deprecated too. Patrick, + Junio and Dragan discussed these commands, but decided that only + `git pickaxe`, which is an alias for `git blame`, could be removed + for now. + + So Patrick sent a + [version 3 of his patch](https://lore.kernel.org/git/84c01f1b0a2d24d7de912606f548623601c0d715.1716555034.git.ps@pks.im/), + which only added the removal of `git pickaxe`. + + Junio replied to this version 3 with a lot of comments to discuss + how each item was justified and how we could improve on justifying + items in general. Patrick then agreed on ways to improve the + document. + + Patrick sent a + [version 4](https://lore.kernel.org/git/cover.1717141598.git.ps@pks.im/) + where the single patch had been broken down into 4 patches. In the + process a lot of the proposed deprecations from the previous version + were removed and the document name was changed from + "UpcomingBreakingChanges.md" to "BreakingChanges.md" as some changes + listed in the "Superseded features that will not be deprecated" + section should not be considered upcoming. + + The goal was to introduce the document in a skeletal form in the + first patch and then add only one item to each of the three sections + in the following patches. This way each of the last 3 patches should + be an example of how other items should later be added to the + document. + + Junio, Patrick and Todd Zullinger then discussed relatively small + improvements to the form and content of the document. + + Patrick sent a + [version 5 of the patch series](https://lore.kernel.org/git/cover.1717402497.git.ps@pks.im/) + where the main change was that the document was converted to + AsciiDoc instead of Markdown and renamed from "BreakingChanges.md" + to "BreakingChanges.txt" for format compatibility with most other + documents in the codebase. + + Junio, Phillip Wood and Patrick discussed other small improvements, + which Patrick integrated into + [version 6 of the patch series](https://lore.kernel.org/git/cover.1717504292.git.ps@pks.im/). + + Junio then suggested a few more small improvements, which Patrick + finally integrated into + [version 7 of the patch series](https://lore.kernel.org/git/cover.1718345026.git.ps@pks.im/), + which was later merged into the 'master' branch. + + + + + +## Other News + + + +__Light reading__ + +* [BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days](https://graphite.dev/blog/bitkeeper-linux-story-of-git-creation) + by Nicholas Yan on Graphite Blog. + See also, among others, [GitHistory page in the archives of Git SCM Wiki](https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitHistory.html), + which was mentioned in [Git Rev News Edition #105](https://git.github.io/rev_news/2023/11/30/edition-105/), + and other links that were mentioned in that edition. +* [Git Workflows for API Technical Writers](https://bump.sh/blog/git-workflows-for-api-technical-writers) + by James Higginbotham on Bump\.sh. + Mentions [Bump.sh](https://bump.sh/), an API doc platform for tech writers and engineers, + at the end of the article. +* [What is Git? Our beginner’s guide to version control](https://github.blog/2024-05-27-what-is-git-our-beginners-guide-to-version-control/) and + [Top 12 Git commands every developer must know](https://github.blog/2024-06-10-top-12-git-commands-every-developer-must-know/) + by Kedasha Kerr on GitHub Blog. This blog post accompanies the + [GitHub for Beginners](https://youtube.com/playlist?list=PL0lo9MOBetEFcp4SCWinBdpml9B2U25-f&feature=shared) + series (YouTube playlist). +* [Stop Wasting Hours! Git Bisect: Your Ultimate Bug Hunting Tool](https://ionixjunior.dev/en/stop-wasting-hours-git-bisect-your-ultimate-bug-hunting-tool/) + by Ione Souza Junior on his blog; also available [on DEV.to](https://dev.to/ionixjunior/stop-wasting-hours-git-bisect-your-ultimate-bug-hunting-tool-4ebc) + as a part of [mastering-git series](https://dev.to/ionixjunior/series/26070). +* [The Magic of Git Stash: How It Saved My Day](https://dev.to/waqaryounis7564/the-magic-of-git-stash-how-it-saved-my-day-119k) + by waqaryounis7564 on DEV\.to. +* [Prevent Hidden Merge Conflicts](https://dev.to/shinigami92/prevent-hidden-merge-conflicts-2lem) + by Shinnigami on DEV\.to; but note that the described solutions might warrant some more thought + (linearizing history by requiring rebase instead of merge to integrate changes + versus requiring branch to be up to date before merging), and are not the only possible + solutions (for example: post-merge checks). +* [“Good Commit” vs “Your Commit”: How to Write a Perfect Git Commit Message](https://dev.to/safdarali/good-commit-vs-your-commit-how-to-write-a-perfect-git-commit-message-59ol) + by Safdar Ali on DEV\.to. + * Compare the [Conventional Commits](https://www.conventionalcommits.org/) specification, + first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/), + and [Gitmoji](https://gitmoji.dev/), first mentioned in [Git Rev News Edition #47](https://git.github.io/rev_news/2019/01/23/edition-47/). +* [Ten Things You Didn’t Know Git And GitHub Could Do](https://owenou.com/ten-things-you-didnt-know-git-and-github-could-do/) + by Owen Ou on Owen Ou's blog (2012). +* [Versioning FreeCAD files with git](https://blog.lambda.cx/posts/freecad-and-git/) + (FreeCAD files are zip archives containing text documents) by Dante Catalfamo on lambda.cx blog (2021). + + +  + +* [Programming in Unison](https://lwn.net/Articles/978955/) + by Daroc Alden on LWN\.net ([free subscriber link](https://lwn.net/SubscriberLink/978955/cd8dffc792b86313/)). + [Unison](https://www.unison-lang.org/) is an MIT-licensed programming language, + where programs are stored in an append-only, content-addressed database + (though still displayed to the user for editing as text, using the editor of their choice)... + just like information about project versions is stored in Git. + + + +__Git tools and sites__ + +* [setuptools-scm](https://github.com/pypa/setuptools_scm) + is a tool that extracts Python package versions from `git` or `hg` metadata + instead of declaring them as the version argument or in an SCM managed file. + Additionally, it provides setuptools with a list of files that are managed by the SCM + (i.e. it automatically adds all of the SCM-managed files to the sdist). + Unwanted files must be excluded via `MANIFEST.in`. + The preferred way to configure setuptools-scm is via `pyproject.toml`.
+ The [latest version](https://setuptools-scm.readthedocs.io/en/latest/) + and the [stable version documentation](https://setuptools-scm.readthedocs.io/en/stable/) + are available on Read the Docs. +* [`piku`](https://piku.github.io/), which was inspired by [`dokku`](https://dokku.com/), + allows you to do `git push` deployments to your own servers, no matter how small they are. + An open source PaaS (Platform as a Service) alternative to services such as Heroku. + Written in Python. +* [gitchangelog](https://github.com/vaab/gitchangelog) is a tool that + creates a changelog from git log history. Written in Python; + no longer actively developed (version 3.0.4 is from 2018). + * Compare with for example [git-cliff](https://git-cliff.org/) changelog generator, + mentioned in [Git Rev News Edition #108](https://git.github.io/rev_news/2024/02/29/edition-108/). +* [git-open-remote](https://github.com/masukomi/masuconfigs/blob/master/bin/git-scripts/git-open-remote) + is a shell script by [masukomi](https://masukomi.org) to open the web page(s) for the repo's remote(s). + With this script you can simply cd into a git repo and type `git open-remote`. + Requires [`open`](https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/open.1.html) + or [`xdg-open`](https://linux.die.net/man/1/xdg-open) + (aliased or linked to `open`) to open the web browser, + and [charm gum](https://github.com/charmbracelet/gum) + to implement the selection UI when the Git repo has more than one remote. +* [Git EOL Conversion Diagram](https://gist.github.com/DecimalTurn/3f99a3903366bf9fb2c1f513bd3c5a83) for checkout + as Gist providing an [SVG version](https://raw.githubusercontent.com/gist/DecimalTurn/3f99a3903366bf9fb2c1f513bd3c5a83/raw/d54d0e842c1f22e0b04d7a044dde1489993d87bf/Git-EOL-Conversion-Diagram.svg) + and an [editable version on Mindmup](https://app.mindmup.com/map/_free/2024/06/982eaeb032cf11ef93d0a9d7af4d6195), + by Martin Leduc (@DecimalTurn). + +## Releases + ++ Git [2.45.2 and friends to unbreak "git lfs" and others](https://public-inbox.org/git/xmqqr0dheuw5.fsf@gitster.g/) ++ Git for Windows [2.45.2(1)](https://github.com/git-for-windows/git/releases/tag/v2.45.2.windows.1) ++ GitHub Enterprise [3.13.0](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.0), +[3.12.5](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.5), +[3.11.11](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.11), +[3.10.13](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.13), +[3.9.16](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.16) ++ GitLab [17.1.1, 17.0.3, 16.11.5](https://about.gitlab.com/releases/2024/06/26/patch-release-gitlab-17-1-1-released/), +[17.1](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/), +[17.0.2, 16.11.4, 16.10.7](https://about.gitlab.com/releases/2024/06/12/patch-release-gitlab-17-0-2-released/) ++ GitKraken [10.0.2](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.2](https://desktop.github.com/release-notes/), +[3.4.1](https://desktop.github.com/release-notes/) ++ Tower for Mac 12.0 (BETA) — [Release blog post](https://www.git-tower.com/blog/tower-mac-12/) ++ Garden [1.7.0](https://github.com/garden-rs/garden/releases/tag/v1.7.0), +[1.6.0](https://github.com/garden-rs/garden/releases/tag/v1.6.0) ++ Git-Cola [4.8.0](https://github.com/git-cola/git-cola/releases/tag/v4.8.0) ++ git-credential-oauth [0.12.1](https://github.com/hickford/git-credential-oauth/releases/tag/v0.12.1), +[0.12.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.12.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Štěpán Němec, Bruno Brito, David Aguilar, +Brandon Pugh and Dragan Simic. diff --git a/_posts/2024-07-31-edition-113.markdown b/_posts/2024-07-31-edition-113.markdown new file mode 100644 index 000000000..b2845b209 --- /dev/null +++ b/_posts/2024-07-31-edition-113.markdown @@ -0,0 +1,435 @@ +--- +title: Git Rev News Edition 113 (July 31st, 2024) +layout: default +date: 2024-07-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 113 (July 31st, 2024) + +Welcome to the 113th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of June and July 2024. + +## Discussions + + +### General + +* [[ANNOUNCE] Tickets available for Git Merge 2024](https://lore.kernel.org/git/ZpU0WwsrXCF8BC1f@nand.local/) + + Taylor Blau announced that [tickets for Git Merge 2024, Berlin, September 19th and 20th](https://git-merge.com) + are now on sale. People who would like to come but need financial + assistance with travel costs can contact the Git PLC or Scott + Chacon directly. + +* [[ANNOUNCE] Git Merge 2024 CFP deadline extended](https://lore.kernel.org/git/ZqkHxvDx7dlh0RX6@nand.local/) + + Taylor Blau announced that the Git Merge 2024 CFP (Call For + Proposals) limit has been extended by a week from August 1st to August 8th. + So there are a few more days left to propose talks. + +* [[ANNOUNCE] Berlin Git Meetup on August 14th, 6pm CEST](https://lore.kernel.org/git/ZqoQcuKz_ynYaBNM@tanuki/) + + Patrick Steinhardt announced that some Git developers are trying to + revive the Git user group in Berlin and will host their first + session together with GitButler soon. + + + +### Support + +* [[BUG] "git clean -df ." silently doesn't delete folders with stale .nfs* files](https://lore.kernel.org/git/ae862adb-1475-48e9-bd50-0c07dc42a520@rawbw.com/) + + Yuri reported that `git clean -df .`, which was supposed to delete a + directory and all its contents, didn't work when there were files + named '.nfsXXXXXXXXXXX' managed by NFS in that directory. He + expected that `git clean -df .` would warn or error out when it + cannot remove such a file, instead of ignoring the fact that it + could not remove the file and the containing directory and + terminating with a success exit code. + + Junio Hamano, the Git maintainer, replied to Yuri saying that it was + expected that directories that were not empty were not removed. + + Yuri replied that he expected the '.nfsXXXXXXXXXXX' files to be + removed as they were untracked, that is, neither added nor part of the repo, + and the command was expected to remove such untracked files. + + Junio replied that the '.nfsXXXXXXXXXXX' files were "a limitation" + of NFS that applications, including Git, couldn't and weren't + supposed to remove. He pointed to some documentation which explains + what these special NFS files are, and that they originate from an NFS + protocol based implementation strategy commonly known as "silly rename". + + Yuri replied that Git should still complain when it cannot remove + such files, or that there should be a verbosity option that should + make it complain in such cases. + + Randall S. Becker replied to Yuri that he tried to reproduce the + issue without using NFS and couldn't. So he asked Yuri if he could + share "a reproducible set of commands" and said that it was probably + caused by NFS. + + Junio replied to Randall and Yuri that removing a '.nfsXXXXXXXXXXX' + files under a real NFSv3 client would likely result in the file + being automatically resurrected, and that failure to remove a file + should indeed be reported as Git does when it cannot remove a + regular file. + + Yuri replied to Randall listing a series of instructions to + reproduce the issue. He agreed that Git reported failures when it + couldn't remove a file because of "permissions and special flags + reasons", but he repeated that it should also do it in the case of + such NFS files. + + Randall replied to Yuri saying he thought that Git didn't even see + the NFS files. He asked if a second `git clean -df .` removed the + NFS files and put new ones, with different names, in place. + + Yuri replied that it wasn't the case and there seemed to be a single + NFS file. + + Chris Torek then chimed into the discussion replying to Yuri. He + explained in details how "NFS silly renames" work, and listed some + cases which could result in NFS lying to Git by reporting that an + unlink(2) operation succeeded when in fact the file was renamed but + not deleted. In such a case Git could not report that it couldn't + remove a file. It could report that it couldn't remove the + containing directory though. + + Chris finished his explanations saying "Anyway, that's the OS view + of this mess. I leave the work on Git itself to others. :-)" + + Jeff King, alias Peff, replied to Yuri's email that contained a + series of instructions to reproduce the issue. He said he got the + following warning when trying to reproduce: + ``` + warning: failed to remove xx/.nfs0000000002c8197f00000002: Device or resource busy + ``` + + So Peff thought Git worked properly on his system and then + communicated details of the OS and NFS mount he used. + + Yuri replied by giving information about his system. He also said + that when using `rm -rf` to remove the NFS file, he got a "Device or + resource busy" error message, but not when using Git. + + Randall replied to Peff that doing a self-mount to reproduce as Peff + did was perhaps not the best, as the NFS client might be aware of + the self-mount and things might not behave the same as in a regular + mount. + + Yuri suggested using a virtual machine to avoid a self-mount. + + Gabor Gombas replied to Yuri reporting the results of his tests. He + got a "Directory not empty" or a "Device or resource busy" error + message when he used `git clean -dfx`, but he also got no error + message when using `git clean -df`. + + This led Yuri to reply that with `-dfx` Git indeed warns about NFS + files on his machine, but with `-df` it doesn't, because the NFS + files are in the ignore list. + + It is indeed expected that ignored files are not deleted and are + just ignored without the `-x` option. + + +## Developer Spotlight: Rubén Justo + +* Who are you and what do you do? + + My name is Rubén, and that's how it's spelled correctly. However, + some old friends call me Ruben because when we were kids changing + names was a sign of friendship. Changing the accent from "ben" to + "ru", makes the letter 'e' lose its tilde when writing my name. + + My $dayjob is not related to Git, but I use it quite often during the + workday. Using it sometimes gives me an itch that I often can't + resist trying to scratch. + +* What would you name your most important contribution to Git? + + I can't think of any worth mentioning. But I'll say something in the + other direction; contributing to Git has not only meant solving some + itches, but it has clearly made me improve my overall work style. + I'm grateful for that. + +* What are you doing on the Git project these days, and why? + + This can be read at any time: polishing up some itches that has come + up for me or a colleague. + + Lately, though, I find myself exploring more and more side issues + that arise during iterations of the changes I was originally + interested in. + +* If you could get a team of expert developers to work full time on + something in Git for a full year, what would it be? + + I'll say a feasible one: something _in Git_ that allows me to avoid + writing shortcuts like `@{-1}`, `@{1}`, `@{...` + + At least on my keyboard, it's a pain to type `@`, `{...}`. And I + tend to type those shortcuts a lot. + + Perhaps too easy for the experts and they'll have a lot of spare time + during the year? + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + I think that backwards compatibility is overrated most of the time. + It's usually a matter of getting on with it and time; sometimes a lot + of time, I admit. + + The steps being taken towards Git 3.0 seem very interesting to me + [[ref 1](https://public-inbox.org/git/xmqqa5l2y6aa.fsf_-_@gitster.g/)] + [[ref 2](https://public-inbox.org/git/cover.1718345026.git.ps@pks.im/)]. + Perhaps there is an opportunity to do some breaking changes. I don't + have any in mind, though. + + * What is your favorite Git-related tool/library, outside of + Git itself? + + Definitely: [`tig`](https://jonas.github.io/tig/). + +* Do you happen to have any memorable experience w.r.t. contributing + to the Git project? If yes, could you share it with us? + + Nope. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + To interact with the list, I mainly use [`lei`](https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started), + [`mutt`](http://www.mutt.org/) and [`thunderbird`](https://www.thunderbird.net/en-US/) + in a rather makeshift way. Maybe someday I'll finally configure + [`git send-email`](https://git-send-email.io/). + + In fact, more often than not, when I send a patch, I have the feeling + that someone is going to come along and say: "Come on, Rubén. That + user agent? Set up a decent environment to send this properly". + + To develop, I mainly use vanilla Vim. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + Perhaps I would say that writing and reading code are not the most + important skills in a project like Git. Empathy and the development + of effective arguments to convey ideas or intentions are much more + crucial. + + Realizing and internalizing that, is a solid starting point, I think. + +* If there's one tip you would like to share with other Git + developers, what would it be? + + Keep in mind that reviewing code is much harder than writing it, but + writing a good message for the commit is even harder. + + +## Other News + +__Various__ + ++ [Highlights from Git 2.46](https://github.blog/open-source/git/highlights-from-git-2-46/) + by Taylor Blau on GitHub Blog. Those include pseudo-merge reachability bitmaps, + subcommands in [git-config](https://git-scm.com/docs/git-config/2.46.0) (like `git config list`), + an enhanced credential helper protocol, and improving the still experimental reftable support. ++ [What’s new in Git 2.46.0?](https://about.gitlab.com/blog/2024/07/29/whats-new-in-git-2-46-0/) + by Justin Tobler on GitLab Blog. Highlights include tooling to migrate reference backends + (from files backend to reftables), symref update instructions for `git update-ref --stdin`, + `git config` interface improvements (mentioned in the previous article linked), and bundle URI fixes. ++ [Anyone can Access Deleted and Private Repository Data on GitHub](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github) + via Cross Fork Object Reference (CFOR) from another [public] fork. + Any code committed to a public repository may be accessible forever + as long as there is at least one public fork of that repository. + This is an intentional design decision by GitHub; see [the documentation](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility). + There is though a separate fork network for public and for private versions + of the same repository.
+ Posted on Truffle Security blog. ++ [Debian debate over tag2upload reaches compromise](https://lwn.net/Articles/978324/) + by Joe Brockmeier on LWN\.net. The [tag2upload service](https://salsa.debian.org/dgit-team/dgit/-/blob/master/TAG2UPLOAD-DESIGN.txt) + promises a streamlined way for Debian developers using Git to upload packages to + the [Debian Archive](https://wiki.debian.org/Services/Debian%20Archive). + + +__Light reading__ + ++ [A Git story: Not so fun this time](https://blog.brachiosoft.com/en/posts/git/) + on Brachiosoft Blog. The title refers to the ["Just for Fun"](https://www.amazon.com/Just-Fun-Story-Accidental-Revolutionary/dp/0066620732/) + book, the 2001 autobiography of Linux kernel creator Linus Torvalds, + and how the Git origin story wasn't so much fun, at least for Linus. + The article provides a list of references. Includes new material + not seen in earlier retellings of the Git history, like the ones linked in + [Git Rev News Edition #2](https://git.github.io/rev_news/2015/04/05/edition-2/) (on 10 years of Git), + [Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/), + [Edition #62](https://git.github.io/rev_news/2020/04/23/edition-62/) (on 15 years of Git), + [Edition #105](https://git.github.io/rev_news/2023/11/30/edition-105/) + and [Edition #112](https://git.github.io/rev_news/2024/06/30/edition-112/) + (among others). ++ [Why Facebook doesn’t use Git](https://graphite.dev/blog/why-facebook-doesnt-use-git) + by Greg Foster on Graphite Blog. + + See also [Scaling Mercurial at Facebook](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/), + mentioned in [Git Rev News Edition #24](https://git.github.io/rev_news/2017/02/22/edition-24/). ++ [Pull requests via git push](https://blog.sesse.net/blog/tech/2024-07-15-13-04_pull_requests_via_git_push.html) + and a specially crafted `pre-receive` hook (and `git-http-backend` configured + to allow anonymous push) that turns `git push` into series of patch emails. + (Though this approach has some limitations.) Written by Steinar H. Gunderson on his blog. + + See also [git-pr](https://pr.pico.sh/) in the "Git tools and sites" section. ++ [How I Use Git Worktrees](https://matklad.github.io/2024/07/25/git-worktrees.html) + by Alex Kladov (matklad) on his GitHub Pages-based blog. + TL;DR: consider using worktrees not as a replacement for branches, + but as a means to manage concurrency in your tasks (for example: view, work, review, fuzz, scratch). ++ [Git autocorrect needs more marketing](https://dev.to/cloudx/git-autocorrect-needs-more-marketing-20gg) + by Axel Navarro for Cloud(x); on DEV\.to. + + See also [thefuck](https://github.com/nvbn/thefuck), a command line application + which corrects your previous console command (for example Git command) + if you made an error (like typos in command name), and it _didn't_ do what you wanted; + the tool was first mentioned in + [Git Rev News Edition #101](https://git.github.io/rev_news/2023/07/31/edition-101/). ++ [commit messages are optional](https://schpet.com/note/git-commit-messages-are-optional) + by Peter Schilling in schpet’s notebook (though for some of the mentioned uses, + commits with empty commit messages are better replaced with `git commit --fixup`). ++ [Git-ifying SVN: How I Brought Modern Version Control to an Age-Old System](https://ionixjunior.dev/en/gitifying-svn-how-i-brought-modern-version-control-to-an-ageold-system/) + by Ione Souza Junior on his blog; also available [on DEV.to](https://dev.to/ionixjunior/git-ifying-svn-how-i-brought-modern-version-control-to-an-age-old-system-4o3e) + as a last part of the [mastering-git series](https://dev.to/ionixjunior/series/26070). + Another article from this series was mentioned in [Git Rev News Edition #112](https://git.github.io/rev_news/2024/06/30/edition-112/). ++ [Benchmarking the Modern Development Experience across Versioning Tools: S3, DVC, Git LFS, and XetHub](https://about.xethub.com/blog/benchmarking-the-modern-development-experience) + by Ann Huang on XetHub blog. + + [XetHub](https://about.xethub.com/) is a development platform for datasets and models, + which automatically versions and tracks assets across the Machine Learning stack + to guarantee reproducibility. Mentioned in passing in [Git Rev News Edition #95](https://git.github.io/rev_news/2023/01/31/edition-95/). + + The comparison does not include [DagsHub's Direct Data Access / Data Streaming](https://dagshub.com/docs/feature_guide/dagshub_storage/data_streaming/), + which was [announced](https://dagshub.com/blog/launching-data-streaming-and-upload/) in 2022. + [DagsHub](https://dagshub.com/), a web platform for storing, versioning and managing data (data hub), + was first mentioned in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/). ++ [The visualization and analysis of git commit statistics for IT team leaders.](https://dev.to/responsivecrocodile/the-visualization-and-analysis-of-git-commit-statistics-for-it-team-leaders-2pof) + by Aleksei Bakhirev (Responsive Crocodile) on DEV\.to. Uses the [Assayo](https://github.com/bakhirev/assayo) + tool written by the author for plots (see also the [assayo.online](https://assayo.online/) webpage).
+ Some personal thought: beware of [Goodhart's law](https://en.wikipedia.org/wiki/Goodhart%27s_law): + _"When a measure becomes a target, it ceases to be a good measure"_. + For examples from IT, see Joel on Software "[Measurement](https://www.joelonsoftware.com/2002/07/15/20020715/)" (2002). ++ [Reorient GitHub Pull Requests Around Changesets](https://mitchellh.com/writing/github-changesets) + from one giant mutable changeset, by Mitchell Hashimoto on his blog (2023). ++ [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) + (2008) by Tim Pope on tbaggery blog; it also explains some of the reasoning behind recommendations. + +  + ++ git good (My Hero Academia fanfiction, humor/horror) - Izuku's quirk is Git, + the version control software (some artistic license taken in order to make a good story). + By Unknownlight. Available [on Archive of Our Own](https://archiveofourown.org/works/55773742/chapters/141591955), + [on FanFiction.net](https://www.fanfiction.net/s/14369888/1/git-good) (not recommended by the author), + and [on SpaceBattles](https://forums.spacebattles.com/threads/git-good-my-hero-academia-izukus-quirk-is-git-the-version-control-software.1163142/).
+ Summary: + > Reality shattered like broken glass. The firmament that separated the real world from the eldritch beyond had broken. Two timelines had collided in the center of the street - an incongruous synthesis of two different chains of events. A building collapsed, and it did not. An explosion devastated the surroundings, and it did not. Screaming faces and laughs of joy overlapped each other as if viewed through a kaleidoscopic prism. + > + > The crowd looked on in horror and awe. Who was responsible for tearing apart the fabric of reality? + > + > Izuku groaned. _'Great, another merge conflict'_, he thought. _'What a pain'_. + + +__Easy watching__ + ++ [I was wrong about `git stash`...](https://www.youtube.com/watch?v=ntM7utSjeVU) + (or rather, how one can use `git worktree`), by Philomatics on YouTube [5:18]. + + +__Git tools and sites__ + ++ [pico/git-pr](https://pr.pico.sh/) (Patch Requests) is a new Git collaboration service, + where you send and retrieve patches not via email but via SSH to a `git-pr` server: + ```bash + # Contributor submits his/her changes: + git format-patch origin/main --stdout | ssh pr.pico.sh pr create test + # > Patch Request has been created (ID: 1) + + # Owner can apply those changes via patch request: + ssh pr.pico.sh pr print 1 | git am -3 + ``` + Can be self-hosted. Written in Go, MIT licensed. ++ [eza](https://github.com/eza-community/eza) is a modern replacement + for the venerable file-listing command-line program `ls`. It knows about symlinks, + extended attributes, and Git (like file status in Git repo, Git repo status, + or ignoring files mentioned in `.gitignore`). Written in Rust, MIT licensed. + See the [documentation](https://eza.rocks/). ++ [BlenderBIM](https://blenderbim.org/) is an add-on for detailed and + data-rich [OpenBIM](https://www.buildingsmart.org/about/openbim/) + (Building Information Modeling) with Blender. + BlenderBIM supports [tracking the development of your IFC files with Git](https://docs.blenderbim.org/users/git_support.html) + (Industry Foundation Classes, or IFC, is an international standard for BIM). + Note that merging requires the [ifcmerge](https://github.com/brunopostle/ifcmerge) + tool to be installed (`ifcmerge` is written in Perl and published under the GPLv3 license). ++ [_diff-pdf_](https://vslavik.github.io/diff-pdf/) is a tool for visually comparing two PDFs + which produces a PDF file with visually highlighted differences. + Note that [the repository](https://github.com/vslavik/diff-pdf) states that + the code is not being actively developed. Written in C++, GPLv2 licensed. + + See also [pdf-diff](https://github.com/JoshData/pdf-diff) in Python, CC0-1.0 licensed; + another [pdf-diff](https://github.com/serhack/pdf-diff) in Go, MIT licensed; + and [diff-pdf-visually](https://github.com/bgeron/diff-pdf-visually) in Python, + dual licensed under both MIT License and Apache License, Version 2.0 - with + a slightly different goal. ++ [vdm: A General-Purpose Versioned-Dependency Manager](https://github.com/opensourcecorp/vdm) + is an alternative to e.g. `git submodules` for managing arbitrary external dependencies. + Written in Go, MIT licensed. + + Contrast [Gil (git links) tool](https://github.com/chronoxor/gil) + to manage complex recursive repository dependencies with cross references and cycles, + mentioned in [Git Rev News Edition #110](https://git.github.io/rev_news/2024/04/30/edition-110/). ++ [Bit-Booster is an Offline Commit Graph Drawing Tool](https://bit-booster.com/graph.html), + using HTML and SVG, generating graphs by pasting the result of running + `git log --all --date-order --pretty="%h|%p|%d"` into a textarea. + + It is also an [add-on for Atlassian Bitbucket Server](https://bit-booster.com/graph.html). + + The webpage includes [comparison with other various commit graph add-ons](https://bit-booster.com/best.html) (2016). + +  + ++ [How To Rotate](https://howtorotate.com/) is an open-source collection + of API Key Rotation tutorials for different SaaS providers. ++ [Act](https://github.com/nektos/act) is a command line tool + to run your GitHub Actions locally, using the Docker Engine API. Written in Go. + Please look at the [`act` user guide](https://nektosact.com/) for more documentation. + + There is also [Act runner](https://gitea.com/gitea/act_runner), + a runner for Gitea based on the Gitea fork of `act`. + + +## Releases + ++ Git [2.46.0](https://public-inbox.org/git/xmqqzfq0i0qa.fsf@gitster.g/), +[2.46.0-rc2](https://public-inbox.org/git/xmqq7cdavgqa.fsf@gitster.g/), +[2.46.0-rc1](https://public-inbox.org/git/xmqqwmlivcdp.fsf@gitster.g/), +[2.46.0-rc0](https://public-inbox.org/git/xmqqjzhqmt22.fsf@gitster.g/) ++ Git for Windows [2.46.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.46.0.windows.1), +[2.46.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.46.0-rc2.windows.1), +[2.46.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.46.0-rc1.windows.1), +[2.46.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.46.0-rc0.windows.1) ++ GitLab [17.2.1, 17.1.3, 17.0.5](https://about.gitlab.com/releases/2024/07/24/patch-release-gitlab-17-2-1-released/), +[17.2](https://about.gitlab.com/releases/2024/07/18/gitlab-17-2-released/), +[17.1.2, 17.0.4, 16.11.6](https://about.gitlab.com/releases/2024/07/10/patch-release-gitlab-17-1-2-released/) ++ GitHub Enterprise [3.13.2](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.2), +[3.12.7](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.7), +[3.11.13](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.13), +[3.10.15](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.15), +[3.9.18](https://help.github.com/enterprise-server@3.9/admin/release-notes#3.9.18) ++ GitKraken [10.1.1](https://help.gitkraken.com/gitkraken-client/current/), +[10.1.0](https://help.gitkraken.com/gitkraken-client/current/) ++ Garden [1.7.0](https://github.com/garden-rs/garden/releases/tag/v1.7.0) ++ Git Cola [4.8.1](https://github.com/git-cola/git-cola/releases/tag/v4.8.1) ++ git-credential-oauth [0.13.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.13.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Štěpán Němec and Rubén Justo. diff --git a/_posts/2024-08-31-edition-114.markdown b/_posts/2024-08-31-edition-114.markdown new file mode 100644 index 000000000..a6dd8ac7f --- /dev/null +++ b/_posts/2024-08-31-edition-114.markdown @@ -0,0 +1,231 @@ +--- +title: Git Rev News Edition 114 (August 31st, 2024) +layout: default +date: 2024-08-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 114 (August 31st, 2024) + +Welcome to the 114th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of July and August 2024. + +## Discussions + + + +### Reviews + +* [[PATCH] ReviewingGuidelines: encourage positive reviews more](https://lore.kernel.org/git/xmqqsevysdaa.fsf@gitster.g/) + + Junio Hamano, the Git maintainer, sent a patch to the mailing list + which updated the 'ReviewingGuidelines.txt' documentation with the + goal of encouraging positive reviews even more. + + The 'ReviewingGuidelines.txt' documentation was + [created a few years ago](https://lore.kernel.org/git/pull.1348.v2.git.1663614767058.gitgitgadget@gmail.com/) + by Victoria Dye to provide "consistent definitions for common + review terminology" and to give advice to reviewers, in a similar + way as the MyFirstContribution documentation gives advice to + contributors. + + The few paragraphs that Junio's patch added said that positive + reviews are highly encouraged, even when the author is a work + colleague. They show that people other than the author(s) of the + reviewed patches care about the issue that is addressed. + + When writing positive reviews, reviewers should tell why they + support the patches, and should show that they understand the issue + and how the patches address it. They are also encouraged to describe + how they understand complex parts of the patches. + + Junio's patch also adds a small paragraph saying that "uplifting + feedback goes a long way towards encouraging contributors to + participate more actively in the Git community." + + Eric Sunshine then replied to Junio pointing out a minor typo in his + patch. Patrick Steinhardt replied to Junio too. He said that he had + already guided some of his GitLab colleagues who review patches + and suggested them to do what Junio describes. + + Derrick Stolee, who prefers to be called Stolee, replied to Patrick + agreeing with him and saying that it also helps to not have internal + reviews for experienced contributors. He said that they used to have + internal reviews at Microsoft but it was overly cautious and "loses + the benefits of doing reviews in the open". + + Patrick replied to Stolee saying that GitLab also used to have an + internal review, but it recently became optional and recommended + only for people who are not yet familiar with the mailing list + workflow. + + Junio then sent + [a version 2](https://lore.kernel.org/git/xmqqle1pjwtt.fsf@gitster.g/) + of the patch fixing small typos. Patrick reviewed this version + and found it good, so it was later merged into the 'master' branch. + + + + + +## Other News + +__Various__ ++ [GitLab now supports SHA256 repositories](https://about.gitlab.com/blog/2024/08/19/gitlab-now-supports-sha256-repositories/) + by John Cai on GitLab Blog (in Bulletin Board category). ++ [Forgejo v8.0 is available](https://forgejo.org/2024-07-release-v8-0/). + + [Forgejo](https://forgejo.org/) is a self-hosted lightweight software forge, + written in Go; nowadays a hard fork of Gitea (which in turn was based on Gogs). + It was mentioned in passing in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/), + as one of the forges working on implementing the [ForgeFed](https://forgefed.org/) + federation protocol for forge services. ++ Packt recently published the second edition of the “Mastering Git” book + by Jakub Narębski, one of the Git Rev News editors. + The book is available [on PacktPub](https://www.packtpub.com/en-us/product/mastering-git-9781835086070) + and [on Amazon](https://www.amazon.com/Mastering-Git-expert-level-proficiency-distributed-ebook/dp/B0D98BR1T7). + The first edition of the book was mentioned in [Git Rev News Edition #16](https://git.github.io/rev_news/2016/06/15/edition-16/); + you can find the interview with Jakub Narębski in [Edition #17](https://git.github.io/rev_news/2016/07/20/edition-17/). + +__Light reading__ ++ [Different ways to use `--patch` in Git](https://tekin.co.uk/2024/08/the-many-uses-for-git-patch) + by Tekin Süleyman on his blog. It describes selectively stashing changes, + selectively discarding changes, and selectively restoring changes. + This article expands on the + "[interactively stage changes with \-\-patch](https://tekin.co.uk/2017/03/git-tips-you-possibly-did-not-know-you-needed#3-interactively-stage-changes-with---patch)" advice + in [Git Tips you (Possibly) Didn't Know You Needed](https://tekin.co.uk/2017/03/git-tips-you-possibly-did-not-know-you-needed). ++ [Tracing the evolution of a Python function with git log](https://nerderati.com/tracing-the-evolution-of-a-python-function-with-git-log/) + by Joël Perras on his Nerderati blog. It shows a detailed example on using `git log -L` + (and the `diff=python` gitattribute) to diagnose a real-life bug that was ostensibly + caused by an upgrade to Authlib. + + This technique is also described in the + [See the History of a Method with `git log -L`](https://calebhearth.com/git-method-history) article, + mentioned in [Git Rev News Edition #105](https://git.github.io/rev_news/2023/11/30/edition-105/). ++ [Optimize your workflow with Git stash](https://developer.mozilla.org/en-US/blog/optimize-your-workflow-git-stash/) + by Toon Claes (from GitLab) at MDN Blog. ++ [Seriously, You Need to Learn Git](https://blog.derlin.ch/seriously-you-need-to-learn-git) + by Lucy Linder on her blog (also available [on DEV\.to](https://dev.to/derlin/seriously-you-need-to-learn-git-1n8j)). The article defines various levels of Git knowledge, + and explains how knowing Git might improve one's development process. ++ [Tips for creating merge commits](https://www.brandonpugh.com/blog/tips-for-creating-merge-commits/) + by Brandon Pugh on his blog. ++ [Back-dating Git commits based on file modification dates](https://til.simonwillison.net/git/backdate-git-commits) + by Simon Willison in his [TILs on Git](https://til.simonwillison.net/git) + (Today I’ve Learned). + + It was used by the author to create the [1991-WWW-NeXT-Implementation](https://github.com/simonw/1991-WWW-NeXT-Implementation) + repository out of [the archive](https://www.w3.org/History/1991-WWW-NeXT/Implementation/) + of Tim Berner-Lee's original code for the WorldWideWeb application for NeXT. + This endeavor was described in a short blog post, [1991-WWW-NeXT-Implementation on GitHub](https://simonwillison.net/2024/Aug/1/www-next-implementation-on-github/). ++ [Store Code Discussions in Git using Git Notes](https://wouterj.nl/2024/08/git-notes) + by Wouter de Jong on his blog. The article includes some code (in PHP) + that uses the GitHub API to fetch the pull request comments and store them + in notes (under the `github-comments` notes reference). ++ [Attaching notes to git branches](https://dev.to/pinotattari/attaching-notes-to-git-branches-503k) + by Riccardo Bernardini on DEV\.to. The article describes why this feature is useful + and how `git branch --edit-description` and `git notes` fall short; this led to + the creation of the [git-branchnotes](https://gitlab.com/mockturtle/git-branchnotes) tool. ++ [This developer tool is 40 years old: can it be improved?](https://stackoverflow.blog/2024/08/05/this-developer-tool-is-40-years-old-can-it-be-improved) + by Bill Harding (CEO at GitClear) on StackOverflow Blog. + The article describes how GitClear's "Commit Cruncher" diff algorithm works, + which was created with the goal of making code reviews easier. + Note that the Myers diff algorithm (created by Eugene Myers in his + [seminal work](http://www.xmailserver.org/diff2.pdf) in 1986) + is not the only one available in [`git diff`](https://git-scm.com/docs/git-diff): + there are also `minimal`, `patience` and `histogram` diff algorithms available + (via the `--diff-algorithm` option); + this is not stated in the article. ++ [How Different Are Different diff Algorithms in Git?](https://cs.paperswithcode.com/paper/how-different-are-different-diff-algorithms): + a paper with code by Yusuf Sulistyo Nugroho, Hideaki Hata, Kenichi Matsumoto + from 2019. ++ [Git Things: A grab bag of less frequently talked about git adjacent points](https://matklad.github.io/2023/12/31/git-things.html) + by Alex Kladov (matklad) on his GitHub Pages-based blog, from 2023. ++ [Unified Versus Split Diff](https://matklad.github.io/2023/10/23/unified-vs-split-diff.html): + a discussion what is better for code reviews (and what the author uses) + by Alex Kladov (matklad) on his GitHub Pages-based blog, from 2023. ++ [How Does Git Store Files?](https://blog.git-init.com/how-does-git-store-files/) + — from a conceptual point of view. An article by by Alexis Määttä Vinkler + on [The Pragmatic Git](https://blog.git-init.com/) blog, from 2023. + + + ++ [Code review antipatterns](https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/code-review-antipatterns/) + for the dark side developers, a joke article by Simon Tatham + (don’t do any of the things described in this article). + + + +__Git tools and sites__ ++ [The Pragmatic Git](https://blog.git-init.com/) blog; + note that some articles are paid members only. Powered by Ghost. ++ [Carapace-bin](https://github.com/carapace-sh/carapace-bin) provides argument completion + for multiple CLI commands ([full list](https://carapace-sh.github.io/carapace-bin/completers.html) + including Git, [git-extras](https://github.com/tj/git-extras), `gh` GitHub CLI, `glab` GitLab CLI, + `tea` Gitea CLI, etc.), and works across multiple POSIX and non-POSIX shells. + Details about the Git completion support can be found in issue [#99](https://github.com/carapace-sh/carapace-bin/issues/99). + Written in Go under the MIT license.
+ Carapace-bin is a part of the [Carapace](https://carapace.sh/) multi-shell completion library and binary. + A high-level overview of Carapace itself is available at . ++ [git-random](https://git-random.olets.dev/): quickly build random-content Git + graphs with a specified shape. + This is a tool that can work as an aid for learning and experimenting with Git. + Source code available [on GitHub](https://github.com/olets/git-random/). + Written as a single-file Bash script under a custom + CC BY-NC-SA 4.0 license with Hippocratic License v3 ethical requirements. + + The author mentions that this tool was inspired by seeing Lorna Jane Mitchell + use Matthew J. McCullough's [generaterandomchanges](https://github.com/matthewmccullough/scripts/blob/master/generaterandomchanges) + in her talk _"[Advanced Git for Developers](https://www.youtube.com/watch?v=duqBHik7nRo)"_ + at Laracon EU 2015. ++ [git-branchnotes](https://gitlab.com/mockturtle/git-branchnotes) is a command-line tool + (that can be run as a git external command) that allows you to add notes to a branch and manage them. + Written in Ruby. + ++ [w2vgrep - Semantic Grep](https://github.com/arunsupe/semantic-grep) + is a command-line tool, with the interface similar to that of `grep`, + that performs semantic searches on text input using word embeddings (word2vec). + It's designed to find semantically similar matches to the query, + going beyond simple string matching. Supports multiple languages. + Written in Go under the MIT license. ++ [Collective Code Construction Contract](https://rfc.zeromq.org/spec/42/) (C4) + is an evolution of the github.com [Fork + Pull Model](https://help.github.com/articles/about-pull-requests/), + aimed at providing an optimal collaboration model for free software projects. + + Compare with [Ship / Show / Ask: A modern branching strategy](https://martinfowler.com/articles/ship-show-ask.html) model, + mentioned in [Git Rev News #79](https://git.github.io/rev_news/2021/09/30/edition-79/). + +## Releases + ++ Gerrit Code Review [3.10.1](https://www.gerritcodereview.com/3.10.html#3101), +[3.8.8](https://www.gerritcodereview.com/3.8.html#388), +[3.9.6](https://www.gerritcodereview.com/3.9.html#396) ++ GitHub Enterprise [3.14.0](https://help.github.com/enterprise-server@3.14/admin/release-notes#3.14.0), +[3.13.3](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.3), +[3.12.8](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.8), +[3.11.14](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.14), +[3.10.16](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.16) ++ GitLab [17.3.1, 17.2.4, 17.1.6](https://about.gitlab.com/releases/2024/08/21/patch-release-gitlab-17-3-1-released/), +[17.3](https://about.gitlab.com/releases/2024/08/15/gitlab-17-3-released/), +[17.2.2, 17.1.4, 17.0.6](https://about.gitlab.com/releases/2024/08/07/patch-release-gitlab-17-2-2-released/) ++ GitKraken [10.2.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.3](https://desktop.github.com/release-notes/) ++ git-credential-oauth [0.13.2](https://github.com/hickford/git-credential-oauth/releases/tag/v0.13.2), +[0.13.1](https://github.com/hickford/git-credential-oauth/releases/tag/v0.13.1) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Štěpán Němec, Brandon Pugh, Ralf Steube +and Toon Claes. diff --git a/_posts/2024-09-30-edition-115.markdown b/_posts/2024-09-30-edition-115.markdown new file mode 100644 index 000000000..b1d7fba87 --- /dev/null +++ b/_posts/2024-09-30-edition-115.markdown @@ -0,0 +1,454 @@ +--- +title: Git Rev News Edition 115 (September 30th, 2024) +layout: default +date: 2024-09-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 115 (September 30th, 2024) + +Welcome to the 115th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of August and September 2024. + +## Discussions + +### General + +* [Git Merge 2024 conference](https://git-merge.com/) and [Contributor's Summit 2024](https://lore.kernel.org/git/Zu2DmS30E0kKug2a@nand.local/) + + The Git Merge conference happened on + [September 19th and 20th](https://github.com/git/git-merge) in + Berlin, hosted by [GitButler](https://gitbutler.com/) and + [GitHub](https://github.com/). + + The first day consisted of + [talks](https://github.com/git/git-merge#day-one-talks) and an + afterparty in the evening sponsored by + [GerritForge](https://www.gerritforge.com/). + + On the [second day](https://github.com/git/git-merge?tab=readme-ov-file#day-two-unconference), + there was [the Contributor's Summit](https://lore.kernel.org/git/Zu2DmS30E0kKug2a@nand.local/) in parallel + with [breakout unconference sessions](https://github.com/git/git-merge/tree/main/breakouts). + +* [Git participated in GSoC (Google Summer of Code) 2024](https://summerofcode.withgoogle.com/programs/2024/organizations/git) + + All the contributors have successfully passed their final evaluation + and published a final report: + + - Jialuo She [worked](https://luolibrary.com/) on the + [Implement consistency check for refs](https://summerofcode.withgoogle.com/programs/2024/projects/ukm4PTEF) + project. He was mentored by Karthik Nayak and Patrick Steinhardt. The final + report can be found on + [his website](https://luolibrary.com/2024/08/25/GSoC-Final-Report/). + + - Chandra Pratap [worked](https://chand-ra.github.io/) on the + [Move and improve reftable tests in the unit testing framework](https://summerofcode.withgoogle.com/programs/2024/projects/tlh611d7) + project. He was mentored by Patrick Steinhardt and Christian Couder. The final + report can be found on + [his website](https://chand-ra.github.io/2024/08/24/GSoC-Final-Report.html). + + - Ghanshyam Thakkar [worked](https://spectre10.github.io/posts/) on the + [Move existing tests to a unit testing framework](https://summerofcode.withgoogle.com/programs/2024/projects/e9C4rhrv) + project. He was mentored by Christian Couder and Kaartic Sivaraam. The final + report can be found on [his website](https://spectre10.github.io/posts/gsoc_final_report/). + + Congratulations to the contributors and their mentors! + +* Git will [participate in the next Outreachy round](https://www.outreachy.org/communities/cfp/git/) + + Git applied to participate in the next + [Outreachy](https://www.outreachy.org/) round from December 2024 to + March 2025 and was accepted. + [Two projects](https://www.outreachy.org/apply/project-selection/#git) + are proposed: + + - "Convert unit tests to use the clar testing framework" which will + be mentored by Patrick Steinhardt and Phillip Wood. + + - "Finish adding a 'os-version' capability to Git protocol v2" + which will be mentored by Christian Couder. + + See this [Outreachy webpage](https://www.outreachy.org/docs/applicant/) + for more information about the application process for contributors. + +### Reviews + +* [[PATCH] tests: drop use of 'tee' that hides exit status](https://lore.kernel.org/git/xmqq4j7uhfvm.fsf@gitster.g/) + + Junio Hamano, the Git maintainer, sent a patch removing uses of the + `tee` command from test scripts. + [tee(1)](https://en.wikipedia.org/wiki/Tee_(command)) is a shell + command that duplicates its input to both its output and to one or + more files. The issue was that in some test scripts it was used + after a [pipe](https://en.wikipedia.org/wiki/Pipeline_(Unix)) to + directly duplicate the output of a Git command, so using a format + like: + + `git COMMAND OPTIONS... | tee FILE...` + + However, it's not a good idea to use a pipe after a Git command because + pipes discard the exit code of the command before them, so the + standard (Unix) shell behaviour is that the exit code of the whole + sequence is simply the exit code of the last command of a pipe sequence, + here `tee`. In Git tests though, we wouldn't want a test + to pass if the Git command fails when it should succeed. + + \[For shell intimates: there are ways to override this default behaviour, + such as [the `pipefail` option](https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_09_02), + or [named pipes](https://en.wikipedia.org/wiki/Named_pipe), but + there are a number of reasons, like shell portability and making + it easy to understand small parts of the code, why Git developers + try to avoid using those features in the Git codebase.\] + + As there was no reason to hide the exit code of the Git commands in + the tests that used `tee`, Junio's patch basically just replaced + `| tee` with a simple `>` + [redirection](https://en.wikipedia.org/wiki/Redirection_(computing)). + + Rubén Justo replied to Junio suggesting a wording improvement in the + commit message, but otherwise agreeing with the patch. + + Johannes Schindelin, alias Dscho, also replied to Junio saying that + having something that duplicates the output of the Git command to + standard output could still be useful for debugging, especially when + dealing with CI failures. He showed an implementation of a + `redirect_and_show()` helper function that could perhaps be used + instead of `tee`, but agreed that it might be overkill and hoped that + having more unit tests written in C could help. + + Jeff King, alias Peff, replied to Dscho saying that a better help + for debugging CI failures might be to have a way to automatically + save the state of the test directory, called + `trash directory.tXXXX-YYYY` where `tXXXX-YYYY` is related to the + name of the test script. + + Junio also replied to Dscho saying that a simple `cat FILE` + instruction could be added after the lines where `| tee` was + replaced with a redirection to make sure the Git command output + appeared on standard output. Junio also agreed with Peff that saving + the state of test directories would be best to debug CI failures. + + A version of Junio's patch taking into account the wording + improvement suggested by Rubén was eventually merged. + + + +## Developer Spotlight: Jialuo She + +_Editor's note: We're starting a new initiative in Git Rev News where + we interview recent GSoC/Outreachy students to get their reflections + on completing their projects. Feel free to share any thoughts or + feedback you might have!_ + +* Who are you and what do you do? + + My name is Jialuo She. I find it quite challenging to select an English + name for myself, so I decide to leave it as is. However, you can simply + call me "Luo(/lwɔː/)". I am currently employed at NVIDIA as a Tegra + System Architect. In this role, I am responsible for developing the + verification infrastructure for complex full-chip features, such as + CPU-GPU cache coherency. So my daily job is unrelated to Git. In my + spare time, I continue my GSoC work to + [implement consistency checks for refs](https://summerofcode.withgoogle.com/programs/2024/projects/ukm4PTEF). + +* How did you initially become interested in contributing to Git, + and what motivated you to choose it as your GSoC project? + + When I was a student, I read [the book "Pro Git"](https://git-scm.com/book/en/v2) + to learn how to use Git in my daily development process. One day, I + found [a tutorial](https://www.leshenko.net/p/ugit/) that teaches + how to write a mini Git step by step, and I really appreciated the + design of Git. + + As I was approaching my graduate school graduation, I hoped to use the + opportunity provided by GSoC to do something meaningful for the long + term. Since I felt that I had an understanding of Git's internal + principles, believing that my chances of being selected would be much + higher. When I saw the "Implement consistency check for refs" project, + I became very interested and resolutely chose Git. + +* How do you balance your contributions with other responsibilities + like work or school? + + As a newcomer, contributing to Git can be particularly time-consuming + due to unfamiliarity with the overall codebase. I would dedicate an + evening to responding to review feedback, which forces me to think + about how to make improvements, and then I would code over the weekend. + Of course, if there were urgent situations at work or life, I would have + to postpone my contributions to Git. I feel there's no need to think + about balancing because it happens naturally. + +* What was your biggest takeaway or learning from GSoC that you now + apply regularly in your work? + + After participating in GSoC, I begin to consider whether my commit + sequence is clear and understandable when writing code at work. I also + become more stringent with myself regarding commit messages, ensuring + they clearly explain the background, motivation, and implementation + details. + +* What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it? + + When building the ref consistency check infrastructure, I encountered + an exceptionally long review process that lasted about three months. + It was quite frustrating because there was no positive feedback compared + with other participants. Then I reflected on myself, wondering why I + was always comparing myself to others instead of focusing on what I was + doing. So, I adjusted my mindset. + +* Have you thought about mentoring new GSoC students? + + If I have the opportunity and time, I would definitely mentor GSoC + students. I am very grateful to my mentors, Patrick and Karthik, for + introducing me to the Git community and enabling me to continue + contributing after completing GSoC. I hope that one day I can also + ignite the passion in others. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + The write and read support for symlink symrefs. + +* What is your favorite Git-related tool/library, outside of Git + itself? + + I very much like the [GitLens tool](https://gitlens.amod.io/) when using + VSCode. By using this tool, I hardly use the bare `git blame` command. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + When reviewing patches, I will firstly use [`b4`](https://b4.docs.kernel.org/en/latest/) + or simply fetch the branch stored in Junio's tree, and then I will + see the diffs just in the VSCode. To reply to a patch, I download the + raw email and use [`mutt`](http://www.mutt.org/) to write contents. + When sending patches, I still use `mutt` to make the environment as + simple as possible to improve efficiency. + + I develop Git using VSCode and the [clangd](https://clangd.llvm.org/) + language server. I generate the `compile_commands.json` file using + `compiledb make`. I believe this is one of the best development + approaches available today, offering excellent code suggestions, + completions, and static analysis. + +* How do you envision your own involvement with Git or other open + source projects in the future? + + I hope to complete the implementation of all ref consistency checks. + Additionally, I aim to further familiarize myself with the Git codebase + related to refs, follow the development of the reftable backend, and + participate in more reviews. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + In my opinion, the barrier to starting contributions to Git is relatively + high because Git doesn't have something like "good first issue" labels. + Therefore, I believe the best approach is to participate in mentoring + programs or continue work from certain mentoring programs as a student. + +* Would you recommend other students or contributors to participate in + the GSoC, or other mentoring programs, working on Git? Why? Do you + have advice for them? + + I highly recommend that students integrate into the Git community + through mentoring programs. These programs provide basic ideas to help you + get started and contribute to Git. Working on Git is an amazing experience, + allowing you to be guided by many experienced contributors, improve your + code quality standards, and enhance your communication skills. + + As for advice to participants, I believe the most important thing is not to + think of the project merely as a resume booster. Instead, let your passion + shine through and stay at the community after mentoring programs. + + +## Other News + +__Various__ ++ [Radicle 1.0](https://radicle.xyz/2024/09/10/radicle-1.0.html).
+ Radicle is a peer-to-peer, local-first code collaboration stack built on Git. + [Radicle](https://radicle.xyz/) was first mentioned in + [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/), + then in [Edition #70](https://git.github.io/rev_news/2020/12/26/edition-70/), + [#86](https://git.github.io/rev_news/2022/04/30/edition-86/), + and [#110](https://git.github.io/rev_news/2024/04/30/edition-110/) - where one + can find similar and related tools. ++ [git-scm.com is now a static website](https://lore.kernel.org/all/ZvrNmsycmamx2dcR@nand.local/t/#m72b3c0f77102fe9964e77d6c10d9166485e13c0e) + by Johannes Schindelin on the Git mailing list.
+ Moving git.github.io, Git Developer Pages and Git Rev News' website + into git-scm.com is discussed in [GitHub issue #729](https://github.com/git/git.github.io/issues/729). + +__Light reading__ ++ [Why GitHub Actually Won](https://blog.gitbutler.com/why-github-actually-won/): + How GitHub _actually_ became the dominant force it is today, from one of its cofounders. + Written by Scott Chacon on GitButler Blog.
+ Nice companion to various articles on Git history, like the latest + [A Git story: Not so fun this time](https://git.github.io/rev_news/2024/07/31/edition-113/) + in [Git Rev News #113](https://git.github.io/rev_news/2024/07/31/edition-113/) - in #113 you + can also find links to other editions with links to other retellings of the Git history. ++ [Rethinking code reviews with stacked PRs](https://www.aviator.co/blog/rethinking-code-reviews-with-stacked-prs/#) + on Aviator blog by Ankit Jain (also available [on DEV\.to](https://dev.to/dphenomenal/rethinking-code-reviews-with-stacked-prs-3dih), + published by Ibrahim Salami. Aviator provides [`av`](https://github.com/aviator-co/av), a CLI tool + to help with managing stacked PRs on GitHub. + + Stacked Pull Requests, also under the name Stacked Diffs, + were most recently mentioned in + [Git Rev News Edition #111](https://git.github.io/rev_news/2024/05/31/edition-111/), + where you can find links to other editions with other articles, and to related tools. + + See also [Stacked PRs CLI Product Comparison (Public)](https://docs.google.com/spreadsheets/d/1riYPbdprf6E3QP1wX1BeASn2g8FKBgbJlrnKmwfU3YE/edit?gid=0#gid=0) + Google Sheet spreadsheet. + + Contrast [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html), + which strongly recommends patterns that are best suited to Continuous Integration, + first mentioned in [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/), + and [Ship / Show / Ask: A modern branching strategy](https://martinfowler.com/articles/ship-show-ask.html), + mentioned in [Edition #79](https://git.github.io/rev_news/2021/09/30/edition-79/). ++ [Git With Python HowTo: GitPython Tutorial And PyGit2 Tutorial](https://grimoire.carcano.ch/blog/git-with-python-howto-gitpython-tutorial-and-pygit2-tutorial/) + by Marco Antonio Carcano on his blog 'The grimoire of a modern Linux professional'. ++ [Beyond “Commit” and “Push”: 5 Advanced Git Features You Should Know](https://www.git-tower.com/blog/5-advanced-git-features) + by Bruno Brito on GitTower Blog. + Covers git-bisect, git-rerere, gitattributes, git-notes, and git-worktree. ++ [Mastering Tower (Windows Edition)](https://www.git-tower.com/blog/mastering-tower-windows) + and [Mastering Tower (Mac Edition)](https://www.git-tower.com/blog/mastering-tower/) + by Bruno Brito on GitTower Blog. Tower is a proprietary Git client for Mac and Windows, + with 30-day free trial. ++ [Git bisect run techniques](https://paperless.blog/git-bisect-run-techniques) + by Victor Engmark on paperless\.blog. ++ [Semantic Versioning with GitVersion (GitFlow)](https://blog.raulnq.com/semantic-versioning-with-gitversion-gitflow) + by Raul Naupari on his blog; Featured on daily\.dev, also available + [on DEV\.to](https://dev.to/raulnq/semantic-versioning-with-gitversion-gitflow-1gb4). ++ [Host your own Radicle seed node](https://edzz.de/posts/host-your-own-radicle-seed-node/) + by Eduard on Ed's Site. Also available [on DEV\.to](https://dev.to/viiik/how-to-host-your-own-radicle-node-contribute-to-decentralized-source-control-5cgm). ++ [Creating a Git commit: The Hard Way](https://avestura.dev/blog/creating-a-git-commit-the-hard-way) + (with low-level plumbing commands) by Aryan Ebrahimpour + on Avestura's Personal Website. ++ [My Git cheatsheet](https://write.as/pylapp/my-git-cheatsheet) - a list + of some useful commands, as a cheatsheet or a simple reminder to keep and share. + Written by Pierre-Yves Lapersonne on his French and English pylapp blog in the fediverse (write\.as). + + + + +__Git tools and sites__ ++ [b4](https://github.com/mricon/b4) is a tool created to make it easier + for project developers and maintainers to use a distributed development + workflow that relies on patches, e-mail and distribution lists for code + contributions and review (like those used in Linux kernel development). + This tool was first mentioned in [Git Rev News Edition #61](https://git.github.io/rev_news/2020/03/25/edition-61/); + you can find links to various articles and posts about this tool + in [Edition #61](https://git.github.io/rev_news/2020/03/25/edition-61/), + [#91](https://git.github.io/rev_news/2022/09/30/edition-91/), + [#95](https://git.github.io/rev_news/2023/01/31/edition-95/), + [#107](https://git.github.io/rev_news/2024/01/31/edition-107/) and + [#109](https://git.github.io/rev_news/2024/03/31/edition-109/). + Written in Python, under GPL-2.0 license. ++ [Phabricator.KDE.org](http://phabricator.kde.org/) is KDE's desktop environment task management system. + It was used for patch review and other functions in the past, but KDE has since transitioned to GitLab, + at . Bug tracking is done using . + Phabricator is still used for task tracking by KDE until this functionality is migrated to GitLab. + + [Phabricator](https://www.phacility.com/phabricator/) is/was a suite + of web-based development collaboration tools, which includes a code review tool called Differential, + a repository browser called Diffusion, a change monitoring tool called Herald, + a bug tracker called Maniphest, and a wiki called Phriction.
+ Phabricator is [no longer actively maintained](https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/) + by Phacility since June 1, 2021. This tool was mentioned + in [Git Rev News Edition #13](https://git.github.io/rev_news/2016/03/16/edition-13/). + Written in PHP, under Apache 2.0 license. + + [Phorge](https://we.phorge.it/) is a community-maintained fork of Phabricator, + public [since Sep 7, 2022](https://we.phorge.it/phame/post/view/1/going_public/). + It seems to be actively developed. ++ [nb-clean](https://github.com/srstevenson/nb-clean) cleans Jupyter notebooks + of cell execution counts, metadata, outputs, and (optionally) empty cells, + preparing them for committing to version control. + Written in Python, under short ISC license. ++ [av](https://github.com/aviator-co/av) (Aviator) is a command-line tool + that helps you manage your stacked PRs on GitHub. + Written in Go, under MIT license. ++ [Stacked PRs CLI Product Comparison (Public)](https://docs.google.com/spreadsheets/d/1riYPbdprf6E3QP1wX1BeASn2g8FKBgbJlrnKmwfU3YE/edit?gid=0#gid=0) + is a Google Sheet spreadsheet by Aviator, listing various stacked PR/stacked diff tools: + + [ghstack](https://github.com/ezyang/ghstack) in Python, + + [gh-stack](https://github.com/timothyandrew/gh-stack) in Rust - no longer developed, + + [git-branchless](https://github.com/arxanas/git-branchless) in Rust + (mentioned in [Git Rev News Edition #76](https://git.github.io/rev_news/2021/06/27/edition-76/), + [#90](https://git.github.io/rev_news/2022/08/31/edition-90/), + [#93](https://git.github.io/rev_news/2022/11/30/edition-93/), + [#98](https://git.github.io/rev_news/2023/04/30/edition-98/), + and [#106](https://git.github.io/rev_news/2023/12/31/edition-106/)), + + [git-branchstack](https://github.com/krobelus/git-branchstack) in Python, + + [git-chain](https://github.com/dashed/git-chain) in Rust, + + [git-machete](https://github.com/VirtusLab/git-machete) in Python + - also available as a [plugin](https://github.com/VirtusLab/git-machete-intellij-plugin) + for the IntelliJ Platform products, + + [git-ps-rs - Git Patch Stack](https://github.com/drewdeponte/git-ps-rs) in Rust, + + [git-series](https://github.com/git-series/git-series) in Rust + (first mentioned in [Git Rev News Edition #18](https://git.github.io/rev_news/2016/08/17/edition-18/), + with a link to the presentation in [#19](https://git.github.io/rev_news/2016/09/14/edition-19/)), + + [git-stack](https://github.com/gitext-rs/git-stack) in Rust, + + [graphite-desktop](https://github.com/withgraphite/graphite-desktop) + (formerly [graphite-cli](https://github.com/withgraphite/graphite-cli)) + in JavaScript/TypeScript - no longer actively developed, + + [Sapling SCM](https://github.com/facebook/sapling) Git-compatible source control system + by Facebook (mentioned in [Git Rev News Edition #93](https://git.github.io/rev_news/2022/11/30/edition-93/)), + + [spr](https://github.com/ejoffe/spr) - Stacked Pull Requests on GitHub, in Go, + + [Stacked Git (StGit)](https://stacked-git.github.io/) in Rust + (mentioned in Git Rev News Edition [#17](https://git.github.io/rev_news/2016/07/20/edition-17/), + [#21](https://git.github.io/rev_news/2016/11/16/edition-21/), + and [#74](https://git.github.io/rev_news/2021/04/30/edition-74/), + and finally presented as a tool in [#93](https://git.github.io/rev_news/2022/11/30/edition-93/)). ++ [degit](https://github.com/Rich-Harris/degit) is a CLI tool + that makes copies of Git repositories faster than ordinary `git clone`. + Supports GitHub, GitLab, Bitbucket, and Sourcehut (sr\.ht). + Written in JavaScript for Node.js, under MIT license. ++ [GitVersion](https://gitversion.net/) is a tool that generates + a [Semantic Version](https://semver.org/) number based on your Git history. + Available as Continuous Server pipeline, CLI tool, MSBuild task, and software library. + Written in C#, under MIT license. Works on Windows, Linux, and Mac. ++ [ugit: DIY Git in Python](https://www.leshenko.net/p/ugit/) is a tutorial on Git internals, + where you learn about how Git works on the inside by trying to implement + (micro) Git in Python. + + +## Releases + ++ Git [2.47.0-rc0](https://public-inbox.org/git/xmqqv7yijq33.fsf@gitster.g/), +[2.46.2](https://public-inbox.org/git/xmqqa5fyytg0.fsf@gitster.g/), +[2.46.1](https://public-inbox.org/git/xmqqikuytbxd.fsf@gitster.g/) ++ Git for Windows [2.47.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.47.0-rc0.windows.1), +[2.46.2(1)](https://github.com/git-for-windows/git/releases/tag/v2.46.2.windows.1), +[2.46.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.46.1.windows.1) ++ GitHub Enterprise [3.14.1](https://help.github.com/enterprise-server@3.14/admin/release-notes#3.14.1), +[3.13.4](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.4), +[3.12.9](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.9), +[3.11.15](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.15), +[3.10.17](https://help.github.com/enterprise-server@3.10/admin/release-notes#3.10.17) ++ GitLab [16.10.10, 16.9.11, 16.8.10, 16.7.10, 16.6.10, 16.5.10, 16.4.7, 16.3.9, 16.2.11, 16.1.8, 16.0.10](https://about.gitlab.com/releases/2024/09/25/patch-release-gitlab-16-10-10-released/), +[17.4.1, 17.3.4, 17.2.8](https://about.gitlab.com/releases/2024/09/25/patch-release-gitlab-17-4-1-released/), +[17.4](https://about.gitlab.com/releases/2024/09/19/gitlab-17-4-released/), +[17.3.3, 17.2.7, 17.1.8, 17.0.8, 16.11.10](https://about.gitlab.com/releases/2024/09/17/patch-release-gitlab-17-3-3-released/), +[16.11.9](https://about.gitlab.com/releases/2024/09/11/gitlab-16-11-9-released/), +[17.0.7](https://about.gitlab.com/releases/2024/09/11/gitlab-17-0-7-released/), +[17.3.2, 17.2.5, 17.1.7](https://about.gitlab.com/releases/2024/09/11/patch-release-gitlab-17-3-2-released/) ++ GitKraken [10.3.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.5](https://desktop.github.com/release-notes/), +[3.4.4](https://desktop.github.com/release-notes/) ++ Garden [1.8.0](https://github.com/garden-rs/garden/releases/tag/v1.8.0) ++ Git Cola [4.8.2](https://github.com/git-cola/git-cola/releases/tag/v4.8.2) ++ GitButler [0.12.26](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.12.26), +[0.12.25](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.12.25) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Jialuo She, Josh Steadmon and Štěpán Němec. diff --git a/_posts/2024-10-31-edition-116.markdown b/_posts/2024-10-31-edition-116.markdown new file mode 100644 index 000000000..d32904ea5 --- /dev/null +++ b/_posts/2024-10-31-edition-116.markdown @@ -0,0 +1,406 @@ +--- +title: Git Rev News Edition 116 (October 31st, 2024) +layout: default +date: 2024-10-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 116 (October 31st, 2024) + +Welcome to the 116th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of September and October 2024. + +## Discussions + + + + + +### Support + +* [fatal from `submodule status --recursive` when used with `grep -q`](https://lore.kernel.org/git/CAKDm0rNaHbzoiPg=DeuCoxzooNAsxw2BJfc0wg7fC_-=o9uJ7w@mail.gmail.com/) + + Matt Liberty reported that when he tried using + `git submodule status --recursive | grep -q "^+"` on a repo with + a submodule, he got an error message like "fatal: failed to recurse + into submodule XXX", where XXX is the name of the submodule. + + He expected no error message, no output and a 0 exit code from the + whole command line as it should have succeeded. He guessed that Git + didn't like that `grep` when used with `-q` exits immediately + (without printing anything) when there is a match. + + Phillip Wood replied to Matt saying he assumed that `grep`'s exit + broke the pipe between `git` and `grep`, so `git` received a + `SIGPIPE` signal which killed it. Phillip suggested consuming the + whole output from Git if the exit code from it was wanted. + + Matt replied to Phillip that he was interested in the exit code from + `grep`, not from `git`, and that Git shouldn't output any error when + its output is connected to a pipe that gets broken, in the same way + as the `yes` command, for example, doesn't output any error when + piped to `grep -q y`. + + Junio Hamano, the Git maintainer, also replied to Phillip's first + message that the error Git emitted in such a case wasn't useful to + the user. + + Matt replied to Junio that he thought no error at all should be + emitted as most Unix tools don't output any error. + + Then Phillip replied to Matt's first reply to him. He asked if all + Matt wanted was that `git submodule status` did not print any error + message when it receives a `SIGPIPE` signal. Matt replied that he + wanted both no error message and a 0 exit code from it. + + Junio replied to Matt that it was reasonable to ask for no error + message, but it should be OK if the exit code was related to the + `SIGPIPE` message that the Git command received and that killed + it. Junio used the example that even `yes` exited with code 130 when + killed using the Control-C keys on a terminal. + + The exit code associated with a signal is '128 + the signal number', + for example as the Control-C keys send a `SIGINT` signal, whose signal + number is 2, processes killed this way should exit with code '128 + 2', + so 130. + + Eric Sunshine replied to Junio that it wasn't clear how the exit + code from Git was important in the discussion as in the original + command line, Git appears before the pipe, so its exit code might be + lost. + + Matt replied to Eric that the exit code mattered if the `pipefail` + shell option was used. + + Phillip replied to Matt suggesting he remap the exit code + associated with `SIGPIPE`, which is 141 (128 + 13), to 0, if he was + using `pipefail` but still wanted a 0 exit code. Phillip also gave + an example shell function to help with that remapping, and sent + [a first version of a patch](https://lore.kernel.org/git/pull.1799.git.1726837642511.gitgitgadget@gmail.com/) + to fix the error message. + + Junio reviewed that patch and found that it was unnecessarily + including the "signal.h" system header. + + Phillip fixed that issue in + [version 2 of the patch](https://lore.kernel.org/git/pull.1799.v2.git.1726925150113.gitgitgadget@gmail.com/) + which was merged and part of Git v2.47.0. + + +## Developer Spotlight: Chandra Pratap + +_Editor's note: Just like in our previous edition, we return with another + GSoC retrospective interview in this issue. We hope the reflections shared + by GSoC students will provide an insightful perspective that benefits + the community. As always, we welcome your thoughts and feedback!_ + +* Who are you and what do you do? + + Hey! I am Chandra Pratap (prefer going by Chand) and I am an + undergraduate student of Mathematics at SVNIT, Surat, India. I have + a passion for everything computing and like to solve leetcode-styled + problems in my free time or contribute to open-source software. + +* How did you initially become interested in contributing to Git, and + what motivated you to choose it as your GSoC project? + + C was the first programming language that I learnt, and I wanted to + try working on a non-trivial software project. I watched a YouTube + video on open source and that’s where I got the idea of looking for + open-source projects to contribute to. Git and VLC were the only + open-source C-written software that I was familiar with and used in + day-to-day life, so I decided to start contributing to Git out of the two. + By the time GSoC came around, Git was the only open-source + community that I was familiar with, so I decided to choose it as my + GSoC organization. + +* How do you feel your contribution has impacted the Git community + or the broader open-source ecosystem? + + [My project](https://summerofcode.withgoogle.com/programs/2024/projects/tlh611d7) + was about moving and improving reftable tests, so I think + my contributions made life somewhat easier for other Git hackers, + especially those who frequent the reftable sub-project. My project + didn’t really affect any user-facing aspect of Git, so I don’t think it had + a huge impact on the broader open-source ecosystem, besides the + fact that it gained another lifelong contributor. + +* Is there any aspect of Git that you now see differently after having + contributed to it? + + Everything, to be honest. Working on and with Git for the duration of + my project completely changed my mental model for the tool. Before + GSoC, Git was a clunky tool reserved for software development work + but post-Git, I know the most frequent commands like the back of my + hand, and I’ve already used Git to version control many of my non-software + files. I feel like I’ve learnt enough Git to last my entire career. + +* How do you balance your contributions with other responsibilities like + work or school? + + I had summer vacation for the entire duration of GSoC and no other work + commitments, so I had no problems finding time for my GSoC project. + +* Can you share how GSoC helped enhance your technical and non-technical + skills (like communication, project management, etc.)? + + In terms of technical skills, I think my C and Git skills saw the biggest jump. + I am a lot more comfortable working with those two tools than when I + was pre-GSoC. Besides that, I’m a lot less scared of the command line + now. In terms of non-technical skills, I believe I’ve gotten a lot better at + composing mails and communicating with other professionals. I’ve learnt + to write with the right amount of professionalism, so I don’t appear too + uptight or too lax, the right way to respond to constructive feedback, how + to time my schedule to fit with others’, especially those living in other + parts of the globe, and how to ask good questions. + +* What was your biggest takeaway or learning from GSoC that you now + apply regularly in your work? + + I’d say the biggest takeaway from GSoC for me was that it is normal for + everyone to face difficulties when trying to learn a new codebase, tool, etc, + or even a different part of the same codebase. It is important to persevere + and not be afraid of asking questions to achieve the desired results. Other + than that, I’ve learnt a lot about good practices in software development, + like appropriately splitting commits and writing good commit messages, + that I subconsciously incorporate in my work now. + +* What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it? + + The biggest challenge in contributing to Git was the initial phase of + getting involved. I remember starting out working on a small patch for + about 2 months with a lot of help from other contributors before it got + accepted into Git’s upstream. After a few initial contributions, I grew more + confident and could steadily find things to work on and produce + acceptable results. The key to overcoming this challenge was to be + persistent and patient, and not being afraid of asking silly questions. + +* Have you thought about mentoring new GSoC students? + + I’m not sure about being a full-on mentor, but I’d love to co-mentor + any future GSoC student(s) interested in working on the reftable + project. + +* If you could get a team of expert developers to work full time on + something in Git for a full year, what would it be? + + The [Git GUI](https://git-scm.com/docs/git-gui) tool. I believe that + would make Git far more accessible than it currently is and get it + incorporated in a lot more people’s day-to-day works. + +* If you could remove something from Git without worrying about + backwards compatibility, what would it be? + + The packed-refs format for refs seems redundant to me now that + reftable is a core part of Git. + +* What is your favourite Git-related tool/library, outside of Git itself? + + [GitGitGadget](https://gitgitgadget.github.io/) was a lifesaver when + I had just started contributing to Git, so that is probably my favourite + Git related tool. + +* What is your toolbox for interacting with the mailing list and for + development of Git? + + I used Git’s `send-email` to send patches to the mailing list (especially + the `--compose` and `--annotate` flags) and Gmail’s online client to + convey non-patch mails. For developing Git, I used Vim as the editor + on an Ubuntu machine and Git as the version control software (duh). + +* How do you envision your own involvement with Git or other + open-source projects in the future? + + I plan on making small contributions to Git from time to time, since I + cannot find enough time for larger patches. Other than that, I’ll try to + volunteer as a Git mentor for future GSoC or Outreachy cohorts. + Regarding other open-source projects, I’ll try contributing to them when + I learn a new technology and want a real-world experience. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + Go through Git’s [‘My First Contribution tutorial’](https://git-scm.com/docs/MyFirstContribution) + for the initial setup and to get an idea of what’s it like + to work on Git. Then work on a few ‘microprojects’ ([more information on + the Git Developer's website](https://git.github.io/General-Microproject-Information/)) + to dip your toes in the Git Development community. From there, you + can figure out interesting stuff to work on by yourself. + +* Would you recommend other students or contributors to participate in + the GSoC, or other mentoring programs, working on Git? Why? Do you + have advice for them? + + Yes. I believe that Git is a tool that every working professional can find + useful regardless of whether they work in the software industry or not, + and working on Git through an open-source program is an excellent way + to get good at it in a short period of time. There’s also the added benefit + of joining a large and active community of amazingly experienced + developers who can teach you a lot about writing software, and the + software development workflow in general. + + I think the key to getting selected as a participant in GSoC or other + mentoring programs is getting involved as early as possible. The more + time you allow yourself to get familiar with Git’s codebase and + development workflow, the easier it becomes to find an apt project and + write a reasonable proposal for it. Also, the initial phase of contributions is + the most difficult part of getting involved with an open-source project, so it + is better to allow yourself ample time to tackle that initial hurdle. + + +## Other News + +__Various__ ++ [Highlights from Git 2.47](https://github.blog/open-source/git/highlights-from-git-2-47/) + by Taylor Blau on GitHub Blog. Includes features like incremental multi-pack indexes, + `%(is-base:)` atom for `git for-each-ref` (see also the [Brooke Kuhlmann article](https://alchemists.io/articles/git_for_each_ref), mentioned below), + the new “[Platform Support Policy](https://github.com/git/git/blob/v2.47.0/Documentation/technical/platform-support.txt)” document, + `git mergetool` directly supporting Visual Studio Code merge tool, and others. ++ [What's new in Git 2.47.0?](https://about.gitlab.com/blog/2024/10/07/whats-new-in-git-2-47-0/) + by Justin Tobler on GitLab Blog. Highlights include + `init.defaultRefFormat` configuration option that can be set to use `reftable` backend + (see [Beginner's guide to the Git reftable format](https://about.gitlab.com/blog/2024/05/30/a-beginners-guide-to-the-git-reftable-format/)), + `init.defaultObjectFormat` configuration option that can be set to `sha256`, + `git refs verify`, and others. ++ Tower is running a [Git GUIs User's Survey](https://gittower.typeform.com/git-survey) + for people who do not 100% of the time use Git in the terminal. + + +__Light reading__ ++ [How Typefully Uses Tower [Git GUI Client] to Conquer Social Media Publishing](https://www.git-tower.com/blog/how-typefully-uses-tower) + by Bruno Brito on Tower Blog. ++ [Moving all our Python code to a monorepo: pytendi](https://attendi.nl/moving-all-our-python-code-to-a-monorepo-pytendi/). ++ [Bruno — An API Client Using Git to Fight for Developer Experience](https://www.git-tower.com/blog/bruno-api-client-using-git/) + by Ryan Reynolds on Tower Blog. ++ [Using Git as Your Personal To-Do List](https://dev.to/munemprionto/using-git-as-your-personal-to-do-list-3kkd) + by Munem Prionto on DEV\.to - more as a way of learning Git by the way of managing + a TODO list, rather than for practical reasons. + + Contrast with [Using Git to Manage Todos](https://jezenthomas.com/2015/10/using-git-to-manage-todos/) + by Jezen Thomas (2015), mentioned in [Git Rev News Edition #9](https://git.github.io/rev_news/2015/11/11/edition-9/), + which is about using Git to help manage TODO or FIXME comments in the codebase + (assuming that for example your IDE does not have a plugin for managing TODOs). + + One can also consider using a CLI tool that stores data in plain text files + for managing TODOs, like [Taskwarrior](https://taskwarrior.org/). Plain text + files work well with Git. ++ [Git For Each Ref](https://alchemists.io/articles/git_for_each_ref) + by Brooke Kuhlmann in Alchemists Collective articles. + Learn how to use this command to make use of references + for information dumping, statistics, and much more. + Included in this article is use of the new `is-base` field name recently added in + [Git 2.47.0](https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.47.0.adoc). ++ [Searching for and navigating Git commits](https://alexharri.com/blog/searching-and-navigating-git-commits) + by Alex Harri on his blog. ++ [Why some of us like "interdiff" code review](https://gist.github.com/thoughtpolice/9c45287550a56b2047c6311fbadebed2) + by Austin Seipp (a Gist). Describes problems with the UI of multi-commit GitHub Pull Requests + for responding to reviewer comments by providing a new version of the patch series, + and how `git range-diff` and interactive rebase can help with this task. ++ [How I Review GitHub PRs](https://www.bitquabit.com/post/how-i-do-github-prs/) + by Benjamin Pollack on bitquabit. + + ++ [Python PGP proposal poses packaging puzzles](https://lwn.net/Articles/993787/) + by Joe Brockmeier on LWN\.net - [Sigstore](https://docs.sigstore.dev/) vs [OpenPGP](https://www.openpgp.org/). + Sigstore was mentioned in [Git Rev News Edition #91](https://git.github.io/rev_news/2022/09/30/edition-91/) + and [#111](https://git.github.io/rev_news/2024/05/31/edition-111/). ++ [A look at the aerc mail client](https://lwn.net/Articles/993498/) + by Joe Brockmeier on LWN\.net. + + + +__Scientific papers__ ++ Tsukasa Yagi, Shinpei Hayashi: _"Toward Interactive Optimization of Source Code Differences: + An Empirical Study of Its Performance"_, + [arXiv:2409.13590](https://arxiv.org/abs/2409.13590), + with dataset at (but no source code). + + It is based on a prior study: + Nugroho, et al.: _"How different are different diff algorithms in Git?: + Use --histogram for code changes"_ (2019), + + +__Git tools and sites__ ++ [Reviewing git contributions via email](https://git-am.io/) () + is a companion piece to [interactive guide on sending patches with git send-email](https://git-send-email.io/) + (); the latter was mentioned in + [Git Rev News Edition #50](https://git.github.io/rev_news/2019/04/26/edition-50/) + [#68](https://git.github.io/rev_news/2020/10/30/edition-68/), and + [#92](https://git.github.io/rev_news/2022/10/26/edition-92/). ++ ["Data Management" section of Awesome MLOps](https://github.com/kelvins/awesome-mlops#data-management) + also includes tools related to versioning data like + + [Dolt](https://github.com/dolthub/dolt) ([Git Rev News #62](https://git.github.io/rev_news/2020/04/23/edition-62/)), + + [DVC](https://dvc.org/) (first mentioned in [Git Rev News #42](https://git.github.io/rev_news/2018/08/22/edition-42/), + then in [#63](https://git.github.io/rev_news/2020/05/28/edition-63/), + [#64](https://git.github.io/rev_news/2020/06/25/edition-64/), + [#100](https://git.github.io/rev_news/2023/06/30/edition-100/), + [#107](https://git.github.io/rev_news/2024/01/31/edition-107/), and + [#113](https://git.github.io/rev_news/2024/07/31/edition-113/), + among others), + + [Dud](https://kevin-hanselman.github.io/dud/), improving on DVC, but with narrowed scope, + + [Intake](https://intake.readthedocs.io/) ([Git Rev News #96](https://git.github.io/rev_news/2023/02/28/edition-96/)), + + See also the discussion in issue #337 in the Intake repository: + [Data versioning/validation: Comparing Intake with DVC, Quilt and Great Expectations](https://github.com/intake/intake/issues/337) + + [lakeFS](https://lakefs.io/) ([Git Rev News #78](https://git.github.io/rev_news/2021/08/31/edition-78/)), + + [Quilt](https://www.quiltdata.com/) / [Quilt Data](https://www.quiltdata.com/) + ([Git Rev News #99](https://git.github.io/rev_news/2023/05/31/edition-99/)). ++ [git-task](https://github.com/jhspetersson/git-task) is + a local-first task manager/bug tracker that stores everything within your git repository, + and which can sync issues to/from GitHub or GitLab. + Written in Rust, under MIT license. ++ [Bruno](https://www.usebruno.com/) is a fast and Git-friendly open-source API client, + similar to Postman, Insomnia and similar tools. It stores collections directly + in a folder on your filesystem in a plain text markup language, Bru. + + Compare with [Simple Web Application Test (SWAT)](https://github.com/melezhik/swat), + web application oriented testing framework, with test plan stored as plain text files + in specially named directories. + +## Releases + ++ Git [2.47.0](https://public-inbox.org/git/xmqqa5fg9bsz.fsf@gitster.g/), +[2.47.0-rc1](https://public-inbox.org/git/xmqqploiphj3.fsf@gitster.g/) ++ Git for Windows [2.47.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.47.0.windows.2), +[2.47.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.47.0.windows.1), +[2.47.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.47.0-rc1.windows.1) ++ libgit2 [1.8.4](https://github.com/libgit2/libgit2/releases/tag/v1.8.4), +[1.8.3](https://github.com/libgit2/libgit2/releases/tag/v1.8.3) ++ GitLab [17.5.1, 17.4.3, 17.3.6](https://about.gitlab.com/releases/2024/10/23/patch-release-gitlab-17-5-1-released/), +[17.5](https://about.gitlab.com/releases/2024/10/17/gitlab-17-5-released/), +[17.4.2, 17.3.5, 17.2.9](https://about.gitlab.com/releases/2024/10/09/patch-release-gitlab-17-4-2-released/) ++ Gerrit Code Review [3.10.2](https://www.gerritcodereview.com/3.10.html#3102), +[3.8.9](https://www.gerritcodereview.com/3.8.html#389), +[3.9.7](https://www.gerritcodereview.com/3.9.html#397) ++ GitHub Enterprise [3.14.2](https://help.github.com/enterprise-server@3.14/admin/release-notes#3.14.2), +[3.13.5](https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.5), +[3.12.10](https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.10), +[3.11.16](https://help.github.com/enterprise-server@3.11/admin/release-notes#3.11.16) ++ GitKraken [10.4.1](https://help.gitkraken.com/gitkraken-client/current/), +[10.4.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.8](https://desktop.github.com/release-notes/), +[3.4.7](https://desktop.github.com/release-notes/), +[3.4.6](https://desktop.github.com/release-notes/) ++ Garden [1.9.0](https://github.com/garden-rs/garden/releases/tag/v1.9.0), +[1.8.0](https://github.com/garden-rs/garden/releases/tag/v1.8.0) ++ git-credential-oauth [0.13.3](https://github.com/hickford/git-credential-oauth/releases/tag/v0.13.3) ++ GitButler [0.13.8](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.13.8), +[0.13.7](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.13.7), +[0.13.6](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.13.6) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Chandra Pratap, Brooke Kuhlmann, +Štěpán Němec and Brandon Pugh. diff --git a/_posts/2024-11-30-edition-117.markdown b/_posts/2024-11-30-edition-117.markdown new file mode 100644 index 000000000..339c2010f --- /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](https://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..d0e657914 --- /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](https://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..1237e9b80 --- /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](https://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..bd98b1bbc --- /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](https://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..b01f0f903 --- /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](https://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..f2c402768 --- /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](https://git.github.io). + +This edition covers what happened during the months of March and April 2025. + +## Discussions + +### General + +* [Let's celebrate Git's 20th anniversary this coming Monday!](https://lore.kernel.org/git/89757bec-4d7e-1d90-5697-44651c6128df@gmx.de/) + + Johannes Schindelin (alias Dscho) posted on the mailing list that + the oldest Git commit was performed on April 7th, 2005. So Monday + April 7th, 2025 was the 20th anniversary of Git! + + To celebrate this event, Dscho created + [a channel on Git's Discord, called `#20th-anniversary`](https://discord.gg/UcjvsNQR) + where everyone is welcome, especially to talk about their encounter + with Git. + +* [[ANNOUNCE] Git Merge 2025, September 29-30, San Francisco, CA](https://lore.kernel.org/git/Z+L3Mt58n18KUNzs@nand.local/) + + Taylor Blau announced a new [Git Merge 2025](https://git-merge.com) + conference on September 29-30 at GitHub HQ in San Francisco along + with a Contributor's Summit on September 30. + + Registration and a Call for Proposals, which closes on May 13th, are + open. Requests for financial assistance with travel costs can be + sent to the Git PLC at . + +* [Patch (apply) vs. Pull](https://lore.kernel.org/git/1119284365.3926.15.camel@localhost.localdomain/) + + To celebrate Git's 20th anniversary in our own way let's talk about + a discussion on the Git mailing list that happened nearly 20 years + ago. + + On June 20, 2005, Darrin Thompson sent an email about a discrepancy + he was perceiving between his mental model of how Git worked and a + common practice he observed on mailing lists. + + He understood that on one hand Git was about people duplicating + locally the remote history they were interested in, which provided + common points in history that enabled "intelligent merging", while + on the other hand mailing lists were filled with emailed patches. + + He asked how the patches were created and handled to ensure they + could be properly dealt with by the receivers and those who would + later pull from those initial receivers. + + He was basically trying to reconcile the patch-based workflow on + mailing lists with Git's design, especially its merging philosophy + based on a common history. + + Junio Hamano, who would later become the Git maintainer, then + replied to Darrin acknowledging that emailed patches were essentially + "out of band" communications. Merges could still work if the same + patch had been applied independently. Even if that wasn't ideal, it + was "manageable". + + Junio then described his workflow, which consisted of regularly + pulling from Linus, discarding his HEAD, using Linus' HEAD instead, + and reapplying onto it some patches that Linus had rejected but he + still considered good. Then he would work on new changes and commit + them on top. + + Darrin, questioning this approach, asked for ways to manage patches + as a series of commits, and wondered if that would still allow + cherry-picking patches. + + Then Daniel Barkalow and Catalin Marinas chimed in + to talk about [StGit (Stacked Git)](https://stacked-git.github.io/) + which helps manage Git commits as a stack of patches. Catalin + Marinas was the creator of StGit, which seems to still be developed + these days as there was a 2.5.0 release in January 2025. + + Daniel suggested integrating functionality similar to StGit into Git + to help with applying patches and bridging the gap between the + patch-based workflow and Git's commit-based model in general, even + though he thought that commits were "fundamentally resistant to + cherry-picking". + + Catalin over the course of the discussion provided specific details + about how StGit could address Junio's workflow. For example, StGit + would automatically detect when a patch was already merged upstream + and warn the user. It could also handle conflicts during the + reapplication process using `diff3`. + + Catalin also mentioned that StGit would soon support pulling changes + from a remote tree along with patch series information, making it + easier to apply patches from different branches. + + Meanwhile, Linus also replied to the email where Junio described his + workflow, proposing "a different kind of merge logic" to automate + some of the steps, as individual developers often want to move their + work forward to the current tip, instead of merging it. The new + script would "try to re-base all the local commits from the common + parent onwards on top of the new remote head". + + Linus showed some steps that the script would perform, some of them + using a new `git-cherry-pick` script that "basically takes an old + commit ID, and tries to re-apply it as a patch (with author data and + commit messages, of course) on top of the current head". + + Then Linus, Junio and Daniel discussed how to implement this. One + problem appeared to be how to automatically detect patches that had + already been merged even where there were small changes, like typo + fixes or whitespace changes, in the patches. + + Daniel suggested that authors could give an ID that would be + preserved across various later modifications to each of their + patches. Linus didn't like this idea because he thought that they + could be useful for specific projects but should be tracked outside + of Git. Inside Git, he thought they could create confusion as it + wouldn't be clear if a patch has been modified or not. + + Daniel then asked Linus if he actually modified patches before + applying them. Linus replied that he very often did modify them and + that he absolutely didn't want to apply them first and then modify + them as he didn't want "crap" in his code. He further elaborated + that his `git-apply` tool was strict and refused to apply patches + with any 'fuzz' (mismatched context lines), only allowing patches + that matched exactly, potentially after adjusting for line number + offsets. He said: + + "So I want things to be cleaned up before they hit the tree, rather + than have a really dirty history. A dirty history just makes it + harder to read, and I don't believe in a second that it's 'closer to + reality' like some people claim." + + "I don't believe anybody wants to see the 'true' history. If they + did, we'd be logging keystrokes, and sending all of that + around. Nope, people want (and need, in order to be able to follow + it) an 'idealized' history." + + Martin Langhoff also contributed to the discussion, noting that + rebasing and replaying local history was an approach he had used + successfully with [Arch](https://en.wikipedia.org/wiki/GNU_arch). He + suggested that the rebasing process should be restartable after + encountering a failed cherry-pick, and proposed adding features like + a "skip list" for patches already merged upstream and a `--stop-at` + option to handle batches of commits incrementally. + + Daniel and Linus continued to discuss practical ways to identify and + manage patches across repositories. Linus proposed hashing the + actual changes in a patch, ignoring line numbers and whitespace, + rather than relying on explicit IDs or commit metadata. He + implemented this idea in the form of a `git-patch-id` and tested it + on the Linux kernel repository where it found 15 duplicate patches + in the kernel history and processed around 2788 patches in under a + minute with no false positives. + + Junio replied with a series of three patches to the email where + Linus had suggested some steps that the script to re-base all the + local commits would perform. The cover letter of his series was + named "Rebasing for 'individual developer' usage". + + The first patch added a `-m` flag to the `git-commit-script` which + allowed committing using the commit message and author information + from an existing commit. + + The second patch implemented a new `git-cherry` script to find + commits that are in the current branch but not in another branch, so + it can help find commits that haven't been merged upstream. + + The third patch implemented a new `git-rebase-script` that used the + functionality from the two previous patches to actually implement + rebasing. + + + + + +## Community interview + +_Editor note: For Git's 20th anniversary, we are doing an exclusive collaborative +community interview and curating answers of various community members. Also, +there's a [short Q&A](#short-qa-with-our-maintainer-junio-c-hamano) with our +zealous, inclusive and tireless maintainer that follows below._ + + +- **What's your favorite Git trick or workflow that you wish more people + knew about?** + + [_Thalia Rose_][thalia]: For rebase-heavy workflows, `git range-diff` is incredibly + useful. To compare against upstream, use `git range-diff @{u}...@`, + and to compare against the previous HEAD, use `git range-diff @{1}...@`. + + [_Lucas Seiki Oshiro_][seiki]: Everything related to code archaeology + (`git grep`, `git log -S/-G`, `git log -L` and `git bisect`). Those are + my primary debugging tools and every time I explained them to other + people they find them mind-blowing and useful. + And they also started loving it :-) + + [_Elijah Newren_][elijah]: [`range-diff`][range-diff]. The ideas behind + it ought to be the basis for code review, IMO. Commits should be the + unit of review (including commit messages as a fundamental and primary + thing to be reviewed), and a series of commits should be the unit of + merging. I dislike most code review tools, because they get one or + both of those things wrong. Getting both of those things right naturally + leads to `range-diff` or something like it being a very important part + of the workflow, at a minimum for detecting which commits in a series + are unmodified and which have been updated and need to be further reviewed. + + +- **What was your worst Git disaster, and how did you recover from it?** + + [_Thalia Rose_][thalia]: When I was first starting with Git, I wanted to make a repo + to preserve my first coding project when I was twelve, a bunch of VBS scripts. + I had assumed that Git maintained file modification timestamps, so I deleted + the originals because they were now redundant. I now no longer know exactly + when I wrote them and have been careful about timestamps ever since. + + [_Luca Milanesio_][luca]: I suspect to be one of the worst offenders :-) [ [ref](https://www.infoq.com/news/2013/11/use-the-force) ] + + Thankfully I was using Gerrit Code Review and the replication plugin: + the refs were not lost but just rewind and we could reset all the + correct SHA1s for all of them. + + [_Lucas Seiki Oshiro_][seiki]: I don't remember something that I did, + but I remember a simple and curious disaster: our deploy workflows + stopped working, only leaving a message like "cannot fetch + ambiguous reference `master`". I decided to investigate what happened + and I found out that someone by mistake (I don't know how) created a + tag called `master` and pushed it to GitHub. By the time we used the + `master` branch for deploy, and the workflows didn't know if they + should use the `master` branch or tag. GitHub didn't have a feature + for deleting tags through the web interface, so we thought + "what should we do?". + + The solution was to run `git push origin :refs/tags/master`. Simple, + but not obvious. A classic case where it only required a screw to be + turned, but all the hard work was to find which screw should be turned. + + [_Elijah Newren_][elijah]: + My worst Git-related disaster wasn't with Git directly but with our + Git hosting software we used at a prior job, Gerrit. 'twas a + "startup" that was still forming good practices. We had both a + production and a staging instance. The staging instance was seeded + with a copy of production data so we could do scale testing...but that + seeding process was a multi-step manual thing; it hadn't been + automated. One step was, as best I recall, "drop database gerrit", + followed by loading the production copy of the mysql database (this + was long before [NoteDB][notedb] arrived). And as many readers + probably have guessed by now, I was on the wrong host one day when + I ran that command. + + The actual git repositories were still intact, but the review metadata + was toast. Luckily, we had a backup from about 7 hours earlier, so we + could recover the older review metadata and with some hackery fix the + mysql metadata mismatch with the newer repository contents. And since + Gerrit emailed folks comments from reviews as they were posted, we + could tell people to look at their emails for the pieces we couldn't + recover. + + It was a really long night trying to fix things. Some folks told me + they thought I was going to throw up just looking at me. But I + learned how wonderful it was to be at a company with blameless + post-mortems, and I appreciated the many folks who reached out to tell + me stories of mistakes they had made. They were more interested in + whether we learned our lesson and put processes into place to prevent + repeats, and I definitely did both. + + I did, of course, also get some good-natured ribbing, such as people + saying I got to play the part of little Bobby Tables once (see + [this xkcd comic][bobby-tables] if you don't know that reference). + I kindly reminded them that I didn't drop a table -- I dropped the whole + database (plus, it wasn't injection, it was just running a command in + the wrong location). Also, one of my colleagues helpfully modified + the prompt on production to be red and bold, "This is PROD Gerrit", + and the prompt on staging to be green, "This is staging Gerrit; it's + okay to drop database here!" The prompts ended up not mattering since + I automated the process, and made sure the process just error'ed out + if run on prod instead of staging. But the prompt persisted for many + years anyway, because I thought it was a hilarious way to poke fun at + my blunder. + + +- **If you could go back in time and change one design decision in Git, + what would it be?** + + [_Luca Milanesio_][luca]: Use SHA-256 straight away, as it was + published 24 years ago and already existed at the time Git was designed. + + [_Lucas Seiki Oshiro_][seiki]: Perhaps writing a more abstract CLI. After + studying Git a little more deeper it makes sense for me, but I would group + the functionality into more high-level subcommands and would make the flags + and options more consistent across the subcommands. + + For example, Docker CLI have all the image operations under + `docker image` and all the network operations under `docker network`. + If I want to delete an image, I use `docker image rm`, if I want to + delete a network, I use `docker network rm`, and so on. I would make + Git CLI work based on that idea, for example: + + - `git branch add my_branch` + - `git branch delete my_branch` + - `git branch list` + - `git remote add my_remote ...` + - `git remote delete my_remote` + - `git remote list` + - `git tag add my_tag` + - `git tag delete my_tag` + - `git tag list` + + With some shorter alias, just like Docker has `docker rmi` and + `docker rm`. + + [_Elijah Newren_][elijah]: The index. For a few reasons. + + 1. Performance. + 1. The index is pervasive throughout the codebase, and while it works + great for small repositories, it means that many operations are O(size + of repository) instead of O(size of changes). [sparse indices][sparse-index] + help, but the code has to be carefully audited for sparse indices to + work with each codepath, and even then there tends to be a fallback of + just-load-everything-anyway because the data structure doesn't lend + nicely to just expanding a little more. + + 2. An under-appreciated aspect of the performance improvements that + came from our new merge strategy, [`merge-ort`][merge-ort], were due + to dispensing with the index as the primary data structure. The index + had two problems: + 1. first of all it meant loading every path in the repository, + which would have prevented ort's optimization to avoid recursing into + subtrees when unnecessary (an optimization that often made merges e.g. + 50x faster). Sparse indices didn't exist back then, but even if they + had we would have had to complicate them significantly in order to + have their sparseness be determined by renames and the intersection of + modified paths on the two sides of history instead of having + sparseness determined by user-defined path rules; I think that'd have + been much more complicated than just dispensing with the index as the + data structure, but we didn't even have sparse indices back then + anyway. + + 2. Second, the use of the index as done in the old merge strategy, + `merge-recursive`, resulted in O(N^2) behavior since entries (including + conflicted higher order stages) had to be inserted in sorted order. + Deleting entries didn't have the same O(N^2) problem due to some + tricks to queue the deletion for later, but attempting to do the same + for insertions was far from straightforward and I believe would have + required making some other data structure primary and then forming the + index at the end. (Note that the primary data structure used, whatever + it is, cannot just have a list of things to insert, it also needs to + be checked for various properties intermingled with insertions...and + those sometimes relied on the fact that the index was sorted for quick + lookups.)

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

+ But slicing and dicing before things are committed, as opposed to + being able to slice and dice after, is a choice that adds a lot of + complexity to the user interface and does so even for users who aren't + interested in slicing and dicing commits. We don't have a + sufficiently flexible set of tooling for slicing and dicing commits + after-the-fact within git to switch to a post-commit-slice-and-dice + workflow even today, but I suspect that some of the ideas from [JJ][jujutsu] + would or could be much better than the methods I use today in git to + slice and dice commits. + + +- **Which Git feature or improvement over the past 20 years do you think + had the biggest impact on your workflow?** + + [_Lucas Seiki Oshiro_][seiki]: Sorry, but I can't answer. I am from a + generation that started programming when Git was already the de facto + VCS so I can't compare a world that has it with a world that doesn't have. + + [_Elijah Newren_][elijah]: Speed. + + Being able to instantly switch branches (in smaller repos, sure, but + CVS and SVN couldn't pull it off even in small repos) was a game + changer. + + +- **What Git problem that existed 10 years ago has been most + successfully solved?** + + [_Lucas Seiki Oshiro_][seiki]: Sorry again, but 10 years ago I was only + starting to use Git and when I started to use more complex features they + already were there. + + [_Elijah Newren_][elijah]: Merging and rebasing with lots of renames + (and generally merging without a worktree or index). I'm obviously + a bit biased on this point, but that doesn't mean I'm wrong. ;-) + It used to be awful and works great now. + + Relatedly, merging without a worktree or index was problematic; you + had to either use an alternative merge strategy with limited + capabilities, or use something other than git (e.g. [libgit2][libgit2]). + But now git handles it well with its default merge strategy. + + +- **Which Git commands or workflows do you think are still misunderstood + or underutilized today?** + + [_Lucas Seiki Oshiro_][seiki]: I think [squash merges][squash-merge] and + [submodules][submodule] are really misunderstood, yet they are the opposite + of being underutilized. Sadly I saw several people using them in daily basis, + based on the wrong idea of what they are and then using them incorrectly. + + + What I think is underutilized is the full power of commits being + a good source of documentation and good resource for, again, performing + code archaeology that may help understanding what the code does and + debugging it. Several developers treat the commits as just checkpoints. + + [_Elijah Newren_][elijah]: `range-diff` is very under-utilized, but I + already discussed that above. + + +- **What's one Git based project, tool, or extension you think deserves + more recognition from the community?** + + [_Lucas Seiki Oshiro_][seiki]: Perhaps it would be better to leave this + question for other less known tools. But if you want an answer, I think: + + - [Delta](https://github.com/dandavison/delta) is a really cool tool + for formatting the diff-related outputs; + + - [Kworkflow](https://kworkflow.org/) is a powerful tool for + contributing to the Linux kernel source code (I should also + try it for contributing to the Git source code); + + - Merge drivers in general. `diff3` works in most cases but it is + only based on pure diffs, without performing deeper operations based + on the file format they are merging. + + +- **What Git feature or capability surprised you most when you first + discovered it?** + + [_Lucas Seiki Oshiro_][seiki]: As you may have noticed, I'm really + a fan of Git archaeology :-), so I would say all that I mentioned + in the first answer (i.e., `git grep`, `git log -S/-G`, `git log -L` + and `git bisect`). But my favorite is still [bisect][bisect]. + It's an egg of Columbus and everyone that I have shown it to + was equally amazed by it! + + +- **What's your boldest prediction about how version control might look + in another 20 years?** + + [_Lucas Seiki Oshiro_][seiki]: I still see Git as the dominant VCS + in the future, but I think more Git-based VCSs (like [Jujutsu][jujutsu] + will arise. Just like we have today programming languages built on top + of the stack of the other languages (e.g. Clojure, Kotlin and Scala on + JVM, TypeScript on JS), networking protocols written on top of other + protocols (e.g. QUIC on UDP, gRPC on HTTP) and so on. + + The Git core is simple, flexible, transparent and powerful and there's + still room for people using it directly in several creative ways. Once + I saw [a project using it as a backend for a NoSQL database][git-backend-nosql], + who knows how many use cases we still have for it. + + [_Elijah Newren_][elijah]: I'm more interested in what storms might be + brewing along that path, and what we might be able to do to avoid them. + In particular, some questions and observations in that area: + + * With monorepos growing ever larger, do we have hard-to-workaround-or-fix + design decisions that pose scaling challenges? e.g. + * the index data structure + * per-directory .gitignore files, per-directory .gitattribute files, etc. + * ...or do the prominent Git forges have hard-to-workaround-or-fix + design decisions that'll give Git a reputation for not scaling? e.g. + * making refs/pull/NNN/merge a public ref and excessively + implicitly updating it + * Will we face a crisis of interest? e.g. + * `git` is currently written in C. Even if that's not a liability + already, coupled with "decades" I think it is. Young developers + probably don't want to learn C, and older ones who already know C + may worry about C becoming a Fortran or Cobol. + * Companies employing Git developers think "git already won" and + redeploy those engineers on other problems + * Will the combination of issues above result in folks who want improvements + deciding their best bet is not improving Git but in creating/funding + an alternative? Will that snowball? + +
+ To me, the entry of new projects like [JJ][jujutsu] and [sapling][sapling] + suggest the above are real concerns already rather than just theoretical. + Both projects have compelling things that git lacks. I like the friendly + competition, and the JJ and sapling developers are awesome to talk to + at Git Merge conferences. But there is a risk that this friendly + competition mirrors that of Git and Mercurial from years past, and + that Git at some future point down the road ends up on the other side + of that history and gets largely displaced by the alternatives. I'd + rather not see that happen, but I sometimes wonder if we're taking + enough measures to avoid marching towards such an outcome. + + +[thalia]: https://discord.com/channels/1042895022950994071/1361310935427584213/1361316878819131452 +[luca]: https://public-inbox.org/git/04A328E9-1146-4D4A-84E7-456FFEB66A5A@gmail.com/ +[seiki]: https://public-inbox.org/git/AE27429C-97B1-4226-8F30-5B635A050498@gmail.com/ +[elijah]: https://public-inbox.org/git/CABPp-BH2yH4iJ28Bo7Q=uryu68LLk7a0Tvb2SzAbAiHK8QpRug@mail.gmail.com/ +[squash-merge]: https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---squash +[submodule]: https://git-scm.com/docs/git-submodule +[bisect]: https://git-scm.com/docs/git-bisect +[range-diff]: https://git-scm.com/docs/git-range-diff +[sparse-index]: https://git-scm.com/docs/sparse-index +[merge-ort]: https://git-scm.com/docs/merge-strategies#Documentation/merge-strategies.txt-ort +[jujutsu]: https://github.com/jj-vcs/jj?tab=readme-ov-file#introduction +[git-backend-nosql]: https://www.kenneth-truyers.net/2016/10/13/git-nosql-database +[notedb]: https://www.gerritcodereview.com/notedb.html +[bobby-tables]: https://xkcd.com/327/ +[libgit2]: https://libgit2.org/ +[sapling]: https://sapling-scm.com/ + + +### Short Q&A with our maintainer, Junio C Hamano + +- **Looking back over ~20 years of maintaining Git, what has been the + most surprising or unexpected evolution in the project — technically + or community-wise?** + + Technically, one of the things I found surprising is how many lines + from Linus's original version still survive in today's codebase. The + [initial version of Git](https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290) + was 1244 lines spread across 11 files, which is miniscule compared + to 300+ thousands of lines in 4600+ files in v2.49.0, but it is not + fair to say Linus's original genius is less than 0.3% of what we have. + If you try running `git blame` in reverse, you'll see that about 10% + of lines we have in our tree came from the original version Linus + released 20 years ago. You can check out a + [little script called "Linus"](https://git.kernel.org/pub/scm/git/git.git/tree/Linus?h=todo) + out of my "todo" branch and run it to see for yourself. + + Community-wise, there weren't many things that surprised me. I + expected a bit more developers who are interested in the core part of + system to stick around, say for more than 10 years, and I hoped that + some of them would be from younger generations who have never seen any + version control system other than Git, but how many among the active + contributors we see on the list every week fall into that category? We + have long-timers who are respected in the community, but we want to + grow that pool by say 5 every year or so, some of them ready to stick + around for another 10 years. In [a recent interview](https://github.blog/open-source/git/git-turns-20-a-qa-with-linus-torvalds/), + Linus said he wanted somebody with good taste who sticks around, and + I do believe it is essential to have a sufficient number of long-timers + who can guide new folks into the community. + + So that is a bit of surprise that makes me a little sad, but at the + same time, I think what is happening is that a development community + of an extremely popular and successful system that is mature with + friendly atmosphere has attracted many aspiring new folks, they + scratch their own itches and have fun, but then they find more + interesting things to do and go back to be happy end-users, which is + totally expected and natural thing. + +- **What are your thoughts about AI-assisted development tools in the + context of Git? Do you see a place for Git itself to become more + "intelligent"?** + + I've kept saying that + + is one of the most important design discussion in the early days of + Git. In that article, Linus outlines how his "ideal" SCM tool would + let you follow the history of a single function in today's codebase + backwards, notice that at certain revision the function appeared, but + the tool finds five functions disappeared in the same revision, all + looking very similar to the function we are interested in that was + added there, and the tool can explain that the commit consolidated + duplicated reimplementations done in various subdirectories into a + single common function and adjusted the existing callers of them to + the SCM user (if you want to learn more details, go to the original + and read it twice, I'll wait). + + We can do `git log -S` repeatedly to drill + down the history to find the revision that introduced that new + (possibly consolidated) function. In fact, the `-S` feature + was invented exactly for the purpose of serving as the first step of + Linus's "ideal" SCM tool described in the article. But "finding + similar existing (and possibly getting lost) code in the same or + possibly nearby revisions" have been nebulous. I do not think anybody + in the Git circle tried it yet. I wonder, after 20 years, perhaps we + can feed a project's codebase to LLMs and let them figure out such a + fact? + +- **What's your boldest prediction about how version control might look in + another 20 years?** + + I do not even foresee what software development in 20 years would look + like. I am not an insight kind of person. + +- **What advice would you give to someone who might one day step into your + role as Git maintainer?** + + Be original. I didn't aim to duplicate the style Linus ran his tree + during the first four months of the project. My successor does not + have to duplicate my style of running the project, either. Having said + that, personally I would like to see more distribution of + responsibility. The maintainer may play a role of the final arbiter, + but it would be great if we can come up with a mechanism to allow list + participants to bear more of the burden of picking and choosing good + direction to go, deciding if a particular change is worth doing or + are there better ways to do the same thing, etc. I've been trying to + nudge the list discussions in that direction for the past few years, + but without much success, I think. + + +## Other News + +__Various__ + +* [Git turns 20: A Q&A with Linus Torvalds](https://github.blog/open-source/git/git-turns-20-a-qa-with-linus-torvalds/) + by Taylor Blau on GitHub blog. +* [Celebrating Git's 20th anniversary with creator Linus Torvalds](https://about.gitlab.com/blog/2025/04/07/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/) + by Patrick Steinhardt on GitLab blog. +* [Linus Torvalds built Git in 10 days - and never imagined it would last 20 years](https://www.zdnet.com/article/linus-torvalds-built-git-in-10-days-and-never-imagined-it-would-last-20-years/) + by Steven Vaughan-Nichols on ZDNet. +* [20 years of Git. Still weird, still wonderful.](https://blog.gitbutler.com/20-years-of-git/) + by Scott Chacon on Butler's Log (GitButler). +* [Journey through Git's 20-year history](https://about.gitlab.com/blog/2025/04/14/journey-through-gits-20-year-history/) + by Patrick Steinhardt on GitLab blog. +* [GitHub MCP Server is now available in public preview](https://github.blog/changelog/2025-04-04-github-mcp-server-public-preview/). + [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction) + is an AI tool calling standard that gives LLMs (Large Language Models) + a standardized way to call functions, look up data, and interact with the world. + + +__Light reading__ + +* [Verifying tricky git rebases with git range-diff](https://andrewlock.net/verifiying-tricky-git-rebases-with-range-diffs/) + by Andrew Lock on his .NET Escapades blog. +* [Mirroring my git repositories](https://dustri.org/b/mirroring-my-git-repositories.html) + using [cgit](https://git.zx2c4.com/cgit/about/) for the interface and nginx as a web server. + By Julien (jvoisin) Voisin on their blog. +* [Mirroring my Repositories from GitHub to GitLab](https://cleberg.net/blog/git-mirror.html), + including both public and private repositories on GitLab Free tier. + By Christian Cleberg on his blog. +* [Documentation as Code with AsciiDoctor, GitLab CI, and GitLab Pages](https://jensknipper.de/blog/gitlab-ci-pages-asciidoc-documentation-as-code/) + by Jens Knipper on his personal blog. +* [Afraid to Git](https://dammit.nl/afraid-to-git.html): + a rant by Michiel Scholten on his dammIT blog, explaining how misbehaving AI scrapers + cause him not to put his Gitea instance (his Git server) on the Internet, + and force others - like [Linux' kernel.org](https://git.kernel.org/) - to use tools like [Anubis](https://github.com/TecharoHQ/anubis). +* [Fedora change aims for 99% package reproducibility](https://lwn.net/Articles/1014979/) + by Joe Brockmeier on LWN\.net. +* [How to Exclude Commits from Git Blame](https://www.git-tower.com/blog/how-to-exclude-commits-from-git-blame) by Bruno Brito on Tower's blog. + + +__Easy watching__ + +* [Two decades of Git: A conversation with creator Linus Torvalds](https://www.youtube.com/watch?v=sCr_gb8rdEI) + video interview (YouTube, 41:49). + + +__Git tools and sites__ + +* [Devlands](https://devlands.com/) is the game that creates immersive experience + to help learning Git. Created by Jacob Stopak, the author of the [Git-Sim](https://github.com/initialcommit-com/git-sim) + tool to visualize Git commands directly in your own repo, which was first mentioned + in [Git Rev News Edition #95](https://git.github.io/rev_news/2023/01/31/edition-95/). + Described in [I struggled with Git, so I'm making a game to spare others the pain](https://initialcommit.com/blog/im-making-a-git-game) + article on Initial Commit Blog. +* [Git Game Show](https://justinpaulson.github.io/git_game_show/) is a text interface app + that transforms your project's Git commit history into a live, multiplayer trivia game. + One user hosts a session, other players join remotely, and the system rotates + through rounds of different question-based "mini-games," awarding points + and declaring a final winner. +* [dgit](https://manpages.debian.org/testing/dgit/dgit.1.en.html) is a tool that + allows you to treat the Debian archive as if it was a Git repository. + Conversely, it allows Debian to publish the source of its packages as Git branches, + in a format which is directly useable by ordinary people. + * Note that GitHub's Spokes system that stores multiple distributed copies + of Git repositories was once called DGit. See the [Stretching Spokes](https://github.blog/engineering/infrastructure/stretching-spokes/) + article by Michael Haggerty on GitHub Blog mentioned in + [Git Rev News Edition #14](https://git.github.io/rev_news/2016/04/20/edition-14/). +* [Mega](https://github.com/web3infra-foundation/mega) + is an unofficial open source implementation of Google Piper (a proprietary, massive, + centralized version control system that Google uses internally to manage their vast codebase). + It is a monorepo & monolithic codebase management system that supports Git. + More information can be found in [Why Google Stores Billions of Lines of Code in a Single Repository](https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext). + Written in Rust and TypeScript. +* [Oshit aka Oshiro's git](https://github.com/lucasoshiro/oshit): VCS written in Haskell + that tries to be compatible with Git. This is not safe to use, + and is only meant for learning how Git works and how hard it is. +* [codeowner-filter](https://kertal.github.io/codeowner-filter/) is a simple web tool + that solves the problem of finding just the files your team owns based + on the contents of [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) file. + It will generate search filters for VSCode, scope configuration for IDEA IDEs, and a list. +* [CodeOwners Filter](https://github.com/akowalska622/codeowners-filter) is a Visual Studio Code extension + that gives you a visual representation of the CODEOWNERS file + and helps you generate glob include patterns for any code owner. +* [rebuilderd](https://github.com/kpcyrd/rebuilderd) + is a tool that monitors the package repository + of a Linux distribution and uses rebuilder backends + like archlinux-repro to verify the provided binary packages + can be reproduced from the given source code. + Written in Rust, under GPL license. +* [reproduce](https://github.com/vltpkg/reproduce) is an open-source tool + designed to independently verify whether a published npm package + can be faithfully rebuilt from its declared source. + It is described in the [Reproducibility vs. Provenance: Trusting the JavaScript Supply Chain](https://blog.vlt.sh/blog/reproducibility) + blog post by Darcy Clarke. +* [Graft](https://graft.rs/) is an open-source transactional storage engine + designed for efficient data synchronization at the edge. + It is described in the [Stop syncing everything](https://sqlsync.dev/posts/stop-syncing-everything/) + article by Carl Sverre, his [Storing small things in big places](https://www.youtube.com/watch?v=eRsD8uSAi0s1) + Vancouver Systems talk (video on YouTube, 55:04), and his + [Building a serverless database replica with Carl Sverre](https://www.youtube.com/watch?v=dJurdmhPLH411) + High Performance SQLite talk (video on YouTube, 1:10:19). + Written in Rust. + + +## Releases + ++ GitHub Enterprise [3.16.2](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.2), +[3.15.6](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.6), +[3.14.11](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.11), +[3.13.14](https://docs.github.com/enterprise-server@3.13/admin/release-notes#3.13.14) ++ GitLab [17.11.1, 17.10.5, 17.9.7](https://about.gitlab.com/releases/2025/04/23/patch-release-gitlab-17-11-1-released/), +[17.11](https://about.gitlab.com/releases/2025/04/17/gitlab-17-11-released/), +[17.10.4, 17.9.6, 17.8.7](https://about.gitlab.com/releases/2025/04/09/patch-release-gitlab-17-10-4-released/), +[17.10.3](https://about.gitlab.com/releases/2025/04/02/gitlab-17-10-3-released/), +[17.9.5](https://about.gitlab.com/releases/2025/04/02/gitlab-17-9-5-released/) ++ Gerrit Code Review [3.12.0-rc0](https://www.gerritcodereview.com/3.12.html#3120), +[3.12.0-rc1](https://www.gerritcodereview.com/3.12.html#3120), +[3.12.0-rc2](https://www.gerritcodereview.com/3.12.html#3120), +[3.12.0-rc3](https://www.gerritcodereview.com/3.12.html#3120), +[3.12.0-rc4](https://www.gerritcodereview.com/3.12.html#3120) ++ GitHub Desktop [3.4.19](https://desktop.github.com/release-notes/) ++ GitButler [0.14.19](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.19), +[0.14.18](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.18) ++ Tower for Mac [13.0 (BETA)](https://www.git-tower.com/beta) ([Release blog post](https://www.git-tower.com/blog/tower-mac-13/)) + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Junio Hamano, Lucas Seiki Oshiro, +Luca Milanesio, Thalia Rose, Elijah Newren, +Toon Claes, Lee Reilly, Bruno Brito and Štěpán Němec. diff --git a/_posts/2025-05-31-edition-123.markdown b/_posts/2025-05-31-edition-123.markdown new file mode 100644 index 000000000..3f38199ff --- /dev/null +++ b/_posts/2025-05-31-edition-123.markdown @@ -0,0 +1,268 @@ +--- +title: Git Rev News Edition 123 (May 31st, 2025) +layout: default +date: 2025-05-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 123 (May 31st, 2025) + +Welcome to the 123rd edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of April and May 2025. + +## Discussions + +### General + +* [[GSoC] Welcoming our 2025 contributors and thanking our applicants](https://lore.kernel.org/git/A2C60325-F96A-49FC-8910-035BFC209EB5@gmail.com/) + + The Git project was accepted in the + [Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/) + this year again, and 3 applicants were selected: + + - Meet Soni will work on + [the "Consolidate ref-related functionality into git-refs" project](https://summerofcode.withgoogle.com/programs/2025/projects/xVrT5e2q) + mentored by Patrick Steinhardt and Jialuo She. See Meet's + [blog](https://inosmeet.github.io/posts/) and + [repository](https://github.com/inosmeet/git) for more. + + - Lucas Seiki Oshiro will work on + [the "Machine-Readable Repository Information Query Tool" project](https://summerofcode.withgoogle.com/programs/2025/projects/fGgMYHwl) + mentored by Karthik Nayak and Patrick + Steinhardt. See Lucas's [blog](https://lucasoshiro.github.io/en/) + and [repository](https://github.com/lucasoshiro/git) for more. + + - Ayush Chandekar will work on + [the "Refactoring in order to reduce Git’s global state" project](https://summerofcode.withgoogle.com/programs/2025/projects/no7dVMeG) + mentored by Christian Couder and Ghanshyam Thakkar. See Ayush's + [blog](https://ayu-ch.github.io/archive.html) and + [repository](https://github.com/ayu-ch/git) for more. + +### Reviews + +* [[PATCH] git: add `--no-hooks` global option](https://lore.kernel.org/git/pull.1899.git.1743719888430.gitgitgadget@gmail.com/) + + Derrick Stolee, who prefers to be called just Stolee, sent a patch + to the mailing list that added a new `--no-hooks` global option and + an equivalent `GIT_HOOKS` environment variable to Git. The goal was + to allow users to disable all Git hooks during command execution. + + This could be useful for expert users who would want to bypass + pre-commit hooks when they have poor performance or perform useless + checks. + + Switching between enabled and disabled hooks and other workarounds, + like setting `core.hooksPath` to a "bogus path", did not look + convenient and very safe. + + brian m. carlson, who spell their name using only lowercase letters, + replied to Stolee acknowledging the need for this functionality as + some Jenkins users already set `core.hooksPath` to `/dev/null` for + security reasons. They warned that disabling hooks could break + [Git LFS](https://git-lfs.com/) in a way that is "less noticeable + and detectable" than the current `/dev/null` approach. + + They agreed that certain hooks like pre-commit hooks should be + optional, for example to make it easy to commit some + work-in-progress that doesn't meet standards, but saw fewer reasons + to bypass hooks that could be important for repository integrity. + + Stolee agreed that some hooks are important for integrity, but said + his intention was on the side of optional hooks. + + Phillip Wood also replied to Stolee's initial email noting that + there is already `git commit --no-verify` which bypasses the + pre-commit and commit-msg hooks. He argued that hooks so slow that + users want to bypass them are self-defeating and that the solution + should be to fix the hook's performance rather than make it easier + to skip. About setting `core.hooksPath` to `/dev/null`, he asked why + it could be unsafe. In general he said he wasn't convinced that + `--no-hooks` was a good idea, and later asked for "a clearer + motivation" to better understand its usefulness. + + Stolee agreed that setting `core.hooksPath` to `/dev/null` was safe, + and said he had forgotten that could be used instead of a bogus + path. + + Junio Hamano, the Git maintainer, then replied to Phillip thanking + him for pushing back on the idea, and saying that there should be a + "compelling reason" to justify a change. + + Also instead of implementing options to disable hooks or + configuration in some user facing "porcelain" commands, Junio + advocated for cleaning up and refactoring these commands into new + stable "plumbing" commands designed to be easily used in scripts. + + In the meantime, Lucas Seiki Oshiro replied to Phillip. Lucas had + noticed that using `/dev/null` to disable hooks wasn't mentioned in + the documentation of `core.hooksPath`, even though it was tested in a + test script. He asked if Stolee's patch should therefore be turned + into a documentation patch. + + brian agreed with Lucas that documenting how to disable hooks was a + good idea even if the `--no-hooks` option wasn't implemented. + + D. Ben Knoble also replied to Stolee's initial patch. He supported + the addition of the `--no-hooks` option, sharing his own + frustrations with poorly performing or difficult-to-manage hooks. He + described how a tool re-enables hooks after every `npm install` + leading him to overuse `--no-verify`, which he considered a worse + situation. He believed there should be a safe and sane way to + disable optional client-side hooks and felt that a `--no-hooks` + option would be useful, potentially encouraging better practices + like moving certain checks to server-side hooks. + + Stolee then replied to Junio thanking him for deciding about this + and saying he would follow up with a version 2 of his patch that + would only document that setting `core.hooksPath` to `/dev/null` was + the supported mechanism to disable hooks. + + In [the version 2 of his patch](https://lore.kernel.org/git/pull.1899.v2.git.1744818135435.gitgitgadget@gmail.com/), + Stolee just updated the documentation of the `core.hooksPath` + configuration option, adding the following small paragraph: + + > You can also disable all hooks entirely by setting `core.hooksPath` + > to `/dev/null`. This is usually only advisable for expert users and + > on a per-command basis using configuration parameters of the form + > `git -c core.hooksPath=/dev/null ...`. + + Lucas replied to that new patch. He suggested rewording the + documentation to focus on non-expert users rather than + experts. Stolee disagreed, explaining he intentionally targeted + expert users as a "there be dragons here" warning about the risks of + disabling hooks. + + brian supported Stolee's approach, agreeing that this feature should + be presented as expert-only due to the potential for data loss (like + missing Git LFS uploads). He appreciated Stolee's gracious pivot + from code changes to documentation. + + Junio also thanked Stolee for gracefully changing direction and + ensuring no loose ends were left after abandoning the original + approach. + + + + + +## Other News + + + + +__Light reading__ + ++ [What I've learned from jj (Jujutsu)](https://zerowidth.com/2025/what-ive-learned-from-jj/) + by Nathan Witmer on zerowidth positive lookahead blog.
+ [Jujutsu](https://jj-vcs.github.io/) (`jj`) is an experimental Git-compatible DVCS, + first mentioned in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [Git aliases](https://heitorpb.github.io/bla/git-aliases/) + by Heitor de Bittencourt on Heitor's Log blog, + which includes comparison with shell aliases, + and is only missing the trick to set `git` completion for the `!` alias. ++ [Pushing a whole stack of branches with a single Git command](https://andrewlock.net/pushing-a-whole-stack-of-branches-with-a-single-git-command/) + (with the help of git aliases) + by Andrew Lock on .NET Escapades. ++ [Tally All Git Trailers in a Repository](https://calebhearth.com/tally-git-trailers.page), + with a list of interesting and useful trailers _(with many links)_, + by Caleb Hearth on his blog. ++ [You can use Git to version control your notes, and here’s how I do it](https://www.xda-developers.com/you-can-use-git-to-version-control-your-notes/) + by Ayush Pande on XDA Developers + (with Joplin as an example of a note-taking application one can use with Git). ++ [A Short Guide on Git for Vibe Coders](https://anfalmushtaq.com/articles/a-short-guide-on-git-for-vibe-coders) + by Anfal Mushtaq on his blog. ++ [Version Control To The Max](https://hackaday.com/2025/05/14/version-control-to-the-max/) + by Al Williams on Hackaday, + about backing up the entire development environment + (with QEMU or VirtualBox or VMWare). ++ [Converting a Git repo from tabs to spaces](https://eev.ee/blog/2016/06/04/converting-a-git-repo-from-tabs-to-spaces/) + with the help of the "filter" gitattribute and the `expand` tool (part of the _coreutils_), + by Eevee on Fuzzy Notepad blog (2016). ++ [How the GitHub CLI can now enable triangular workflows](https://github.blog/open-source/git/how-the-github-cli-can-now-enable-triangular-workflows/) + by Tyler McGoffin on GitHub Blog. ++ [Using `git-upload-pack` for a simpler CI integration](https://blog.screenshotbot.io/2025/05/09/using-git-upload-pack-for-a-simpler-ci-integration/), + on how Screenshotbot can now extract commit graph data from remote repositories + (assuming one has SSH access to their Git repositories), + by Arnold Noronha on Screenshotbot Blog. ++ [Fixing SSH Conflicts: Using a Separate SSH Key for GitHub](https://dev.to/hastycodea/fixing-ssh-conflicts-using-a-separate-ssh-key-for-github-4in1) + by Hastycode Andreh on DEV\.to. + One trick to add is the possible use of `url..insteadOf`. ++ [The reductionist theory or rethinking of .gitignore bloat](https://dev.to/iegik/the-reductionist-theory-or-rethinking-of-gitignore-bloat-4gfo) + by Arturs Jansons on DEV\.to. + Mentions [gitignore.io](https://www.gitignore.io/), + first mentioned in passing in [Git Rev News Edition #6](https://git.github.io/rev_news/2015/08/05/edition-6/), + then linked to (with new final URL) in [Git Rev News Edition #94](https://git.github.io/rev_news/2022/12/31/edition-94/), + and [github/gitignore](https://github.com/github/gitignore) - which was + first mentioned in passing in [Git Rev News Edition #21](https://git.github.io/rev_news/2016/11/16/edition-21/), + then also linked to in [Edition #94](https://git.github.io/rev_news/2022/12/31/edition-94/), + + + + +__Git tools and sites__ + ++ [A modern theme for cgit](https://yingtongli.me/blog/2025/05/16/cgit.html) + by Lee Yingtong Li on Inane Observations blog. + The source code for this themed fork of [cgit](https://git.zx2c4.com/cgit/tree/README) + is available at . + Under GPL v2 license. ++ [AutoGit-o-Matic](https://github.com/FPGArtktic/AutoGit-o-Matic) is a Bash script + that automates Git operations across multiple repositories. It helps you + pull or fetch updates from multiple repositories with a single command + (with dry-run capability), + scans directories for Git repositories automatically, + logs operations in both TXT and JSON formats, + and is configurable via an INI file. + Under GPL-3.0 license. ++ [StatsCat](https://github.com/z1cheng/statscat) is a CLI tool + to get per-author and per-directory statistics of all your Git repositories. + Written in Go, under MIT license. + + +## Releases + ++ Git [2.50.0-rc0](https://public-inbox.org/git/xmqqzfewsml1.fsf@gitster.g/) ++ GitLab [18.0.1, 17.11.3, 17.10.7](https://about.gitlab.com/releases/2025/05/21/patch-release-gitlab-18-0-1-released/), +[18.0](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/), +[17.11.2, 17.10.6, 17.9.8](https://about.gitlab.com/releases/2025/05/07/patch-release-gitlab-17-11-2-released/) ++ Gerrit Code Review [3.10.6](https://www.gerritcodereview.com/3.10.html#3106), +[3.11.3](https://www.gerritcodereview.com/3.11.html#3113), +[3.12.0-rc5](https://www.gerritcodereview.com/3.12.html#3120), +[3.12.0-rc6](https://www.gerritcodereview.com/3.12.html#3120), +[3.12.0](https://www.gerritcodereview.com/3.12.html#3120), +[3.9.11](https://www.gerritcodereview.com/3.9.html#3911) ++ GitHub Enterprise [3.16.3](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.3), +[3.15.7](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.7), +[3.14.12](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.12), +[3.13.15](https://docs.github.com/enterprise-server@3.13/admin/release-notes#3.13.15), +[3.17.0](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.0) ++ GitKraken [11.1.1](https://help.gitkraken.com/gitkraken-client/current/), +[11.1.0](https://help.gitkraken.com/gitkraken-client/current/), +[11.0.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.4.20](https://desktop.github.com/release-notes/) ++ Garden [2.2.0](https://github.com/garden-rs/garden/releases/tag/v2.2.0) ++ Git Cola [4.13.0](https://github.com/git-cola/git-cola/releases/tag/v4.13.0) ++ GitButler [0.14.26](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.26), +[0.14.25](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.25) ++ git-credential-oauth [0.15.1](https://github.com/hickford/git-credential-oauth/releases/tag/v0.15.1) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <>. diff --git a/_posts/2025-06-30-edition-124.markdown b/_posts/2025-06-30-edition-124.markdown new file mode 100644 index 000000000..d72a4820b --- /dev/null +++ b/_posts/2025-06-30-edition-124.markdown @@ -0,0 +1,690 @@ +--- +title: Git Rev News Edition 124 (June 30th, 2025) +layout: default +date: 2025-06-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 124 (June 30th, 2025) + +Welcome to the 124th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of May and June 2025. + +## Discussions + + + + + +### Support + +* [[BUG] `git stash` incorrectly showing submodule branch instead of superproject branch](https://lore.kernel.org/git/TO1PPF29324B4CE6D3518208073452C3C51CD97A@TO1PPF29324B4CE.CANPRD01.PROD.OUTLOOK.COM/) + + Stuart MacDonald sent a bug report to the mailing list. The report + described a workflow where people worked on a UI project that + included a hardware SDK as a submodule. Both the UI project (the + "superproject") and the SDK project (the submodule) had their own + branches. + + When using `git stash` on a bug fix branch on the superproject, + while the submodule was on a feature branch, it appeared that the + command `git stash list` output a message, like: + + `stash@{0}: On feature_sdk_foo: debugging` + + indicating the stash had been created on the submodule's branch + instead of the superproject's branch. The branch `feature_sdk_foo` + didn't even exist in the superproject. + + Stuart mentioned he thought this used to work correctly around 2021, + though he wasn't 100% certain. + + K Jayatheerth replied to Stuart confirming the bug happened on + different OSes, showing minimal steps to reproduce it, and saying it + was "one of the most interesting Git bugs" he had seen in a while. + + Jayatheerth came back later with + [a patch](https://lore.kernel.org/git/20250512164001.62065-1-jayatheerthkulkarni2005@gmail.com/) + that fixed the bug. It appeared that the branch name was obtained + via the `refs_resolve_ref_unsafe()` function, which returns a + pointer to a static buffer, but that static buffer was overwritten. + To fix this, the patch copied the branch name instead of pointing to + the static buffer. + + Stuart thanked Jayatheerth even though he couldn't rebuild Git with + the patch. + + Junio Hamano, the Git maintainer, replied to the patch with small + suggestions, while Eric Sunshine noted that the change should also + be accompanied by a new test. + + Jayatheerth replied to Eric and Junio saying he would fix the small + issues and add tests, which he later did in + [an updated patch](https://lore.kernel.org/git/20250608063537.233243-1-jayatheerthkulkarni2005@gmail.com/). + + René Scharfe reviewed the updated patch and suggested a number of + improvements to the code and the test. + + Jayatheerth then sent + [a v2 of his patch](https://lore.kernel.org/git/20250608144542.275836-1-jayatheerthkulkarni2005@gmail.com/) + which addressed René's comments. Junio reviewed it and suggested + further improvements. + + [The v3 patch from Jayatheerth](https://lore.kernel.org/git/20250611014204.24994-1-jayatheerthkulkarni2005@gmail.com/) + addressed Junio's comments and was merged. + +## Community Spotlight: Luca Milanesio + +_Luca Milanesio is a long standing contributor to both JGit and Gerrit +Code Review, an open-source veteran who's been accelerating Application +Lifecycle workflows for 30+ years—from founding GerritHub.io to pioneering +AI-powered repository optimization research._ + +_This is a continuation of our initiative to interview community +contributors outside of our mailing list. Our previous interviews +were with [VonC in edition 106][vonc] and [Chris Torek in edition 120][torek]._ + +- **Who are you and what do you do?** + + My name is Luca Milanesio, and I am the CEO of GerritForge Inc., + a company I founded 6 years ago, which is fully dedicated to the + development and support of Git and the Gerrit Code Review ecosystem + for medium and large enterprises around the globe. + + I am a passionate Open-Source contributor, and I have helped many + projects grow over my 30+ years of software development career, + including Jenkins, JGit, GitBlit, Swagger/Open-API, Kibana, Avro, + and Gerrit Code Review. + + I am a maintainer and release manager of Gerrit Code Review, a + member of its Engineering Steering Committee, and committer of the + JGit project. + + I introduced GerritHub.io 11 years ago, a free Gerrit Code Review + service for all public and private projects on GitHub. It has over + 50k subscribers and is currently used by over 300 organisations and + open-source projects worldwide. + + My latest work is research about using AI, specifically reinforcement + learning, to dynamically understand and learn how Git repository metrics + evolve and execute actions to improve their performance by up to 100x. + The research has been selected for the 50th edition of the [IEEE/ACM + International Conference on Software Engineering in Ottawa (CA)][3]. + +- **What would you name your most important contribution to the Git ecosystem?** + + I have introduced a multi-site replication plugin between the Git + repositories managed by JGit and Gerrit Code Review [[ref][1]]. + + Google introduced the multi-site replication concept in JGit from + the very beginning in 2012, [with the introduction of DFS][2], a + multi-site distributed storage mechanism for Git. Although DFS was + a completely abstract interface layer that could have been + implemented on top of any distributed storage, in practice, it was + effectively implemented and used only by Google in its internal + implementation of JGit. + + In the meantime, the rest of the Open-Source community was left with + the traditional filesystem-based implementation and its extensions + to work effectively and efficiently with a shared filesystem (e.g., NFS). + I started using the NFS implementation of JGit on GerritHub.io and + contributed many patches and improvements over the years. Still, I + was soon hit with all the quirks and limitations of the NFS protocol + in trying to mock the “illusion” of a POSIX filesystem over a network + protocol, including locking, stale file handles, and caching + inconsistencies. After working for 4 years on the NFS implementation + of JGit on GerritHub.io on a shared filesystem, I forked the + [high-availability plugin project][4] and started the + [multi-site project][1], which has now entered its 6th year of adoption. + + Thanks to the multi-site support, anyone worldwide can use Git + replication across Gerrit primary nodes without fearing a + split-brain disaster, as it [historically happened years ago][5] + on a large-scale Git service. + +- **With over 30 years in software development, how have you seen version + control systems evolve, and what makes Git stand out in this evolution?** +` + I started using RCS on my Unix box for tracking the local version of files + and avoiding bad surprises, and since then I’ve seen so many so-called + revolutions of the version control that promised “the moon” but ended up + creating yet another commercial silo. To name a few, consider + [Rational ClearCase][clearcase] and [Perforce][perforce], and the legacy + they have made for the software industry. + + In my experience, version control is the foundation of any Software + Development Life Cycle (SDLC for short) and should always be thought of + as an evolving technology: I don’t believe that Git is here to stay + forever as-is, even though it would be difficult to imagine an + Open-Source project starting today not using Git as version control. + + But if you roll back to the year 2000, you could have swapped Microsoft + with VA Software and Git with Subversion, and asked the same question: + _`“What version control and hosting site should a new Open-Source project + use?”_ I believe the answer would differ significantly from the one you + have today [[ref][6]]. + + What makes Git different from its predecessors is its adoption in + large Open-Source projects unlikely to be discontinued any time soon, + such as Linux and the Android OS project. With the advent of IoT and + the extensive adoption of Android OS everywhere, from appliances to + aerospace and automotive, Git version control has become responsible + for powering the SDLC of most devices we use daily. + + A second factor that has brought Git to the world stage as the future + of VCS is its ability to abstract from any vendor bias and be truly + driven by only its user base: software developers. Git was invented + by Linus Torvalds because he needed it, not because a company X wanted + to disrupt the market of the existing version control system Y to + achieve goal Z. + + A third factor is the growth of other Git-compatible version control + systems, such as [JJ (aka Jujutsu)][7]. Git is, first of all, a data + format for versioned directories and BLOBs and a protocol on how this + data can be safely transferred between peers: no implementation-specific + quirks, no vendor lock-ins, no silos, just data and protocol. + This has led other developers, like [Martin Von Zweigbergk][martinvonz] + (Senior Software Engineer @Google), to create version control systems + on top of it, assuring interoperability with the existing code and + innovation simultaneously. + + This is unprecedented and unique in the history of VCSs I have seen + in my whole 30+ career as a Software Developer. Do I believe that + Git will continue to exist in its current form in 25 years from + now? No, I believe it will be very different in the future, but + its foundations will remain the same, and I see many more + evolutions similar to Martin’s JJ project. + +- **You've been working on comparing Git reftable implementations + with JGit alternatives. Could you walk us through what motivated + this research and preview any interesting findings you've + discovered?** + + Being the Gerrit Code Review release manager comes with many + responsibilities, including verifying that whatever we release + is production-ready and always better than what has ever been + released. That also includes, first and foremost, the Git + performance, following Shawn Pearce’s (Gerrit Code Review + project founder, R.I.P.) mantra, “performance is a feature.” + + We have been working in Q1 of 2025 to release and certify + [Gerrit v3.12][gerrit-3.12], which includes the latest and + greatest of JGit’s implementation of reftable, which was + available since 2019 but not used in Gerrit because of the + lack of support from the C Git project. Some parts of Gerrit + use the “C Git” implementation for some scripting side + and replication; therefore, a Git repository with reftable + would not have been compatible with Gerrit until Git v2.45, + which was [released last year][8]. + + In February 2024, at the time of the release of reftable + support in Git v2.45, I was busy with my AI research work + for [optimising Git performance][3], and I immediately + thought that it was the right time to put JGit and C Git + implementation of reftable in the arena and see how they + interoperate and perform during heavy workload. + + The first finding was that reftable has an entirely different + philosophy from any other ref storage used before by Git. + Loose refs and packed refs are both based on the concept of + file-level locking and caching. Both C Git and JGit ensure + that every update is atomic by carefully creating and releasing + ref-level or packed-refs-level lock files and using atomic + filesystem updates to ensure that the concurrency of reads + and updates does not impact the normal functionality of + in-flight operations. JGit has a “wait for lock” mechanism + where the in-flight operation would wait for the lock file + to be released before acquiring the resource, with an exponential + backoff mechanism on packed-refs, whilst C Git just fails the + operation with a lock failure. + + Reftable is different because it is designed to be highly + scalable and performant, compared to loose refs or packed-refs. + To prioritise performance and low latency, reftable decides + to give up thread safety and locking altogether, relying on an + optimistic locking pattern. In a nutshell, whilst packed-refs + blocks the file and waits until it is released, reftable allows + multiple users to access the same data on disk and refer + directly without locking. The operation is always safe because, + unlike packed-refs and loose-refs, the reftable files are always + immutable and therefore safe to be shared concurrently without + any locks. + + What’s the catch? The concurrent updates of the same refs by + two different threads or processes will want to update the + list of reftables simultaneously. Whoever manages to perform + the update is gaining the “logical lock” and will cause any + other concurrent threads or processes to fail the whole + transaction they may have prepared. + + Why is this different from loose-refs and packed-refs? The + client interaction and compensation behaviour with a reftable + needs to be substantially different: if with loose-refs or + packed-refs the client was retrying the operation, or just + waiting in case of JGit, with reftable the client should + abort the whole logical operation, destroy the current + snapshot of the reftable read in memory, and restart the + whole transaction from scratch. + + The issue here is that reftable is simply configured + as a storage format for the refs, and the higher layers + are currently unprepared to manage the difference in + behaviour. This is currently causing trouble in the + JGit world, with [some initial issues reported][9] at the + API level, like the lack of “auto-refresh” and even more + problematic [stability problems reported on Gerrit Code Review][10] + when using reftable from concurrent threads. + + The $1M question about reftable is, *"Is it ready for mainstream + use in production?”* My answer is obviously a bold yes, but with + a very important caveat: whoever is using reftable should be aware + of what it is and how it should be used, and cannot be simply used + blindly, assuming that it works exactly as a loose-ref or + packed-refs. Reftable is ready, Git and Gerrit Code Review aren’t + ready yet to leverage it, and I am sure they will soon be adjusted + to get the best use of it. + +- **What's your approach to load testing Git repositories \- which + tools work best, what key metrics should organizations monitor, + and what are some interesting findings from your research in + this area?** + + At GerritForge, we’ve been investing a lot of time and effort + in testing and improving the performance of Git repositories, + as demonstrated by the recent research paper published on the + use of AI to improve repository performance 100x times. + + Over the years, we have developed much experience, successfully + using the [Gatling framework][11] and extending it to support + the [Git protocol over HTTPS and SSH][12]. The use of Gatling + is great because it allows us to create very comprehensive + scenarios using a DSL (domain-specific language), which is + high-level and can replicate real-life user behaviour. + Replicating real-life traffic is paramount when testing a Git + repository performance because it allows creating future volumes + in terms of length of delta-chains, number and distribution of + refs, and number of packfiles / loose objects, that reflect the + project lifecycle. + + Another key aspect of generating a workload against a Git repository + is scaling up the clients and making their requests parametric enough + to avoid different requests locking each other. With Gatling, you + have the concept of “user sessions” where different logical users + can have dynamic variables used in the Git requests that can be used + for making the operation independent (e.g., branch name fragments, + or tags) and avoiding them from failing or ending up in a deadlock. + + As part of [our research work][3], I managed to recreate 10 years + of Git traffic generated by hundreds of users and execute it in + just 12 hours, thanks to Gatling and the Git-Gatling plugin. + + An interesting finding from the research and experiments is that + over 95% of the CPU time is spent in serving git-upload-pack + commands (not really a surprise though), of which 90% of it is + spent in [the “search-for-reuse” phase][13]. + + A second interesting finding is that the presence of a bitmap, + single or multi-pack, is not a guarantee of fast and effective + Git operations: the quality of the bitmap also matters a lot. + A bad bitmap could be so detrimental that removing it could + make the Git repository much faster, which may sound + counterintuitive. + +- **Based on your testing, what improvements do you think are most + needed in Git's core implementation?** + + I believe that the Git GC process needs a full revamp: the way + it is designed today isn’t suitable for large repositories. I + have presented a simple “role play” demo of what could happen + to a large mono-repo when you are trying to resolve a production + slowdown [running a Git GC][14]: in my imaginary scenario, a + large team of developers is pushing a lot of changes to get the + latest features through on their product’s mono-repo, not unlike + what happens when a large developer conference is approaching + and company ABC wants to launch a new version of their product DEF. + The operation raises the main metrics of the repository and makes + the “search-for-reuse” phase explode, causing the complete blockage + of the CI/CD pipeline. The Git SCM Manager knows what to do … and + runs a Git GC, causing even more damage than the original problem. + + I believe Git GC needs to be redesigned from the ground up. + Instead of being a simple sequence of operations, it needs to be + much more intelligent and adaptive to perform the right operation + at the right time. This could also be *“do nothing”* as the CPU + load is too high or the volatility of the repository is diverging. + +- **How do you see the relationship between Git and JGit evolving + in the future?** + + I believe Git and JGit have a wonderful symbiosis of ideas and + code: many popular features in JGit ended up innovating and + inspiring similar implementations in Git (e.g., bitmap, + ref-table, just to name a couple). Also, the other way around + is happening, with the implementation of MIDX in JGit recently + merged, thanks to the collaboration of GerritForge and Google. + + I like Git because it makes the language absolutely irrelevant + to the implementation: extending Git doesn’t mean you have to + write C code, and you can always start a brand new Git functionality + in a language XYZ in the future. Git is all about data and protocol + specification, not language, code, or operating system. + + I believe that should remain the case, and I am looking forward to + new languages implementing and innovating on Git, like the recent + [Gitoxide project][15], a pure-native implementation in Rust. + +- **If you could get a team of expert developers to work full-time + on something in Git for a full year, what would it be?** + + I may repeat myself, but I would redesign the Git GC command from + the ground up. + +- **If you could remove something from Git without worrying about + backwards compatibility, what would it be?** + + Well, I would get rid of SHA-1 altogether immediately, forget + about the legacy, and force everyone to use SHA-256 … but + change requires time. + +- **What is one of your most favourite features of Git?** + + I thank all the Git developers every single day for the + interactive rebase. I use it as my bread and butter every + morning. + +- **What is your favorite Git-related tool/library, outside of Git itself?** + + I am shamelessly admitting that I love Git command line and + I do not feel I need anything else as a tool or library to + interact with it. Many people find it confusing, and I agree + that some syntax could be misleading. Nevertheless, it is worth + using it, proposing changes, and improving how it works and is + perceived by the developers. + + A tool that requires other tools is a symptom of a problem. + +- **Could you brief a bit about one of your most memorable experience + with Git?** + + As you haven’t mentioned if the experience should be positive or + negative, I always mention the world-stage attention I got from + force-pushing hundreds of Git repositories on the Jenkins CI + organisation [over 12 years ago][16]. It was bad and good at + the same time, because despite the panic caused in hundreds of + Jenkins CI projects, it demonstrated that force pushing isn’t + a destructive operation, and all the BLOBs were easily recovered, + and the refs pointed again to the expected SHA1. + + Also, my unfortunate mistake highlighted the resilience of the + Git repository model, where there isn’t a “single source of truth” + and GitHub’s repository is just “one of the peer repositories” + around the globe. You can always recover from any type of damage + with Git, at least from what I’ve seen in my 15 years of + contributing and using it with real-life large-scale repositories + and customers. + +- **What is your advice for people who want to start using Git? + Where and how should they start?** + + This could have been a valid question 15 years ago, when Git was + still “quite recent” and not widely adopted yet. Nowadays, Git is + taught at school and universities and has become the de facto + standard of any Open-Source project around the globe. I was also + pleasantly surprised to learn that my 10-year-old son was + introduced to Git by his Computer Science teacher at primary school. + +- **There's a common conception that "Git is confusing". What are your + thoughts about the same?** + + I believe the most confusing part of Git is the working copy and the + staging area. That’s the reason why [JJ][7] gets rid of it altogether + and introduces the concept of “unnamed” commit. That’s genius from + Martin Von Zweigbergk, if you think about it: you just stage files + because you’d like to create a commit. So the stage is the + “next commit you’re about to write”, therefore the unnamed commit. + +- **If there’s one tip you would like to share with other users of Git, + what would it be?** + + Never use an IDE to manage your Git repository and commits: always + stay in control of what happens and learn something every day by using + the Git command line. + +- **If there’s one tip you would like to share with other Git developers, + what would it be?** + + I am not currently contributing to C Git, so my tip would be more for + JGit developers instead. I would love to see more end-to-end JGit + features and protocols testing using tools like [Gatling][11] + and the [Git-Gatling plugin][12]. + +- **Anything else that you'd like to share with us?** + + In the future, I’d like to see Git become just one standard feature + of each operating system: anyone should version a file on their + system, regardless of whether that file is source code, a document, + a video, or a drawing. Maybe it is not a random event that the father + of Linux is also the creator of the Git version control system, + isn’t it? + + Thanks for allowing me to share my experience with Git and my history + of being a JGit contributor and committer. + +[vonc]: https://git.github.io/rev_news/2023/12/31/edition-106/#community-spotlight-vonc +[torek]: https://git.github.io/rev_news/2025/02/28/edition-120/#community-spotlight-chris-torek +[clearcase]: https://en.wikipedia.org/wiki/IBM_DevOps_Code_ClearCase +[perforce]: https://www.perforce.com/ +[martinvonz]: https://github.com/martinvonz +[gerrit-3.12]: https://www.gerritcodereview.com/3.12.html +[1]: https://gerrit.googlesource.com/plugins/multi-site/+/refs/heads/master/DESIGN.md +[2]: https://review.gerrithub.io/c/eclipse-jgit/jgit/+/3930 +[3]: https://conf.researchr.org/home/icse-2025 +[4]: https://gerrit.googlesource.com/plugins/high-availability +[5]: https://github.blog/news-insights/company-news/oct21-post-incident-analysis/ +[6]: https://en.wikipedia.org/wiki/SourceForge +[7]: https://jj-vcs.github.io/jj/latest/ +[8]: https://github.com/git/git/blob/master/Documentation/RelNotes/2.45.0.adoc +[9]: https://github.com/eclipse-jgit/jgit/issues/102 +[10]: https://github.com/eclipse-jgit/jgit/issues/130 +[11]: https://gatling.io/ +[12]: https://docs.gatling.io/reference/script/third-parties/ +[13]: https://github.com/eclipse-jgit/jgit/blob/46d0d1b40b147e4282043a6c404947166c71be93/org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/pack/PackWriter.java#L1452 +[14]: https://youtu.be/xhxrGxvChU0?t=395 +[15]: https://github.com/GitoxideLabs/gitoxide +[16]: https://www.infoq.com/news/2013/11/use-the-force/ + + +## Other News + +__Various__ ++ The Git Merge 2025 [speaker list](https://git-merge.com/#speakers) + and [schedule](https://git-merge.com/#schedule) have been announced. + It will be held on September 29 - 30, 2025, in San Francisco, CA, USA. ++ [[ANNOUNCE] Git v2.50.0](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u) + by Junio C Hamano on the Git mailing list. ++ [Highlights from Git 2.50](https://github.blog/open-source/git/highlights-from-git-2-50/) + by Taylor Blau on GitHub Blog.
+ Mentions + improvements for multiple cruft packs, including `git repack --combine-cruft-below-size` + (and improvements to its `--max-cruft-size` option), + incremental multi-pack reachability bitmaps (highly experimental), + the "ort" merge strategy replacing the "recursive" strategy entirely, + various `git cat-file` improvements, `git maintenance` new tricks, and more. ++ [What’s new in Git 2.50.0?](https://about.gitlab.com/blog/what-s-new-in-git-2-50-0/) + by Justin Tobler on GitLab Blog.
+ Mentions the + new [git-diff-pairs(1)](https://git-scm.com/docs/git-diff-pairs) command + which accepts "raw" formatted filepair info (from e.g. `git diff-tree`) + as input on stdin to determine exactly which patches to output, + batched reference updates with [git-update-ref(1)](https://git-scm.com/docs/git-update-ref) + and its new `--batch-updates` option + (which allows the updates to proceed even when one or more reference updates fails), + the new `--filter` option for [git-cat-file(1)](https://git-scm.com/docs/git-cat-file), + improved performance when generating bundles with [git-bundle(1)](https://git-scm.com/docs/git-bundle) + (used by GitLab to generate repository backups + and also as part of the [bundle-URI](https://git-scm.com/docs/bundle-uri) mechanism), + and better bundle URI unbundling. + + +__Light reading__ ++ [How to Install Gitea (with SQLite3 and HTTPS!) on a VPS](https://www.git-tower.com/blog/how-to-install-gitea) + by Bruno Brito on Tower Blog. ++ [Reduce the load on GitLab Gitaly with bundle URI](https://about.gitlab.com/blog/reduce-the-load-on-gitlab-gitaly-with-bundle-uri/). + Discover what the bundle URI Git feature is, how it is integrated into Gitaly, + configuration best practices, and how GitLab users can benefit from it. + GitLab Blog post writen by Olivier Campeau. ++ [How we decreased GitLab repo backup times from 48 hours to 41 minutes](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/) + by Karthik Nayak and Manuel Kraft on GitLab Blog. + Describes how the GitLab team tracked a performance bottleneck in `git bundle create` + to a 15-year-old Git function and fixed it. ++ [Working with stacked branches in git (part 2)](https://andrewlock.net/working-with-stacked-branches-in-git-part-2/) + by Andrew Lock on his blog, \.NET Escapades, continues where + [Working with stacked branches](https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/) + (mentioned in [Git Rev News Edition #93](https://git.github.io/rev_news/2022/11/30/edition-93/)) left off. ++ [Git: please stop squash merging!](https://lucasoshiro.github.io/posts-en/2024-04-08-please_dont_squash/) + and [Git: the danger of squash merging submodules](https://lucasoshiro.github.io/posts-en/2024-06-27-squash-submodule/) + by Lucas Seiki Oshiro on his GitHub Pages-powered personal blog. + + The first of those blog posts mentions + [Squash commits considered harmful](https://dev.to/wesen/squash-commits-considered-harmful-ob1) by Manuel Odendahl and + [Squash merges are evil](https://medium.com/bananatag-engineering-blog/squash-merges-are-evil-171f55139c51) by L. Holanda. + + See the [Combining branches](https://wizardzines.com/comics/combining-branches/) + comic by Julia Evans (@b0rk) for an explanation about the differences between merge, rebase, and squash merge. ++ [Cleaning up gone branches](https://haacked.com/archive/2025/04/17/git-gone/) + by Phil Haack on his You've Been Haacked blog. + Describes how to delete all the branches that have been merged into the default branch, + even if the project uses Squash and Merge when merging PRs + (also known as squash merge). ++ [Part 7: Office Migration from Source Depot to Git, or how I learned to love DevEx](https://danielsada.tech/blog/carreer-part-7-how-office-moved-to-git-and-i-loved-devex/) + by Daniel Sada on his personal blog + (part of his [My career so far](https://danielsada.tech/series/my-career-so-far/) series). + + Nicely complements [Microsoft’s Performance Contributions to Git in 2017](https://devblogs.microsoft.com/devops/microsofts-performance-contributions-to-git-in-2017/) + by Derrick Stolee on Microsoft Dev Blogs, mentioned in + [Git Rev News Edition #40](https://git.github.io/rev_news/2018/06/20/edition-40/), + and other posts at . ++ [Git Branch Manager: a manager for git branches](https://daveschumaker.net/git-branch-manager-a-manager-for-git-branches/) + by Dave Schumaker on his blog, + describes how he created the [Git Branch Manager](https://github.com/daveschumaker/gbm) + tool by "vibe coding" with Claude Code. The 'P.S.' part just kills it... ++ [no more gitmojis](https://kjelsrud.dev/blog/no-more-gitmojis/) + on Sids' blog; moving from [gitmojis](https://gitmoji.dev/) + to just using [conventional commits](https://conventionalcommits.org/). + + [Gitmoji](https://gitmoji.dev/) was first mentioned in [Git Rev News Edition #47](https://git.github.io/rev_news/2019/01/23/edition-47/), + though then under a [different URL](https://gitmoji.carloscuesta.me/) + (which now redirects to the current one). + + The similar [Emoji-Log](https://github.com/ahmadawais/Emoji-Log) commit log messages standard + was mentioned in [Git Rev News Edition #101](https://git.github.io/rev_news/2023/07/31/edition-101/). + + The [Conventional Commits](https://www.conventionalcommits.org/) specification + was first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/), + and in many editions since. ++ [`git diff --ignore-all-space` makes code review way easier](https://garrit.xyz/posts/2025-06-11-git-diff-ignore-all-space-makes-code-reviews-way-easier) + by Garrit Franke on Garrit's Notes blog; + a TIL (Today I've Learned) style post. ++ [Per-project git commit templates](https://tylercipriani.com/blog/2025/05/21/git-commits/) + by Tyler Cipriani on his blog. + Mentions in passing different commit guidelines used by various projects, like + [Conventional Commits](https://www.conventionalcommits.org/), + [Gitmoji](https://gitmoji.dev/), + [Problem/Solution format](https://zeromq.org/how-to-contribute/#write-good-commit-messages) used by ZeroMQ, and + [Acked-by:, Cc:, and Co-developed-by: trailers](https://docs.kernel.org/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by) + used by Linux kernel developers. ++ [The history of change-packing tools at Microsoft (so far)](https://devblogs.microsoft.com/oldnewthing/20180122-00/) + by Raymond Chen on Microsoft Dev Blogs: The Old New Thing (2018).
+ Change-packing is a way to save a whole changeset or commit to a single file, + to be able to save changes without committing them (like `git stash`), + or to get another developer’s opinion on code you’ve written (_buddy build_), etc. ++ [GIF: The Git Interchange Format](https://willhbr.net/2025/06/16/gif-the-git-interchange-format/) + by Will Richardson on his blog, + about how to cram a whole git repo (with history) into an animated GIF. + + + +__Scientific papers__ ++ Shane McIntosh, Luca Milanesio, Antonio Barone, Jacek Centkowski, Marcin Czech, Fabio Ponciroli: + _"Using Reinforcement Learning to Sustain the Performance of Version Control Repositories"_, + ICSE 2025: 47th International Conference on Software Engineering, + (preprint). ++ Jakub Narębski, Mikołaj Fejzer, Krzysztof Stencel, Piotr Przymus: + _"PatchScope - A Modular Tool for Annotating and Analyzing Contributions"_, + ISSTA 2025: 34th ACM SIGSOFT International Symposium on Software Testing and Analysis, + [DOI:10.1145/3713081.3731727](https://dl.acm.org/doi/10.1145/3713081.3731727) (short paper, free access). + + [PatchScope](https://github.com/ncusi/PatchScope) was first mentioned in + [Git Rev News Edition #117](https://git.github.io/rev_news/2024/11/30/edition-117/). + +__Git tools and sites__ ++ [GetHooky](https://ezpieco.github.io/GetHooky/) is a simple git hook manager for everyone. + Inspired by [Husky](https://typicode.github.io/husky/), + but a CLI tool, thus works for every stack. + Written in Go, under MIT license. + + [Husky](https://github.com/typicode/husky), a Git hook management tool, was first mentioned in + [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/); + you can find links to other articles talking about it in + [#87](https://git.github.io/rev_news/2022/05/26/edition-87/), + [#89](https://git.github.io/rev_news/2022/07/31/edition-89/), and + [#102](https://git.github.io/rev_news/2023/08/31/edition-102/). ++ [Git Branch Manager](https://github.com/daveschumaker/gbm) is + a terminal-based (TUI) Git branch management tool + that provides an interactive interface for managing Git branches, + with rich visual feedback and advanced features. + Written in Python (with the help of Claude Code), under MIT license. ++ [Gittyup](https://github.com/Murmele/Gittyup) is a graphical Git client + designed to help you understand and manage your source code history. + Written in C++ using Qt, under MIT license. + It is a continuation of the [GitAhead](https://github.com/gitahead/gitahead) client, + mentioned in [Git Rev News Edition #59](https://git.github.io/rev_news/2020/01/22/edition-59/). ++ [Conventional Changelog](https://github.com/conventional-changelog/conventional-changelog) + is an npm tool to generate changelogs and release notes + from a project's commit messages and metadata. + Written in TypeScript and JavaScript, under ISC license. + First mentioned in [Git Rev News Edition #81](https://git.github.io/rev_news/2021/11/29/edition-81/). + + +## Releases + ++ Git [2.50.0](https://public-inbox.org/git/xmqq1prj1umb.fsf@gitster.g/), +[2.50.0-rc2](https://public-inbox.org/git/xmqqfrg8surr.fsf@gitster.g/), +[2.50.0-rc1](https://public-inbox.org/git/xmqqsekgn4gk.fsf@gitster.g/) ++ Git for Windows [2.50.0.windows.1](https://github.com/git-for-windows/git/releases/tag/v2.50.0.windows.1), +[2.50.0-rc2.windows.1 (pre-release)](https://github.com/git-for-windows/git/releases/tag/v2.50.0-rc2.windows.1), +[2.50.0-rc1.windows.1 (pre-release)](https://github.com/git-for-windows/git/releases/tag/v2.50.0-rc1.windows.1), +[2.50.0-rc0.windows.1 (pre-release)](https://github.com/git-for-windows/git/releases/tag/v2.50.0-rc0.windows.1) ++ libgit2 [1.9.1](https://github.com/libgit2/libgit2/releases/tag/v1.9.1) ++ GitLab [18.1.1, 18.0.3, 17.11.5](https://about.gitlab.com/releases/2025/06/25/patch-release-gitlab-18-1-1-released/), +[18.1](https://about.gitlab.com/releases/2025/06/19/gitlab-18-1-released/), +[18.0.2, 17.11.4, 17.10.8](https://about.gitlab.com/releases/2025/06/11/patch-release-gitlab-18-0-2-released/) ++ GitHub Enterprise [3.17.1](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.1), +[3.16.4](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.4), +[3.15.8](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.8), +[3.14.13](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.13), +[3.13.16](https://docs.github.com/enterprise-server@3.13/admin/release-notes#3.13.16), +[3.17.0](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.0) ++ GitKraken [11.2.0](https://help.gitkraken.com/gitkraken-client/current/), +[11.1.1](https://help.gitkraken.com/gitkraken-client/current/), +[11.1.0](https://help.gitkraken.com/gitkraken-client/current/), +[11.0.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.5.0](https://desktop.github.com/release-notes/), +[3.4.21](https://desktop.github.com/release-notes/) ++ GitButler [0.14.35](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.35), +[0.14.34](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.34) ++ Tower for Mac [13](https://www.git-tower.com/release-notes/mac) - [Release Blog Post](https://www.git-tower.com/blog/posts/tower-mac-13) / [YouTube video](https://youtu.be/2hjLn9mq9fY) ++ Tower for Windows [9.1](https://www.git-tower.com/beta/windows) (Beta) - [Release Blog Post](https://www.git-tower.com/blog/posts/tower-windows-91) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Luca Milanesio, Bruno Brito, +Lee Reilly and Štěpán Němec. diff --git a/_posts/2025-07-31-edition-125.markdown b/_posts/2025-07-31-edition-125.markdown new file mode 100644 index 000000000..b63ee5d2c --- /dev/null +++ b/_posts/2025-07-31-edition-125.markdown @@ -0,0 +1,645 @@ +--- +title: Git Rev News Edition 125 (July 31st, 2025) +layout: default +date: 2025-07-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 125 (July 31st, 2025) + +Welcome to the 125th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of June and July 2025. + +## Discussions + + +### General + +* 20 years ago: [Meet the new maintainer..](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/) + + On July 26 2005, so 20 years ago, Linus Torvalds announced on + the mailing list that Junio Hamano accepted the maintainership of + the Git project and that Junio "was the obvious choice". Linus said + he wasn't dropping Git but he just preferred working on it as a + contributor. + + Junio replied with an [A note from the new GIT maintainer](https://lore.kernel.org/git/7vmzo8ss2l.fsf@assigned-by-dhcp.cox.net/) + email where he acknowledged his new role as Git maintainer, thanked + the community for their support and collaboration, and promised to + take a more careful and deliberate approach in shepherding the + project. He also said he would post his own patches to the mailing + list for review before including them in the repository, and + encouraged community feedback. + +* [[ANNOUNCE] Git Mini Summit at Open Source Summit Europe, Amsterdam, August 28th](https://lore.kernel.org/git/aGwHt9HCd86hVuKh@pks.im/) + + Patrick Steinhardt announced a Git Mini Summit co-located with the + [Open Source Summit Europe](https://events.linuxfoundation.org/open-source-summit-europe/) + in Amsterdam on August 28th 2025. + + There will be lightning talks and some time for people to + connect. Proposals for the lightning talks should be sent to + Patrick, while the possibility to have remote talks is still + investigated. + + [Registration is open](https://events.linuxfoundation.org/open-source-summit-europe/features/co-located-events/#git-mini-summit-2025) + for both the Git Mini Summit only and for the Open Source Summit Europe including the Git Mini Summit. + + +### Reviews + +* [[PATCH v4 0/3] send-email: add oauth2 support and fix outlook breaking threads](https://lore.kernel.org/git/PN3PR01MB9597A83D537E3AE96144227EB8BA2@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM/) + + Last April, Aditya Garg sent a patch series containing three main + changes to `git send-email`. He mentioned that he was sending the + email series using the very patches he was proposing, via Outlook. + + The first patch was a rebased version of + [an earlier patch by Julian Swagemakers](https://lore.kernel.org/git/20250125190131.48717-1-julian@swagemakers.org/) + adding support for OAuth2 authentication, which started to be + required by Microsoft. Julian's patch unfortunately had been waiting + for review for over a year before Aditya picked it up. + + The second patch fixed thread breaking caused by Outlook's + proprietary Message-ID handling. + + The final patch added a new option for generating passwords, such as + OAuth2 tokens, via an external script. + + Junio Hamano, the Git maintainer, reviewed the three patches saying + he liked the commit messages, documentation and code comments even + though he suggested a few small style improvements to the code + style plus a number of grammar and formatting changes to the + documentation. + + He also asked for reviews from others as he said he was not familiar + with the `Authen::SASL` library. + + Aditya replied to Junio's review acknowledging the need for more + reviews and saying that OAuth2 was a significant and more secure + technology. He then took the initiative to Cc Greg Kroah-Hartman, + who wrote a precursor of `git send-email` for the Linux kernel. + + M Hickford also replied to Aditya expressing enthusiasm for the work + but wondering why the v4 version of the patch series was sent in a + new email thread rather than as a reply to the previous version. + + brian m. carlson commented on the second patch saying that replacing + message IDs like Outlook does is technically allowed by + standards. They raised concerns about hardcoding only two Outlook + server hostnames, and suggested adding configuration options for + Message-ID generation modes. + + Julian Swagemakers then pointed out that the goal of the third patch + could already be achieved using Git's existing custom credential + helper mechanism. Aditya confirmed this worked and said he was + unaware of this feature, which led to the decision to drop the third + patch. Recognizing that the existing feature was poorly + discoverable, the discussion led to improvements in Git's + documentation, adding clearer examples of using credential helpers + for OAuth2 tokens. + + Erik Huelsmann, the maintainer of the `Authen::SASL` Perl module, + joined the conversation after Aditya emailed him directly + referencing a GitHub issue about the lack of OAuth2 support in + `Authen::SASL`. In that issue Erik had + [commented that he would be happy to support XOAUTH2](https://github.com/gbarr/perl-authen-sasl/issues/18#issuecomment-2453040190), + but needed a patch and a way to test it. + + Aditya and Julian then worked together, with guidance from Erik, to + add the necessary XOAUTH2 and OAUTHBEARER support directly into + `Authen::SASL`. Shortly after, a new version of the `Authen::SASL` + module was officially released with this new functionality. This + successful collaboration meant the first patch in the series, which + was a workaround for the missing library support, was no longer + needed and was subsequently dropped. Instead, the new version of + `Authen::SASL` started to benefit all Perl users. + + Greg Kroah-Hartman echoed what brian had suggested about using a + configurable solution in the second patch. Greg noted that the + initial approach would not cover company-hosted Outlook servers. Yao + Zi also contributed to this discussion, noting that Tencent's mail + service had similar issues, further reinforcing the need for a + flexible solution beyond just hardcoding specific server names. + + That suggestion was then refined by Junio Hamano, who proposed a + concrete implementation for the new option by providing an example + patch. The final `--[no-]outlook-id-fix` option auto-detects known + Outlook servers but allows manual override for other deployments. + + After several iterations on its name and behavior, with Eric + Sunshine helping refine the user-facing documentation, Aditya + submitted a final, simplified patch series (v6). It now contained + only the single, refined patch to fix Outlook thread breaking, with + the other two patches having been made obsolete by the + `Authen::SASL` library update and the use of existing Git features. + + Aditya's patch was merged and released as part of Git v2.50.0. + + + +## Developer Spotlight: Usman Akinyemi + +_Editor’s note: This edition features a retrospective interview with a +contributor who contributed to Git through a mentoring program. We hope +the reflections shared by the Outreachy contributor will provide an +insightful perspective that benefits the community. As always, we +welcome your thoughts and feedback!_ + +* **Who are you and what do you do?** + + I’m Usman Akinyemi, a final-year CS and AI student, and an open-source + contributor passionate about Linux, distributed systems, and developer + tools. I’ve contributed to core projects like Git, systemd, LLVM, and + LibreOffice. During [my Outreachy internship](https://uniqueusman.hashnode.dev/my-outreachy-internship-experience-at-git), + I improved Git’s v2 protocol by adding OS-level metadata for better + diagnostics and security. + + Currently, I’m a [Google Summer of Code contributor](https://summerofcode.withgoogle.com/programs/2025/projects/wBCitF8F) + building a containerized pipeline for medical imaging using Kaapana, + Kubernetes and Airflow. I am also currently working on creating a + new subtype for RISC-V assembly instructions through the + Linux Foundation’s LFX program. + + Outside code, I mentor new contributors, volunteer with DesignIT and + LEAD and CODE to teach digital skills, and organize a tech webinar for + Nigerian students. I’ll be [speaking at Git Merge 2025](https://git-merge.com/#usman-akinyemi), + sharing insights from my open-source journey. I believe in the power of + community, collaboration, and curiosity to build a career that crosses + borders. + +* **How did you initially become interested in contributing to Git, + and what motivated you to choose it as your Outreachy project?** + + Though I have been contributing to other projects before applying for + Outreachy (Dec 2024), I was just a user of the Git project. When it + comes to the Outreachy contribution period when I had to pick a + project, I picked both Git and LibreOffice. I picked Git as it is a + project I use every time, also the thought of contributing to a + project used by almost all the developers in the whole world was + definitely a dream coming true. To also maximize my getting selected + for Outreachy, I picked Git because it is written in C, + which many other participants are always scared to pick (going for the + hard thing). The story did not end there as I got selected for both + LibreOffice and Git and I had to choose one as my Outreachy projects. + It was a hard decision but I picked it mainly because the Git + community is a community where it is so easy to communicate with other + team members, and it is a community where I clearly know who is who and + what they do in the community. Also Git is more well recognised. + +* **How do you feel your contribution has impacted the Git community + or the broader open source ecosystem?** + + [My contribution](https://lore.kernel.org/git/20250215155130.1756934-1-usmanakinyemi202@gmail.com/) + makes a fundamental improvement to the Git v2 protocol by enabling + Git clients to share their operating system information via the user + agent string. This helps platforms like GitHub, GitLab, and others + gain visibility into which OS environments are interacting + with their servers. It significantly improves debugging, security + auditing, and telemetry, helping maintainers understand usage patterns + and tailor support or upgrade strategies accordingly. Since this + change is part of the core Git client, it means it is used by all Git + users. I’m proud to have contributed something with such + wide-reaching, foundational impact. + +* **Is there any aspect of Git that you now see differently after + having contributed to it?** + + Before contributing to Git, I saw it as a complex tool that "just + works". Although I knew Git was different from GitHub, I struggled to + clearly differentiate between the two. But after contributing, I could + clearly differentiate between the two and I now see Git as a carefully + designed software project with a strong emphasis on performance, + cross-platform compatibility, and community-driven development. + + I’ve come to appreciate the level of thought and care that goes into + every change, from writing clean patches and commit messages to + engaging in technical discussions and defending your design decisions. + + Contributing to Git isn’t also about hierarchical review; instead, + it’s a collaborative process where every contributor is expected to + take full ownership of their patches, understand the problem they are + trying to fix, the solution and explain their rationale clearly by + writing clean patches, commit messages and engaging in technical + discussions and defending your design decisions. In fact, there have + been moments when some of my contributions led to insights even long + time contributors hadn’t considered, including Junio Hamano. That + boosted my confidence not just in contributing to Git, but to other + software projects as well, i.e., I can get my patches accepted anywhere, + I just need to convince others that it actually solves a problem. + +* **How do you balance your contributions with other responsibilities + like work or school?** + + Seriously, it has not been easy, most of my contributions to all + open source projects have always been during college. But, I have sort + of made contributions to open source as one important aspect of my + life and also as a way to learn new technologies and also practice + whatever new skills I learnt. Contributing to projects millions of + people use is also definitely rewarding and satisfying. + +* **Can you share how Outreachy helped enhance your technical and + non-technical skills (like communication, project management, etc.)?** + + Technically, I have been able to improve my C programming and bash + scripting skills. Also reading and understanding very large codebases + like Git. Of course now I can call myself an expert in using Git as a + tool itself. + + To contribute to Git, you must be able to communicate well, as all the + Git workflows happen remotely and over mailing lists. Most of the time + in the Git community it is not about the correctness of your code -- it + is about how well you can communicate your rationale to the community + before your patches can be accepted. So, over time, as a Git + contributor, my communication skills in a technical environment have + really improved. + + I have also learnt to write clean code, organize my changes into well + formatted patches, and write clear commit messages. + +* **What was your biggest takeaway or learning from Outreachy that + you now apply regularly in your work?** + + I’d say my biggest takeaway from Outreachy is learning how to write + clear, structured commit messages. Git commits, like those in the + Linux kernel, follow a thoughtful format: describe the current state, + the problem, and the fix. From reading most of the commit messages in + Git, you would have understood and been able to visualize what the changes + will look like. It also makes it easy to track the changes to other + prerequisite commits. I have been using the Git commit messages format + in other projects and I really love it. + +* **What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it?** + + I think the challenge which I initially faced is sending patches to + Git, not really a big challenge though as I was able to make my first + patch in a few days after joining the community. And the reason is + that Git does not use GitHub or GitLab, something someone would have + thought they will be using. Git uses a mailing list just like the + Linux kernel. While writing this, I remember that I had a challenge + retrieving patches from the mailing list as my project depended on some + patches that were sent by my mentor previously. I had to use `git am`, + something I never used before. Help from my mentor really helped, + as well as reading through the "[Hacking Git](https://git.github.io/Hacking-Git/)" + page. + +* **Have you thought about mentoring new GSoC / Outreachy students?** + + Yeah, I am planning to put in as a mentor for the coming Outreachy + period and hopefully for GSoC also. I will be starting as a co-mentor + though. + +* **If you could get a team of expert developers to work full time on + something in Git for a full year, what would it be?** + + Smile, I will definitely say the Rustication of some parts of Git + which has been going on currently, I think one that has already been + integrated to Git is [libgit-rs](https://lore.kernel.org/git/cover.1738187176.git.steadmon@google.com/). + Rust seems to be a language that focuses more on safety/security, + and safety/security is very important in Git. I am also a Rustacean + so I should be able to help hopefully if that happens. + +* **If you could remove something from Git without worrying about + backwards compatibility, what would it be?** + + I really do not have anything in mind for now. + +* **What upcoming features or changes in Git are you particularly + excited about?** + + I think it is one of the [GSoC projects by Lucas](https://summerofcode.withgoogle.com/programs/2025/projects/fGgMYHwl). + I have been passively following the project. It is about introducing + a new Git sub-command (currently intended to be called `git repo-info`) + that will centralize data currently retrieved by `git rev-parse` in a + JSON format. + +* **What is your favorite Git-related tool/library, outside of Git + itself?** + + I think it's both GitHub and GitLab -- if I have to choose one, I will say GitHub. + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I started with [GitGitGadget](https://gitgitgadget.github.io/) initially + just to get my patches to the mailing list faster but, along the line + I switched to `git send-email` and really, it is more flexible and easy + to use than I thought of it. For my machine, I basically use Arch Linux + and Neovim as my text editor. + +* **How do you envision your own involvement with Git or other open + source projects in the future?** + + As I said earlier, open source has really been part of my life and it + has really helped me a lot in improving my skills, meeting new people + and even making some few bucks through internships. After my + internship at Outreachy, I did send patches to the Git community and I + planned to keep doing that. After Outreachy, I have contributed to a + few other projects like RISC-V and OSIPI (through GSoC). I currently + mentor people who want to start their open source journey, and I plan + to do more of it. I planned to keep contributing to open source + projects and hopefully get a job in open source. + +* **What is your advice for people who want to start Git development? + Where and how should they start?** + + I have been in many open source projects and see how their workflows + are, I will definitely say Git is one of the easiest and most + interesting projects to contribute to. The community members are + really supportive. Seriously, it is one of the best open source + communities I have been to. The best place to start is going through + the "[Hacking Git](https://git.github.io/Hacking-Git/)" page. It has + all the information on how to start contributing and you can make + your first contribution to Git. You should generally start with a + microproject which aims to introduce you to the Git contribution + workflow. Everything can be found above. Making your first contribution + to Git is actually very much easier than you might have thought. + Also, do not be scared to ask for help, Git developers are always ready to render help. + +* **Would you recommend other students or contributors to participate in + the GSoC, Outreachy or other mentoring programs, working on Git? + Why? Do you have advice for them?** + + Definitely, Outreachy and GSoC are very much interesting mentoring + programs to start your open source journey. They both really make it + easy to start contributing to open source. You get assigned to mentors + who are experts in open source and the organization. It is a way to get + skills you will never be able to get in your classroom and skills + needed to thrive and excel in the software engineering world. Apart + from skills, it is a way to have proof of work before graduation and + also gain global recognition. As I have said, Git is a well known and + recognized software project in the whole world, contributing to it is + an achievement on its own. + + _Shout session_ + + I would like to shout out to all Git contributors, you are doing a + great job! I would also like to shout out to my Outreachy mentor + Christian Couder, he was really supportive during my Outreachy + program! Thanks to the Git Rev teams also! + + +## Other News + +__Various__ + ++ [[LWN.net] A set of Git security-fix releases](https://lwn.net/Articles/1029182/) + by Jonathan Corbet on LWN\.net, and
+ [Multiple vulnerabilities fixed in Git](https://www.openwall.com/lists/oss-security/2025/07/08/4) + by Taylor Blau on oss-security mailing list. ++ [[ANNOUNCE] Git v2.50.1 and friends](https://public-inbox.org/git/xmqqzfdevcov.fsf@gitster.g/t/#u) + by Junio C Hamano on the Git mailing list. ++ [Launchpad](https://launchpad.net/) is [phasing out Bazaar code hosting](https://discourse.ubuntu.com/t/phasing-out-bazaar-code-hosting/62189). + This post provides a link to the [Migrate a Repository From Bazaar to Git](https://jugmac00.github.io/blog/migrate-a-repository-from-bazaar-to-git/) article. + + +__Light reading__ + ++ [Artisanal Handcrafted Git Repositories](https://drew.silcock.dev/blog/artisanal-git/) + by Drew Silcock on drew's dev blog. + This article talks about how to handmake your Git repositories without using `git` commands. + You might also learn a bit more about how Git works under the hood during the process. ++ [How to use git worktree effectively with Python projects](https://www.andreagrandi.it/posts/how-to-use-git-worktree-effectively-with-python-projects/) + (with the help of a simple [git-add-worktree.sh](https://gist.github.com/andreagrandi/542b438bf0017d93aff2b640037e3ce1) Bash script) + by Andrea Grandi on his blog. ++ [Managing Multiple Claude Code Sessions Without Worktrees](https://blog.gitbutler.com/parallel-claude-code/) + by Scott Chacon on Butler's Log (GitButler Blog). + With [Claude Code](https://www.anthropic.com/claude-code)'s new [lifecycle hooks](https://docs.anthropic.com/en/docs/claude-code/hooks), + [GitButler](https://gitbutler.com/) Git client auto-sorts simultaneous AI coding into separate branches, + without manual [use of `git worktree`](https://www.anthropic.com/engineering/claude-code-best-practices#c-use-git-worktrees). + With this feature you can write three features, and get three clean branches. ++ [wtp: A Better Git Worktree CLI Tool](https://dev.to/satococoa/wtp-a-better-git-worktree-cli-tool-4i8l) + by Satoshi Ebisawa on DEV\.to. + The [wtp](https://github.com/satococoa/wtp) tool was created to make + working with multiple tasks in parallel using [Claude Code](https://www.anthropic.com/claude-code) + easier than with `git worktree`. ++ [Automated repo maintenance via GitHub Copilot coding agent](https://blog.pamelafox.org/2025/07/automated-repo-maintenance-with-github.html) + by Pamela Fox on her Blogger-based blog. ++ [Git Worktrees: Git Done Right](https://www.nickyt.co/blog/git-worktrees-git-done-right-2p7f/) + by Nick Taylor on Just Some Dev blog (and also [on DEV\.to](https://dev.to/nickytonline/git-worktrees-git-done-right-2p7f)). ++ [I Lost My Git Stash, So I Built a Tool (VS Code Extension) to Share It](https://dev.to/karandeepsingh7070/i-lost-my-git-stash-so-i-built-a-tool-to-share-it-27bn) + by Karandeep Singh on DEV\.to. ++ [Git: share a full repository as a file with `git fast-export`](https://adamj.eu/tech/2025/07/15/git-share-fast-export/) + by Adam Johnson on his blog + (for some reason the post does not mention the alternative of using + [`git bundle`](https://git-scm.com/docs/git-bundle)). + + Adam Johnson is the author of "[Boost Your Git DX](https://adamchainz.gumroad.com/l/bygdx)" book, + first mentioned in [Git Rev News Edition #104](https://git.github.io/rev_news/2023/10/31/edition-104/), + then its updates in [#110](https://git.github.io/rev_news/2024/04/30/edition-110/) + and [#119](https://git.github.io/rev_news/2025/01/31/edition-119/). ++ [Conventional Commits makes me sad](https://srazkvt.codeberg.page/posts/2025-07-06-conventional-commits-makes-me-sad.html) + by Sarah Mathey on her Codeberg Pages powered Sarah's Website blog.
+ The [Conventional Commits](https://www.conventionalcommits.org/) specification + was first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/). ++ [Git experts should try Jujutsu](https://pksunkara.com/thoughts/git-experts-should-try-jujutsu/) + by Pavan Sunkara on his personal blog.
+ [Jujutsu (`jj`)](https://github.com/martinvonz/jj) is a version control system + first mentioned in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [Jujutsu For Busy Devs](https://maddie.wtf/posts/2025-07-21-jujutsu-for-busy-devs) and + by Madeleine Mortensen on her personal blog. ++ [Using Radicle CI for Development](https://radicle.xyz/2025/07/23/using-radicle-ci-for-development) + by Lars Wirzenius on Radicle Blog.
+ [Radicle](https://radicle.xyz/) is the distributed git hosting system, + first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/). ++ [Cutting GitHub out of the loop](https://www.circusscientist.com/2025/07/23/cutting-github-out-of-the-loop/) + (by deploying to a VPS with Git and SSH). + Written by tomjuggler on The Circus Scientist Site. ++ [Super Easy* 2-Stage Git Deployment](https://ratfactor.com/cards/super-easy-2-stage-git-deployment) + by Dave Gauer on Dave's Virtual Box of Cards. ++ [Guest Post: How I Scanned all of GitHub’s “Oops Commits” for Leaked Secrets](https://trufflesecurity.com/blog/guest-post-how-i-scanned-all-of-github-s-oops-commits-for-leaked-secrets) + by Sharon Brizinov on The Dig, the Truffle Security blog. ++ [Top 17 Essential Git Tools for Enhanced Developer Productivity](https://dev.to/vaib/top-17-essential-git-tools-for-enhanced-developer-productivity-7f3) + by vAlber on DEV\.to. + + + + +__Git tools and sites__ + ++ [DiffX - Next-Generation Extensible Diff Format](https://diffx.org/): + describes problem with Unified Diff format, and proposes as a solution + a new file format specification for Extensible Diffs, + fully backwards-compatible with existing tools, + while also being future-proof and remaining human-readable. ++ [git-phoenix](https://github.com/yaitskov/git-phoenix) is a command line tool + that does repository recovery after accidental removal or file system failure, + using [photorec](https://www.cgsecurity.org/wiki/PhotoRec) (or similar tool). + Written in Haskell, under 3-clause BSD license. ++ [wtp (Worktree Plus)](https://github.com/satococoa/wtp) is a Git worktree management tool + that extends git's worktree functionality with + automated setup, branch tracking, and project-specific hooks. + Written in Go, under the MIT license. ++ [GitNifty](https://gitnifty.js.org/index.html) is a robust and promise-based Git utility for Node.js, + offering developers smart, automation-ready commands for common Git operations. + Created for building CLI tools, automation scripts, or custom Git workflows. + Written in TypeScript, and released under the Apache License. ++ [difit](https://github.com/yoshiko-pg/difit) is a CLI tool + that lets you view and review local git diffs with a GitHub-style viewer + (in a browser). Written in TypeScript, under MIT license.
+ See [difit: Preview GitHub-like diffs locally before you push](https://dev.to/unhappychoice/difit-preview-github-like-diffs-locally-before-you-push-37gc) + by Yuji Ueki on DEV\.to. ++ [Flint](https://flintable.com/docs/flint/) is a Git-integrated code formatter + that lets each developer work in their preferred style locally, + while maintaining a consistent style remotely. + By automatically applying “local” and “remote” formatting passes during pull and push operations, + Flint prevents formatting noise in commits and code reviews. + It is currently in _alpha_ and is available exclusively on npm. + Written in Bash, under MIT license. ++ [DotProj](https://dotproj.ac-jr.com/) is a developer-centric CLI tool + designed to manage project-specific configuration files with Git versioning. + It helps keep your development environment settings organized, versioned, and synchronized + across multiple machines and projects. + DotProj uses Git commands (commit, push, pull, clone) making it intuitive for developers. + Written as a Bash shell script, under MIT license. ++ [git-remote-sqlite](https://github.com/chrislloyd/git-remote-sqlite) + is a [Git protocol helper](https://git-scm.com/docs/gitremote-helpers) + that helps you store a Git repository in a SQLite database. + Written in Zig, under MIT license. ++ [Backlog.md](https://backlog.md/) is a tool that turns any folder with a Git repo + into a self-contained project board, powered by plain Markdown files + and a zero-config CLI. Written in TypeScript, under MIT license. AI ready. ++ [git-resolve.sh](https://elixir.bootlin.com/linux/v6.16-rc3/source/scripts/git-resolve.sh) + is a Bash script that resolves a short git commit ID to its full SHA-1 hash, + which is particularly useful for fixing references in commit messages. + Under GPL-2.0 license. ++ [GitHub Trends](https://www.githubtrends.io/) is a service that + uses the GitHub API to bring you insightful metrics on your contributions, + broken by repository and language. ++ [DeepWiki](https://deepwiki.com/): AI-generated docs for any repo. + This service turns any public GitHub repo into up-to-date documentation you can talk to + (see for example [DeepWiki: git/git](https://deepwiki.com/git/git). + DeepWiki is the free public version of [Devin Wiki](https://docs.devin.ai/work-with-devin/devin-wiki) and [Devin Search](https://docs.devin.ai/work-with-devin/devin-search).
+ There are a few similar projects, like + [Open Source DeepWiki](https://github.com/AsyncFuncAI/deepwiki-open) and + [OpenDeepWiki](https://github.com/AIDotNet/OpenDeepWiki). ++ [GitHub Repository Maintenance Agent](https://github.com/pamelafox/github-repo-maintainer-agent/) + is an AI-powered agent for triaging failed [Dependabot](https://docs.github.com/en/code-security/getting-started/dependabot-quickstart-guide) pull requests + across one's GitHub repositories. The agent uses [Pydantic AI](https://ai.pydantic.dev/) + for LLM-based decisions and the GitHub API for repository, PR, and issue management. + Written in Python, under MIT license. ++ [tangled](https://tangled.sh/) is a new social-enabled git collaboration platform + built on the [AT Protocol](https://atproto.com/) (that powers the Bluesky social network). + Written in Go, under MIT license; note that it is in alpha stage of development.
+ Compare with: + + [Radicle](https://radicle.xyz/), a peer-to-peer, local-first code collaboration stack built on Git + (first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/)). + + [ForgeFed](https://forgefed.org/) (formerly GitPub), a federation protocol for software forges + (first mentioned in [Git Rev News Edition #69](https://git.github.io/rev_news/2020/11/27/edition-69/)). + + [`git-ssb`](https://scuttlebot.io/apis/community/git-ssb.html) + (see the [git-ssb-intro](https://github.com/hackergrrl/git-ssb-intro) guide), a + decentralized Git repo hosting and issue tracking on [Secure-ScuttleButt (SSB)](https://www.scuttlebutt.nz/) + (first mentioned in [Git Rev News Edition #26](https://git.github.io/rev_news/2017/04/19/edition-26/). + + [gitstr (`git str`)](https://github.com/fiatjaf/gitstr), + a tool to send and receive Git patches + over [Nostr](https://nostr.com/), using [NIP-34](https://github.com/nostr-protocol/nips/pull/997) + (first mentioned in [Git Rev News Edition #109](https://git.github.io/rev_news/2024/03/31/edition-109/)). ++ [Git With Me](https://sr.ht/~meejah/git-withme/) is a tool for + peer-to-peer, encrypted, ephemeral Git collaboration. + `git withme` provides a way for a single host to invite numerous peers + with short, one-time secure codes. The peers connect directly via + [Dilated Magic Wormhole channels](https://meejah.ca/blog/fow-wormhole-forward), + allowing collaborators to `git clone git://localhost/`. ++ [Radicle Desktop](https://desktop.radicle.xyz/) is a desktop application + that lets you interact with [Radicle](https://radicle.xyz/), + a peer-to-peer code collaboration and publishing stack. + Written in TypeScript for Node.js and Rust, using the Tauri framework. + Under GPLv3 license. ++ [GitBug: Git Learning Simulator](https://github.com/dvig14/gitbug) + is a CLI app that teaches Git through hands-on bug fixing. + It uses a realistic merge conflict scenario with visual feedback at every step. + The goal of the app is to help you learn by doing, not just reading. + Written in Python, under MIT license, in early stage (alpha).
+ Compare with: + + [Learn Git Branching](https://learngitbranching.js.org/), + mentioned first in [Git Rev News Edition #30](https://git.github.io/rev_news/2017/08/16/edition-30/). + + [Git Gud](https://nic-hartley.github.io/git-gud/), a visual web-based Git simulator, + meant to help understand Git better, announced by its author Nic Hartley in + [Git Gud at git](https://dev.to/nichartley/git-gud-at-git-5d9k). + First mentioned in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/). + + [Git Gud](https://github.com/benthayer/git-gud), a command line game + designed to help you learn how to use the Git version control system. + Written in Python by Ben Thayer. First mentioned in + [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/). + + [Oh My Git!](https://ohmygit.org/), an open source game about learning Git, + written using the Godot game engine ([source](https://github.com/git-learning-game/oh-my-git)). + There was a lightning talk about this game at FOSDEM 2021: + [Building a Git learning game: A playful approach to version control](https://fosdem.org/2021/schedule/event/git_learning_game/). + First mentioned in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/). + + [Git-Sim](https://github.com/initialcommit-com/git-sim) tool (written in Python) + to visually simulate Git operations in your own repos with a single terminal command. + Described in [Git-Sim: Visually Simulate Git Operations In Your Own Repos](https://initialcommit.com/blog/git-sim) + (mentioned in [Git Rev News Edition #95](https://git.github.io/rev_news/2023/01/31/edition-95/)) + and [Git-Sim 3 Month Dev Update: Community Response, New Features, & The Future](https://initialcommit.com/blog/git-sim-3-month-dev-update) + (mentioned in [Edition #98](https://git.github.io/rev_news/2023/04/30/edition-98/)). + + [Visualize Git](http://git-school.github.io/visualizing-git/) web app + that illustrates what's going on under the hood when you use common Git operations, + first mentioned in [Git Rev News Edition #107](https://git.github.io/rev_news/2024/01/31/edition-107/). + + [Devlands](https://devlands.com/), which is the game that creates + immersive experience to help learning Git. + First mentioned in [Git Rev News Edition #122](https://git.github.io/rev_news/2025/04/30/edition-122/). ++ [Ferriby](https://github.com/dawedawe/ferriby) is a CLI game + where you try to keep Ferrises alive and happy + by feeding them commits in your repositories. + Written in Rust, under MIT license. ++ [Pride Versioning](https://pridever.org/), + a [joking take](https://mastodon.online/@nikitonsky/113691789641950263) + on [Semantic Versioning (SemVer)](https://semver.org/). + + +## Releases + ++ Git [2.50.1 and friends](https://lore.kernel.org/git/xmqq5xg2wrd1.fsf@gitster.g/) ++ Git for Windows [2.50.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.50.1.windows.1), +[2.50.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.50.0.windows.2), +[2.49.1](https://github.com/git-for-windows/git/releases/tag/v2.49.1.windows.1) ++ GitHub Enterprise [3.17.4](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.4), +[3.16.7](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.7), +[3.15.11](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.11), +[3.14.16](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.16), +[3.17.3](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.3), +[3.16.6](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.6), +[3.15.10](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.10), +[3.14.15](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.15), +[3.17.2](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.2), +[3.16.5](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.5), +[3.15.9](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.9), +[3.14.14](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.14) ++ GitLab [18.2.1, 18.1.3, 18.0.5](https://about.gitlab.com/releases/2025/07/23/patch-release-gitlab-18-2-1-released/), +[18.2](https://about.gitlab.com/releases/2025/07/17/gitlab-18-2-released/), +[18.1.2, 18.0.4, 17.11.6](https://about.gitlab.com/releases/2025/07/09/patch-release-gitlab-18-1-2-released/) ++ Gerrit Code Review [3.10.7](https://www.gerritcodereview.com/3.10.html#3107), +[3.11.4](https://www.gerritcodereview.com/3.11.html#3114), +[3.12.1](https://www.gerritcodereview.com/3.12.html#3121) ++ GitKraken [11.2.1](https://help.gitkraken.com/gitkraken-client/current/), +[11.2.0](https://help.gitkraken.com/gitkraken-client/current/), +[11.1.1](https://help.gitkraken.com/gitkraken-client/current/), +[11.1.0](https://help.gitkraken.com/gitkraken-client/current/), +[11.0.0](https://help.gitkraken.com/gitkraken-client/current/) ++ GitHub Desktop [3.5.2](https://desktop.github.com/release-notes/), +[3.5.1](https://desktop.github.com/release-notes/) ++ Sourcetree [4.2.13](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.13.html) ++ GitButler [0.15.8](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.15.8), +[0.15.7](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.15.7) ++ Sublime Merge [Build 2110](https://www.sublimemerge.com/download) ++ Tower for Mac [13.1](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) ++ Tower for Windows [9.1](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) - [YT video](https://youtu.be/4pNRUz0bNIU) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Usman Akinyemi, brian m. carlson, Aditya Garg, +Erik-B. Ernst, Bruno Brito and Štěpán Němec. diff --git a/_posts/2025-08-31-edition-126.markdown b/_posts/2025-08-31-edition-126.markdown new file mode 100644 index 000000000..2dbfa9032 --- /dev/null +++ b/_posts/2025-08-31-edition-126.markdown @@ -0,0 +1,648 @@ +--- +title: Git Rev News Edition 126 (August 31st, 2025) +layout: default +date: 2025-08-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 126 (August 31st, 2025) + +Welcome to the 126th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of July and August 2025. + +## Discussions + + + + + + +### Support + +* [[BUG] `git pull` ignores `pull.autostash=true` configuration when used with `--git-dir` and `--work-tree` flags on a bare repository](https://lore.kernel.org/git/010001980c1ee007-2797fc86-fdf3-46e9-bec9-f8da2c9ebb8d-000000@email.amazonses.com/) + + Bryan Lee posted a bug report about the `pull.autostash` + configuration variable being ignored in a repository used to manage + his dotfiles. + + He expected his unstaged changes to be automatically stashed before + a pull when that configuration variable is set to `true`. Instead, + the command failed with an error message telling him to "Please + commit or stash them". So he thought Git ignored the autostash + configuration completely due to the setup, which consisted of a bare + repository and a separate work tree accessed through the following + alias: + + `$ alias dot='git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME'` + + Lidong Yan replied to Bryan admitting that he wasn't sure why the + autostash feature would be ignored when using the `--git-dir` and + `--work-tree` flags. He suggested setting `rebase.autostash` instead + of `pull.autostash` to `true` though. + + Bryan Lee thanked Lidong saying that `pull.autostash` was not a Git + configuration option and that `rebase.autostash` did work for + rebase operations. But he raised the issue that Git silently accepts + invalid configuration keys without any warning, which can cause + users to waste a lot of time debugging. + + Lidong replied with a suggestion to add a `git config verify` + subcommand. But Junio Hamano, the Git maintainer, chimed in + expressing doubts about such a command, as Git cannot distinguish + between a typo of a known variable and a legitimate custom variable + that a user or a third-party tool might be using. Lidong elaborated + that such a command could work by having Git maintain an internal + registry of all valid keys, which could also be extended by users + and tools for their own custom configurations. + + Johannes Sixt suggested that instead of building a complex + verification system, it would be easier to fix the origin of the + misconception that `pull.autostash` was the correct configuration. + + Junio replied to Johannes that having `git pull` pay attention to + `rebase.autostash` was at least a documentation failure, if not a + bug. He argued that users have different expectations for a + relatively safe local rebase compared to a pull from a remote, which + could be riskier. Also it didn't make sense for `git pull` to + respect `rebase.autostash` but not `merge.autostash`. + + Ben Knoble then chimed in with a counter-argument to Junio. He + reasoned that since a `git pull` that rebases is conceptually a + fetch followed by a rebase, it would be "far more inconsistent" if + it didn't honor the rebase configuration. Breaking that expectation + would be unnatural for users taught to think of pull in that + way. Following this logic, he also supported the idea that a merging + pull should respect `merge.autostash`. + + Then Junio wondered if introducing a new, dedicated `pull.autostash` + variable would be a good idea. But soon Lidong came up with + [a patch](https://lore.kernel.org/git/20250717030732.75106-1-yldhome2d2@gmail.com/) + to actually add this configuration variable. + + Eric Sunshine reviewed the patch and left a number of suggestions to + improve it in many ways. After some discussions with Lidong and + Junio, Lidong posted + [a version 2 of the patch](https://lore.kernel.org/git/20250720124334.12045-1-yldhome2d2@gmail.com/). + + This new version implemented a number of improvements based on the + discussion. Some tests were added. The logic was updated to fall + back to either `rebase.autostash` or `merge.autostash` depending on + whether the pull performed a rebase or a merge. The order of + precedence was also clarified: `pull.autostash` now overrides the + more general `rebase.autostash` and `merge.autostash` + settings. Finally, the documentation was updated with more precise + explanations. + + This feature was released recently as part of Git v2.51.0. + +## Developer Spotlight: Seyi Kuforiji + +_Editor’s note: This edition features a retrospective interview with a +contributor who contributed to Git through a mentoring program. We hope +the reflections shared by the Outreachy contributor will provide an +insightful perspective that benefits the community. As always, we +welcome your thoughts and feedback!_ + +* **Who are you and what do you do?** + + My name is Seyi Kuforiji, and I’m an Outreachy alum who worked on + [modernizing Git’s unit testing platform](https://seyi-kuforiji-902b48.gitlab.io/posts/week-1-Introduce-yourself) + by converting its homegrown unit test framework to use [Clar](https://github.com/clar-test/clar). + I studied geography at the University of Lagos, but my curiosity + and passion for computers and software drove me to start learning + Python and Git immediately after graduating. + + Since then, I’ve enjoyed exploring different areas of IT, from + software engineering to data science and DevOps, because I genuinely + love learning and experimenting with new tools. I also earned a + certification in Health Data Science and Precision Medicine from + Stanford University, which reflects my commitment to leveraging + technology to improve lives. Participating in Outreachy through Git + demonstrated to me the impact of open-source collaboration, and it has + strengthened my passion for developing solutions that give back to the + community. + + Outside of work, I’m usually diving into something new. Right now, the + [Linux graphics stack](https://lwn.net/Articles/955376/) has caught my + attention, but when I decide to give my brain a break from tech, I play + chess or watch sports. + +* **How did you initially become interested in contributing to Git, + and what motivated you to choose it as your Outreachy project?** + + Git was one of the first tools I ever learned years ago. At first, I + didn’t really understand it; I only knew a few commands like + `git clone`, `git add .`, and `git commit -m ""`, and I was + living life with just those. I remember during my 12-month software + engineering bootcamp, I helped some of my colleagues with Git because + I had this so-called “prior knowledge”, and for a while, I was treated + like a genius, at least until they caught up! + + So when I saw Git on the list of Outreachy projects, I knew right away + that this was where I needed to be: to deepen my understanding of the + tool and maybe level up from “genius” to something closer to expert + wizardry. These days, some say I’m a wizard, others say I’m a maestro, + but I’m just a humble guy who enjoys learning and sharing knowledge. + +* **How do you feel your contribution has impacted the Git community + or the broader open source ecosystem?** + + My contribution to Git, which was modernizing its homegrown unit + testing framework to use Clar, has helped improve Git’s testing + capabilities by making the tests more maintainable, easier to + understand, and easier to extend to cover more edge cases in the + future. Clar brings additional benefits such as clearer test + reporting, a more structured way to organize tests, and improved + readability, which makes the testing process more approachable for new + contributors. While this was primarily an internal-facing improvement, + I believe it plays an important role in maintaining the reliability of + Git’s functions and operations. A stronger testing framework makes it + easier for both new and experienced contributors to work with the + codebase confidently, which in turn strengthens Git for the millions + of people who rely on it every day. + +* **Is there any aspect of Git that you now see differently after + having contributed to it?** + + Like I said earlier, I started out only knowing a handful of Git + commands to do basic operations. My biggest takeaway since + contributing to Git has been discovering the full power of its + interactive rebase. I always saw rebase on cheat sheets but never + really experienced its capabilities until I worked more deeply with + Git. The best way I can describe it is that it feels like a time + machine: I make changes and commits, Git captures those states in + time, and with interactive rebase, I can go back, rewrite history, and + improve it as if it were the first time. + + I still find it so cool that in my text editor, I can see files I had + already deleted in later commits come back to life during a rebase. It + completely changed how I view Git, not just as a version control + system, but as a powerful storytelling tool for code. + +* **How do you balance your contributions with other responsibilities + like work or school?** + + I usually create a schedule with a clear timeframe dedicated to + working on the Git project. For example, during Outreachy, I set aside + specific blocks of time each day, treating it almost like a regular + job. This helped me stay consistent, avoid distractions, and make + steady progress. + + I’ve learned that balancing open-source contributions with other + responsibilities is all about structure and prioritization. By + planning my week ahead, I can make sure that my work, personal life, + and contributions don’t clash. Of course, I also try to stay flexible; + some weeks are more demanding than others, but having a framework + keeps me grounded and ensures I can keep giving my best to Git. + +* **Can you share how Outreachy helped enhance your technical and + non-technical skills (like communication, project management, etc.)?** + + My C and low-level engineering skills have improved immensely through + this experience. I now feel much more confident working in a large and + complex codebase, and I’ve built the mindset to take on hard problems + without shying away. This confidence is what’s encouraging me to dive + deeper into the Linux kernel, where I’ve been learning and + experimenting with the graphics stack and GPU drivers. My knowledge of + Git itself has also grown significantly, particularly with the + interactive rebase functionality, which has completely changed how I + think about version control and history management. + + On the non-technical side, I grew a lot in communication and project + management. I learned how to break down tasks into smaller, achievable + goals, track progress against deadlines, and ask for help effectively + when I was stuck. Collaborating with mentors and the wider Git + community also taught me the importance of giving clear updates in + blog posts and writing thoughtful commit messages. + + Overall, the experience didn’t just make me a better programmer; it + made me more disciplined, collaborative, and confident in working on + real-world projects. + +* **What was your biggest takeaway or learning from Outreachy that + you now apply regularly in your work?** + + My biggest takeaway from Outreachy is the balance between + understanding deeply and taking action. My mentor encouraged me to not + just know how things work but also to dig into why they work. At the + same time, I learned that it’s easy to get stuck in the learning + phase, waiting until you feel "ready." During my first few weeks, I + hesitated too much. What really helped me was realizing that you don’t + need to know everything before you start; you just need enough to + begin, and the rest comes as you build and iterate. That shift has + stayed with me and is something I now apply regularly in my life. + +* **What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it?** + + One of the biggest challenges I faced was understanding the Git + codebase. Git is a very large and complex project with many + interconnected parts, and even though my task was limited to the unit + testing section, I also needed to understand the underlying + functionality being tested. At first, it felt daunting, but I overcame + this by burning the midnight candle, digging deeper, and committing + myself to continuous learning. Bit by bit, things started to make + sense. What really helped was breaking down the complexity into + smaller pieces and focusing on one area at a time, while also asking + lots of questions and referring back to documentation. + +* **Have you thought about mentoring new GSoC / Outreachy students?** + + Yes, I hope to mentor future Outreachy interns if the opportunity arises. + +* **If you could get a team of expert developers to work full time on + something in Git for a full year, what would it be?** + + A first-class graphical interface officially maintained by the Git + project, for those who prefer using an app instead of the command + line. + +* **What upcoming features or changes in Git are you particularly + excited about?** + + I’ve been reading recent discussions on the Git mailing list about how + Git might evolve in the age of AI, particularly around enabling + integrations with AI agents. The idea of extending Git’s capabilities + so that AI tools can better understand, interact with, and even + automate certain workflows is quite exciting. For example, AI-assisted + code reviews, intelligent merge conflict resolution, or automated + repository maintenance could become more seamless if Git had + standardized ways for agents to plug into its internals. + +* **What is your favorite Git-related tool/library, outside of Git + itself?** + + GitHub and GitLab. + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I mostly work from the command line. For sending contributions, I use + `git format-patch` and `git send-email`, since I’m more comfortable with + CLI tools. + +* **How do you envision your own involvement with Git or other open + source projects in the future?** + + I intend to remain active in the Git community for many years by + making steady contributions. At the moment, I’m still learning and + exploring the project to identify areas where I can improve and add + value. Over time, I hope to grow into a consistent contributor and + take on more responsibility within the project. + +* What is your advice for people who want to start Git development? + Where and how should they start? + + For anyone starting Git development, I’d recommend a few key + resources. The "[Hacking Git](https://git.github.io/Hacking-Git/)” + guide is definitely a go-to resource for understanding how the + project is structured and how to navigate the codebase. + The [MyFirstContribution](https://git-scm.com/docs/MyFirstContribution) + page is also very helpful for learning how to get started with making + changes. Beyond that, the general Git documentation is valuable for + building a solid foundation. Starting small, asking questions, and + getting familiar with these resources can make the process much + smoother. + +* **Would you recommend other students or contributors to participate in + the GSoC, Outreachy or other mentoring programs, working on Git? + Why? Do you have advice for them?** + + 100% yes. Programs like GSoC and Outreachy give you the unique + opportunity to learn directly from some of the smartest and most + experienced contributors in the Git community. Having a mentor to + guide you through real contributions accelerates your learning, helps + you build confidence and good practices early on. I’d absolutely + recommend it. My advice would be: come with curiosity, patience, and + the willingness to learn. Don’t worry if you don’t understand + everything at first. Ask questions, read the documentation, and engage + with the community. The mentorship and the experience you gain are + invaluable. + + +## Other News + +__Various__ + ++ [What’s new in Git 2.51.0?](https://about.gitlab.com/blog/what-s-new-in-git-2-51-0/) + by Karthik Nayak on GitLab Blog. It describes performance optimizations + for `git push` and `git fetch` (most significant when using the "reftable" + backend for references), further plans for Git 3.0 (which can be + found in the [BreakingChanges document](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/BreakingChanges.adoc)), semi-removal of `git whatchanged` + (still available with `--i-still-use-this` flag), and marking + `git switch` and `git restore` as no longer experimental, + adding a new `--start-after` flag for `git for-each-ref` (that can be + combined with the `--count` flag to support pagination), etc. ++ [Highlights from Git 2.51](https://github.blog/open-source/git/highlights-from-git-2-51/) + by Taylor Blau on GitHub Blog. It describes cruft-free multi-pack indexes + (which currently require setting a new `repack.MIDXMustContainCruft` config option), + smaller packs with a "path walk" method of collecting objects when repacking + (which you can try out with the new `--path-walk` command-line option), + a variant of the internal stash representation that can be used for stash interchange + (with new `export` and `import` commands for `git stash`), etc. ++ [Xet is now the default storage option for new users and organizations](https://huggingface.co/changelog/xet-default-for-new-users) + at [Hugging Face](https://huggingface.co/), switching from [Git LFS](https://git-lfs.com/). + This includes moving existing repositories from LFS to Xet. + To get the most out of Xet storage [read the usage instructions in the Hub docs](https://huggingface.co/docs/hub/en/storage-backends#using-xet-storage). + Note that Xet remains backward compatible with legacy clients optimized for Git LFS. + + [XetHub](https://xethub.com/) was first mentioned in passing in + [Git Rev News #95](https://git.github.io/rev_news/2023/01/31/edition-95/), + and its [benchmark by XetHub against S3, DVC, and Git LFS](https://about.xethub.com/blog/benchmarking-the-modern-development-experience) + was mentioned in [Git Rev News Edition #113](https://git.github.io/rev_news/2024/07/31/edition-113/). + + Compare with [DagsHub launching Direct Data Access in 2022](https://dagshub.com/blog/launching-data-streaming-and-upload/). + [DagsHub](https://dagshub.com/) was first mentioned in + [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/), + then in [#85](https://git.github.io/rev_news/2022/03/31/edition-85/), + [#96](https://git.github.io/rev_news/2023/02/28/edition-96/), + [#107](https://git.github.io/rev_news/2024/01/31/edition-107/), and + [#113](https://git.github.io/rev_news/2024/07/31/edition-113/). + + +__Light reading__ + ++ [The future of large files in Git is Git](https://tylercipriani.com/blog/2025/08/15/git-lfs/) + by Tyler Cipriani on his blog. It describes how one can use + partial clone today (and large object promisors in the future, + which are work in progress) instead of using [Git LFS](https://git-lfs.com/) + or similar solutions like [git-annex](https://git-annex.branchable.com/) + (or no longer actively developed solutions like git-media and git-fat) + or [DVC](https://dvc.org/) (Data Version Control). ++ [Code Review Can Be Better](https://tigerbeetle.com/blog/2025-08-04-code-review-can-be-better/) + (than GitHub's default code review process) + by matklad (Alex Kladov) on the TigerBeetle blog.
+ Mentions their [`git-review`](https://github.com/tigerbeetle/tigerbeetle/pull/2732) + work-in-progress tool, and also the + + [Fossil](https://fossil-scm.org/) version control system with built-in project management + (first mentioned in [Git Rev News Edition #11](https://git.github.io/rev_news/2016/01/13/edition-11/)), the + + [NoteDb](https://gerrit-review.googlesource.com/Documentation/note-db.html) backend + for [Gerrit](https://www.gerritcodereview.com/) - which allows storing review state in Git, + (NoteDb was first mentioned in [Git Rev News Edition #40](https://git.github.io/rev_news/2018/06/20/edition-40/)), the + + [git-bug](https://github.com/git-bug/git-bug) tool that uses Git to store information about issues / bugs + (first mentioned in [Git Rev News Edition #43](https://git.github.io/rev_news/2018/09/19/edition-43/)), the + + [git-appraise](https://github.com/google/git-appraise) tool that uses Git to store information about reviews + (first mentioned in [Git Rev News Edition #11](https://git.github.io/rev_news/2016/01/13/edition-11/)), the + + [prr](https://doc.dxuuu.xyz/prr/index.html) ('pull request review') tool that brings mailing list style code reviews to GitHub PRs + (mentioned in [Git Rev News Edition #90](https://git.github.io/rev_news/2022/08/31/edition-90/)), the + + [git-pr](https://pr.pico.sh/) project that leverages Git native features to replace the entire pull request workflow, + (mentioned in [Git Rev News Edition #113](https://git.github.io/rev_news/2024/07/31/edition-113/)), and the + + [How Jane Street Does Code Review](https://www.janestreet.com/tech-talks/janestreet-code-review/) + article by Ian Henry on Jane Street Tech Talks site. ++ [Jujutsu + Radicle = ❤️](https://radicle.xyz/2025/08/14/jujutsu-with-radicle) + by fintohaps on Radicle Blog, describing how the author uses Jujutsu in tandem with Radicle. + + [Jujutsu (`jj`)](https://jj-vcs.github.io/jj/) is a Git-compatible version control system + written in Rust, and was first mentioned in + [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). + + [Radicle](https://radicle.xyz/), a peer-to-peer, local-first code collaboration stack built on Git, + was first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/). ++ [introducing spindle](https://blog.tangled.sh/ci) by Anirudh & Akshay on Tangled blog; + spindle is Tangled’s new CI runner built atop Nix and the AT Protocol. + + [Tangled.sh](https://blog.tangled.sh/intro) is a new social-enabled Git collaboration platform + built on top of the AT Protocol (which is behind [BlueSky](https://bsky.app/) + microblogging federated social media service). + First mentioned in [the previous edition of Git Rev News](https://git.github.io/rev_news/2025/07/31/edition-125/). + + Compare the [Using Radicle CI for Development](https://radicle.xyz/2025/07/23/using-radicle-ci-for-development) + article by Lars Wirzenius, also mentioned in [Git Rev News #125](https://git.github.io/rev_news/2025/07/31/edition-125/). + [Radicle](https://radicle.xyz/) is another distributed Git hosting system, + first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/). ++ [How we used Radicle with GitHub Actions](https://radicle.xyz/2025/05/30/radicle-with-github-actions): + Quick guide to trying Radicle without dropping GitHub or whatever CI you’re using. + Published by rudolfs (Rūdolfs Ošiņš) on Radicle Blog. ++ [Archive Legacy GitHub Repos with Subtree](https://dev.to/tonymet/archive-legacy-github-repos-with-subtree-1dj3) + by Tony Metzidis on DEV\.to, about how to use `git subtree` to consolidate + hundreds of legacy experimental repos into an archive, + preserving all of the commit history. ++ [I'll think twice before using Github Actions again](https://ninkovic.dev/blog/2025/think-twice-before-using-github-actions) + by Nemanja Ninković on their blog. ++ [Git without a forge](https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/) + by Simon Tatham on his quasiblog, describing how to interact with a bare Git repo, + and explaining why he personally does not use any of the Git forges. ++ [How I Cleaned Up My Git History Like a Boss (a.k.a. Fixing Wrong Author Emails)](https://dev.to/emrahg/how-i-cleaned-up-my-git-history-like-a-boss-aka-fixing-wrong-author-emails-19lb) + by Emrah G. on DEV\.to. The solution uses the (deprecated) `git filter-branch` tool; + the recommended replacement is [`git filter-repo`](https://github.com/newren/git-filter-repo). + Also, you can correct the _visible_ e-mail with the [`.mailmap`](https://git-scm.com/docs/gitmailmap) file + (changing what Git shows, without having to rewrite history). ++ [Revolutionizing Git Workflows: The MCP Git Commit Generator](https://www.bampouris.eu/blog/mcp-git-commit-generator/) + by Theoklitos Bampouris on his blog (and also [on DEV\.to](https://dev.to/theoklitosbam7/revolutionizing-git-workflows-the-mcp-git-commit-generator-530m)), + about using Agentic AI and an LLM chatbot, + leveraging the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction). + The generated commit message will follow [Conventional Commits](https://www.conventionalcommits.org/) conventions.
+ Note: please read the proposed commit message before accepting it, + especially for more complex changes. While AI agents can take information + from changes and from an issue tracker, they cannot write whys of the change; + they cannot access your thoughts. + + [Git Rev News Edition #97](https://git.github.io/rev_news/2023/03/31/edition-97/) + lists a few other tools that use the GPT-3 / ChatGPT Large Language Model (LLM) + to help write commit messages. ++ [Better git status](https://purpleidea.com/blog/2025/08/04/better-git-status/) + by James (@purpleidea) on his blog. He uses `git alias` which examines + the terminal width, and then `git status --column=nodense` if the terminal is wide enough. ++ [Some Pretty Cool Git Tools To Save Your Sanity](https://fev.al/posts/git-tools/) + by Charles Féval on his blog. + Mentions `git revise` for splitting pull requests (PRs), + and custom `git backup`, `git reparent`, `git split`, `git move-branch`, and `git bookmark` commands. ++ [Using Git worktrees for development](https://blog.kulman.sk/git-worktree/) + by Igor Kulman on his blog. ++ [Curing A Case Of Git-UX](https://oppi.li/posts/curing_a_case_of_git-UX/) + by Akshay on their blog; describes how one can improve git worktree UX + with the help of [fzf](https://github.com/junegunn/fzf) + (or [skim](https://github.com/lotabout/skim) or [fzy](https://github.com/jhawthorn/fzy)), + and shell functions. + + See also [Improving shell workflows with fzf](https://seb.jambor.dev/posts/improving-shell-workflows-with-fzf/), + mentioned in [Git Rev News Edition #74](https://git.github.io/rev_news/2021/04/30/edition-74/). ++ [Making my GitHub heatmap widget](https://leanrada.com/notes/github-heatmap-widget/) by + Lean Rada on their blog. The created tool partially scrapes and reformats HTML input, + but is constructed in such way that it could consume JSON from GitHub API instead. ++ [TryHackMe - Git Happens](https://jacen.moe/blog/20250805-tryhackme-git-happens/) + by Jacen Sekai on his blog, about [Git Happens](https://tryhackme.com/room/githappens): + an easy-ranked box on [TryHackMe](https://tryhackme.com/), website for + hands-on cyber security training through real-world scenarios. ++ [The Ingredients of a Productive Monorepo](https://blog.swgillespie.me/posts/monorepo-ingredients/) + by Sean Gillespie on his blog. + + You can find a definition of "monorepo" and a list of various tools on the [Monorepo.tools](https://monorepo.tools/) site, + which was first mentioned in [Git Rev News Edition #84](https://git.github.io/rev_news/2022/02/28/edition-84/). ++ [Git Branching Explained: Base, Topic, and Parent Branches](https://www.git-tower.com/blog/base-topic-parent-branches) + by Bruno Brito on Tower Blog. ++ [Git and jujutsu: in miniature](https://lottia.net/notes/0013-git-jujutsu-miniature.html) + by Charlotte (lottia) on her blog (2024). ++ [Git Interactive Rebase TODO Order is Wrong](https://salferrarello.com/git-interactive-rebase-order-is-wrong/) + by Sal Ferrarello on his blog (2019), stating a personal preference for stack-like order, + with latest commits appearing on the top.
+ The author even wrote a Vim plugin, + [Interactive Rebase Reverse Vim](https://github.com/salcode/vim-interactive-rebase-reverse), + to reverse the order of the commits in an interactive `git rebase`. ++ [Every line of code is always documented](https://mislav.net/2014/02/hidden-documentation/) + by Mislav Marohnić on his blog (2014). The article describes how to + extract information about a code snippet from project history using `git blame`, + 'pickaxe' search with `git log -S`, and a + [git-churn](https://github.com/garybernhardt/dotfiles/blob/f0c0ff92209e5aed4fa3ef6faf056eb9944a8f12/bin/git-churn) script, + and how to stay on the right side of history + (among others, to be able to use this technique effectively). + + + + +__Git tools and sites__ + ++ [WRKFLW](https://github.com/bahdotsh/wrkflw) is a command-line tool + for validating and executing GitHub Actions workflows locally, + without requiring a full GitHub environment. + It helps developers test their workflows directly on their machines + before pushing changes to GitHub. + Written in Rust, under MIT license. + + Compare with the [Act](https://github.com/nektos/act) command line tool + to run your GitHub Actions locally, using the Docker Engine API. + Written in Go, under MIT license. + Mentioned in [Git Rev News Edition #113](https://git.github.io/rev_news/2024/07/31/edition-113/). ++ [Setup DVC Action](https://github.com/marketplace/actions/setup-dvc-data-version-control) + by Iterative is a JavaScript action that can be used as a step in GitHub Actions.
+ [DVC](https://dvc.org) (Data Version Control) was first mentioned + in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/) + and many times since (most recently in [Edition #116](https://git.github.io/rev_news/2024/10/31/edition-116/)). ++ [Lappverk](https://codeberg.org/natkr/lappverk/) is a tool for modifying other people's software. + It works by keeping a series of `.patch` files as its source of truth + (like [quilt](https://savannah.nongnu.org/projects/quilt)), + but using temporary Git repositories as an interface to modify the patches, + rather than implementing its own version control system from scratch. + Written in Rust, under Apache 2.0 License. + Started out as Patchable internal tool.
+ You might also be interested in reading the announcement blog post: + [Modifying Other People's Software](https://natkr.com/2025-08-14-modifying-other-peoples-software/) + by Natalie Klestrup Röijezon (natkr) on natkr's ramblings. + + Compare [patchwork](http://jk.ozlabs.org/projects/patchwork/) - a web-based patch tracking system + designed to facilitate contribution and management of contributions to an open-source project, + first mentioned in [Git Rev News Edition #20](https://git.github.io/rev_news/2016/10/19/edition-20/). + + Compare [Stacked Git (StGit)](https://stacked-git.github.io/), + an application for managing Git commits as a stack of patches, + first mentioned in [Git Rev News Edition #17](https://git.github.io/rev_news/2016/07/20/edition-17/). + + Compare [B4 Tools](https://github.com/mricon/b4), a helper utility + to work with patches made available via a [public-inbox](https://public-inbox.org/README.html) archive like [lore.kernel.org](https://lore.kernel.org/). + This tool is written to make it easier to participate in patch-based workflows, + like those used in the Linux kernel development. + First mentioned in [Git Rev News Edition #61](https://git.github.io/rev_news/2020/03/25/edition-61/). ++ [patch-hub](https://github.com/kworkflow/patch-hub/tree/unstable) is a TUI tool + that streamlines the interaction of Linux developers + with patches archived on [lore.kernel.org](https://lore.kernel.org/). + Written in Rust, under GPL 2.0 license.
+ It is a spin-off of [kw](https://github.com/kworkflow/kworkflow), + a tool for helping Linux kernel developers in everyday tasks + (which is written in shell, and is under GPL 2.0 license). ++ [GitGenius](https://selvaneyas.github.io/gitgenius) is a smart and simple CLI tool + that explains Git errors in plain English and helps you fix them quickly. + Written in Python, under MIT license. + + See also [thefuck](https://github.com/nvbn/thefuck), a command line application + which corrects your previous console command (for example Git command) + if you made an error (like typos in command name), and it _didn't_ do what you wanted; + the tool was first mentioned in [Git Rev News Edition #101](https://git.github.io/rev_news/2023/07/31/edition-101/). + + Compare the [Oh Shit, Git!?!](http://ohshitgit.com/) / [Dangit, Git!?!](https://dangitgit.com/) + website by Katie Sylor-Miller, + first mentioned in [Git Rev News Edition #19](https://git.github.io/rev_news/2016/09/14/edition-19/). ++ [GIT.WTF!?!](https://git.wtf/) is a website with articles in which you can + find solutions to your Git problems, + along with tips & tricks to improve your Git workflows. ++ [GITHUB2FORGEJO](https://github.com/PatNei/GITHUB2FORGEJO) + is a Bash script for migrating all repositories from a GitHub user account + to a specified Forgejo instance. It supports mirroring or one-time cloning + and includes a cleanup feature for removing repositories on Forgejo + that no longer exist on GitHub. + Under GPL 3.0 license.
+ Based on [GitHub2Forgejo](https://github.com/RGBCube/GitHub2Forgejo) + Nushell script, also under GPL 3.0 license. + + [Forgejo](https://forgejo.org/) is a self-hosted lightweight software forge, + which started as a “soft” fork of Gitea (itself a fork of Gogs), + and was first mentioned in passing in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/). ++ [git-revise](https://git-revise.readthedocs.io/) is a Git subcommand and Python library + for efficiently updating, splitting, and rearranging commits. + Under MIT License.
+ The [Introducing git-revise](https://mystor.github.io/git-revise.html) + blog post was mentioned in [Git Rev News Edition #54](https://git.github.io/rev_news/2019/08/21/edition-54/). ++ [git-tools](https://github.com/cfe84/git-tools) is a set of additional Git commands + to "help you make crazy stuff in a very unsafe way". + Includes `git backup`, `git move-branch`, `git reparent` (similar to `git rebase --onto`), + `git split`, `git bookmark`, `git newbranch`, and `git get`. + Written in Go, under GPL 2.0 license. ++ [git-fetch-file](https://github.com/andrewmcwattersandco/git-fetch-file) is a utility + for importing specific files from other Git repositories into your own project, + while keeping a manifest (`.git-remote-files`) that remembers where they came from + and what commit they belong to. + Written in Python, under GPL 2.0 license. ++ [git-word-blame](https://framagit.org/mdamien/git-word-blame) + is a tool that shows word-by-word authors of a file, creating TSV and HTML files. + Written in Python, under GPL 3.0 license. + The README includes links to a few alternative tools in the "See also" section. ++ [`gguser`](https://github.com/withshubh/gguser) is a CLI tool + to easily switch between different Git user profiles. + It simplifies managing multiple GitHub or GitLab accounts + by allowing users to switch between profiles effortlessly. + Written in JavaScript for Node.js (npm), under Apache 2.0 License. ++ [GitLabForm](https://gitlabform.github.io/gitlabform/) is a specialized configuration-as-code tool + for GitLab's application settings, groups, projects, and more, + using hierarchical configuration written in YAML. + Written in Python, under MIT license.
+ See the [GitlabForm for Gitlab repository automation](https://www.mikestreety.co.uk/blog/gitlabform-for-gitlab-repository-automation/) + blog post by Mike Street on his blog. ++ [`gmap`](https://github.com/seeyebe/gmap) is a fast command-line tool + (with terminal interface) to explore Git activity - heatmaps, churn, authorship, and more. + It helps you understand your Git repository at a glance - not just what changed, + but when, how much, and by whom. + Written in Rust, under MIT license. ++ [Ayllu](https://ayllu-forge.org/) is a code forge optimized for single instance deployments. + It is still a work in progress. Written in Rust, under AGPL license. ++ [DiffMem](https://github.com/Growth-Kinetics/DiffMem) is a lightweight, + Git-based memory backend designed for AI agents and conversational systems. + It uses Markdown files for human-readable storage, + Git for tracking temporal evolution through differentials, + and an in-memory BM25 index for fast, explainable retrieval. + This project is a proof-of-concept (PoC). + Written in Python, no license (!). + + +## Releases + ++ Git [2.51.0](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/), +[2.51.0-rc2](https://lore.kernel.org/git/xmqqh5ybcfwt.fsf@gitster.g/), +[2.51.0-rc1](https://lore.kernel.org/git/xmqqikizoybn.fsf@gitster.g/), +[2.51.0-rc0](https://lore.kernel.org/git/xmqqms8f5889.fsf@gitster.g/) ++ Git for Windows [v2.51.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.0.windows.1), +[v2.51.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.0-rc2.windows.1), +[v2.51.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.0-rc1.windows.1), +[v2.51.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.0-rc0.windows.1) ++ GitLab [18.3.1, 18.2.5, 18.1.5](https://about.gitlab.com/releases/2025/08/27/patch-release-gitlab-18-3-1-released/), +[18.3](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/), +[18.2.4](https://about.gitlab.com/releases/2025/08/18/gitlab-18-2-4-released/), +[17.11.7](https://about.gitlab.com/releases/2025/08/15/gitlab-17-11-7-released/), +[18.2.2, 18.1.4, 18.0.6](https://about.gitlab.com/releases/2025/08/13/patch-release-gitlab-18-2-2-released/) ++ Gerrit Code Review [3.10.8](https://www.gerritcodereview.com/3.10.html#3108), +[3.11.5](https://www.gerritcodereview.com/3.11.html#3115), +[3.12.2](https://www.gerritcodereview.com/3.12.html#3122) ++ GitHub Enterprise [3.17.5](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.5), +[3.16.8](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.8), +[3.15.12](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.12), +[3.14.17](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.17) ++ GitKraken [11.3.0](https://help.gitkraken.com/gitkraken-client/current/) ++ Git Cola [4.14.0](https://github.com/git-cola/git-cola/releases/tag/v4.14.0) ++ GitButler [0.15.16](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.15.16), +[0.15.15](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.15.15) ++ Sublime Merge [Build 2112](https://www.sublimemerge.com/download) ++ Tower for Mac [14](https://www.git-tower.com/blog/tower-mac-14) ([YouTube video](https://youtu.be/WYhtxBAzOB0)) ++ Kinetic Merge [1.9.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.9.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Štěpán Němec, Gerard Murphy, +Seyi Kuforiji and Bruno Brito. diff --git a/_posts/2025-09-30-edition-127.markdown b/_posts/2025-09-30-edition-127.markdown new file mode 100644 index 000000000..6cff400ee --- /dev/null +++ b/_posts/2025-09-30-edition-127.markdown @@ -0,0 +1,475 @@ +--- +title: Git Rev News Edition 127 (September 30th, 2025) +layout: default +date: 2025-09-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 127 (September 30th, 2025) + +Welcome to the 127th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of August and September 2025. + +## Discussions + + + + + +### Support + +* [Doing blobless clone by default; switching between blobless, treeless and full clones by a command](https://lore.kernel.org/git/79ed51fbd94ec2793ab0388b33963b366e48c590.camel@aegee.org/) + + Dilyan Palauzov (Дилян Палаузов) sent an email to the Git mailing + list where he proposed making blobless cloning + (`--filter=blob:none`) the default behavior for `git clone` via a + global configuration option. He also suggested adding a command to + download all locally missing history, a command to convert a + repository to a pure treeless or pure blobless clone, and a config + option to make blobless clone the default behavior when running just + `git clone `. + + He said that most users used `git clone` to build or change software, not to + immediately analyze history with commands like `git log`. Therefore, + a reduced data download would speed up initialization, save + bandwidth, and reduce server load. + + Kristoffer Haugsbakk replied saying the proposed command to + "download all locally missing history" for treeless and blobless + clones "sounds like git-backfill(1)". He also noted that he had + "never used blob/treeless" clones himself. + + Derrick Stolee, who likes to be called just "Stolee", and who + contributed the `git backfill` command, replied to Kristoffer + confirming that `git backfill` is intended to assist with downloading + the missing blobs in a blobless partial clone. + + About treeless clones though, he noted that `git backfill` is not + optimized for them, and that treeless clones are generally not + intended for "refilling," as downloading missing trees is + "particularly expensive". + + Stolee suggested using `scalar clone`, which is already shipped with + Git, instead of making blobless cloning the default, as + `scalar clone` was contributed partly to allow users to opt into a + version of `git clone` that incorporates "best practices and + advanced features as they are developed", while `git clone` + maintains backward compatibility. He recognized that `scalar clone` + might not be "discoverable enough" though. + + Junio Hamano replied to Stolee's suggestion that a future command + like `git big-clone` could emerge from the feedback on + `scalar clone`. He said a separate command like `git big-clone` + would not be discoverable enough either. Instead as a new feature + matures, it should be a welcome change for `git clone` to borrow it + as a new option. Such optimizations (like those for large repos) + could be automatically enabled based on the repository's size, + provided it was done with end-user consent. + + Patrick Steinhardt replied to Stolee about treeless clones. He + agreed that the existing command `git backfill` is not optimized for + refilling treeless clones, and proposed an idea to backfill trees by + batching based on depth, but concluded that this method was + "definitely not ideal" and would perform "way worse compared to + backfilling blobs". + + Patrick also said that for these reasons he generally recommends not + to use treeless clones at all. + + Stolee replied to Patrick agreeing with the general caution + regarding treeless clones, and that they were "not a good approach + for doing ongoing work as a human". + + However he noted that they are useful if a user needs the speed of a + shallow clone combined with the ability to analyze commit history + (though with no path history) for an "ephemeral scenario like a CI + build". But they are a "tool for a very narrow case" and should only + be used by those who understand how to avoid their pitfalls. Patrick + then agreed with that point of view. + + Konstantin Ryabitsev, the system administrator for kernel.org, + replied to the original email from Dilyan about making blobless + clones the default behavior for `git clone`. He said a + counter-rationale to this proposal was that shallow clones (which + include blobless clones) generate significantly more load on the + server side. + + The reason is that for these partial clones, no pre-existing packs + are available for the operation, requiring more computation from the + server. So changing the default behavior for `git clone` could + likely result in slower clones for everyone and lead to more + unavailable servers due to the high load. + + Ben Knoble also replied to Dilyan's original email by opposing the + proposal to make blobless clones the default behavior while agreeing + that managing this preference via a config option was a reasonable + compromise. + + Ben's opinion was that such a default behavior would defeat the + "tremendous advantage of distributed version control", which is about + having the whole repository available independently. It would also + make some of his use cases more difficult as he frequently clones + repositories specifically to run "history spelunking searches". + + He noted that he primarily deals with repositories where the issue + isn't about clones, but about mismanaging large binary files in + history, which causes large blobs and clone times. + +## Developer Spotlight: Toon Claes + +* **Who are you and what do you do?** + + I'm Toon from Belgium. My name is pronounced like "tone" (rhymes with + "bone"), and not like the "toon" in "cartoon", but usually I'm already + happy if people remember my name 😉. + + I'm employed by GitLab for more than 8 years, and since late 2024 I've + been part of the Git team, contributing to the Git project. I've started + my professional career in 2008 building software for a payment terminal + running embedded GNU/Linux using C & C++. Later I've transitioned into + doing web and mobile development for a while. And now recently, I've + been circling back to more lower-level programming, contributing to Git + using C. + +* **What would you name your most important contribution to Git?** + + I'm fairly new in the Git community, but recently I've been working on + adding [`git last-modified`(1)](https://git.github.io/htmldocs/git-last-modified.html). + It's a sub-command that will be released in Git v2.52. This command + finds the commit that last modified each path in a tree. It can + be used on forges (like GitLab, GitHub, Codeberg), to show commit + data in a tree view. + +* **What are you doing on the Git project these days, and why?** + + The subcommand [`git last-modified`(1)](https://git.github.io/htmldocs/git-last-modified.html) + was recently merged in the 'master'. But there's more work to be + done to improve its performance. + +* **If you could get a team of expert developers to work full time on + something in Git for a full year, what would it be?** + + Once data is committed to Git, and it's made part of the history (i.e. + committed or merged into the default branch), it's trapped forever. This + is a core principle of Git: you cannot rewrite history without changing + commit hashes. This is very powerful, but also problematic in some + scenarios. + + For example, at my $DAYJOB we receive commonly the request from + customers to remove confidential or sensitive information from a Git + repository. This is not possible without rewriting history. Or when, by + accident, large files are committed to Git, you cannot get them out + (without rewriting history). Or people might want to remove/change + their personal information in a repository, for example when they + transition genders. + + Can we (and should we?) build something that removes and overwrites + pieces of history, without changing commit hashes? It's a slippery + slope, because from experience I know Git users are very creative and + might use this feature in ways it was not intended for. + +* **If you could remove something from Git without worrying about + backwards compatibility, what would it be?** + + The use of the double `..` and triple `...` dot notation in + [`gitrevisions(7)`](https://git-scm.com/docs/gitrevisions#_dotted_range_notations) + and `git diff(1)`. I even once ranted about it in [a video](https://www.youtube.com/watch?v=phThP8DwJVs). + +* **What is your favorite Git-related tool/library, outside of + Git itself?** + + I'm a big fan of [Magit][1]. It's arguably the best tool to interact + with Git and I also learned a lot from it. I consider myself an + advanced Git user, but I wouldn't be able to split up changes in + several commits without [Magit][1]. + +[1]: https://magit.vc/ + +* **Do you happen to have any memorable experience w.r.t. contributing + to the Git project? If yes, could you share it with us?** + + One of my earliest contributions to Git was a bug fix in the code used + by `git bundle create`. We noticed sometimes references didn't end up in + the bundle. After a lot of digging I submitted a patch that removed + about 30 lines of code written way back in 2007. The code from 2007 + caused references to be skipped if they were modified while the + `git bundle create` process was running. But it wasn't needed anymore + due some changes made in 2013, although no one ever realized that. + You can read more about it [in the patch][2]. + + It was really satisfying to submit a patch that was nothing more than + code deletion of really old code (and adding some tests). And it taught + me to write a good commit message, which I was praised for by + [the maintainer][3]. It was a very nice experience as a newcomer in the + community. + +[2]: https://lore.kernel.org/git/20241211-fix-bundle-create-race-v3-1-0587f6f9db1b@iotcl.com/ +[3]: https://lore.kernel.org/git/xmqqzfl4l22t.fsf@gitster.g/ + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I mostly live in Emacs and my terminal (zsh). I consume email in Emacs + using [notmuch][4]. To submit patches I use [b4][5], which I also + sometimes use to pull in patches. But I also sometimes pull in + the branches from [Junio's fork][6] or the fork shared across + my colleagues. + + In Git, I compile and unit test changes using Meson. Its use was + introduced in the Git project around the [end of 2024][7]. It's + reliable because it prevents me from forgetting to recompile + before running tests; it's fast because it parallelizes compilation + by default and automatically [uses Ccache][8]; it allows out-of-tree + builds, which is really convenient if you want to benchmark various + revisions of Git. + +[4]: https://notmuchmail.org/doc/latest/notmuch-emacs.html +[5]: https://github.com/mricon/b4 +[6]: https://github.com/gitster/git +[7]: https://lore.kernel.org/git/20241206-pks-meson-v11-0-525ed4792b88@pks.im/ +[8]: https://mesonbuild.com/Feature-autodetection.html#ccache + +* **What is your advice for people who want to start Git development? + Where and how should they start?** + + Learn to navigate [the mailing list archive][9]. It lacks structure so + things can be hard to find, but there's so much information up there. If + you're interested in a topic, or you think you've found the bug, start digging. + Use [`git blame(1)`][10] to find the commit that introduced the changes + and look up the conversation around it in the mailing list archive. + This will help you understand why some decisions are made. Also it + familiarizes you with the people in the community, how they think, + how they communicate, and what's expected from you. Having the + knowledge from those conversations can help you build a strong case + whenever you're submitting a feature change or bug fix. + +[9]: https://lore.kernel.org/git +[10]: https://git-scm.com/docs/git-blame + + +## Other News + +__Various__ + ++ [What’s next for Git? 20 years in, the community is still pushing forward](https://github.blog/open-source/whats-next-for-git-20-years-in-the-community-is-still-pushing-forward/) + by Lee Reilly on GitHub Blog - mainly about + the [Git Merge 2025 talks lineup](https://git-merge.com/#speakers). ++ [Git Developers Debate Making Rust Mandatory](https://www.phoronix.com/news/Git-Weighs-Mandatory-Rust) + by Michael Larabel on Phoronix. ++ [A policy for `Link:` tags](https://lwn.net/Articles/1037069/) (for Linux), + by Jonathan Corbet on LWN\.net. ++ [Working almost continuously for six months](https://www.linkedin.com/feed/update/urn:li:activity:7378744230275350528/), Yasin Dehfuli completed the [Persian translation of the ProGit book](https://git-scm.com/book/fa/v2). ++ An initiative [to refresh the look and content of https://git-scm.com/](https://github.com/git/git-scm.com/issues/2046) has been kicked off by Toon Claes. Contributions welcome, especially from visual designers! + + +__Light reading__ + ++ [git-flow-next: The Next Iteration of Advanced Git Workflows](https://www.git-tower.com/blog/git-flow-next) + by Bruno Brito on Tower Blog. ++ [A kludgy new way to git-blame](https://benknoble.github.io/blog/2025/09/17/blame/) + by D. Ben Knoble on his Junk Drawer personal blog, + about the new `git-greb` script that feeds `git grep` to `git blame` + (with appropriate options) in order to blame matching lines. ++ [My new git utility `what-changed-twice` needs a new name](https://blog.plover.com/2025/09/21/#what-changed-twice) + by Mark Dominus (陶敏修) on his The Universe of Discourse blog, + about the tool to help get related changes into the same commit. ++ [Supercharge your Git workflows](https://about.gitlab.com/blog/supercharge-your-git-workflows/) + by Darwin Sanoy on GitLab Blog, about how to + optimize `git clone` operations in any environment, reducing clone time and disk space, + with the [Git Much Faster](https://gitlab.com/gitlab-accelerates-embedded/misc/git-much-faster) script. + + Compare with [Scalar](https://github.com/microsoft/scalar), + a tool that helps Git scale to handle large Git repositories + by enabling some advanced Git features. + Scalar was first mentioned in [Git Rev News Edition #60](https://git.github.io/rev_news/2020/02/19/edition-60/), + and now is part of Git: [scalar - A tool for managing large Git repositories](https://git-scm.com/docs/scalar). + [The Story of Scalar](https://github.blog/2022-10-13-the-story-of-scalar/) + was mentioned in [Edition #92](https://git.github.io/rev_news/2022/10/26/edition-92/). ++ [The Origin Story of Merge Queues](https://mergify.com/blog/the-origin-story-of-merge-queues) + by Julien Danjou on Mergify Blog. + This article traces merge queues history + (from Bors and Homu to Bulldozer, Kodiak, Mergify, GitHub and GitLab), + why they emerged, and how they became a standard in modern software development. + + [Mergify.com](https://mergify.com/), + a web service for automating pull requests (free for open-source projects), + was mentioned in [Git Rev News Edition #87](https://git.github.io/rev_news/2022/05/26/edition-87/). ++ [Git - Fun Facts](https://dev.to/rubansi/git-fun-fact-45de) + by Rubansi Vincent on DEV\.to: + a mix of fun and surprising facts about Git. ++ [diff --stat for binary files (in the Jujutsu version control system)](https://neugierig.org/software/blog/2025/08/jj-binary-stat.html) + by Evan Martin on neugierig\.org: Tech Notes. + + [Jujutsu (`jj`)](https://jj-vcs.github.io/jj/) is a Git-compatible version control system + written in Rust, first mentioned in + [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [Jujutsu For Busy Devs, Part 2: "How Do I...?"](https://maddie.wtf/posts/2025-07-21-jujutsu-for-busy-devs/entry/1) + by Madeleine Mortensen, continues the [Jujutsu For Busy Devs](https://maddie.wtf/posts/2025-07-21-jujutsu-for-busy-devs) + series, mentioned in [Git Rev News Edition #125](https://git.github.io/rev_news/2025/07/31/edition-125/). ++ [Dear GitHub: no YAML anchors, please](https://blog.yossarian.net/2025/09/22/dear-github-no-yaml-anchors) + by William Woodruff (yossarian) on his ENOSUCHBLOG blog. + He says that they are redundant with existing functionality, + make CI/CD human and machine comprehension harder, + and their support in GitHub Actions does not introduce any new, previously unavailable features. ++ [Custom VC-Focused Emacs Functions I Created to Enhance My Git Workflow](https://www.rahuljuliato.com/posts/vc-git-functions) + by Rahul M. Juliato on Rahul's Blog. ++ [How to delete all squash-merged local git branches with one terminal command](https://whitep4nth3r.com/blog/how-to-delete-all-squash-merged-local-git-branches-with-one-terminal-command/) + (which you probably shouldn't use), + by Salma Alam-Naylor on her blog. ++ [finding deleted content using git logs](https://kjelsrud.dev/blog/finding-deleted-content-using-git-logs/) + by Sindre Kjelsrud, also known as “Sid”, on Sids' blog: + a short note on `git log -S`. ++ [Git exclude, a handy feature you might not know about](https://marijkeluttekes.dev/blog/articles/2025/09/03/git-exclude-a-handy-feature-you-might-not-know-about/) + by Marijke Luttekes on her blog, about `.git/info/exclude`. ++ [Git Dual Remotes](https://zanshin.net/2025/09/02/git-dual-remotes/): + a short note by Mark H. Nichols on his Zanshin.net personal site, + about the difference between `git push` and `git fetch` with multiple URLs, + and `jj git push --all-remotes`. ++ [Migrating from Gitea to Forgejo the long way](https://msfjarvis.dev/posts/migrating-from-gitea-to-forgejo-the-long-way/) + by Harsh Shandilya on his blog.
+ [Gitea](https://about.gitea.com/) and [Forgejo](https://forgejo.org/) are software forges. ++ [Some thoughts on personal git hosting](https://shkspr.mobi/blog/2025/09/some-thoughts-on-personal-git-hosting/) + by Terence Eden on Terence Eden’s Blog. ++ [Setting up cgit with Caddy v2 web server](https://www.sixfoisneuf.fr/posts/setting-up-cgit-with-caddy2/) + by Simon Garrelou on his SixFoisNeuf blog (2022). ++ [Sourcegraph went dark](https://www.eric-fritz.com/articles/sourcegraph-went-dark/) + by Eric Fritz on his blog (2024), + about the work that went into ensuring that references are kept alive + after the `sourcegraph/sourcegraph` repository went private + (there is a public snapshot available at [sourcegraph/sourcegraph-public-snapshot](https://github.com/sourcegraph/sourcegraph-public-snapshot), + which is a read-only archived repository). ++ [How to use stacked PRs to unblock your entire team](https://graphite.dev/blog/stacked-prs) + by Ninad Pathak on Graphite Blog (2024), and
+ [A guide to using Graphite's stacked PRs for GitHub users](https://dev.to/semgrep/a-guide-to-using-graphites-stacked-prs-for-github-users-5c47) + by Martin Jambon for Semgrep on DEV\.to. + + See also [Stacked Branches with GitButler](https://blog.gitbutler.com/stacked-branches-with-gitbutler/) + by Scott Chacon on the GitButler Blog, + mentioned in [Git Rev News Edition #118](https://git.github.io/rev_news/2024/12/31/edition-118/). + + See also [Understanding the Stacked Pull Requests Workflow](https://www.git-tower.com/blog/stacked-prs/) by Bruno Brito on Tower's blog, + mentioned in [Git Rev News Edition #111](https://git.github.io/rev_news/2024/05/31/edition-111/) + together with various other articles and tools about stacked diffs, stacked PRs, and stacked branches. + + See also [Rethinking code reviews with stacked PRs](https://www.aviator.co/blog/rethinking-code-reviews-with-stacked-prs/#) + by Ankit Jain on the Aviator blog, + mentioned in [Git Rev News Edition #115](https://git.github.io/rev_news/2024/09/30/edition-115/) + with links to more sites and tools related to stacked PRs, etc. ++ [GitButler's new patch based Code Review (Beta)](https://blog.gitbutler.com/gitbutlers-new-patch-based-code-review) + by Scott Chacon on GitButler's Blog. ++ [first-class merges and cover letters](https://dotat.at/@/2025-09-11-cover-letter.html) + by Tony Finch on his blog. + + +__Slightly heavier reading__ + ++ [Quo Vadis, Code Review? Exploring the Future of Code Review](https://arxiv.org/abs/2508.06879), + a scientific article from August 2025, arXiv:2508.06879 + (most authors of the paper are from Blekinge Institute of Technology, Karlskrona, Sweden). ++ [Code Review as Decision-Making -- Building a Cognitive Model from the Questions Asked During Code Review](https://arxiv.org/abs/2507.09637), + a scientific article from July 2025, arXiv:2507.09637 + (all authors are from Lund University, Lund, Sweden). + Submitted to _Empirical Software Engineering_, Springer Nature. + + +__Easy watching__ + ++ [Git Mini Summit 2025 Videos](https://blog.gitbutler.com/git-mini-summit-2025) + by Scott Chacon on GitButler's Blog. ++ Kinetic Merge in action + + [Merging through a file split](https://youtu.be/JHb9DKK0LIA) + + [Complex merge demonstration](https://youtu.be/6jry6NKxGJA) + + [Merging code embedded inside an if-statement](https://www.youtube.com/watch?v=sm4Naq_zJU0&t=2s) ++ [12 Git commands visualized in 3D: a spatial approach to understanding version control](https://www.youtube.com/watch?v=C2aFC8wFp2A) + [4:58], on the Initial Commit channel on YouTube. ++ [Stacked Branches With Lazygit](https://www.youtube.com/watch?v=M6S-9Y8peDY) + [12:18] by Jesse Duffield (Lazygit author) on YouTube. + + [lazygit](https://github.com/jesseduffield/lazygit) is a simple [windowed] terminal UI for Git, + written in Go. It was first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/). + + +__Git tools and sites__ + ++ [Kinetic Merge](https://github.com/sageserpent-open/kineticMerge) + is a command-line tool that helps you merge a heavily refactored codebase and stay sane. + Its goals are to: + + Merge two branches of a Git repository *holistically across the entire codebase*. + + Take into account the motion of code in either branch due to refactoring. + + Handle file renames, file splits, file concatenation. + + Handle code being excised from one place in a file and moved elsewhere in that file or to somewhere within another file, or hived off all by itself in its own new file. + + Work alongside the usual Git workflows, allowing ordinary Git merge to take over at the end if necessary. + + Be a simple command line tool that tries to do as much as it can without supervision, and with minimal supervision when complexities are encountered. + + Written in Scala, under an MIT license. ++ [Git Much Faster](https://gitlab.com/gitlab-accelerates-embedded/misc/git-much-faster) + is a comprehensive benchmarking tool for comparing different Git clone strategies, + especially for large repositories. + Written as a Bash shell script, under MIT license. ++ [_prek_](https://prek.j178.dev/) is a reimagined version of [pre-commit](https://pre-commit.com/), built in Rust. + It is a framework to run hooks written in many languages, + and it manages the language toolchain and dependencies for running the hooks. + prek is not production-ready yet: some subcommands and languages are not implemented. + Under MIT license. + + See also [Ready prek go!](https://hugovk.dev/blog/2025/ready-prek-go/) + article by Hugo van Kemenade on his blog. ++ [git-sqlite](https://github.com/cannadayr/git-sqlite) + is a collection of shell scripts, + including a custom diff and merge driver for SQLite, + that allows a SQLite database to be tracked using the Git version control system. + Under MIT license. + ++ [LearnGit.io](https://learngit.io/) teaches version control + using animated visualizations of Git internals—and is + [now free](https://learngit.io/posts/learngit-io-is-now-free-for-students) for students and teachers. + Created by Jack Lot of [The Modern Coder](https://www.youtube.com/@themoderncoder) YouTube channel, + LearnGit offers 41 video lessons across 11 modules, along with quizzes, + a Git command search, and high-quality written documentation. + Educators can email jack@learngit.io for bulk vouchers. + First mentioned in [Git Rev News Edition #108](https://git.github.io/rev_news/2024/02/29/edition-108/). ++ [GitFichas](https://gitfichas.com/en) (also know as GitStudyCards) + is a collection of study cards about Git, + for devs that might need a refresher about Git commands. + GitFichas is now [open-source](https://github.com/jtemporal/gitfichas) + and undergoing some construction. ++ Git's home page now has a [Learn](https://git-scm.com/learn) section, including [a handy Git Cheat Sheet](https://git-scm.com/cheat-sheet), contributed by the ever-industrious + [Julia Evans](https://jvns.ca/). These contributions are part of [the initiative to refresh the look and contents of git-scm.com](https://github.com/git/git-scm.com/issues/2046). + + +## Releases + ++ Git for Windows [v2.51.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.51.0.windows.2) ++ Gerrit Code Review [3.13.0-rc0](https://www.gerritcodereview.com/3.13.html#3130) ++ Bitbucket Data Center [10.0](https://confluence.atlassian.com/bitbucketserver/release-notes-872139866.html) ++ GitHub Enterprise [3.17.6](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.6), +[3.16.9](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.9), +[3.15.13](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.13), +[3.14.18](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.18) ++ GitLab [18.4.1, 18.3.3, 18.2.7](https://about.gitlab.com/releases/2025/09/25/patch-release-gitlab-18-4-1-released/), +[18.4](https://about.gitlab.com/releases/2025/09/18/gitlab-18-4-released/), +[18.3.2, 18.2.6, 18.1.6](https://about.gitlab.com/releases/2025/09/10/patch-release-gitlab-18-3-2-released/) ++ GitKraken [11.4.0](https://help.gitkraken.com/gitkraken-desktop/current/) ++ Sourcetree [4.2.14](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.14.html) ++ tig [2.6.0](https://github.com/jonas/tig/releases/tag/tig-2.6.0) ++ Garden [2.3.0](https://github.com/garden-rs/garden/releases/tag/v2.3.0) ++ Git Cola [4.15.0](https://github.com/git-cola/git-cola/releases/tag/v4.15.0) ++ GitButler [0.16.8](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.16.8), +[0.16.7](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.16.7) ++ Kinetic Merge [1.9.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.9.0) ++ git-credential-oauth [0.16.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.16.0) ++ Tower for Mac [14.4, 14.5](https://www.git-tower.com/release-notes/mac) ++ git-flow-next [0.1](https://git-flow.sh/) + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Toon Claes, Johannes Schindelin, +Bruno Brito, Gerard Murphy, Jack Lot, Ben Knoble +and Štěpán Němec. diff --git a/_posts/2025-10-31-edition-128.markdown b/_posts/2025-10-31-edition-128.markdown new file mode 100644 index 000000000..77bfb6678 --- /dev/null +++ b/_posts/2025-10-31-edition-128.markdown @@ -0,0 +1,549 @@ +--- +title: Git Rev News Edition 128 (October 31st, 2025) +layout: default +date: 2025-10-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 128 (October 31st, 2025) + +Welcome to the 128th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of September and October 2025. + +## Discussions + +### General + +* [Git participated in GSoC (Google Summer of Code) 2025](https://summerofcode.withgoogle.com/programs/2025/organizations/git) + + All the contributors have successfully passed their final evaluation + and published a final report: + + - Lucas Oshiro [worked](https://lucasoshiro.github.io/gsoc-en/#weeks) on the + [Machine-Readable Repository Information Query Tool](https://summerofcode.withgoogle.com/programs/2025/projects/fGgMYHwl) + project. He was mentored by Patrick Steinhardt and Karthik Nayak. The final + report can be found on + [his website](https://lucasoshiro.github.io/gsoc-en/#final-report). + + - Meet Soni [worked](https://inosmeet.github.io/posts/gsoc25/) on the + [Consolidate ref-related functionality into git-refs](https://summerofcode.withgoogle.com/programs/2025/projects/xVrT5e2q) + project. He was mentored by Patrick Steinhardt and Jialuo She. The final + report can be found on + [his website](https://inosmeet.github.io/posts/gsoc25/gsoc25_final/). + + - Ayush Chandekar [worked](https://ayu-ch.github.io/) on the + [Refactoring in order to reduce Git’s global state](https://summerofcode.withgoogle.com/programs/2025/projects/no7dVMeG) + project. He was mentored by Christian Couder and Ghanshyam Thakkar. The final + report can be found on + [his website](https://ayu-ch.github.io/2025/08/29/gsoc-final-report.html). + + Kaartic Sivaraam and Christian Couder were + ["org admins"](https://developers.google.com/open-source/gsoc/help/oa-tips). + + Congratulations to the contributors, their mentors and the org admins! + +* [Git Merge 2025 conference](https://git-merge.com/) and [Contributor's Summit 2025](https://lore.kernel.org/git/aOQVeVYY6zadPjln@nand.local/) + + The Git Merge conference happened on + [September 29th and 30th](https://github.blog/open-source/git/20-years-of-git-2-days-at-github-hq-git-merge-2025-highlights/) + in San Francisco, hosted by [GitHub](https://github.com/) at their + GitHub HQ. The [session records](https://www.youtube.com/playlist?list=PLNXkW_le40U6Ms1XlsYKi_yUh5J2FOSlf) + are available. + + On the second day, there was also + [the Contributor's Summit](https://lore.kernel.org/git/aOQVeVYY6zadPjln@nand.local/). + The [full notes](https://docs.google.com/document/d/1arvvXP8DrF3F8PCKQOmGvYh5jUg8P9Clx9m-FgDD4EI/) + as well as [notes broken down by topic](https://lore.kernel.org/git/aOQV6iM49QDhcC+C@nand.local/#r) + are available. + +* [Git Mini Summit 2025](https://lore.kernel.org/git/aGwHt9HCd86hVuKh@pks.im/) + + On August 28 in Amsterdam, a [Git Mini Summit](https://lore.kernel.org/git/aGwHt9HCd86hVuKh@pks.im/) + happened as + [a co-hosted event of the Open Source Summit Europe](https://osseu2025.sched.com/event/28R2Q/git-mini-summit-additional-fee-pre-registration-required), + sponsored by GerritForge, GitButler, GitLab, and Google. + The [schedule](https://drive.google.com/file/d/1vacimnS9NUTcYUsRe8100El8Hdl_C7GD/view) + and [session records](https://blog.gitbutler.com/git-mini-summit-2025) + are available. + + + + +### Support + ++ [[Change] Git build issue on NonStop](https://lore.kernel.org/git/01c101dc2842$38903640$a9b0a2c0$@nexbridge.com/) + + Randall S. Becker reported on the mailing list that CI tests on the + NonStop x86 platform were broken after the `uintptr_t` type started + to be used in [clar](https://github.com/clar-test/clar) tests when + displaying error messages in test failures (in case pointer comparisons + fail). + + Jeff King, alias Peff, replied to Randall that `uintptr_t` was + already used in many places in the regular code, and guessed the + issue might come from how clar defined that type. He noted though + that the line in the clar test where `uintptr_t` appeared also + contained `PRIxPTR` which is a macro that is not used in the regular + code. So he wondered if just replacing that macro with `PRIuMAX` + (which is often used) would be enough to fix the issue. + + `PRIxPTR`, `PRIuMAX` and similar macros are format specifier macros + from the C standard library (defined in ``) that provide + portable ways to print integer types using functions like `printf()` + across different platforms. They are all named in the same way, with + `PRI` meaning `printf`, the next letter indicating the format, like + `x` for hexadecimal and `u` for unsigned decimal, and the last part + indicating the type, like `PTR` for pointer-sized integers, `MAX` + for maximum-width integers, `64` for 64-bit, etc. + + Randall replied to Peff that replacing `PRIxPTR` with `PRIuMAX` + would work, and that he was going to try it. + + Patrick Steinhardt also replied to Randall and Peff saying it would + work, and asked Peff if he wanted to send that change. + + Peff replied to Patrick that he'd be happy if Patrick sent the + change, but noted that using `PRIxMAX` might be better than + `PRIuMAX` as the code wanted to print hexadecimal values. + + Patrick then reported to Peff that Peff's suggestion to use the + `PRIxMAX` or `PRIuMAX` format specifier macros didn't work on 32 bit + systems, because casting a pointer to an integer of different size + (the pointer is 32 bits, but `uintmax_t` is 64 bits) fails. + + Patrick proposed using `%p` as a format specifier saying it might be + a better trade-off. The downside was that the output format would be + unpredictable across platforms as `%p` doesn't have a standardized + output format. So tests that validated the exact error message + format would have to be dropped. But at least `%p` would work + everywhere and produce stable output. + + Junio Hamano, the Git maintainer, agreed with Patrick that `%p` was + "the most appropriate solution". + + Randall then confirmed that `%p` worked on NonStop x86 even if the + man pages warned to the contrary. + + The `%p` solution was eventually merged to the 'master' branch. + + +## Developer Spotlight: Kristoffer Haugsbakk + +* **Who are you and what do you do?** + + I’m Kristoffer from Norway. My day job is working on a Java webapp + primarily used for clinical mental health questionnaires. + +* **What would you name your most important contribution to Git?** + + One I like was when I and the mailing list collaborators fixed a bug + related to Git notes handling by [git-format-patch(1)][1]. It’s + small and niche but Git notes handling is very important to me; I + think Notes are a great way to maintain metadata between patch + submissions. In fact I think it’s great for most commit metadata + that I am interested in maintaining. + +[1]: https://git-scm.com/docs/git-format-patch + +* **What are you doing on the Git project these days, and why?** + + The one I am focusing on is improving the [git-patch-id(1)][2] + documentation. It so happens that you can use that command to make a + commit—patch-id mapping for the whole repository, which you then in + turn can use to make an improved [git-cherry(1)][3] oneliner (one + that says what the upstream commit hash is) as well as, say, using + commands like git-range-diff to see if the upstream committer made + any changes to your submission like fixing commit message typos. But + most uses of this command that I see just use it to figure out what + the patch ID of one single commit is and have to script everything + around that, like loop over [git-rev-list(1)][4]. + +[2]: https://git-scm.com/docs/git-patch-id +[3]: https://git-scm.com/docs/git-cherry +[4]: https://git-scm.com/docs/git-rev-list + +* **If you could get a team of expert developers to work full time on + something in Git for a full year, what would it be?** + + I would ask them to find a way for projects to define their own + conventions and preferences that can be easily shared with all + contributors. Something better than asking each contributor to + download and install hooks. Projects need a better and more + declarative way to configure how their project is supposed to + work. One example might be that a project does not want merge + commits to land in the mainline. It should be simple to take that + high-level goal and make sure that the in-effect central repository + never gets any merge commits. + + Git will not be replaced any time soon, despite it being more + difficult to use than it ought to be. But we can already see what + the effects of the high difficulty of using it is: some projects + outsource all commit messages to issue trackers, and change + proposals (pull requests and patch series descriptions) to webapp + forges. (Meaning they don’t even duplicate the PR description + somewhere in Git like in a commit message.) What you end up with is + still Git but with all the interesting information living at least + one hyperlink away. + +* **If you could remove something from Git without worrying about + backwards compatibility, what would it be?** + + I can’t think of a single thing to remove that would have a big + impact. + + I guess I would remove [git-filter-branch(1)][5]. People can use + [git-filter-repo(1)][6]. And with that one removed I wouldn’t have to ask + people to not use it any more. ;) + +[5]: https://git-scm.com/docs/git-filter-branch +[6]: https://github.com/newren/git-filter-repo + +* **Documentation contributions require understanding both the technical + implementation and the user perspective. How do you approach + bridging that gap? Do you have strategies for ensuring documentation + stays accurate as code evolves?** + + Most of the challenge in bridging the gap for me is about trying to + describe things accurately while not being tedious and verbose. The + worst challenge is when I realistically have one paragraph to + explain something but there are eight factors to mention. (Not a + real case; just the feeling of a challenge that I have encountered + before.) + + For things that are either just difficult or have many factors to + consider I think the best approach we have right now is to mention + other documentation pages in parentheses. An obvious candidate is + [gitglossary(7)][7] where we can gather all kinds of jargon and be + as verbose as we want to. :) + + I don’t have any strategies for ensuring that documentation stays + accurate as code evolves. Let’s take something concrete as an + example: an update to the documentation adds a very similar + paragraph to two documentation pages. That is an obvious maintenance + burden since a later update is likely to necessitate a change in + both places, but you are likely to only deal with one of them. The + obvious fix is to parameterize the paragraph. But I don’t have good + indirect experience with that in [AsciiDoc][8]; the last time I saw + something parameterized was when an [AsciiDoc][8] macro forced + inline formatting to be handled literally. The cure seems worse than + the disease to me. + + The best I can do now when making updates is to investigate the + lines that I am changing and find the histories of any possible + near-duplicate texts. + +[7]: https://git-scm.com/docs/gitglossary +[8]: https://asciidoc.org/ + +* **What is your favorite Git-related tool/library, outside of Git + itself?** + + [Magit][9]. An Emacs Git frontend. + +[9]: https://magit.vc/ + +* **Do you happen to have any memorable experience w.r.t. contributing + to the Git project? If yes, could you share it with us?** + + When I added a test case to `t/t7001-mv.sh` that [made the continuous + build routine on Windows (CI) time out][16]. The test was + `test_expect_failure` and triggered a C assertion, and the Windows + CI pops up a modal dialog on assertion failures. That dialog is of + course never dismissed by any operator and so the suite eventually + timed out. + +[16]: https://lore.kernel.org/git/pull.1908.git.1745593515875.gitgitgadget@gmail.com/ + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I use the builtin commands for making patches and sending them + ([git-format-patch(1)][10] and [git-send-email(1)][11]). For programming and + writing I use the basic, needed tools along with Emacs. Very + occasionally I will use GDB. + +[10]: https://git-scm.com/docs/git-format-patch +[11]: https://git-scm.com/docs/git-send-email + +* **What is your advice for people who want to start Git development? + Where and how should they start?** + + Find something technically wrong in the documentation and fix + it. That’s what I did in 2016; I wanted to test out this new (to me) + “email-based workflow”. Focus on fixing things instead of + subjectively improving something. Because someone might object and + propose that you send a new version. Making subjective documentation + improvements is the next step in terms of difficulty I guess. + + It sounds trivial but someone used to Git forges will have enough + challenges just sending proper patches to the project over email. + + Also read through [`Documentation/SubmittingPatches`][12]. I don’t + really see many corrections that refer to other documents. You could + of course get a correction that refers to some [*lore*][13] but that + is unlikely to happen for simple changes if you just structure it + similar to recent, accepted submissions that you find. + +[12]: https://git-scm.com/docs/SubmittingPatches +[13]: https://lore.kernel.org/git + +* **If there's one tip you would like to share with other Git + developers, what would it be?** + + You won’t get any C programming tips from me since I can’t write or + edit three lines of C code without segfaulting five times. + + Take advantage of the fact that the Git history is so + well-structured. Maybe you find some questionable behavior or + code. Use the “pickaxe” technique (see [git-log(1)][14]) on some + good candidate text and trace the behavior back to the start. Maybe + the commit message explains the issue or behavior. If not use + `refs/notes/amlog` (which you should be “subscribed” to already) and + see if something relevant was discussed on the patch discussion. If + not there is likely to be no written record out there; another thing + that this project is disciplined about is keeping the relevant + discussion on the mailing list, not the mailing list and N other + satellite fora. + + Those links (to commits and archived emails) are very valuable when + you want to discuss a change to something that has been in + [git(1)][15] for years and years. + +[14]: https://git-scm.com/docs/git-log#Documentation/git-log.txt--Gregex +[15]: https://git-scm.com/docs/git + +## Other News + +__Various__ + ++ [Git considers SHA-256, Rust, LLMs, and more](https://lwn.net/Articles/1042172/) + by Jonathan Corbet on LWN\.net. ++ [Git Developers Talk About Potentially Releasing Git 3.0 By The End Of Next Year](https://www.phoronix.com/news/Git-3.0-Release-Talk-2026) + by Michael Larabel on Phoronix. ++ [GitHub is migrating to Azure! And goodbye to new development for a year.](https://www.redhotcyber.com/en/post/github-is-migrating-to-azure-and-goodbye-to-new-development-for-a-year/) + by Redazione RHC on Red Hot Cyber. ++ [Fedora Moves Towards Forgejo](https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/) + by Matthew Miller and Akashdeep Dhar on December 4, 2024 + in Fedora Magazine. + + [Forgejo](https://forgejo.org/) is a self-hosted lightweight software forge, + written in Go; nowadays a hard fork of Gitea (which in turn was based on Gogs). + It was first mentioned in passing in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/). + + +__Light reading__ + ++ [Building for the future: on Tangled's existence and direction](https://anirudh.fi/future) + by Anirudh Oppiliappan on their blog; + also published [at icy takes blog](https://icy.leaflet.pub/3m47cll72hs25) on ATProto. + + [Tangled.sh](https://blog.tangled.sh/intro) is a new social-enabled Git collaboration platform + built on top of the AT Protocol / ATProto + (which is behind the [BlueSky](https://bsky.app/) microblogging federated social media service). + It was first mentioned in [Git Rev News Edition #125](https://git.github.io/rev_news/2025/07/31/edition-125/). ++ [6 months of Tangled: a quick recap, and notes on the future](https://blog.tangled.org/6-months) + by Anirudh Oppiliappan and Akshay Oppiliappan on Tangled Blog. ++ [Socially self-hosting source code with Tangled on Bluesky](https://anil.recoil.org/notes/disentangling-git-with-bluesky) + by Anil Madhavapeddy, Professor of Planetary Computing, on his blog. ++ [Redistributing Git with Nostr](https://fiatjaf.com/18ff5416.html) + by início on their blog. + + There exists [gitstr (`git str`)](https://github.com/fiatjaf/gitstr), + which is a tool to send and receive Git patches + over [Nostr](https://nostr.com/), using [NIP-34](https://github.com/nostr-protocol/nips/pull/997) + (first mentioned in [Git Rev News Edition #109](https://git.github.io/rev_news/2024/03/31/edition-109/)). + + Note that [git-credential-oauth](https://github.com/hickford/git-credential-oauth), + a Git credential helper that securely authenticates to GitHub, GitLab, BitBucket and Gerrit + using [OAuth](https://datatracker.ietf.org/wg/oauth/about/), + can replace the "create an account; pick a password; confirm an email address; set up SSH keys for pushing" steps. ++ [How GitHub won software development](https://www.infoworld.com/article/4069045/how-github-won-software-development.html) + by Nick Hodges on Rubber Duck Reflections opinions blog on InfoWorld. ++ [You already have a git server](https://maurycyz.com/misc/easy_git/) + on Maurycy's blog; + describes how one can serve Git repositories via SSH (with SSH access) + or via dumb HTTP (with a web server). ++ [Simple automated deployments using git push](https://garrido.io/notes/simple-automated-deployments-git-push/) + by Gabriel Garrido on his blogs / notes (2024). ++ [Discussion of the Benefits and Drawbacks of the Git Pre-Commit Hook](https://yeldirium.de/2025/10/09/pre-commit-hooks/index.html) + by Hannes Leutloff on his blog. ++ [You can use `fzf` to review git commits](https://jvns.ca/til/fzf-preview-git-commits/) + by Julia Evans in her TIL (Today I've Learned) section. + + See also [Improving shell workflows with fzf](https://seb.jambor.dev/posts/improving-shell-workflows-with-fzf/), + mentioned in [Git Rev News Edition #74](https://git.github.io/rev_news/2021/04/30/edition-74/), and + [Curing A Case Of Git-UX](https://oppi.li/posts/curing_a_case_of_git-UX/), + mentioned in [Git Rev News Edition #126](https://git.github.io/rev_news/2025/08/31/edition-126/). ++ [Switch to Jujutsu already: a tutorial](https://www.stavros.io/posts/switch-to-jujutsu-already-a-tutorial/) + by Stavros on Stavros' Stuff. + + [Jujutsu (`jj`)](https://jj-vcs.github.io/jj/) is a Git-compatible version control system + written in Rust, which was first mentioned in + [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [Magit Is Amazing!](https://heiwiper.com/posts/magit-is-awesome/) + by Abdallah Maouche (heiwiper) on his blog + (how it does things that others need to use Jujutsu over Git for). + + [Magit](https://magit.vc/) is a popular [Emacs](https://www.gnu.org/software/emacs) editor interface to Git, + first mentioned (in passing) in [Git Rev News Edition #6](https://git.github.io/rev_news/2015/08/05/edition-6/). ++ [Branching in a Sapling Monorepo](https://engineering.fb.com/2025/10/16/developer-tools/branching-in-a-sapling-monorepo/) + + [Sapling](https://sapling-scm.com/) is a scalable, user-friendly, and open-source source control system + that powers Meta's (Facebook's) monorepo. + It was first mentioned in [Git Rev News Edition #93](https://git.github.io/rev_news/2022/11/30/edition-93/). ++ [Stop Rebasing Everything: Your Git History Isn’t That Special](https://dev.to/dolig/stop-rebasing-everything-your-git-history-isnt-that-special-ln3), + an argument in the merge-vs-rebase debate. + by Guillaume on DEV\.to. ++ [Diff Algorithms](https://flo.znkr.io/diff/) + by Florian Zenker on his website.
+ The result of this exploration was [znkr.io/diff](https://znkr.io/diff), + a difference algorithm module for Go. + + Note that with [`git diff`](https://git-scm.com/docs/git-diff) + you can choose between `myers` (default), `minimal`, `patience` and `histogram` algorithms. ++ [Git Super-Power: The Three-Way Merge](https://qsantos.fr/2024/05/01/git-super-power-the-three-way-merge/) + by Quentin Santos on his blog (2024).
+ Provides the following tl;dr: `git config --global merge.conflictstyle diff3`. ++ [Anyone Can Commit Code as You on GitHub (Here's How to Stop Them)](https://www.nickyt.co/blog/anyone-can-commit-code-as-you-on-github-heres-how-to-stop-them-2in7/) + with signed commits (with tutorial focusing on macOS using GPG Keychain). + Written by Nick Taylor on his Just Some Dev blog. ++ [GitHub Ensloppification](https://dbushell.com/2025/08/11/github-ensloppification/) + by David Bushell on his blog. ++ ["GitHub" Is Starting to Feel Like Legacy Software](https://www.mistys-internet.website/blog/blog/2024/07/12/github-is-starting-to-feel-like-legacy-software/) + rant by Misty De Méo on her blog (2024). ++ [Implementing Conventional Commits with Jira Ticket Prefix Validation](https://heristop.github.io/blog/2024-07-09-conventional-commit-jira/) + by Alexandre Mogère (heristop) on Zazen Code. + + The [Conventional Commits](https://www.conventionalcommits.org/) specification + was first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/), + and in many editions since. ++ [Conventional Commits considered harmful](https://larr.net/p/cc.html) + (or rather overly strict enforcement of the standard), + rant by Salih Muhammed, with a few further links. ++ [Contribute to GitFichas](https://jtemporal.com/contribute-to-gitfichas/) + by Jessica Temporal on her blog. + + [GitFichas](https://gitfichas.com/en) (also know as GitStudyCards) + is a collection of study cards about Git, + for devs that might need a refresher about Git commands. + Mentioned in [the previous edition of Git Rev News](https://git.github.io/rev_news/2025/09/30/edition-127/). + + +__Easy watching__ + ++ [Gerrit User Summit 2025, featuring also GitButler and Jujutsu](https://www.youtube.com/playlist?list=PLySCWiWz9cNuiJK2Uy3foHGvkxL3fBLUC) + by Luca Milanesio on GerritForge's YouTube channel. ++ [Jujutsu at Google](https://www.youtube.com/watch?v=v9Ob5yPpC0A&list=PLOU2XLYxmsILM5cRwAK6yKdtKnCK6Y4Oh&index=8) + ([slides](https://drive.google.com/file/d/1dVzug1lHoOxdbFu8gcCJCu-G_uVMUATI/edit)) + on Google for Developers channel on YouTube; + part of [JJ Con 2025 playlist](https://www.youtube.com/playlist?list=PLOU2XLYxmsILM5cRwAK6yKdtKnCK6Y4Oh).
+ In this talk, Martin von Zweigbergk presents + on Jujutsu architecture and future plans.
+ JJ Con 2025 was a dedicated conference hosted by Google + for the [Jujutsu](https://jj-vcs.github.io/jj/latest/) version control system. ++ [Solving Git's Pain Points with Jujutsu (with Martin von Zweigbergk)](https://www.youtube.com/watch?v=ulJ_Pw8qqsE) + on Developer Voices channel on YouTube. + + +__Scientific papers__ + ++ Ya-Nan Li, Yaqing Song, Qiang Tang, Moti Yung: + _"End-to-End Encrypted Git Services"_, + Cryptology {ePrint} Archive, Paper 2025/1208, + , + DOI:10.1145/3719027.3744815 + + See [_"Scientists develop end-to-end encryption for git services"_](https://techxplore.com/news/2025-10-scientists-encryption-git.html) + article by University of Sydney, edited by Stephanie Baum, reviewed by Robert Egan, + on TechXplore. ++ S.R.P. van Hal, M. Post, K. Wendel: + _"Generating Commit Messages from Git Diffs"_, + [arXiv:1911.11690](https://arxiv.org/abs/1911.11690) (2019)
+ mentions "inherent shortcoming of current commit message generation models, + which perform well by memorizing certain constructs." + + +__Git tools and sites__ + ++ [diff-modulo-base](https://git.sr.ht/~nhaehnle/diff-modulo-base) + is a tool that allows you to compare the relevant changes + of two versions of a rebased branch given three input diffs: + two _base_ diffs that show the changes since the respective merge bases + and a _target_ diff between the branches you are actually interested in. + + It is very similar to (and actually builds on) `git range-diff`, + but differs in resulting output. + Written in Rust, under MIT License. ++ [Worktree Manager](https://github.com/jarredkenny/worktree-manager) (wtm) + is a fast, modern CLI tool for managing Git worktrees in bare repositories. + Written in TypeScript for Bun, under MIT License. ++ [git-metrics](https://github.com/jdrouet/git-metrics) + is a Git extension that makes it possible to track metrics about your project, + which are stored within the git repository (using `git notes`). + Written in Rust, under MIT License.
+ Described in [Build metrics and budgets with git-metrics](https://dev.to/jdrouet/build-metrics-and-budgets-with-git-metrics-4pb4) + article by Jérémie Drouet on DEV\.to (2024). + + There is another [git-metrics](https://github.com/Praqma/git-metrics) tool, + by the Praqma / Eficode DevOps company, + which consists of a set of scripts to analyse a Git repository for metrics + such as lead time and open branches. Written in Python, no license provided. + It was mentioned in passing in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/). ++ [git-spice](https://abhinav.github.io/git-spice/) is a tool for stacking Git branches. + It lets you manage and navigate stacks of branches, conveniently modify and rebase them, + and create GitHub Pull Requests or GitLab Merge Requests from them. + Written in Go, under GPL 3.0 License. + + A _stacked branch_ refers to a set of branches that build upon each other in a linear sequence. + Stacked branches or stacked diffs were first mentioned in [Git Rev News #44](https://git.github.io/rev_news/2018/10/24/edition-44/), + and most recently in [Git Rev News #127](https://git.github.io/rev_news/2025/09/30/edition-127/), + where you can find even more links about this technique. ++ [Git Granary](https://git.dbushell.com/dbushell/granary) + is a [Git Large File Storage](https://git-lfs.com/) (LFS) + server implementation written in TypeScript. Under MIT License. + Git Granary was designed for self-hosted personal use.
+ See [Git Granary](https://dbushell.com/2024/07/25/git-granary/) + blog post by David Bushell on his blog (2024). ++ [gibr](https://github.com/ytreister/gibr) is a Git CLI tool + for intelligently creating branch names. + It connects your Git workflow to your issue tracker for that purpose; + currently supporting GitHub, GitLab, Jira, and Linear + (with Monday\.com support planned). + Written in Python, under MIT License. ++ [0github.com](https://0github.com/) + is a service offering a heatmap diff viewer for code reviews, + color-coding every diff line/token by how much human attention it probably needs. + To try it, replace github.com with 0github.com in any GitHub pull request URL. + The [cmux](https://cmux.dev/) engine it uses is open source (MIT License). + It uses a LLM (Large Language Model) to perform this task. + + +## Releases + ++ Git [2.51.2](https://lore.kernel.org/git/xmqqo6psjq2n.fsf@gitster.g/), +[2.51.1](https://lore.kernel.org/git/xmqqa51suhh5.fsf@gitster.g/) ++ Git for Windows [v2.51.2(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.2.windows.1), +[v2.51.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.1.windows.1), +[v2.51.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.51.0.windows.2) ++ GitHub Enterprise [3.18.0](https://docs.github.com/enterprise-server@3.18/admin/release-notes#3.18.0) ++ GitLab [18.5.1, 18.4.3, 18.3.5](https://about.gitlab.com/releases/2025/10/22/patch-release-gitlab-18-5-1-released/), +[18.5](https://about.gitlab.com/releases/2025/10/16/gitlab-18-5-released/), +[18.4.2, 18.3.4, 18.2.8](https://about.gitlab.com/releases/2025/10/08/patch-release-gitlab-18-4-2-released/) ++ Gerrit Code Review [3.10.9](https://www.gerritcodereview.com/3.10.html#3109), +[3.13.0-rc0](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.0-rc1](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.0-rc2](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.0-rc3](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.0-rc4](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.0-rc5](https://www.gerritcodereview.com/3.13.html#3130) ++ GitKraken [11.5.1](https://help.gitkraken.com/gitkraken-desktop/current/), +[11.5.0](https://help.gitkraken.com/gitkraken-desktop/current/) ++ GitHub Desktop [3.5.3](https://desktop.github.com/release-notes/) ++ Git Cola [4.16.0](https://github.com/git-cola/git-cola/releases/tag/v4.16.0) ++ GitButler [0.16.10](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.16.10), +[0.16.9](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.16.9) ++ Kinetic Merge [1.10.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.10.0), +[1.9.1](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.9.1) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Kristoffer Haugsbakk, Lee Reilly, +Luca Milanesio and Štěpán Němec. diff --git a/_posts/2025-11-30-edition-129.markdown b/_posts/2025-11-30-edition-129.markdown new file mode 100644 index 000000000..12f681d8c --- /dev/null +++ b/_posts/2025-11-30-edition-129.markdown @@ -0,0 +1,605 @@ +--- +title: Git Rev News Edition 129 (November 30th, 2025) +layout: default +date: 2025-11-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 129 (November 30th, 2025) + +Welcome to the 129th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of October and November 2025. + +## Discussions + + + + + +### Support + ++ [[Bug report] `git cherry-pick` silently ignores error whereas `git apply` fails for hunk apply](https://lore.kernel.org/git/CAEyHQXWd77_jJachC6FYbWMJ+L=KkKoUqiACQ7z8r-ZwYq8JYw@mail.gmail.com/) + + Bhavik Bavishi filed and sent a bug report to the mailing + list. Running `git cherry-pick` failed to apply some changes but + didn't report any error. On the contrary, when creating a patch + using `git format-patch` from the same commit and applying it using + `git apply --verbose`, the latter command also failed to apply the + same changes but errored out. It seemed that there shouldn't be such + a behavior discrepancy and that `git cherry-pick` should have + reported an error, too. + + Johannes Sixt suggested using `git apply --3way` to apply the + patch. He was interested not only in the success or failure of the + command, but also in the end result of applying the patch. Was that + end result similar to the result of `git cherry-pick` or + different? + + Bhavik reported back that indeed `git apply --3way` succeeded and + produced the same end result as `git cherry-pick`. Even though it looked + like `git cherry-pick` worked as expected, that still seemed a + strange behavior. + + Johannes Sixt replied that a merge strategy is used by both + `git cherry-pick` and `git apply --3way`. Unlike a simple patch + application, a merge strategy is intelligent enough to detect if a + change has already been applied. He illustrated this with an example + where text repeats in a file, but only specific instances are + modified. + + In the meantime, Chris Torek also replied to Bhavik providing a + wealth of explanations. He explained that `git apply` works with a + *patch*, which is essentially a "we expect the file looks like this" + instruction. If the file doesn't match the expected context lines + exactly, the patch fails. + + In contrast, `git cherry-pick` performs a *3-way merge*. It locates + a "common base version" (the ancestor), compares it to "Ours" + (current branch), and "Theirs" (the commit being picked) . If the + merge logic sees that "Theirs" introduces a change that "Ours" has + already made, it silently discards the duplicate change rather than + erroring out. This confirms that the command was working as + intended, using the full history to resolve what looked like a + conflict to the simpler `git apply` tool. + + Bhavik thanked Chris for the helpful explanations. + +## Developer Spotlight: Ayush Chandekar + +_Editor’s note: This edition features a retrospective interview with a +contributor who contributed to Git through a mentoring program. +We hope the reflections shared by the GSoC contributor will +provide an insightful perspective that benefits the community. +As always, we welcome your thoughts and feedback!_ + +* **Who are you and what do you do?** + + I am Ayush Chandekar, a GSoC 2025 alumnus under Git, my project was + titled '[Refactoring in order to reduce Git’s global state](https://summerofcode.withgoogle.com/programs/2025/projects/no7dVMeG)'. + Currently I am an engineering undergraduate at IIT Roorkee, + I consider myself to be a jack of all trades, with interests + ranging from low-level programming to game development, + cybersecurity, and blockchain. I am also a member of + [SDSLabs](https://sdslabs.co/), a student run technical club + at my university which also focuses on making software and + tech accessible for the campus. + + As a kid I always enjoyed tinkering with computers and would + spend majority of my time on games, but slowly I started enjoying + the chance that development gave me to be the one behind the scene, + controlling and making stuff which works. My approach is driven by + curiosity and a desire to understand how things really function. + Whenever I start learning something new, I naturally end up going + deeper and deeper into the smaller, niche details, not because + I have to, but because it genuinely fascinates me. I enjoy peeling + back the layers, figuring out the underlying mechanisms, and + understanding the “why” behind everything I work on. It’s that + curiosity that keeps pulling me into new domains and motivates me + to keep exploring. Apart from this, for fun, I like to participate + in hackathons, GameJams and Cyber security Capture-The-Flag(CTF) + competitions. Outside of tech, I enjoy listening to music, brewing + coffee, skateboarding, and learning guitar, they help me unwind + and keep a balance beyond the screen. + +* **How did you initially become interested in contributing to Git, + and what motivated you to choose it as your GSoC project?** + + I wanted to start my journey of contributing to open source projects. + Before that, I was working on small C projects, and that’s when I + came across Git. I was immediately drawn to understanding how + developers actually work on Git itself. The workflow felt new to me, + kind of old-school in a good way, and it definitely took some time + to get used to, but I really enjoyed the process. As I dug deeper, + I realized how Git's internals work, and that made me even more + curious. The idea that I could learn from such a mature codebase, + while also improving a tool used globally, was extremely motivating. + It felt like the perfect place to challenge myself, improve my skills, + and contribute to a big project. + +* **Is there any aspect of Git that you now see differently after + having contributed to it?** + + It is about how there are so many different commands. Before my GSoC, + I was only aware of the usual `git push`, `git pull`, `git clone`, + etc. Now, I know many more commands like `git bisect`, `git range-diff`, + etc. I even understand how some of them work internally. Contributing + to Git really opened my eyes to the depth and complexity of the tool. + +* **How do you balance your contributions with other responsibilities + like work or school?** + + Balancing contributions with other responsibilities is a bit + challenging. As an undergrad student, I’m involved in various + activities at my university, including sports and other commitments, + so my schedule gets busy. But whenever I sit down to work or study, + I get very absorbed in it, and I often end up spending long stretches + of time without even realizing it. That focus helps me make steady + progress even with a packed routine. + +* **Can you share how GSoC helped enhance your technical and + non-technical skills (like communication, project management, + etc.)?** + + GSoC helped me grow in both technical and non-technical areas. + On the technical side, I became much more comfortable reading + large codebases, debugging tricky issues, and writing clean, + well-structured patches. I also learned the importance of clear + and detailed commit messages. On the non-technical side, GSoC + improved my communication skills a lot, especially explaining + my ideas, asking the right questions, and discussing feedback + with the community. It also taught me how to plan my work, break + tasks into smaller steps, and manage my time over a long project. + Overall, it made me more confident in collaborating in an open-source + environment. I would also like to thank my mentor, Christian, for + his guidance and patience throughout the project. His feedback + played a big role in helping me improve. + +* **What was your biggest takeaway or learning from GSoC that + you now apply regularly in your work?** + + My biggest takeaway from GSoC was the importance of writing + clear and detailed commit messages. Before the program, I + didn’t pay much attention to how a commit was explained, + but contributing to Git made me realise how essential it + is. A good commit message not only describes what changed + but also why the change was necessary, making it much easier + for reviewers and future contributors to understand the context. + + Another major learning was understanding how to handle reviews + from multiple people. In the Git community, different contributors + often suggest different things, and figuring out how to take in + all that feedback while still taking ownership of my work was a + big shift for me. I learned how to look at each suggestion carefully, + understand the reasoning behind it, and decide what improves the + patch. It also taught me when to explain my choices and when to + adjust my approach. This experience helped me become more confident + in iterating on my work and communicating clearly, while staying + responsible for the decisions I make. + +* **What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it?** + + There were a few challenges which I faced. Initially, it was + getting accustomed to the mailing list workflow as it was new to + me. Most of the challenges were making sure that the community + accepted your patches. A lot of people reviewed my patches and + got different responses. Here, I learnt to take ownership of + my patches. + +* **Have you thought about mentoring new GSoC / Outreachy students?** + + Yes, I’ve definitely thought about mentoring future GSoC students, + most likely as a co-mentor. I feel it would be a great way to + give back to the community and support newcomers the same way + I was supported. + +* **If you could remove something from Git without worrying about + backwards compatibility, what would it be?** + + It would be removing the global state from Git, which was my + GSoC project and is also an ongoing effort in the community + for the maintainability and modularity of the codebase. + +* **What upcoming features or changes in Git are you particularly + excited about?** + + I've been following Patrick's [patch series on `git history`](https://public-inbox.org/git/20251027-b4-pks-history-builtin-v6-0-407dd3f57ad3@pks.im/). + I am excited about that feature's release. + +* **What is your favorite Git-related tool/library, outside of Git + itself?** + + I have heard of [Jujutsu](https://jj-vcs.github.io/jj/latest/), + I haven't tried it yet but it seems cool, other than that + sticking to my essentials, GitLab and GitHub. + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I just use Gmail to view and reply mails most of the time. But when + it comes to sending patches, I use the good ol' `git send-email`. + I had set up [mutt](http://www.mutt.org/) once, but didn't use it + as much. + +* **How do you envision your own involvement with Git or other open + source projects in the future?** + + I don't have anything planned out in particular but I do really + admire the way my mentor and other contributors in the organisation + contribute. Open source is something which basically runs the world, + organisations like Git and Linux function because of collective and + voluntary efforts; they are what makes the world as it is today, + and carrying that forward I want to contribute in a way which makes + software accessible to everyone and help build up on these + foundational blocks. + +* **What is your advice for people who want to start Git development? + Where and how should they start?** + + Git is an amazing project to learn all aspects of development. + It helps you to learn/improve your C and debugging skills. Another + important thing is how you get to work with different contributors + in the community. You get reviews from everyone which helps you + understand different perspectives. To start with, I would suggest + going through this page called '[Hacking Git](https://git.github.io/Hacking-Git/)' + and checking different articles mentioned there along with the + [Contribution Guidelines](https://git-scm.com/docs/MyFirstContribution). + It is quite difficult to decide what to work on initially, as there + are no traditional issues as other organizations have. Being active + on the mailing list, checking out the ongoing topics might help you + decide what to work on. Everyone on the mailing list and discord is + very friendly and is always looking forward to help you out, so feel + free to ask if you have any doubts :) + +* **Would you recommend other students or contributors to participate + in the GSoC, Outreachy or other mentoring programs, working on Git? + Why? Do you have advice for them?** + + As I answered before, it is sometimes difficult to decide what you + can work on. I feel that for Git, since projects are already listed + on the [GSoC and Outreachy pages](https://git.github.io/SoC-2025-Ideas/), + it takes away the pain of figuring out where to start. You just need + to pick a project that interests you and then spend some time studying + it. Other than that, you’re also mentored by someone experienced in + Git development, and with their guidance you’re able to follow best + practices and learn a lot of new things. These programs really help + build confidence, especially when contributing to a large and complex + codebase. You also get to improve your communication skills through + discussions, reviews, and patch iterations. And most importantly, it + opens doors for future contributions, networking, and long-term + involvement in open source. My advice would be to learn to be patient + with reviews. A lot of people in the community contribute voluntarily, + so you may not get reviews on your patches quickly, and that’s + completely normal. + + +## Other News + +__Various__ + +- [What’s new in Git 2.52.0?](https://about.gitlab.com/blog/whats-new-in-git-2-52-0/) + by Christian Couder, Patrick Steinhardt, Toon Claes on GitLab Blog. + Highlights include `git last-modified` command, + `git fast-export` and `git fast-import` signature-related improvements, + new and improved `git maintenance` strategies, + a new subcommand for the new `git repo` to display repository metrics, etc. +- [Highlights from Git 2.52](https://github.blog/open-source/git/highlights-from-git-2-52/) + by Taylor Blau on GitHub Blog. + Mentions the `git last-modified` command for tree-level blame information, + advanced repository maintenance strategies for `git maintenance`, + new subcommands added to `git refs`, the experimental `git repo` command, etc. +- [lakeFS Acquires DVC, Uniting Data Version Control Pioneers to Accelerate AI-ready Data](https://lakefs.io/media-mentions/lakefs-acquires-dvc-uniting-data-version-control-pioneers/) + announcement by lakeFS on their Mentions Media page. + - [DVC Joins lakeFS: Your Questions Answered!](https://dvc.org/blog/dvc-joins-lakefs-your-questions-answered/) + by Jeny De Figueiredo on DVC Blog. + - [A Shared Vision for the Future of DVC](https://dvc.org/blog/a-shared-vision-for-the-future-of-dvc/) + by Dmitry Petrov on DVC Blog. + - See also [“Data Management” section of Awesome MLOps](https://github.com/kelvins/awesome-mlops#data-management), + mentioned in [Git Rev News Edition #116](https://git.github.io/rev_news/2024/10/31/edition-116/). + That edition also includes references to DVC and lakeFS, + and other similar tools (though the list there is missing + [Meltano](https://meltano.com/) (first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/)) and + [Pachyderm](https://www.pachyderm.com/) (first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/)). +- [20 Years of Git, 2 days at GitHub HQ: Git Merge 2025 highlights 🎉](https://github.blog/open-source/git/20-years-of-git-2-days-at-github-hq-git-merge-2025-highlights/) + by Lee Reilly on GitHub Blog. + - See also [the previous edition of Git Rev News](https://git.github.io/rev_news/2025/10/31/edition-128/) + for more links about Git Merge 2025. + + +__Light reading__ + +- [Version Control in the Age of AI: The Complete Guide](https://www.git-tower.com/blog/version-control-in-the-age-of-ai) + by Bruno Brito on Git Tower blog. +- [Analyzing 10 years of accepted patch series to Git](https://benknoble.github.io/blog/2025/11/14/git-patch-series-length/) + by D. Ben Knoble on his Junk Drawer personal blog. +- [Mergiraf: syntax-aware merging for Git](https://lwn.net/Articles/1042355/) + by Daroc Alden on LWN\.net. + - [Mergiraf](https://mergiraf.org/introduction.html) is a merge-conflict resolver + that uses a generic algorithm plus a small amount of language-specific knowledge + to solve conflicts that Git's default strategy cannot. + It was mentioned in [Git Rev News Edition #117](https://git.github.io/rev_news/2024/11/30/edition-117/). + - The Mergiraf author recommends using the tool together with + [Difftastic](https://difftastic.wilfred.me.uk/), a structural diff tool + that understands syntax, mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/). +- [Should I Switch From Git to Jujutsu](https://etodd.io/2025/10/02/should-i-switch-from-git-to-jujutsu/) + by Evan Todd on his personal blog. + - [Jujutsu (`jj`)](https://jj-vcs.github.io/) is a Git-compatible + version control system written in Rust, which was first mentioned + in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). + - See also [Switch to Jujutsu already: a tutorial](https://www.stavros.io/posts/switch-to-jujutsu-already-a-tutorial/) + by Stavros on Stavros’ Stuff, + mentioned in [the previous edition](https://git.github.io/rev_news/2025/10/31/edition-128/). +- [Why Git is the first tool every new developer needs to learn](https://www.howtogeek.com/beginning-git-what-it-is-and-why-its-crucial/) + by Graeme Peacock on How-To Geek. +- [Git for Vibe Coders](https://www.kdnuggets.com/git-for-vibe-coders), + just enough to stop Claude from accidentally deleting your code and database. + By Abid Ali Awan on KDnuggets. +- [4 advanced git commands you probably haven't heard of](https://www.howtogeek.com/advanced-git-commands-you-probably-havent-heard-of/): + [`git clean`](https://git-scm.com/docs/git-clean), + [`git bisect`](https://git-scm.com/docs/git-bisect), + [`git cherry-pick`](https://git-scm.com/docs/git-cherry-pick), + [`git revert`](https://git-scm.com/docs/git-revert), + by Bobby Jack on How-To Geek. +- [Setting File Permissions in Git](https://www.tvaidyan.com/2025/11/13/setting-file-permissions-in-git/) + by Tom Vaidyan on his personal blog; + though I wonder why he shows the low-level `git update-index --chmod=+x ` "plumbing" command + first, instead of the corresponding user-facing `git add --chmod=+x ` "porcelain" command. +- [Why You Should Be Using Git Worktrees](https://blog.randombits.host/why-you-should-be-using-git-worktrees/) + by Conor in Quick Tip on their Random Bits personal blog + (it includes their helper `gwc`, i.e. `git worktree create`, shell script). +- [tree-me: Because git worktrees shouldn't be a chore](https://haacked.com/archive/2025/11/21/tree-me/) + by Phil Haack on his You've Been Haacked blog. +- [Use skip-worktree to ignore modified files](https://www.brandonpugh.com/til/git/skip-worktree-ignore-modified-files/) + by Brandon Pugh in the "TIL: Today I learned..." section on his blog. +- [Managing Multiple Projects in One Repository: Submodules, Subtrees, Monorepos & Partial Cloning Explained](https://dev.to/k-kibet/managing-multiple-projects-in-one-repository-submodules-subtrees-monorepos-partial-cloning-21mc) + by Kibet Korir (K-kibet) for Codespear on DEV\.to. +- [Automatically switching Git Identities and SSH Keys on the same machine](https://dev.to/enbis/automatically-switching-git-identities-and-ssh-keys-on-the-same-machine-75n) + with the help of `includeIf` directive in the `.gitconfig` file, + by Enrico Bison (enbis) on DEV\.to. See also: + - [Splitting SSH and git configs](https://iamjonfry.com/splitting-ssh-and-git-configs/) + mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/). + - [How to Use Multiple Git Configs on One Computer](https://www.freecodecamp.org/news/how-to-handle-multiple-git-configurations-in-one-machine/) + mentioned in [Git Rev News Edition #71](https://git.github.io/rev_news/2021/01/28/edition-71/). + - [How I configure my Git identities](https://www.benji.dog/articles/git-config/) + mentioned in [Git Rev News Edition #117](https://git.github.io/rev_news/2024/11/30/edition-117/). + - [One PC, Multiple Git Configs (This Will Save You Time!)](https://medium.com/@matteopampana/one-pc-multiple-git-configs-this-will-save-you-time-f702880744f7) + mentioned in [Git Rev News Edition #120](https://git.github.io/rev_news/2025/02/28/edition-120/). +- [Git: Amend any commit](https://ylan.segal-family.com/blog/2025/11/15/git-ammend-any-commit/) + (scripting around `git commit --amend`, `git commit --fixup`, and `git rebase --autosquash`) + by Ylan Segal on his "on.code && such" blog. +- [If You Think YOUR Commit Messages Are Bad, Just Wait...](https://dev.to/sylwia-lask/if-you-think-your-commit-messages-are-bad-just-wait-3fgk) + by Sylwia Laskowska on DEV\.to, + with others providing more examples in comments. +- [Mistakes I see engineers making in their code reviews](https://www.seangoedecke.com/good-code-reviews/) + by Sean Goedecke on his blog. +- [Testable Dotfiles Management With Chezmoi](https://shunk031.me/post/testable-dotfiles-management-with-chezmoi/) + by Shunsuke Kitada (北田俊輔), Ph.D. on shunk031\.me. +- [Backing up my repositories to self-hosted Gitea](https://blog.kulman.sk/self-hosted-gitea-backup/) + by Igor Kulman on his personal blog. + - [Gitea](https://about.gitea.com/) is a Go-based software forge, + a fork of [Gogs](https://gogs.io/). + It was first mentioned in [Git Rev News Edition #23](https://git.github.io/rev_news/2017/01/25/edition-23/). +- [Fixing Vercel's 'Git Author Must Have Access' Error](https://www.pavlinbg.com/posts/fix-vercel-git-author-error), + which was caused by the way how Vercel handles multiple accounts. + Written by Pavlin Gunov (PavlinBG) on his blog. +- [Running DVC on a SLURM cluster](https://dvc.org/blog/dvc-slurm-cluster-exscientia/) + by Dom Miketa on DVC Blog (2024). + - [DVC](https://dvc.org/) (Data Version Control), + an open-source version control system for data science projects, + was first mentioned in [Git Rev News Edition #23](https://git.github.io/rev_news/2017/01/25/edition-23/). + + +__Easy watching__ + +- [How to ensure the Git community is and stays healthy: Emily Shaffer / Patrick Steinhardt & guests](https://www.youtube.com/watch?v=vKsOFHNSb4Q) + on GitButler channel on YouTube [duration: 44:42]. + + +__Git tools and sites__ + +- [gitlogue](https://github.com/unhappychoice/gitlogue) + is a cinematic Git commit replay tool for the terminal, + turning your Git history into a living, animated story; + with realistic typing animations, syntax highlighting, and file tree transitions, + transforming code changes into a visual experience. + Written mainly in Rust, under ISC License. +- [PyDriller](https://github.com/ishepard/pydriller) is a Python framework + that helps developers in analyzing Git repositories. + With PyDriller you can easily extract information about + commits, developers, modified files, diffs, and source code. + Written in Python, under Apache 2.0 license. +- [tree-me](https://github.com/haacked/dotfiles/blob/main/bin/tree-me) + is a minimal `git worktree` helper + that leverages Git's native capabilities. + It uses Git-like subcommands and follows conventions so you don’t have to think: + auto-detects the repository name from your Git remote, + auto-detects the default branch, organizes by repo, provides tab completion, etc. + Single bash script, part of [haacked dotfiles](https://github.com/haacked/dotfiles). + No license. + - See also [Worktree Manager](https://github.com/jarredkenny/worktree-manager) (wtm), + a fast, modern CLI tool for managing Git worktrees in bare repositories, + mentioned in [Git Rev News Edition #128](https://git.github.io/rev_news/2025/10/31/edition-128/). +- [Spelungit](https://github.com/haacked/spelungit) is a Model Context Protocol (MCP) server + for exploring Git commit history using semantic search. + With this tool you can search through commits with natural language commands + like "Search Git history to find out why this class was added", + or "search_commits(query="authentication login changes", limit=5)". + Uses Microsoft's all-MiniLM-L6-v2 embedding model via [sentence-transformers](https://www.sbert.net/), + or deterministic hash-based embeddings when sentence-transformers is unavailable. + Written in Python (with a few Bash scripts), under MIT License. + - See also [Spelungit: When `git log --grep` isn't enough](https://haacked.com/archive/2025/09/29/announcing-spelungit/) + by Phil Haack on You've Been Haacked blog. +- [forgit](https://github.com/wfxr/forgit) is a utility tool + powered by [fzf](https://github.com/junegunn/fzf) (command-line fuzzy finder) + for using Git interactively. + Written in shell, under MIT license. +- [gitnr](https://github.com/reemus-dev/gitnr) is a cross-platform CLI utility + to create `.gitignore` files using one or more templates + from [TopTal](https://github.com/toptal/gitignore) (), + [GitHub](https://github.com/github/gitignore), or your own collection. + Written in Rust, under MIT License. +- [`mani`](https://manicli.com/) is a CLI tool + that helps you manage multiple repositories. + It's useful when you are working with microservices, multi-project systems, + multiple libraries, or just a collection of repositories, + and want a central place for pulling all repositories and running commands across them. + Written in Go, under MIT License. +- [eget](https://github.com/zyedidia/eget) is a command-line tool + for easily fetching and extracting pre-built binaries from GitHub releases. + Written in Go, under MIT License. +- [dunk](https://github.com/darrenburns/dunk) is a tool + to provide prettier Git diffs in the terminal + by piping `git diff` output into it (`git diff | dunk` or `git diff | dunk | less -R`). + In very early stages of development. + Written in Python, under MIT License. + - See also [git-delta](https://dandavison.github.io/delta/), + a syntax-highlighting pager for `git`, `diff`, `grep`, and `git blame` output. + It was first mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/), + though there is another [delta](https://github.com/octavore/delta) + command-line diff tool which was first mentioned in [edition #9](https://git.github.io/rev_news/2015/11/11/edition-9/). + - See also [diff-so-fancy](https://github.com/so-fancy/diff-so-fancy) tool, + which beside piping `git diff` output to it, + can also be used as `core.pager` and `interactive.diffFilter`. + It was first mentioned in [Git Rev News Edition #13](https://git.github.io/rev_news/2016/03/16/edition-13/). + - There is also a [`contrib/diff-highlight`](https://github.com/git/git/tree/master/contrib/diff-highlight) + diff pager script in the Git repository, written in Perl. + It was mentioned in [Git Rev News Edition #53](https://git.github.io/rev_news/2019/07/24/edition-53/). +- [GitType](https://github.com/unhappychoice/gittype) is a CLI tool + that turns your own source code into typing challenges. + Because why practice with boring [lorem ipsum](https://www.lipsum.com/) + when you can type your beautiful `fn main()` implementations? + Written in Rust, under MIT License. +- [Serie](https://github.com/lusingander/serie) is a TUI tool that + provides a rich Git commit graph in your terminal. + Written in Rust, under MIT License. + - See also [tig](https://jonas.github.io/tig/), + an ncurses-based text-mode interface for Git, + first mentioned in [Git Rev News Edition #18](https://git.github.io/rev_news/2016/08/17/edition-18/). +- [prettydiff](https://github.com/prettydiff/prettydiff) is a beautifier and language aware + code comparison tool for many languages. It also minifies and does a few other things. + There is a web service showing how the tool works at . + Written in TypeScript and HTML, + under [CC0](https://creativecommons.org/public-domain/cc0/) license. +- [fnox: Fort Knox for your secrets](https://fnox.jdx.dev/) + is a tool to manage secrets with encryption, or cloud providers, or both. + Fnox uses a simple TOML config file (`fnox.toml`) that you check into Git; + secrets are either encrypted inline, or provided as references + that point to a secret in age, AWS, 1Password, etc. + Written in Rust, under MIT License. +- [asdf](https://asdf-vm.com/guide/introduction.html) is a tool version manager. + All tool version definitions are contained within one file (`.tool-versions`) + which you can check in to your project's Git repository to share with your team, + ensuring everyone is using the exact same versions of tools. + Written mainly in Bash and Go, under MIT License. +- [grebedoc.dev](https://grebedoc.dev/) is a service + that offers static site hosting for Git forges; + it publishes the `pages` branch in your Git repository as a website on your domain. + More specifically, it is a public deployment of + [git-pages](https://codeberg.org/git-pages/git-pages) + and [Caddy](https://caddyserver.com/), configured to work especially with + [Codeberg](https://codeberg.org/) but also with other Git forges. + It is operated by Catherine 'whitequark' and teammates. + - Compare with [GitHub Pages](https://docs.github.com/en/pages), + [GitLab Pages](https://docs.gitlab.com/user/project/pages/), + [static websites on Bitbucket Cloud](https://support.atlassian.com/bitbucket-cloud/docs/publishing-a-website-on-bitbucket-cloud/), + [Codeberg Pages](https://codeberg.page/) (can't guarantee high availability), + [sourcehut pages](https://srht.site/), and + [Cloudflare Pages](https://pages.cloudflare.com/) (JAMstack platform), etc. +- [gitsuggest](https://github.com/csurfer/gitsuggest) is a tool + to suggest GitHub repositories based on the repositories you have shown interest in + by “starring”. It is using the Latent Dirichlet Allocation (LDA) method. + There is also a [gitSuggest](http://www.gitsuggest.com/) service (in beta) on Heroku. + Written on Python, under MIT License. +- [Josh](https://josh-project.github.io/josh/) (Just One Single History) + ([repo](https://github.com/josh-project/josh)) + is a tool that combines the advantages of monorepos with those of multirepos + by leveraging a blazingly fast, incremental, and reversible implementation + of Git history filtering. + Note that to guarantee filters are reversible + Josh restricts the kind of filter that can be used. + Use cases include partial cloning, workspaces, simplified CI/CD; + this tool also provides a GraphQL API. + Josh is distributed via [Docker Hub](https://hub.docker.com/r/joshproject/josh-proxy), + and you can start it with the appropriate `docker run` command. + See its [Frequently Asked Questions](https://josh-project.github.io/josh/faq.html#frequently-asked-questions) + for comparison with `git sparse-checkout`, partial clone, submodules, `git subtree`, + and `git filter-repo`. + Written mainly in Rust, under MIT License. +- [Furgit](https://villosa.lindenii.org/furgit//repos/furgit/) + ([GitHub mirror](https://github.com/runxiyu/furgit)) + is a fast Git library in pure Go (and a little bit of optional Go Assembly). + Written for [Lindenii Villosa](https://villosa.lindenii.org/villosa//repos/villosa/) + (successor to [Lindenii Forge](https://forge.lindenii.org/forge/-/repos/server/)), + a software forge primarily designed for self-hosting + by small organizations and individuals. + Under AGPL 3.0 license. +- [git-embigenner](https://github.com/veqqq/git-embigenner) + is a very simple shell script to cheat a high score on GitHub, + which will spam commits to populate your profile's contribution graph. + - Compare with [Git Draw](https://github.com/ben174/git-draw), + a Chrome extension which will allow you to freely draw on your GitHub heatmap, + mentioned in [Git Rev News Edition #12](https://git.github.io/rev_news/2016/02/10/edition-12/)
+ and [gitfiti](https://github.com/gelstudios/gitfiti), + a tool for crafting graffiti in a GitHub commit history calendar, + mentioned in [Git Rev News Edition #41](https://git.github.io/rev_news/2018/07/18/edition-41/). + - Contrast [Vigilante Justice on GitHub: GitHub Graffiti](https://trufflesecurity.com/blog/vigilante-justice-on-github) by Dylan Ayrey, + mentioned in [Git Rev News Edition #118](https://git.github.io/rev_news/2024/12/31/edition-118/), + about how you can paint funny pixel art (graffiti) with fake commit Git histories + on spammer/phisher’s GitHub profiles (that is, on their activity heatmap plot). + + +## Releases + ++ Git [2.52.0](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/), +[2.52.0-rc2](https://lore.kernel.org/git/xmqqzf8rqihh.fsf@gitster.g/), +[2.52.0-rc1](https://lore.kernel.org/git/xmqqqzubhyj9.fsf@gitster.g/), +[2.52.0-rc0](https://lore.kernel.org/git/xmqqwm47t4x3.fsf@gitster.g/) ++ Git for Windows [v2.52.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.52.0.windows.1), +[v2.52.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.52.0-rc2.windows.1), +[v2.52.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.52.0-rc1.windows.1), +[v2.52.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.52.0-rc0.windows.1) ++ GitLab [18.6.1, 18.5.3, 18.4.5](https://about.gitlab.com/releases/2025/11/26/patch-release-gitlab-18-6-1-released/), +[18.6](https://about.gitlab.com/releases/2025/11/20/gitlab-18-6-released/), +[18.5.2, 18.4.4, 18.3.6](https://about.gitlab.com/releases/2025/11/12/patch-release-gitlab-18-5-2-released/) ++ Bitbucket Data Center [10.1](https://confluence.atlassian.com/bitbucketserver/release-notes-872139866.html) ++ Gerrit Code Review [3.10.9](https://www.gerritcodereview.com/3.10.html#3109), +[3.11.6](https://www.gerritcodereview.com/3.11.html#3116), +[3.11.7](https://www.gerritcodereview.com/3.11.html#3117), +[3.12.3](https://www.gerritcodereview.com/3.12.html#3123), +[3.13.0-rc5](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.0](https://www.gerritcodereview.com/3.13.html#3130), +[3.13.1](https://www.gerritcodereview.com/3.13.html#3131) ++ GitHub Enterprise [3.18.1](https://docs.github.com/enterprise-server@3.18/admin/release-notes#3.18.1), +[3.17.7](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.7), +[3.16.10](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.10), +[3.15.14](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.14), +[3.14.19](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.19) ++ GitKraken [11.6.0](https://help.gitkraken.com/gitkraken-desktop/current/) ++ GitHub Desktop [3.5.4](https://desktop.github.com/release-notes/) ++ Git Cola [4.16.1](https://github.com/git-cola/git-cola/releases/tag/v4.16.1) ++ GitButler [0.18.1](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.18.1), +[0.18.0](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.18.0) ++ Kinetic Merge [1.11.2](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.11.2), +[1.11.1](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.11.1), +[1.11.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.11.0) ++ Tower for Mac [15](https://www.git-tower.com/blog/tower-mac-15) ([YouTube tour](https://youtu.be/xTrxb2dJP8M)) ++ Tower for Windows [10](https://www.git-tower.com/blog/tower-windows-10) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Ayush Chandekar, Štěpán Němec, +Bruno Brito and D. Ben Knoble. diff --git a/_posts/2025-12-31-edition-130.markdown b/_posts/2025-12-31-edition-130.markdown new file mode 100755 index 000000000..f857dc28f --- /dev/null +++ b/_posts/2025-12-31-edition-130.markdown @@ -0,0 +1,605 @@ +--- +title: Git Rev News Edition 130 (December 31st, 2025) +layout: default +date: 2025-12-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 130 (December 31st, 2025) + +Welcome to the 130th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of November and December 2025. + +## Discussions + + + + + +### Support + +* [git-2.51.0: Fetching tags does not work](https://lore.kernel.org/git/CAB9xhmPcHnB2%2Bi6WeA3doAinv7RAeGs04%2Bn0fHLGToJq%3DUKUNw%40mail.gmail.com) + + Last September, David Bohman reported a regression in Git 2.51.0 + where `git fetch --tags` failed to update tags in a bare + repository. He noted that the command output indicated tags would be + updated, but they were not actually added to the + repository. Reverting to version 2.50.1 resolved the issue. + + Junio Hamano, the Git maintainer, attempted to reproduce the issue + using a simple bare clone setup but was unsuccessful, suggesting + that David needed to narrow down the specific conditions. + + In early November, David returned to the thread reporting that the + issue persisted in Git 2.51.2. He provided a specific reproduction + case involving a bare clone of the [`bind9` source repository](https://gitlab.isc.org/isc-projects/bind9). + The output showed that one + tag update was rejected (with a `would clobber existing tag` error), + and consequently, all other valid new tags (`v9.18.41`, etc.) + failed to appear in the repository, despite being listed as "new + tag" in the output. The command exited with status code 1. + + Randall S. Becker suggested using `git fetch --tags --force` to + clear the situation. David Bohman replied that while he could + reproduce it locally, the key behavioral change was that prior to + version 2.51, Git would fail regarding the conflicting tag but still insert the + non-conflicting ones. + + Chris Torek identified the new reference transaction system + introduced in recent versions as the root cause. He noted that the + behavior had shifted to "all or nothing" (either all tags get + updated, or none do) and questioned which behavior was actually + buggy. David Bohman argued that this was a risky change for a mature + tool and noted that the diagnostic messages were misleading because + they reported success for tags that were not actually inserted. + + Karthik Nayak confirmed he could reproduce the issue and attributed + it to transaction reference updates. + + Karthik submitted + [version 1](https://lore.kernel.org/git/20251103-fix-tags-not-fetching-v1-1-e63caeb6c113%40gmail.com) + of a patch to fix the issue. He explained that commit `0e358de64a` + (fetch: use batched reference updates, 2025-05-19) introduced + batched reference updates for `git fetch`. When fetching references, + updates are added to a transaction. However, specifically when + fetching tags, if a conflict occurs, the function + `fetch_and_consume_refs()` returns an error code immediately. This + caused the code to jump to the cleanup section, skipping the commit + of the transaction entirely, and thus discarding even valid updates. + + The proposed fix involved extracting the transaction commit logic + into a new function, `commit_ref_transaction()`, and ensuring it is + called even when an error code is returned, provided the fetch is + not atomic. + + Eric Sunshine reviewed the patch, asking why the test code was + wrapped in subshells and suggesting that `!` should be replaced with + `test_must_fail`. Karthik agreed to these changes. + + Justin Tobler reviewed the code, agreeing with the logic. He + suggested adding a comment to `commit_ref_transaction()` to + distinguish it from `ref_transaction_commit()` and asked if the + return value of this new function should be checked. + + Karthik submitted + [version 2](https://lore.kernel.org/git/20251106-fix-tags-not-fetching-v2-1-610cb4b0e7c8%40gmail.com) + of the patch. This version added comments, removed subshells from + tests, and extended the fix to the `backfill_tags()` function. + + Patrick Steinhardt reviewed version 2. He questioned the commit + message's mention of the deprecated "branches/" format in relation + to tag backfilling. Karthik replied, clarifying that after + re-reading the code, he understood that backfilling happens when the + user does not specify `--tags` or `--no-tags`, confirming Patrick's + understanding. + + Patrick noted that the code now had three different call sites + committing the transaction and felt it was "somewhat fragile." + Justin pointed out that the return code of + `commit_ref_transaction()` was being ignored in the new + implementation. Karthik agreed to check the return value. + + Karthik submitted + [version 3](https://lore.kernel.org/git/20251108-fix-tags-not-fetching-v3-0-a12ab6c4daef%40gmail.com) + of the series. He split the changes into two commits: one for + extracting the logic and one for the fix. He also moved the commit + logic into the cleanup section to avoid calling it at every failure + point. + + Patrick reviewed version 3. He suggested using `goto out` in + `commit_ref_transaction()` for better readability. He also asked for + clarification on why the condition `retcode > 0` was safe in the + cleanup section, specifically regarding `prune_refs()`. Karthik + replied, explaining that `prune_refs()` creates its own internal + transaction, but later realized he was mistaken about the timing and + promised to verify. + + Karthik submitted + [version 4](https://lore.kernel.org/git/20251111-fix-tags-not-fetching-v4-0-185d836ec62a%40gmail.com). + This version simplified the code and changed the check from + `retcode > 0` to just `retcode`. + + Patrick pointed out that the commit message regarding `prune_refs()` + behavior change seemed incorrect because no transaction exists at + that stage. Karthik verified this and confirmed there is no change + for `prune_refs()`. + + Karthik submitted + [version 5](https://lore.kernel.org/git/20251113-fix-tags-not-fetching-v5-0-371ea7ec638d%40gmail.com) + with corrected commit messages and better test cleanup. + + Junio reviewed version 5 and identified a remaining + issue. He noted that while the patch fixed the transaction commit, + jumping to the cleanup label early meant that subsequent operations + (specifically `commit_fetch_head()`, `set_upstream()`, and setting + remote HEADs) were still being skipped when errors occurred. He + argued that in non-atomic fetches, these should still run. Karthik + agreed and proposed a fix to only jump to cleanup if `--atomic` was + used. + + Karthik submitted + [version 6](https://lore.kernel.org/git/20251118-fix-tags-not-fetching-v6-0-2a2f15fc137e%40gmail.com), + adding a third commit to the series to address the skipped + operations regression identified by Junio. + + Junio reviewed version 6. He liked the tests but warned + against using `touch` to create files due to timestamp issues and + noted a missing test case for `--set-upstream` on a successful + fetch. Karthik agreed to fix these. + + Karthik submitted + [version 7](https://lore.kernel.org/git/20251119-fix-tags-not-fetching-v7-0-0c8f9fb1f287%40gmail.com), + removing `touch` and adjusting the test prerequisites. + + Eric reviewed the tests in version 7, asking if `! test -f` should + be `test_path_is_missing`. Junio suggested using `rm -f FETCH_HEAD` + before the test to ensure it is actually created during the run, and + inspecting the file content to verify what was recorded. Karthik + agreed. + + Karthik submitted + [version 8](https://lore.kernel.org/git/20251121-fix-tags-not-fetching-v8-0-23b53a8a8334%40gmail.com). + This version verified the content of `FETCH_HEAD` and used + `test_path_is_missing`. + + Junio commented that the series looked good. Patrick pointed out a + tiny grammar nit ("eventhough") and asked if the shell syntax + `>file` used in the test was compatible with all systems, noting + `: >file` is more typical. Karthik replied that existing tests use + the shorter syntax, so it should be fine. + + The small patch series was eventually merged, and should be part of + Git 2.53.0 that should be released at the latest towards the + beginning of February 2026. With this version, not only the transaction logic + will be fixed, but related regressions regarding post-fetch + operations (like updating `FETCH_HEAD`) will also have been + identified and resolved. + + +## Developer Spotlight: Lucas Seiki Oshiro + +* **Who are you and what do you do?** + + My name is Lucas Oshiro, I'm one of the three + GSoC '25 participants working on Git. I'm from São Paulo, Brazil, + and I hold bachelor and master degrees in Computer Science from the + [University of São Paulo](https://www5.usp.br/#english). I don't + have only one specific interest in programming topics, I enjoy + several different topics, like lower-lever C code (like we do for Git), + FP languages (especially Haskell), play with network simulators, data + analysis, operating systems, databases and so on. + +* **How did you initially become interested in contributing to Git, + and what motivated you to choose it as your GSoC project?** + + Well, it's a long story... I think that it dates back to 2017, in a + Computer Networks assignment at my university. My partner in that + assignment was [Matheus Tavares](https://matheustavares.gitlab.io/posts/gsoc-final-report), + who participated in [GSoC '19 on Git](https://summerofcode.withgoogle.com/archive/2019/projects/4787791739748352). + At the time, we needed to study a vulnerability and how it was fixed. + We chose [CVE-2017-1000117](https://nvd.nist.gov/vuln/detail/cve-2017-1000117), + which was a vulnerability in Git. That was my first time reading Git + source code. + + Two years later, I was a member of a [group focused on contributing to Free/Open-Source software](https://flusp.ime.usp.br) + at my University. I sent a patch to Git at the time, but I needed to + focus on other stuff and I couldn't finish it. + + After that, I started to work as a back-end software engineer and + witnessed several Git-related problems. My two previous experiences with + Git's source code made me want to understand what was happening and + delving into its internals, so I could help other developers from my + company when something unexpected happened with Git. + + This way, Git always felt like the right choice. + +* **How do you feel your contribution has impacted the Git community + or the broader open source ecosystem?** + + My GSoC project was to create the new command [`git repo info`](https://summerofcode.withgoogle.com/archive/2025/projects/fGgMYHwl)). + It was released in Git 2.52.0 and, like many other new Git features, I + expect it will take some time to be widely adopted, since it's only + available in bleeding-edge repositories. But I expect that it will be + useful for forges, CIs, local tools, scripts, and other tools that + depend on Git. + +* **Is there any aspect of Git that you now see differently after + having contributed to it?** + + I can't think of anything that I see differently after GSoC, but my + previous contacts with Git's source code made me realize the importance + of having a good commit history with good commit messages. It also made + me understand how powerful Git is as a debugging and searching tool. + +* **How do you balance your contributions with other responsibilities + like work or school?** + + This year, I was more focused on finishing my master's research and I + didn't have too many conflicts with GSoC, so I could focus on my + master's when my patches were under review. However, I must admit that + one of the reasons that I didn't apply to GSoC before was that, here + in Brazil, we typically have final exams in June, which makes it hard + to balance them with something else. + +* **Can you share how GSoC helped enhance your technical and + non-technical skills (like communication, project management, + etc.)?** + + I see Git as a product created by developers, for developers, and I + think that here we sometimes need to do the work that in other contexts + would be done by product owners and designers. I felt that especially + during code reviews, which were often more focused on product and design + decisions rather than the code itself. I had to learn how to discuss + these kinds of decisions, always aiming to do what is best for Git + and its users. + +* **What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it?** + + I think that the biggest challenge was the complete redesign of + `git repo info` during the GSoC period, which made me re-write it from + scratch several times. I think this was a consequence of my previous + answer and that this challenge was solved itself. + +* **Have you thought about mentoring new GSoC / Outreachy students?** + + Yes, it would be very nice! + +* **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?** + + Git is amazing and I think we all agree that it makes the programmers' + lives easier. It would be great if we had a GUI wrapping Git but + targeting non-technical users. + +* **If you could remove something from Git without worrying about + backwards compatibility, what would it be?** + + Perhaps commands that accumulate responsibilities, like `git checkout`, + `git reset` and `git rev-parse`. They make sense from the Git + perspective, but I think they are confusing from the users' + perspective. + +* **What upcoming features or changes in Git are you particularly + excited about?** + + Some that come to my mind are: + + - Patrick Steinhardt's new [`git history`](https://lore.kernel.org/git/20250819-b4-pks-history-builtin-v1-0-9b77c32688fe@pks.im/) + command: rewriting history is essential to keep the repository sane + and useful as a data storage, if done correctly. Currently we do that + through interactive rebase but I think it can be intimidating for less + experienced users. Jujutsu proposes a more straightforward way to do + that, and it's nice to see Patrick bringing it to Git. + + - Justin Tobler's [new `git repo structure` command](https://public-inbox.org/git/20251217175404.37963-1-jltobler@gmail.com/): + of course I'm interested in this subcommand since it is the sibling of + my GSoC project. But it's not only because of that: a Git repository is + a very rich source of information and `git repo structure` will be a + powerful tool to retrieve it. + + - Julia Evans's [contributions to documentation](https://public-inbox.org/git/?q=f%3A%22Julia+Evans%22&r=): + Julia has been producing high-quality content about several programming + topics for years. I'm happy to see Git being documented by someone so + committed to spreading knowledge and who knows how to explain advanced + concepts using a simple language. + +* **What is your favorite Git-related tool/library, outside of Git + itself?** + + I use [delta](https://github.com/dandavison/delta) a lot, I like the way + it highlights diffs. Other tools that I find interesting are [Jujutsu](https://docs.jj-vcs.dev/latest/) + and [Magit](https://magit.vc/), but I don't use them too much. + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I like desktop mail clients, but I don't have a strong preference. On + Linux, I use Thunderbird. On Mac, I use Apple Mail. I also have some + GMail filters for classifying the messages (patches, What's Cooking and + Rev News announcements). + + However, those mail clients don't have code syntax highlighting, and it's + hard to read the patches inside them. For that purpose, I use + [patch-hub](https://github.com/kworkflow/patch-hub), a TUI for reviewing + patches from kernel mailing lists (including Git). + +* **How do you envision your own involvement with Git or other open + source projects in the future?** + + There are some things I want to finish in `git repo info`, and I + still send patches for it. I enjoyed contributing to Git and I + don't want to stop here. + + Outside Git development, I'll give an advanced course on Git next + month. It will be a great opportunity to share what I've learned here + with other people. + +* **What is your advice for people who want to start Git development? + Where and how should they start?** + + Read the [Git Internals chapter from Pro Git](https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain), + follow everything described in [Hacking Git](https://git.github.io/Hacking-Git/), + and work on a [microproject](https://git.github.io/SoC-2025-Microprojects/). + +* **Would you recommend other students or contributors to participate + in the GSoC, Outreachy or other mentoring programs, working on Git? + Why? Do you have advice for them?** + + Yes. I mean, I've already recommended some people from my university to + apply to GSoC or Outreachy on Git and gave some tips to them. Some of + them have already sent patches that were accepted. + + +## Other News + +__Various__ + ++ [Debian’s git transition](https://diziet.dreamwidth.org/20436.html) + by Ian Jackson on diziet's journal on Dreamwidth. + The main goal of the transition is to make it so that + everyone who interacts with Debian source code should be able to do so entirely in git. ++ [Git’s New Era: What Git 2.52 and the Road to Git 3.0 Mean for Developers in 2026](https://blog.stackademic.com/gits-new-era-what-git-2-52-and-the-road-to-git-3-0-mean-for-developers-in-2026-eb2c3b4e6e79) + by Faisal haque on Medium. + Free access provided via Faisal haque's Friend Link. + + See also [What’s new in Git 2.52.0?](https://about.gitlab.com/blog/whats-new-in-git-2-52-0/) on GitLab Blog and + [Highlights from Git 2.52](https://github.blog/open-source/git/highlights-from-git-2-52/) on GitHub Blog, + mentioned in the [previous edition of Git Rev News](https://git.github.io/rev_news/2025/11/30/edition-129/). + + See also [Git Developers Talk About Potentially Releasing Git 3.0 By The End Of Next Year](https://www.phoronix.com/news/Git-3.0-Release-Talk-2026) on Phoronix, + mentioned in [Git Rev News Edition #128](https://git.github.io/rev_news/2025/10/31/edition-128/). + + There is also [BreakingChanges: Git 3.0](https://git-scm.com/docs/BreakingChanges#_git_3_0) + document in the Git documentation. + + +__Light reading__ + ++ [Package managers keep using git as a database, it never works out](https://nesbitt.io/2025/12/24/package-managers-keep-using-git-as-a-database.html) + by Andrew Nesbitt on his blog. ++ [Git Commit Count Percentile Stats, Annual Days Active from 878,592 Dev-year Data Points](https://www.gitclear.com/research_studies/git_commit_count_percentiles_annual_days_active_from_largest_data_set) + by Bill Harding, a first-party research by GitClear. ++ [Fizzy Design Evolution: A Flipbook from Git](https://www.zolkos.com/2025/12/08/fizzy-design-evolution-a-flipbook-from-git) + by Rob Zolkos on his blog; includes the generated video. ++ [Comparing the homepage-claims of popular Git hosting providers](https://www.zufallsheld.de/2025/12/02/comparing-homepage-claims-of-git-providers/) + by Sebastian Gumprich on zufallsheld - a tech blog. ++ [Are people migrating away from GitHub?](https://www.roboleary.net/blog/github-migration/), + a short post (with examples) by Rob O'Leary on his blog. ++ [GitHub Actions Has a Package Manager, and It Might Be the Worst](https://nesbitt.io/2025/12/06/github-actions-package-manager.html) + by Andrew Nesbitt on his blog. ++ [The Pain That Is GitHub Actions](https://www.feldera.com/blog/the-pain-that-is-github-actions) + by Gerd Zellweger on feldera blog. ++ [Migrating from GitHub to Codeberg](https://robinmetral.com/notes/migrating-from-github-to-codeberg/) + by Robin Métral on his blog. ++ [Migrating my code to Codeberg](https://eldred.fr/blog/codeberg/) and + [GitHub → Codeberg: my experience](https://eldred.fr/blog/forge-migration/) + by Eldred Habert on ISSOtm's warehouse blog. ++ [Migrating Dillo from GitHub](https://dillo-browser.org/news/migration-from-github/) + by Rodrigo Arias Mallo on Dillo project blog. ++ [Migrating from GitHub to Codeberg](https://ziglang.org/news/migrating-from-github-to-codeberg/) + by Andrew on Zig Language News. ++ [How Do Git Remotes Work? And How Do I Self-host My Own?](https://fev.al/posts/git-remote/) + What it takes to create the simplest, barest self-hosted Git remote, + and learn stuff about Git in the process. + Post by Charles Féval on his blog. ++ [Guarding My Git Forge Against AI Scrapers](https://vulpinecitrus.info/blog/guarding-git-forge-ai-scrapers/) + by ~lymkwi (lux) on VulpineCitrus blog. + The forge in question is a self-hosted [Forgejo instance](https://git.vulpinecitrus.info/). ++ [Rethinking Git Pre-Commit Hooks](https://mathieularose.com/rethinking-git-pre-commit-hooks) + by Mathieu Larose on his blog. ++ [pre-commit hooks are fundamentally broken](https://jyn.dev/pre-commit-hooks-are-fundamentally-broken/) + by Jynn Nelson (@jyn) on the website of jyn. + + See also [Discussion of the Benefits and Drawbacks of the Git Pre-Commit Hook](https://yeldirium.de/2025/10/09/pre-commit-hooks/index.html) + in [Git Rev News Edition #128](https://git.github.io/rev_news/2025/10/31/edition-128/). + + The [Git Hooks](https://githooks.com/) website gives an example of using pre-commit hook + to check the commit message for spelling errors;
+ the [`pre-commit.sample`](https://github.com/git/git/blob/master/templates/hooks/pre-commit.sample) + provided with Git checks for non-ASCII characters in filenames + (and can be configured to be turned off with `hooks.allownoascii`). + + There are various tools that help managing pre-commit hooks, like + [pre-commit](https://pre-commit.com/) + (first mentioned in [Git Rev News #45](https://git.github.io/rev_news/2018/11/21/edition-45/)) + and [_prek_](https://prek.j178.dev/) + (first mentioned in [Git Rev News #127](https://git.github.io/rev_news/2025/09/30/edition-127/)). ++ [Fixing the "Ghost Folder" in GitHub: Converting a Broken Submodule to a Normal Folder](https://dev.to/raziq_din_bd0274cc2ac748b/fixing-the-ghost-folder-in-github-converting-a-broken-submodule-to-a-normal-folder-44c5) + by Raziq Din on DEV\.to. ++ [Shooting myself in the foot with Git by accident](https://utcc.utoronto.ca/~cks/space/blog/programming/GitConcurrentUsageOops) + by Chris Siebenmann on CSpace blog. + The Git error in question was + _"error: fetching ref refs/remotes/origin/master failed: incorrect old value provided"_. ++ [Tracking renamed files in Git](https://oleb.net/2025/git-file-renaming/) and + [Use 'git mv' to record filename case changes in Git](https://oleb.net/2025/git-mv-case-change/) + by Ole Begemann on his blog. ++ [Branch Protection Rules vs Rulesets: The Right Way to Protect Your Git Repository](https://dev.to/piyushgaikwaad/branch-protection-rules-vs-rulesets-the-right-way-to-protect-your-git-repos-305m) + by Piyush Gaikwad on DEV\.to. + The main idea is to use Branch Protection Rules for long lived branches, + and Branch Rulesets for short lived branches, defining rules before branches are created. ++ [`magit-insert-worktrees` improves status buffers](https://huonw.github.io/blog/2025/12/magit-insert-worktrees/) + by Huon Wilson on his "Huon on the internet" blog. + + The [Magit](https://magit.vc/) package for interfacing to Git within the Emacs editor + was first mentioned in passing in [Git Rev News Edition #6](https://git.github.io/rev_news/2015/08/05/edition-6/); + among other mentions there was [Emacs and Magit](https://lwn.net/Articles/727550/) + article on LWN\.net in [Git Rev News Edition #30](https://git.github.io/rev_news/2017/08/16/edition-30/). ++ [Archiving git branches as tags](https://etc.octavore.com/2025/12/archiving-git-branches-as-tags/) + with a git alias. Blog post by octavore + (the author of [Delta](https://github.com/octavore/delta), a command-line diff tool) + on "et cetera". ++ [Building a Meta-Logger: Tracking My Work Across GitHub, Codeberg, and Bitbucket Using Go](https://dev.to/nimxch/building-a-meta-logger-tracking-my-work-across-github-codeberg-and-bitbucket-using-go-4kp6) + by Nimai Charan on DEV\.to. ++ [why i think jj-vcs is worth your time](https://schpet.com/note/why-i-think-jj-vcs-is-worth-your-time) + on Schpet’s Notebook. + + [Jujutsu (`jj`)](https://jj-vcs.github.io/) is a Git-compatible + version control system written in Rust, which was first mentioned + in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). + + See also [Should I Switch From Git to Jujutsu](https://etodd.io/2025/10/02/should-i-switch-from-git-to-jujutsu/) + (mentioned in [Git Rev News Edition #129](https://git.github.io/rev_news/2025/11/30/edition-129/)) and + [Switch to Jujutsu already: a tutorial](https://www.stavros.io/posts/switch-to-jujutsu-already-a-tutorial/) + (mentioned in [Git Rev News Edition #128](https://git.github.io/rev_news/2025/10/31/edition-128/)). ++ [From Zero to GitHub: Starting A New jj (Jujutsu) Repo](https://www.visualmode.dev/from-zero-to-github-starting-a-new-jj-jujutsu-repo) + by Josh Branchaud on VisualMode. ++ [30 Years of `
` Tags](https://www.artmann.co/articles/30-years-of-br-tags): + Three decades of making things on the internet. + Includes the introduction of Git, GitHub, and the GitDevOps (push to publish) workflow. + Post by Christoffer Artmann on his blog. ++ [Free Software Needs Free Tools](https://mako.cc/writing/hill-free_tools.html) + by Benjamin Mako Hill (2010). + + +__Easy watching__ + ++ [Magit, fzf, and ast-grep demo](https://www.saltycrane.com/blog/2025/12/magit-fzf-and-ast-grep-demo/) + by Eliot (@saltycrane) on SaltyCrane Blog. + The video [on YouTube](https://www.youtube.com/watch?v=W4eOz3L6Ga8) + is 12:40 minutes long. ++ [Git & GitHub Crash Course for Beginners](https://www.freecodecamp.org/news/git-and-github-crash-course-for-beginners/) + by Beau Carnes on freeCodeCamp. + The video [on YouTube](https://www.youtube.com/watch?v=mAFoROnOfHs) + by freeCodeCamp.org and logicBase Labs + is 1:21:19 hours long. + + +__Git tools and sites__ + ++ [check-projects](https://github.com/uralys/check-projects) + is a fast, cross-platform CLI tool (with TUI interface) + to check the Git status of multiple projects organized by categories. + Written in Go, under MIT license. ++ [repos](https://github.com/epilande/repos) + is an interactive CLI tool for managing multiple Git repositories. + Written in TypeScript (with pre-built binaries), under MIT license. ++ [Patchy 🩹](https://github.com/richardgill/patchy) + is a CLI for generating and applying patches to Git repositories. + + Similar in a way to [Stacked Git](https://stacked-git.github.io/), + StGit for short, first mentioned in [Git Rev News Edition #17](https://git.github.io/rev_news/2016/07/20/edition-17/), + to a lesser extent to [patchwork](http://jk.ozlabs.org/projects/patchwork/), + first mentioned in [Git Rev News Edition #20](https://git.github.io/rev_news/2016/10/19/edition-20/), + or to [git-revise](https://mystor.github.io/git-revise.html), + first mentioned in [Git Rev News Edition #54](https://git.github.io/rev_news/2019/08/21/edition-54) - where + you can find links to other similar tools. ++ [git-pw](https://patchwork.readthedocs.io/projects/git-pw/en/latest/usage.html) + is a tool for integrating Git with Patchwork. + Written in Python, under MIT license. ++ [git-forge](https://github.com/Leleat/git-forge) + is a simple CLI tool for basic interactions with issues and pull requests + across GitHub, GitLab, Gitea, and Forgejo. + (Re)Written in Rust, under MIT license.
+ See also [git-forge: Faster Issues and PRs From Your Terminal](https://neverready.app/blog/2025/03-git-forge/) + blog post by Anh Tuan Le. ++ [gtr - Git Worktree Runner](https://github.com/coderabbitai/git-worktree-runner) + by the CodeRabbit team + is a portable, cross-platform CLI for managing Git worktrees with ease, + with editor and AI tool integration. + It automates per-branch worktree creation, configuration copying, + dependency installation, and workspace setup. + Written in Bash, under Apache 2.0 license.
+ See also [A Better Way to Run Git Worktrees Finally!](https://dev.to/nemesiscodex/a-better-way-to-run-git-worktrees-finally-1lh9) + by Julio Daniel Reyes on DEV\.to, + with [video on YouTube](https://www.youtube.com/watch?v=r9uGLZ3AkWo) [5:52]. + + There is also [Worktree Manager (wtm)](https://github.com/jarredkenny/worktree-manager) + mentioned in [Git Rev News Edition #128](https://git.github.io/rev_news/2025/10/31/edition-128/), and + [wtp (Worktree Plus)](https://github.com/satococoa/wtp) + mentioned in [Git Rev News Edition #125](https://git.github.io/rev_news/2025/07/31/edition-125/). ++ [Git Pow](https://github.com/markrai/gitpow) + is an open-source, cross-platform Git client. + It implements conditional strategies to handle larger repositories, + showing image previews to visualize what changed, + and grouping commits by month/year, among other features. + Written in Rust and JavaScript using the [Tauri](https://tauri.app/) framework. + Under GNU GPL v3.0 license. ++ [Git Repository Squirrel 🐿️ (reposquirrel)](https://github.com/reposquirrel/reposquirrel) + is a comprehensive Git repository analytics tool + that provides detailed insights into developer contributions, subsystem ownership, + and codebase evolution over time. + Written in Python (using the Flask library) and JavaScript, + under [CC-BY-NC-SA 4.0 license](https://creativecommons.org/licenses/by-nc-sa/4.0/). + [Demo](http://13.61.92.173:5555/) and Docker image available. ++ [Gitmal](https://github.com/antonmedv/gitmal) + is a static page generator for Git repositories. + Gitmal generates static HTML pages with files, commits, code highlighting, and Markdown rendering. + Written in Go, under MIT license. ++ [Git Rewind](https://github.com/mikelane/git-rewind) + is a GitHub App that provides Your GitHub year in review — with privacy-first, + read-only access (using fine-grained permissions). + Written in TypeScript, under MIT license. + Available at [git-rewind.vercel.app](https://git-rewind.vercel.app/). ++ [Critic](https://github.com/jensl/critic) + is a code review system. + It is a web application written in Python, tightly integrated with Git. + Under Apache 2.0 license.
+ See also [Meet Critic: Code Inspection System in Opera Software](https://sudonull.com/post/135595) + on Sudo Null IT News. ++ [Buggy: Fast and simple bug tracker](https://git.dillo-browser.org/buggy/tree/README.md?h=main). + The buggy program compiles a set of issues written in Markdown into HTML pages + suitable to be read from a web browser. It is intended to be used + alongside a version control system (VCS) like Git to track changes in the issues. + Written in C, under MIT license. ++ [Today I Learned: Git](https://github.com/jbranchaud/til?tab=readme-ov-file#git) + by Josh Branchaud, under MIT license. + + +## Releases + ++ libgit2 [1.9.2](https://github.com/libgit2/libgit2/releases/tag/v1.9.2) ++ GitHub Enterprise [3.19.0](https://docs.github.com/enterprise-server@3.19/admin/release-notes#3.19.0), +[3.18.3](https://docs.github.com/enterprise-server@3.18/admin/release-notes#3.18.3), +[3.17.9](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.9), +[3.16.12](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.12), +[3.15.16](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.16), +[3.14.21](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.21), +[3.18.2](https://docs.github.com/enterprise-server@3.18/admin/release-notes#3.18.2), +[3.17.8](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.8), +[3.16.11](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.11), +[3.15.15](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.15), +[3.14.20](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.20) ++ GitLab [18.7](https://about.gitlab.com/releases/2025/12/18/gitlab-18-7-released/), +[18.6.2, 18.5.4, 18.4.6](https://about.gitlab.com/releases/2025/12/10/patch-release-gitlab-18-6-2-released/) ++ GitKraken [11.7.0](https://help.gitkraken.com/gitkraken-desktop/current/) ++ Sourcetree [4.2.15](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.15.html) ++ Garden [2.4.0](https://github.com/garden-rs/garden/releases/tag/v2.4.0), +[2.5.0](https://github.com/garden-rs/garden/releases/tag/v2.5.0) ++ Git Cola [4.17.0](https://github.com/git-cola/git-cola/releases/tag/v4.17.0) ++ GitButler [0.18.3](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.18.3), +[0.18.2](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.18.2) ++ Sublime Merge [Build 2121](https://www.sublimemerge.com/download) ++ Kinetic Merge [1.13.2](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.13.2), +[1.13.1](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.13.1), +[1.13.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.13.0), +[1.12.2](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.12.2), +[1.12.1](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.12.1), +[1.12.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.12.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Lucas Seiki Oshiro and David Aguilar. diff --git a/_posts/2026-01-31-edition-131.markdown b/_posts/2026-01-31-edition-131.markdown new file mode 100644 index 000000000..ba208dcde --- /dev/null +++ b/_posts/2026-01-31-edition-131.markdown @@ -0,0 +1,384 @@ +--- +title: Git Rev News Edition 131 (January 31st, 2026) +layout: default +date: 2026-01-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 131 (January 31st, 2026) + +Welcome to the 131st 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](https://git.github.io). + +This edition covers what happened during the months of December 2025 and January 2026. + +## Discussions + + + + + +### Support + +* [Would it make sense to add a `commit.signOff` config?](https://lore.kernel.org/git/86c5d40d-5a06-4a69-90d8-a737685b0536%40haller-berlin.de) + + Stefan Haller started the discussion by asking if it would be + appropriate to add a `commit.signoff` configuration variable. He + observed that while many Git commands, such as `merge`, + `cherry-pick`, and `revert`, accept the `--signoff` argument, only + `format-patch` has a corresponding configuration to enable it for + all invocations. Stefan found it reasonable for users to want a + "Signed-off-by" trailer added automatically to every commit they + make. This question was prompted by his work on the Lazygit + project, which already includes such a configuration and had + received a feature request to extend its behavior to the `revert` + command. + + The "Signed-off-by" trailer is a formal certification that the + contributor has the right to submit the work under the project's + license, often associated with a Developer Certificate of Origin + (DCO). While widely used in open-source projects to maintain a legal + paper trail, its use in closed-source environments is less common. + + Carlo Marcelo Arenas Belón replied to Stefan, noting that a similar + topic had been + [discussed recently](https://lore.kernel.org/git/xmqq4iwvfx8s.fsf@gitster.g/) + where it was argued that sign-offs should be given explicitly rather + than automated. Junio Hamano, the Git maintainer, agreed and + suggested resurrecting a + [proposal from 2020](https://lore.kernel.org/git/xmqqpnfw8gyn.fsf@gitster-ct.c.googlers.com/) + to explicitly document why Git intentionally lacks this + configuration. Junio expressed a desire to "save time from potential + contributors" who might otherwise put effort into a patch that the + community had already reached a consensus against. + + Collin Funk supported the idea of documenting the consensus and + recommended using the full phrase "Signed-off-by" instead of the + abbreviation "SoB" to ensure clarity for all readers. brian + m. carlson suggested that the explanation could be placed in the Git + FAQ, the manual pages, or both. brian also provided a minor + grammatical correction to the initial text proposal. + + Junio submitted + [version 1](https://lore.kernel.org/git/xmqqldj48pyl.fsf%40gitster.g) + of a patch to document the decision. The proposed text explained + that automation makes it harder to defend a sign-off's validity in + court, as a person could claim the trailer "was done by inertia + without person X really intending to certify what DCO says". The + patch also acknowledged that while `format.signoff` exists, it is + considered a "historical mistake" that should not be emulated by + other commands. + + Elijah Newren found the initial draft somewhat difficult to parse + and suggested an alternative version with more sentence + breaks. Elijah’s draft emphasized that Git avoids automatic + sign-offs specifically to "protect the legal and intentional + significance of a sign-off". He also recommended a shorter version + for the manual pages that would point users toward a more detailed + entry in the FAQ. Johannes Sixt agreed that Elijah’s version was + much easier to read and suggested a minor shortening of the final + sentences to maintain impact. Johannes also emphasized the + importance of leaving a pointer in the manual pages, as users + looking for automation features are more likely to check + documentation for specific commands rather than the general FAQ. + + Junio provided + [version 2](https://lore.kernel.org/git/xmqqv7i62r6w.fsf%40gitster.g) + of the patch, which incorporated Elijah's and Johannes's + refinements. During the final review, Johannes suggested changing + the phrase "pile on more mistakes" to "add more mistakes" to be + clearer for non-native English speakers. Junio adopted this change, + noting it would be clear for everyone. Kristoffer Haugsbakk also + contributed a final polish by suggesting the use of a proper + `linkgit:gitfaq[7]` reference in the manual page. Elijah and brian + both confirmed they were satisfied with the final result. + + During the discussion there was a clear consensus that Git will not + add a global `commit.signoff` configuration. The creation of + permanent documentation in the Git FAQ and manual pages to explain + the legal reasoning behind this decision will prevent future + contributors from wasting time on a feature that would be rejected. + + + +## Other News + +__Various__ + ++ [A data model for Git (and other docs updates)](https://jvns.ca/blog/2026/01/08/a-data-model-for-git/) + by Julia Evans on her blog + (see [comments on Mastodon](https://comments.jvns.ca/post/115861337435768520) + and on [LWN\.net announcement](https://lwn.net/Articles/1053595/)). ++ [SQL Server Management Studio 22 Git Integration](https://www.mssqltips.com/sqlservertip/11585/ssms-22-git-integration/) + by Daniel Calbimonte on MSSQLTips. + + +__Light reading__ + ++ [Diff Algorithm Spelunking](https://dacharycarey.com/2025/12/29/diff-algorithm-spelunking/) + by Dachary Carey. + + See also [Difftastic](https://difftastic.wilfred.me.uk/), + a structural diff tool that understands syntax, + first mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/), + and [Delta](https://dandavison.github.io/delta/), + a syntax-highlighting pager for git, diff, and grep output, + first mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/). ++ [Git Rebase for the Terrified](https://www.brethorsting.com/blog/2026/01/git-rebase-for-the-terrified/) + by Aaron Brethorst on Brethorsting Blog. ++ [I made my own git](https://tonystr.net/blog/git_immitation) + by Tony Strømsnæs on his blog. + As it was created with the goal of improving the author's understanding of Git, + it is intentionally made not compatible with Git: + it uses SHA-256 instead of (current) SHA-1, and zstd instead of zlib. + The example code is written in Rust. + + The [Build your own `Git`](https://github.com/codecrafters-io/build-your-own-x#build-your-own-git) + section of [build-your-own-x](https://github.com/codecrafters-io/build-your-own-x) + lists a few articles about reimplementing parts of Git functionality. + Mentioned in [Git Rev News Edition #40](https://git.github.io/rev_news/2018/06/20/edition-40/). + + [Write yourself a Git!](https://wyag.thb.lt/) + by Thibault Polge is an attempt at explaining the Git version control system + from the bottom up by reimplementing it in Python. + Mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/). ++ [git-pkgs: explore your dependency history](https://nesbitt.io/2026/01/01/git-pkgs-explore-your-dependency-history.html) + by Andrew Nesbitt on his blog. ++ [Git's HTTP server side design does not scale](https://xeiaso.net/notes/2025/distributed-git-ddos/): + a small rant about CGI. Written by Xe Iaso on their blog. ++ [Tracking kernel development with korgalore](https://people.kernel.org/monsieuricon/tracking-kernel-development-with-korgalore) + by Konstantin Ryabitsev on his blog. + TLDR: use [korgalore](https://korgalore.docs.kernel.org/) + to bypass mailing list delivery problems. + (See also [comments on LWN\.net](https://lwn.net/Articles/1055219/#Comments).) ++ [My first 20,000 curl commits](https://daniel.haxx.se/blog/2026/01/17/my-first-20000-curl-commits/) + by Daniel Stenberg on his blog. ++ [GitOps with ArgoCD feels like the right abstraction](https://nick.scialli.me/blog/gitops/) + by Nick Scialli on his blog. ++ [Bob and Alice: a git patch love story](https://cybrkyd.com/post/a-git-patch-love-story/) + by cybrkyd (Just another Cyber Kid). ++ [Allowlist for .gitignore](https://blog.izissise.net/posts/gitignoreallowlist/) + by Hugues Morisset (izissise) on his blog. + Describes a dedicated script to generate the allow-list based `.gitignore` file effectively + to used with a monorepo. ++ [On git show](https://tonystr.net/blog/git) + by Tony Strømsnæs on his blog, + about the use of `git show :`. ++ [How to sync files between two local machines using Git](https://www.howtogeek.com/i-turned-git-into-a-private-github-free-sync-system-between-my-own-machines-and-it-completely-changed-how-i-work/) + by Bobby Jack on How-To Git. ++ [Manage Diagrams in AsciiDoc (with PlantUML) on GitHub](https://lornajane.net/posts/2026/manage-diagrams-in-asciidoc-on-github) + (using a build script) by Lorna Jane Mitchell on LornaJane Blog. + + See also [Include diagrams in your Markdown files with Mermaid](https://github.blog/developer-skills/github/include-diagrams-markdown-files-mermaid/) + (2022) by Martin Woodward & Adam Biagianti on GitHub Blog, + mentioned in [Git Rev News Edition #84](https://git.github.io/rev_news/2022/02/28/edition-84/). ++ [Maintaining shadow branches for GitHub PRs](https://maskray.me/blog/2026-01-22-maintaining-shadow-branches-for-github-prs) + by Fangrui Song (MaskRay). + The goal is to be able to see clean diffs between base and feature branch, + even though the underlying commits were rewritten, + and the base moved ahead. ++ [Post-Agentic Code Forges](https://sluongng.substack.com/p/post-agentic-code-forges), + by Son Luong Ngoc (sluongng) on Son’s Substack. + + See also [Getting AI to Work in Complex Codebases](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/ace-fca.md). ++ [Abandon Git LFS because AI Agents](https://justin.poehnelt.com/posts/abandon-git-lfs-because-agents/) + by Justin Poehnelt (jpoehnelt) on his blog + (includes description on how to use `git filter-repo` to migrate from Git LFS + to standard Git). ++ [How I use Jujutsu](https://abhinavsarkar.net/posts/jj-usage/) + by Abhinav Sarkar on their blog. + + [Jujutsu (`jj`)](https://jj-vcs.github.io/jj/) is a Git-compatible version control system, + written in Rust, which was first mentioned in + [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [How GitHub monopoly is destroying the open source ecosystem](https://ploum.net/2026-01-05-unteaching_github.html) + by Lionel Dricot (Ploum). ++ [Moving from GitHub pages to Codeberg pages](https://kotthoff.dev/posts/2026/github-to-codeberg-pages/) + by Florian Kotthoff on his Hugo & PaperMod powered blog. ++ [Showcasing my Git repositories on the web](https://cybrkyd.com/post/showcasing-my-git-repositories-on-the-web/) + (by creating a static site with GitGen, where everything is generated ahead of time) + by cybrkyd. + + Compare [Gitmal](https://github.com/antonmedv/gitmal), a static page generator for Git repositories, + mentioned in the [previous edition](https://git.github.io/rev_news/2025/12/31/edition-130/). ++ [This tool (pgit) turns any Git repo into a private, offline “GitHub” website](https://www.howtogeek.com/this-easy-tool-gives-me-the-best-of-github-on-my-local-machine/) + by Bobby Jack on How-To Geek. ++ [Git Brag: Highlight and Share Your Open Source Contributions](https://blog.tedivm.com/open-source/2026/01/git-brag-highlight-and-share-your-open-source-contributions/) + by Robert Hafner on his tedious ramblings blog. ++ [Your GitHub Contribution Graph Means Absolutely Nothing - And Here’s Why](https://dev.to/sylwia-lask/your-github-contribution-graph-means-absolutely-nothing-and-heres-why-2kjc) + by Sylwia Laskowska on DEV\.to. ++ [Git forge opinions: GitHub, GitLab, Gitea, Sourcehut](https://cadence.moe/blog/2022-07-03-git-forge-opinions-github-gitlab-gitea-sourcehut) + (2022) by Cadence on cadence’s website. + + + +__Git tools and sites__ + ++ [forgeperf.org](https://forgeperf.org/) - Software Forge Performance Index. + Reports generated with [Lighthouse](https://github.com/GoogleChrome/lighthouse), + originally updated weekly, last update February 7, 2024. + Created and maintained by the [SourceHut](https://sourcehut.org/) forge. ++ [Mirror to Codeberg](https://codeberg.org/Recommendations/Mirror_to_Codeberg): + a central place of information about mirroring repos to Codeberg. + Includes some thoughts about why one would want to switch from GitHub or GitLab, + or at least have a second place for your code: a mirror that's contributable, + with links to other articles. ++ [git-natural-api](https://jsr.io/@fiatjaf/git-natural-api) + is a lightweight git HTTP client for fetching repository data without cloning. + It uses /git-upload-pack custom calls to get access to file trees, + commit history or individual objects. + Written in TypeScript, provides a JavaScript/TypeScript API. + Can be used in browser, using Bun, Deno, or Node\.js. + No license provided. ++ [Grasp](https://ngit.dev/grasp/) + (Git Relays Authorized via Signed-Nostr Proofs) + is a distributed, protocol-first approach to hosting Git repos. + You pre-authorize pushes via signed + [Nostr](https://github.com/nostr-protocol/nostr/) events, + then any compliant server can host your repo. + [ngit-relay](https://ngit.dev/relay) is a Grasp reference implementation + that uses a Dockerized stack: nginx, git-http-backend and a Khatru relay. + + Compare [Tangled](https://tangled.org/), + a social-enabled Git collaboration platform built on top of the AT Protocol + (which is behind the [BlueSky](https://bsky.app/) microblogging federated social media service). + First mentioned in [Git Rev News Edition #125](https://git.github.io/rev_news/2025/07/31/edition-125/), + then in [#126](), + and [#128](). + + Compare [Radicle](https://radicle.xyz/), + an open source, peer-to-peer code collaboration stack built on Git, + first mentioned in [Git Rev News Edition #49](), + and many times since; most recently in [#126](). + + There is also [gitstr (`git str`)](https://github.com/fiatjaf/gitstr), + a tool to send and receive Git patches over Nostr, + using [NIP-34](https://github.com/nostr-protocol/nips/pull/997) + (mentioned in [Git Rev News Edition #109](https://git.github.io/rev_news/2024/03/31/edition-109/)). + + Compare [`git-ssb`](https://scuttlebot.io/apis/community/git-ssb.html) + (see the [git-ssb-intro](https://github.com/hackergrrl/git-ssb-intro) guide), + a decentralized Git repo hosting and issue tracking on [Secure-ScuttleButt (SSB)](https://www.scuttlebutt.nz/) + (mentioned in [Git Rev News Edition #26](https://git.github.io/rev_news/2017/04/19/edition-26/) + and [#40](https://git.github.io/rev_news/2018/06/20/edition-40/)). + + Contrast with [ForgeFed](https://forgefed.org/) (formerly GitPub), + a federation protocol for software forges (an [ActivityPub](https://www.w3.org/TR/activitypub/) extension), + mentioned in [Git Rev News Edition #69](https://git.github.io/rev_news/2020/11/27/edition-69/). ++ The [Game of Trees Hub](https://gothub.org/) is a transparently funded + Git repository hosting service. Its infrastructure is based on OpenBSD + and [Game of Trees](https://gameoftrees.org/). + + [Game of Trees (Got)](https://gameoftrees.org/index.html) + is a version control system developed by and for OpenBSD developers, + which wants to remain on-disk compatible with bare Git repositories. + Mentioned in [Git Rev News Edition #54](https://git.github.io/rev_news/2019/08/21/edition-54/). ++ [keifu](https://github.com/trasta298/keifu) (系譜, /keːɸɯ/) is a terminal UI tool + that visualizes Git commit graphs. It shows a colored commit graph, commit details, + and a summary of changed files, and lets you perform basic branch operations. + Written in Rust, under MIT license. ++ [git-com](https://git-com.masukomi.org/) is a TUI tool + for creating structured commit messages that’s easy to configure for each project. + [Written](https://github.com/masukomi/git-com) in Go, under MIT license. ++ [Git Brag](https://gitbrag.tedivm.com/) is an open source web application (or CLI) + that creates a simple report of the contributions you've made to open source projects + on GitHub (it requires logging with GitHub to create the report). + [Written](https://github.com/tedivm/gitbrag) in Python, under MIT license. ++ [GitGen](https://git.cybrkyd.com/GitGen/index.html) + is a lightweight static website generator for local Git repositories written in Python. + It scans a directory of Git repositories and produces a navigable, + self-contained HTML website similar in spirit to cgit or GitWeb, + but without any server-side dependencies. + The generated site includes a repository index, per-repository README rendering, + file listings, commit history, and detailed commit views with diffs. + Under GPLv3 license. + + Compare [Gitmal](https://github.com/antonmedv/gitmal), + a static page generator for Git repositories, + written in Go, under MIT license. + It was mentioned in [Git Rev News Edition #130](https://git.github.io/rev_news/2025/12/31/edition-130/). ++ [pgit](https://github.com/picosh/pgit) is static site generator for git repos. + Demo at . + Written in Go, under MIT license. ++ [GAH!](https://git.sr.ht/~absolutely-vivid/gah) + is your friendly neighborhood good helpful archiver. + It archives GitHub issues and pull requests, + and can create a static site from archives. + Written in Python, under BSD license (Simplified BSD License). ++ [tokendiff](https://github.com/dacharyc/tokendiff) is a Go library and CLI + for token-level diffing with delimiter support. + Tokendiff uses a histogram diff algorithm + that groups semantically related changes together, + producing more readable output than traditional Myers-based approaches + for complex structural changes. + It builds on [diffx](https://github.com/dacharyc/diffx), + a Go implementation of Myers diff. + Under MIT license. ++ [CleanDiff](https://cleandiffapp.com/) is a graphical diffing tool + that shows you what’s changed on a word level, instead of a line level. + It uses the tokendiff library to find semantically relevant changes, + and wraps them in a nice UI and easy Git integration. + [Written](https://github.com/masukomi/cleandiff) in Go and JavaScript, + under MIT license. ++ [patch-hub](https://github.com/kworkflow/patch-hub) + is a terminal-based user interface (TUI) designed to + simplify working with software patches sent through mailing lists + in Linux-related development. It provides an efficient way + to navigate and interact with patches archived on [lore.kernel.org](https://lore.kernel.org/), + specifically for the Linux kernel and adjacent projects. + Written in Rust, under GPL-2.0 license. ++ [Korgalore](https://korgalore.docs.kernel.org/en/latest/index.html) + is a tool for feeding [public-inbox](https://public-inbox.org/README.html) Git repositories, + like [lore.kernel.org](https://lore.kernel.org/), directly into mail targets + (Gmail, JMAP, IMAP, or local maildir) as an alternative to subscribing. + It provides a workaround for Gmail’s notorious hostility + to high-volume technical mailing list traffic. + Written in Python, under GPL-2.0 license. ++ [git-pkgs](https://github.com/git-pkgs/git-pkgs) provides a `git` subcommand + for tracking package dependencies across Git history. + It analyzes your repository to show when dependencies were added, modified, or removed, + who made those changes, and why. + Builds on [bibliothecary](https://github.com/ecosyste-ms/bibliothecary), + the manifest parsing library behind [ecosyste.ms](https://ecosyste.ms/). + Written in Go (originally [in Ruby](https://github.com/git-pkgs/git-pkgs-ruby)), + under MIT license. + + +## Releases + ++ Git [2.53.0-rc2](https://lore.kernel.org/git/xmqqpl6vezt3.fsf@gitster.g/), +[2.53.0-rc1](https://lore.kernel.org/git/xmqq8qdqvqgq.fsf@gitster.g/), +[2.53.0-rc0](https://lore.kernel.org/git/xmqqv7h2bwy6.fsf@gitster.g/) ++ Git for Windows [v2.53.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.53.0-rc2.windows.1), +[v2.53.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.53.0-rc1.windows.1), +[v2.53.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.53.0-rc0.windows.1) ++ GitHub Enterprise [3.19.1](https://docs.github.com/enterprise-server@3.19/admin/release-notes#3.19.1), +[3.18.4](https://docs.github.com/enterprise-server@3.18/admin/release-notes#3.18.4), +[3.17.10](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.10), +[3.16.13](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.13), +[3.15.17](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.17), +[3.14.22](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.22) ++ GitLab [18.8.2, 18.7.2, 18.6.4](https://about.gitlab.com/releases/2026/01/21/patch-release-gitlab-18-8-2-released/), +[18.8.1](https://about.gitlab.com/releases/2026/01/19/gitlab-18-8-1-released/), +[18.8](https://about.gitlab.com/releases/2026/01/15/gitlab-18-8-released/), +[18.7.1, 18.6.3, 18.5.5](https://about.gitlab.com/releases/2026/01/07/patch-release-gitlab-18-7-1-released/) ++ Gerrit Code Review [3.11.8](https://www.gerritcodereview.com/3.11.html#3118), +[3.12.4](https://www.gerritcodereview.com/3.12.html#3124), +[3.13.2](https://www.gerritcodereview.com/3.13.html#3132) ++ GitKraken [11.8.0](https://help.gitkraken.com/gitkraken-desktop/current/) ++ Sourcetree [4.2.16](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.16.html) ++ Garden [2.5.1](https://github.com/garden-rs/garden/releases/tag/v2.5.1), +[2.5.0](https://github.com/garden-rs/garden/releases/tag/v2.5.0) ++ Git Cola [4.17.0](https://github.com/git-cola/git-cola/releases/tag/v4.17.0) ++ GitButler [0.18.7](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.18.7), +[0.18.6](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.18.6) ++ Kinetic Merge [1.14.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.14.0) ++ git-credential-oauth [0.17.2](https://github.com/hickford/git-credential-oauth/releases/tag/v0.17.2), +[0.17.1](https://github.com/hickford/git-credential-oauth/releases/tag/v0.17.1), +[0.17.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.17.0) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Toon Claes. diff --git a/_posts/2026-02-28-edition-132.markdown b/_posts/2026-02-28-edition-132.markdown new file mode 100644 index 000000000..57dee791d --- /dev/null +++ b/_posts/2026-02-28-edition-132.markdown @@ -0,0 +1,502 @@ +--- +title: Git Rev News Edition 132 (February 28th, 2026) +layout: default +date: 2026-02-28 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 132 (February 28th, 2026) + +Welcome to the 132nd 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](https://git.github.io). + +This edition covers what happened during the months of January and February 2026. + +## Discussions + + + + + + +### Support + +* [Slow git pack-refs --all](https://lore.kernel.org/git/CH3PR12MB9026B5872FD42F031970074BC2B3A%40CH3PR12MB9026.namprd12.prod.outlook.com) + + Martin Fick started the discussion by reporting a significant + performance issue where `git pack-refs --all` was taking over five + minutes to complete on a large repository (~3M refs) hosted on an + NFS filesystem. This delay was particularly problematic for Gerrit + servers because Git holds the `packed-refs.lock` for nearly the + entire duration, blocking other reference updates. Martin noted that + JGit was able to perform the same operation in under 20 seconds on + the same repository, suggesting the bottleneck was specific to the + Git implementation. + + The `packed-refs` file is used by Git to store a large number of + references in a single sorted file to avoid the overhead of many + small "loose" reference files. However, updating this file requires + rewriting it entirely, and Git typically verifies that objects exist + and "peels" tags (finding the underlying object a tag points to) + during this process. + + brian m. carlson replied to Martin, suggesting that the slowdown + might be occurring in `should_pack_ref()` because Git needs to + verify that the object at the end of a reference actually + exists. brian also pointed out that NFS was likely a major factor, + as the network latency involved in opening many pack files and + checking loose objects can be substantial. He suggested setting + `receive.unpackLimit` to 1 to reduce the number of loose objects + created in the first place. + + Jeff King (alias Peff) explained that the `packed-refs` file stores + "tag-peeling" information, which requires Git to open each object + for newly written refs via `peel_object()` to read its header and + determine its type. Peff noted that this logic resides in + `write_with_updates()` within `packed-backend.c`. + + Martin conducted further testing using `strace` and `drop_caches` to + eliminate filesystem caching interference. He discovered that while + the actual `write()` calls were fast, there were long gaps—up to + four minutes in total—where the program was not making any system + calls. Martin hypothesized that this "hidden" time was spent by the + kernel handling page faults for `mmap()`ed memory over NFS. + + Patrick Steinhardt concurred that NFS was frequently a source of + such performance issues, mentioning that GitLab had eventually + sunsetted the use of NFS for this reason. Patrick suggested using + `perf(1)` to generate a flame graph to see exactly where the CPU was + spending time. + + Martin provided a summary of a flame graph, which showed about + one-third of the time spent in `_memcmp_sse4_1` and another third in + `unpack_object_header_buffer()`, both accompanied by high page fault + rates. He also noticed significant time spent in a function he + identified as `packed_refs_store_create()`. + + Peff corrected the function name to `packed_ref_store_create()` and + noted that Git might be performing an extra linear pass through the + `packed-refs` file if it lacks certain header tags. He discovered + that JGit-generated files were missing the `sorted` and + `fully-peeled` traits in the header. Without the `sorted` tag, Git + reads the entire file linearly to verify its order before it can + perform binary searches. Peff suggested that JGit should be updated + to write these markers. + + In a final breakthrough, Martin tested adding these tags + manually. He found that while the `sorted` tag did not provide a + major boost, adding the `fully-peeled` tag was the "trigger" that + dropped the execution time from over five minutes to under four + seconds. The absence of the `fully-peeled` tag was forcing Git to + re-peel every reference by looking up the objects in the pack files + over the slow NFS connection. + + Following that discovery, a fix was proposed for JGit in + [Change 1230152](https://eclipse.gerrithub.io/c/eclipse-jgit/jgit/+/1230152). + Adithya Chakilam submitted the patch, titled "pack-refs: Add + sorted/fully-peeled flags," to ensure JGit produces packed-refs + files that Git can process efficiently. + + This resolution not only fixes the immediate performance issue for + Gerrit servers but also ensures that any environment using a mix of + JGit and Git will benefit from reduced lock contention and faster + reference updates. + + + +## Other News + +__Various__ ++ [What’s new in Git 2.53.0?](https://about.gitlab.com/blog/whats-new-in-git-2-53-0/) + by Justin Tobler on GitLab Blog. + The described changes include + fixes for geometric repacking (adding support for promisor remotes), + updates to `git fast-import` commit signature handling options, + and more data being available in `git repo structure` output. ++ [Git 2.53 Released with New Features and Performance Improvements](https://9to5linux.com/git-2-53-released-with-new-features-and-performance-improvements) + by Marcus Nestor on 9to5Linux. ++ [Git 2.53 Released With More Optimizations, One Step Closer To Making Rust Mandatory](https://www.phoronix.com/news/Git-2.53-Released) + by Michael Larabel on Phoronix. ++ Gentoo Linux has kicked off its long transition away from Microsoft's GitHub + to [Codeberg](https://codeberg.org/gentoo/gentoo), an open-source Git-hosting service: + see the [PC Gamer article](https://www.pcgamer.com/software/linux/after-microsoft-couldnt-keep-its-ai-hands-to-itself-a-notoriously-complex-linux-distro-has-started-its-long-march-away-from-github/) + by Joshua Wolens, + and the [Gentoo on Codeberg](https://www.gentoo.org/news/2026/02/16/codeberg.html) + article in Gentoo Linux News. ++ [Vinyl Cache project (formerly Varnish Cache) has left GitHub](https://vinyl-cache.org/organization/moving.html) + for the self hosted [Forgejo](https://forgejo.org/) + instance: ++ [Game of Trees Hub's web interface is live](https://opencollective.com/gothub/updates/web-interface-is-now-enabled-and-we-need-more-subscribers). + + The [Game of Trees Hub](https://gothub.org/) + is a transparently funded Git repository hosting service, + with infrastructure on OpenBSD and the [Game of Trees (GoT)](https://gameoftrees.org/) VCS, + mentioned in the [previous edition](https://git.github.io/rev_news/2026/01/31/edition-131/). ++ [Exploring Solutions to Tackle Low-Quality Contributions on GitHub](https://github.com/orgs/community/discussions/185387) + by Camilla Moraes (@moraesc) on GitHub Community Discussions. ++ [The Former CEO of GitHub [Thomas Dohmke] Just Agreed: Git Wasn't Built for This [AI-based coding]](https://opzero.sh/blog/github-ceo-agrees-git-dead) + by Jeff Cameron on OpZero blog, + following his "interview" with Claude Opus 4.5. + The idea is to version code, intent, constraints, and reasoning together, + and to add a semantic reasoning layer through a "context graph". + Thomas Dohmke [has launched](https://thenewstack.io/thomas-dohmke-interview-entire/) + such an open-source developer platform + for collaboration between developers and AI agents, + [Entire](https://entire.io/). + + On one hand this assumes that AI generated code is a viable path to creating software, + and there would be no technical problems like model collapse, + or economical problems like cost of training and using LLMs. + + On the other hand there exist specialized solutions to help + version data (like [DVC](https://dvc.org) or [Pachyderm](https://www.pachyderm.com/)) + or database schemas. + + +__Light reading__ ++ [Evolving Git for the next decade](https://lwn.net/Articles/1057561/) + by Joe Brockmeier on LWN\.net, reporting about Patrick Steinhardt's (@pks-t) + main track talk at FOSDEM 2026. + The recording of this talk [is available on the FOSDEM site](https://fosdem.org/2026/schedule/event/HTJK33-evolving_git_for_the_next_decade/). ++ [Exploring the .git Directory – How Git Stores Your Code](https://www.git-tower.com/blog/posts/exploring-the-git-directory) + by Bruno Brito on Tower's Blog. ++ [The Ultimate Guide to Git Config: Fine-Tuning Your Git Experience](https://www.git-tower.com/blog/the-ultimate-guide-to-git-config) + by Bruno Brito on Tower's Blog. ++ [TIL that pathnames in git configs can be optional](https://neverready.app/blog/2026/02-git-blame-ignore/) + by Anh Tuan Le on his blog. + It mentions the fact that as of Git 2.52 (Nov 2025), + you can mark config file paths as optional using the `:(optional)` prefix; + see the ['pathname' entry in the "Values" section of the `git config` manpage](https://git-scm.com/docs/git-config#Documentation/git-config.txt-pathname). ++ [Git Reflog Explained: Recover Deleted Commits & Lost Work](https://dev.to/itxshakil/git-reflog-explained-recover-deleted-commits-lost-work-i4n) + by Shakil Alam on DEV\.to. Has a video version. ++ [How to Save Multiple Drafts in Git: A Guide to Using Git Stash](https://www.freecodecamp.org/news/how-to-save-multiple-drafts-in-git-a-guide-to-using-stash/) + by Chidiadi Anyanwu on freeCodeCamp. ++ [Git renames are not renames](https://lornajane.net/posts/2026/git-renames-are-not-renames) + (and where it can cause problems) + by Lorna Jane Mitchell on LornaJane Blog. ++ [The Many Flavors of Ignore Files](https://nesbitt.io/2026/02/12/the-many-flavors-of-ignore-files.html) + by Andrew Nesbitt on his blog. + The post talks about Git's actual semantics for “gitignore syntax”. + + The author wrote [git-pkgs/gitignore](https://github.com/git-pkgs/gitignore), + a Go library that fully matches how Git's gitignore patterns work. ++ [git recent: what branch did I work on?](https://remysharp.com/2026/02/12/git-recent), + about a simple Git alias, by Remy Sharp on his blog. ++ [I Hate GitHub Actions with Passion](https://xlii.space/eng/i-hate-github-actions-with-passion/) + by Przemysław Alexander Kamiński on his xlii.space blog. + + The main problem is with trying to debug [GitHub Actions](https://github.com/features/actions) problems when the action fails; + [Act](https://github.com/nektos/act), a command line tool + to run your GitHub Actions locally using the Docker Engine API, could help there. + Act was first mentioned in [Git Rev News Edition #113](https://git.github.io/rev_news/2024/07/31/edition-113/). + + There is also [WRKFLW](https://github.com/bahdotsh/wrkflw), + a command-line tool for validating and executing GitHub Actions workflows locally, + without requiring a full GitHub environment. + WRKFLW was mentioned in [Git Rev News Edition #126](https://git.github.io/rev_news/2025/08/31/edition-126/). ++ [GitHub Actions: The Hidden Billing Trap](https://theexceptioncatcher.com/2026/02/github-billing/), + on how to avoid unexpected costs with a simple settings adjustment. + Written by Steven Hicks on TheExceptionCatcher. ++ [Git Worktrees with Claude Code, Laravel, and Herd](https://gause.cz/blog/git-worktrees-with-claude-code-laravel-and-herd/) + by Jakub Gause on his blog (also published [on DEV\.to](https://dev.to/gause/git-worktrees-with-claude-code-laravel-and-herd-49d1)). + Describes writing a shell script to help (a [laravel-worktrees Claude skill](https://github.com/gausejakub/claude-skills)). ++ [I Built workz: The Zoxide for Git Worktrees That Finally Fixes .env + node_modules Hell in 2026](https://dev.to/rohansx/i-built-workz-the-zoxide-for-git-worktrees-that-finally-fixes-env-nodemodules-hell-in-2026-2dpj) + by Rohan Sharma on DEV\.to. + Describes his [workz](https://github.com/rohansx/workz) tool + that creates a new worktree, automatically symlinks 22+ types of dependency dirs + (like `node_modules`, `target`, `.venv`), copies env/config patterns, + and can launch your AI coding agent directly in the new worktree. ++ [Agent Identity for Git Commits](https://justin.poehnelt.com/posts/agent-identity-git-commits/) + by Justin Poehnelt on his blog, + about how to set up AI agents to have their commits come from a bot account + without modifying your local Git config. ++ [Your Secrets Aren’t Safe: How the .git Directory Can Leak Data via AI Tools](https://dev.to/yoheiseki/your-secrets-arent-safe-how-the-git-directory-can-leak-data-via-ai-tools-4ioo) + by Yohei Seki on DEV\.to. + The problem is that a malicious MCP server or Skill + can access leaked secrets even if they were removed from the project + (you should treat any committed secret as compromised, and invalidate it; + using `git filter-repo` or BFG RepoCleaner to rewrite history might be a choice). + They can also access authentication information if embedded in `.git/config`. ++ [Git in Postgres](https://nesbitt.io/2026/02/26/git-in-postgres.html) + by Andrew Nesbitt on his blog (following + [Package managers keep using git as a database, it never works out](https://nesbitt.io/2025/12/24/package-managers-keep-using-git-as-a-database.html), + mentioned in [Git Rev News Edition #130](https://git.github.io/rev_news/2025/12/31/edition-130/) from December). + In this post he describes how he created a Git backend using a relational database: + [gitgres](https://github.com/andrew/gitgres) + (implementing the libgit2 `git_odb_backend` and `git_refdb_backend` interfaces + against PostgreSQL through libpq). + He acknowledges that right now gitgres is just a neat hack, + as it currently does not implement delta compression; + nevertheless it might be a good solution for small instances of software forges + for small projects. + + Compare with [git-remote-sqlite](https://github.com/chrislloyd/git-remote-sqlite), + a Git [remote protocol helper](https://git-scm.com/docs/gitremote-helpers) + that helps you store a Git repository in a SQLite database, + mentioned in [Git Rev News Edition #127](https://git.github.io/rev_news/2025/09/30/edition-127/). ++ [The nightmare that is squash merge ft GitHub](https://www.narendravardi.com/the-nightmare-that-is-squash-merge-ft-github/) + by Narendra Vardi on his blog, + about how to fix merge conflicts caused by squash merge using interactive rebase. ++ [How Poor Git Branching Practices Quietly Damage Software Quality](https://akdevcraft.substack.com/p/how-poor-git-branching-practices) + by AK DevCraft on Substack (and also [on DEV\.to](https://dev.to/akdevcraft/how-poor-git-branching-practices-quietly-damage-software-quality-nf7)), + about the Environment-Based Branching antipattern. + + The [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) + by Martin Fowler, mentioned first in [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/), + also talks about this antipattern. ++ [Why [pure] GitOps Doesn't Work at Scale (and What to Do Instead)](https://ctrlplane.dev/blog/why-gitops-doesnt-work-at-scale) + by Justin Brooks (@jsbrooks) at ctrlplane (also [on DEV\.to](https://dev.to/jsbroks/why-gitops-doesnt-work-at-scale-and-what-to-do-instead-2p91)). + He writes why enterprise scale workflows need platform-level orchestration. ++ [GitHub Actions Is Slowly Killing Your Engineering Team](https://www.iankduncan.com/engineering/2026-02-05-github-actions-killing-your-team/) + and [No, Really, Bash Is Not Enough: Why Large-Scale CI Needs an Orchestrator](https://www.iankduncan.com/engineering/2026-02-06-bash-is-not-enough/) + by Ian Duncan on his blog. ++ [My self-hosted Git workflow with GitGen](https://cybrkyd.com/post/my-self-hosted-git-workflow-with-gitgen/) + by cybrkyd; it continues [Showcasing my Git repositories on the web](https://cybrkyd.com/post/showcasing-my-git-repositories-on-the-web/) + from the [previous edition](https://git.github.io/rev_news/2026/01/31/edition-131/). + + [GitGen](https://git.cybrkyd.com/GitGen/index.html) is a lightweight static website generator + for local Git repositories written in Python; + similar tools are [Gitmal](https://github.com/antonmedv/gitmal) + and [pgit](https://github.com/picosh/pgit), both written in Go. ++ [The bare minimum for syncing Git repos](https://alexwlchan.net/2026/bare-git/) + by Alex Chan on her blog. ++ [The Disconnected Git Workflow](https://ploum.net/2026-01-31-offline-git-send-email.html) + by Lionel Dricot (Ploum) + (sidenote: there is also [git-credential-oauth](https://github.com/hickford/git-credential-oauth) + that can solve some of the problems with sending a small one-off patch to a GitHub project). ++ [git.usebox.net and bots](https://www.usebox.net/jjm/blog/git-usebox-net-and-bots/) + by Juan J. Martínez on his Personal Log, + about his modification of [gitweb](https://git-scm.com/docs/gitweb) + to block AI crawlers (that do not respect `robots.txt`). ++ [I Built a Tool That Writes Obituaries for Your Deleted Code](https://dev.to/lakshmisravyavedantham/i-built-a-tool-that-writes-obituaries-for-your-deleted-code-235l) and + [commit-prophet: I Built a Tool That Predicts Buggy Files Using Git History](https://dev.to/lakshmisravyavedantham/commit-prophet-i-built-a-tool-that-predicts-buggy-files-using-git-history-35mk) + by Lakshmi Sravya Vedantham on DEV\.to. ++ [I Read 9,000 Lines of a Stranger's Mergetool](https://dev.to/ticktockbent/i-read-9000-lines-of-a-strangers-mergetool-5bf0) + by Wes on DEV\.to, about the [ec (easy-conflict)](https://github.com/chojs23/ec) tool. + This is the first entry in the [Review Bomb series](https://dev.to/ticktockbent/series/36103), + where Wes finds under-the-radar projects on GitHub, reads the code, contributes something, + and writes it up. ++ [Return to GitHub](https://underlap.org/return-to-github/) + by Glyn Normington on the underlap blog; + the move of [ipc-channel-mux](https://crates.io/crates/ipc-channel-mux) + from [Codeberg](https://codeberg.org/glyn/ipc-channel-mux) to [GitHub](https://github.com/glyn/ipc-channel-mux) + was caused by the need for CI on macOS and Windows + (without having to self-host CI runners). ++ [Simplifying Git by Using GitButler](https://blog.gitbutler.com/simplifying-git): + seeing Git state, branching without fear, understanding and using stacked changes, + better interactive rebase, easier selective staging, recoverability. + Written by PJ Hagerty on GitButler Blog. + [Git Butler](https://www.gitbutler.com/) was first mentioned + in [Git Rev News Edition #46](https://git.github.io/rev_news/2018/12/19/edition-46/). ++ [GitButler CLI Is Really Good](https://matduggan.com/gitbutler-cli-is-really-good/) + by @matdevdug on matduggan\.com. ++ [Introducing jjq, a local merge queue for jj](https://pauladamsmith.com/blog/2026/02/introducing-jjq-a-local-merge-queue-for-jj.html) + by Paul Smith on his blog. + [Jujutsu (`jj`)](https://jj-vcs.dev/) is a Git-compatible + version control system written in Rust, which was first mentioned + in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). + ++ [15+ years later, Microsoft morged my diagram](https://nvie.com/posts/15-years-later/) + by Vincent Driessen, on how Microsoft's Learn portal included + an AI generated diagram with the rough shape of the one in the + [A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/), + but with some GenAI glitches (like the text "Bugfixes from rel, branch may be + **continvoucly** morged back into develop"), and arrows missing + or pointing in the wrong direction, or missing the node. + The image has been replaced since then; + you can see the original compared to the Microsoft one + in the [PC Gamer article about this issue](https://www.pcgamer.com/software/ai/microsoft-uses-plagiarized-ai-slop-flowchart-to-explain-how-github-works-removes-it-after-original-creator-calls-it-out-careless-blatantly-amateuristic-and-lacking-any-ambition-to-put-it-gently/). + + +__Easy watching__ ++ [Evolving Git for the next decade](https://fosdem.org/2026/schedule/event/HTJK33-evolving_git_for_the_next_decade/) + by Patrick Steinhardt [47:46], + a main track talk at FOSDEM (Free and Open source Software Developers' European Meeting), + given on Saturday, 31 January 2026, Brussels. + See also [the summary of this talk](https://lwn.net/Articles/1057561/) + by Joe Brockmeier on LWN\.net (mentioned in the "Light reading" section). ++ [An Efficient Git Workflow For High-Stakes Projects](https://fosdem.org/2026/schedule/event/3VNNBK-efficient-git-for-high-stakes/) + by Vladislav Shpilevoy [45:12], + a main track talk at FOSDEM, on Saturday, 21 January 2026, Brussels. + The example project this workflow was used in is [tarantool](https://github.com/tarantool/tarantool/). ++ [Pull requests maintainers will love to review](https://fosdem.org/2026/schedule/event/L7ERNP-prs-maintainers-will-love/) + by Alya Abbott, + a main track talk at FOSDEM, on Saturday, 21 January 2026, Brussels. + [Slides](https://docs.google.com/presentation/d/1rpq4OsOTpt8nQx_QzBuMzICCenUpeyCzsk4sc-gVpyA/edit?slide=id.g32d6911bc12_0_0#slide=id.g32d6911bc12_0_0) available as Google Slides. ++ [Mercurial, 20 years and counting: how are we still alive and kicking?](https://fosdem.org/2026/schedule/event/AGWUVH-mercurial-aint-you-dead-yet/) + by Raphaël Gomès and Pierre-Yves David [50:02], + a main track talk at FOSDEM, on Saturday, 21 January 2026, Brussels. ++ [Lost Your Commits? Git Reflog Saves You](https://www.youtube.com/watch?v=NN-8kP7nClA) + by Shakil Alam on the Shakil Tech channel on YouTube [5:55]. ++ [Configure your Git](https://www.youtube.com/watch?v=G3NJzFX6XhY) + by Denis Gruzdev aka @codingjerk + on the codingjerk channel on YouTube [14:02]: + a brief review on their personal git config / setup, + showing some of the most used commands, settings, and aliases. + + +__Git tools and sites__ ++ [mise-en-place](https://github.com/jdx/mise) or `mise`, a CLI tool that is + the front-end to your dev env + (managing dev tools like node, python, cmake, terraform, etc; and + managing tasks used to build and test projects), + [introduced monorepo tasks](https://github.com/jdx/mise/discussions/6564), + allowing you to manage tasks across multiple projects in a single repository, + with each project maintaining its own tools, environment variables, and tasks. + + A monorepo is a software-development strategy + in which the code for a number of projects is stored in the same repository. + See for example the [monorepo.tools](https://monorepo.tools/) site, + first mentioned in [Git Rev News Edition #84](https://git.github.io/rev_news/2022/02/28/edition-84/). ++ [difi](https://github.com/oug-t/difi) is a TUI tool that helps you + review and refine Git diffs before you push. + Written in Go using the [Bubble Tea](https://github.com/charmbracelet/bubbletea) library, + under MIT license. ++ [deff](https://github.com/flamestro/deff) is a TUI tool providing + interactive, side-by-side file review for Git diffs + with per-file navigation, vertical and horizontal scrolling, + syntax highlighting, and added/deleted line tinting. + Written in Rust, under MIT license. ++ [ec (easy-conflict)](https://github.com/chojs23/ec) is a terminal Git mergetool + with a 3-way TUI and Neovim integration. + Written in Go, under MIT license. ++ [Maiao](https://github.com/adevinta/maiao): Gerrit-style code review workflow for GitHub. + Maiao brings the power of stacked pull requests to GitHub, + enabling you to break large features into small, reviewable commits + where each commit becomes its own PR. Provides a `git review` command. + Written in Go, under MIT license. + + Stacked Pull Requests, also under the name Stacked Diffs, + were mentioned in [Git Rev News Edition #44](https://git.github.io/rev_news/2018/10/24/edition-44/), + [#105](https://git.github.io/rev_news/2023/11/30/edition-105/), + [#111](https://git.github.io/rev_news/2024/05/31/edition-111/) + (with links to other editions with other articles, and to related tools), + [#115](https://git.github.io/rev_news/2024/09/30/edition-115/). + [#118](https://git.github.io/rev_news/2024/12/31/edition-118/), + [#127](https://git.github.io/rev_news/2025/09/30/edition-127/), + and [#128](https://git.github.io/rev_news/2025/10/31/edition-128/). + + Compare with [`av`](https://github.com/aviator-co/av), + a command-line tool that helps you manage your stacked PRs on GitHub. + It was mentioned in [Git Rev News Edition #115](https://git.github.io/rev_news/2024/09/30/edition-115/). + + [GitButler](https://docs.gitbutler.com/), a Source Code Management system + designed to manage your branches, + [also supports stacked branches](https://blog.gitbutler.com/stacked-branches-with-gitbutler), + which was mentioned in [Git Rev News Edition #118](https://git.github.io/rev_news/2024/12/31/edition-118/). ++ [Diffs](https://diffs.com/), aka [`@pierre/diffs`](https://github.com/pierrecomputer/pierre/tree/main/packages/diffs), + is an open source diff and file rendering library built on + the [Shiki](https://shiki.style/) syntax highlighter. + It supports split (side-by-side) or stacked (unified diff) layout, + different diff highlight styles, in-line highlighting, wrapping, and line numbers. + Includes an annotation framework for injecting comments and annotations, and more. + Written in TypeScript, under Apache 2.0 license. + Intended for use in web applications. + Diffs is in early active development—APIs are subject to change. + + Compare with [diff2html](https://diff2html.xyz/) ([repo on GitHub](https://github.com/rtfpessoa/diff2html)), + a pretty diff to HTML JavaScript library: + diff parser and pretty HTML generator. + Written in TypeScript, under MIT license. + Provides [diff2html-cli](https://github.com/rtfpessoa/diff2html-cli), + [used by](https://diff2html.xyz/#users), among others, + [Ungit](https://github.com/FredrikNoren/ungit), + [Diffy](https://diffy.org/), [git-explorer](https://github.com/thescientist13/git-explorer), + [Simple Git](https://github.com/mauricioszabo/simple-git), + [git-tabular-diff](https://github.com/jstritch/git-tabular-diff). + diff2html was first mentioned in [Git Rev News Edition #98](https://git.github.io/rev_news/2023/04/30/edition-98/), + and diff2html-cli in [Git Rev News Edition #14](https://git.github.io/rev_news/2016/04/20/edition-14/). ++ [Gitnuro](https://gitnuro.com/) is a multiplatform Git client, + based on JetBrains Compose and JGit. + [Written](https://github.com/JetpackDuba/Gitnuro) in Kotlin, under GPL 3.0 license. ++ [RelaGit](https://rela.dev/) - the elegant solution to graphical version control, + is a multiplatform Git GUI written in TypeScript. Under LGPL 3.0 license. + RelaGit is in early beta stage. ++ [SourceGit](https://github.com/sourcegit-scm/sourcegit) is an open-source Git GUI client + that supports Windows, macOS, and Linux. + Includes built-in [conventional commit](https://www.conventionalcommits.org/) message helper, + and support for using AI to generate commit messages. + Written in C#, using the [Avalonia](https://avaloniaui.net) cross-platform UI framework, + under MIT license. ++ [git-toolbelt](https://github.com/nvie/git-toolbelt) is a suite of useful Git commands + that aid with scripting or every day command line usage. + Written in shell, under BSD-3-Clause license. + + See [Git power tools for daily use](https://nvie.com/posts/git-power-tools/) + by Vincent Driessen, the author of git-flow (2018). ++ [sqldef](https://sqldef.github.io/) is a [CLI tool](https://github.com/sqldef/sqldef) for diffing two SQL schemas. + You can use it to manage the migration of RDBMSs using regular SQL DDLs. + Supported databases: MySQL, MariaDB, TiDB, PostgreSQL, SQL Server, and SQLite3. + Written in Go, under MIT license + (for everything except parser, which is under Apache 2.0 license). + Compare with: + + [sqldiff.exe](https://www.sqlite.org/sqldiff.html), + a command-line utility program (Windows binary) + that displays content differences between two SQLite databases, + mentioned in [Git Rev News Edition #87](https://git.github.io/rev_news/2022/05/26/edition-87/). + + [pg-diff](https://michaelsogos.github.io/pg-diff/), + a PostgreSQL schema and data comparing tool written in JavaScript, + mentioned in [Git Rev News Edition #108](https://git.github.io/rev_news/2024/02/29/edition-108/). + + [git-sqlite](https://github.com/cannadayr/git-sqlite), + a custom diff and merge driver for SQLite, + mentioned in [Git Rev News Edition #127](https://git.github.io/rev_news/2025/09/30/edition-127/). ++ [Fresh File Explorer](https://github.com/FreHu/vscode-fresh-file-explorer) + is a VS Code file explorer which shows only recently modified files + based on a combination of Git history and your pending changes. + Written in TypeScript, under MIT license. + + See also [Fresh File Explorer - vscode extension for navigating recent changes](https://dev.to/frehu/fresh-file-explorer-vscode-extension-for-navigating-recent-changes-13c1) + by Frederik Hudák on DEV\.to. ++ [Git Remote Color](https://github.com/jpoehnelt/vscode-git-remote-color) + is a VS Code extension that automatically colors your VS Code workspace + based on the git remote URL: every repository gets its own unique, consistent color. + Inspired by the [Peacock](https://marketplace.visualstudio.com/items?itemName=johnpapa.vscode-peacock) extension, but fully automatic using a deterministic hash of the git remote. + + See also [VS Code Git Remote Color](https://justin.poehnelt.com/posts/vscode-git-remote-color/) + by Justin Poehnelt on his blog. ++ [commit-prophet](https://github.com/LakshmiSravyaVedantham/commit-prophet) + is a command line tool that predicts which files are more likely to have bugs + using Git history patterns and co-change analysis. + Written in Python, under MIT license. ++ [Majutsu](https://github.com/0WD0/majutsu) provides a [Magit](https://magit.vc/)-style + interface for [Jujutsu (`jj`)](https://www.jj-vcs.dev/), + offering an efficient way to interact with JJ repositories from within Emacs. + Primary project license is GNU GPL v3 or later, + but it was previously distributed under MIT license terms. ++ [The Missing GitHub Status Page](https://mrshu.github.io/github-statuses/) + is a third-party service that tracks 90 days uptime; + created because GitHub stopped updating its [GitHub Status](https://www.githubstatus.com/) page + with aggregate uptime numbers. + + +## Releases + ++ Git [2.53.0](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/) ++ Git for Windows [v2.53.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.53.0.windows.1) ++ GitLab [18.9.1, 18.8.5, 18.7.5](https://about.gitlab.com/releases/2026/02/25/patch-release-gitlab-18-9-1-released/), +[18.9](https://about.gitlab.com/releases/2026/02/19/gitlab-18-9-released/), +[18.8.4, 18.7.4, 18.6.6](https://about.gitlab.com/releases/2026/02/10/patch-release-gitlab-18-8-4-released/), +[18.6.2, 18.7.1, 18.8.1](https://about.gitlab.com/releases/2026/02/06/patch-release-gitlab-ai-gateway-18-8-1-released/), +[18.8.3, 18.7.3, 18.6.5](https://about.gitlab.com/releases/2026/02/04/gitlab-18-8-3-released/) ++ Gerrit Code Review [3.11.9](https://www.gerritcodereview.com/3.11.html#3119), +[3.12.5](https://www.gerritcodereview.com/3.12.html#3125), +[3.13.3](https://www.gerritcodereview.com/3.13.html#3133), +[3.13.4](https://www.gerritcodereview.com/3.13.html#3134) ++ GitHub Enterprise [3.20.0](https://docs.github.com/enterprise-server@3.20/admin/release-notes#3.20.0), +[3.19.2](https://docs.github.com/enterprise-server@3.19/admin/release-notes#3.19.2), +[3.18.5](https://docs.github.com/enterprise-server@3.18/admin/release-notes#3.18.5), +[3.17.11](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.11), +[3.16.14](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.14), +[3.15.18](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.18), +[3.14.23](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.23) ++ GitKraken [11.9.0](https://help.gitkraken.com/gitkraken-desktop/current/) ++ GitHub Desktop [3.5.5](https://desktop.github.com/release-notes/) ++ Sourcetree [4.2.17](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.17.html) ++ Git Cola [4.17.1](https://github.com/git-cola/git-cola/releases/tag/v4.17.1) ++ GitButler [0.19.3](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.19.3), +[0.19.2](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.19.2) ++ Sublime Merge [Build 2123](https://www.sublimemerge.com/download) +- Tower for Mac [15.1](https://www.git-tower.com/release-notes/mac?show_tab=release-notes) +- Tower for Windows [11](https://www.git-tower.com/blog/tower-windows-11) +- git-flow-next [1.0](https://git-flow.sh/changelog/) + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from Bruno Brito, Michael Ryzhikov and Shreyansh Paliwal. diff --git a/_posts/2026-03-31-edition-133.markdown b/_posts/2026-03-31-edition-133.markdown new file mode 100644 index 000000000..dd89ecff3 --- /dev/null +++ b/_posts/2026-03-31-edition-133.markdown @@ -0,0 +1,827 @@ +--- +title: Git Rev News Edition 133 (March 31st, 2026) +layout: default +date: 2026-03-31 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 133 (March 31st, 2026) + +Welcome to the 133rd 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](https://git.github.io). + +This edition covers what happened during the months of February and March 2026. + +## Discussions + + + + + +### Support + ++ [git-am applies commit message diffs](https://lore.kernel.org/git/bcqvh7ahjjgzpgxwnr4kh3hfkksfruf54refyry3ha7qk7dldf@fij5calmscvm) + + On February 6, 2026, Matthias Beyer forwarded to the Git mailing list a + surprising warning that had just circulated on Mastodon: + + > PSA: Did you know that it's **unsafe** to put code diffs into your + > commit messages? + > + > Such diffs will be applied by patch(1) (also git-am(1)) as part of + > the code change! + > + > This is how a sleep(1) made it into i3 4.25-2 in Debian unstable. + + The incident had originated in the i3 window manager project, where a + commit message contained an unindented diff for illustration purposes. + When Debian packagers later applied the patch using `patch`, the diff + in the commit message was applied as actual code, sneaking a spurious + `sleep` call into the Debian unstable package. Matthias asked the + list whether this was a known issue and whether it could be an attack + vector. + + To understand why this happens, it helps to know how `git am` parses + its input. When processing a patch email, it must split the stream into + two parts: the commit message and the actual patch to apply. It does + this by treating the first occurrence of any of the following lines as + the boundary between the two: + + - a line consisting of only three dashes (`---`), + - a line beginning with `diff -`, or + - a line beginning with `Index: `. + + Everything before that boundary becomes the commit message; everything + after is fed to the patch application machinery. Crucially, `git am` + scans from the top of the email, so the very first such line it + encounters terminates the commit message regardless of whether that + line was meant to be part of the message text. + + This design dates back to the tool's origins. As Jeff King (also known + as "Peff") quickly explained in reply to Matthias, `git am` was + originally designed to handle patches sent by all kinds of people, not + just Git users. A contributor might have generated a diff with plain + GNU `diff` and typed the rest of the email by hand, without any `---` + separator. The tool was therefore intentionally permissive: it would + find a `diff -` line anywhere in the email and treat it as the start + of the patch. Peff demonstrated this with a live example. He fed + `git am` a hand-typed email containing a GNU diff, and it produced the + expected commit. + + This historical context also explained why `git am` is notoriously + hard to fix: "I don't think there is a way to unambiguously parse the + single-stream output that format-patch produces," Peff wrote, noting + that he could find at least three earlier discussions of the same + problem (in 2015, 2022, and 2024). The stream is simply ambiguous by + design. Even the `---` marker itself cannot be used to robustly split + things, since `---` on a line by itself is a valid diff hunk line + indicating that the string `--` was removed from a file. + + Matthias proposed parsing from the end of the email rather than from + the top. Peff replied that this would still be ambiguous for the same + reasons, and would introduce new corner cases. + + Jacob Keller noted early on that the issue was certainly surprising but + that he was unsure it constituted a security attack vector, since + someone should be reading the commit message before applying. But + Matthias pushed back: the whole point was that nobody realized the + behavior was there. He called it "sheer luck" that it was only a + `sleep` and not something more malicious crafted as a diff in the + commit message. + + Florian Weimer wondered whether the `git format-patch` output was + really ambiguous, given that the patch section is normally preceded by + a diffstat block. Peff replied that the diffstat is optional and is not + even parsed by the receiving side at all. + + Jakob Haufe added an important nuance: even if `git am` was fixed to + require indented diffs, it would only partially mitigate the problem, + because `patch` (which many distributions use to apply upstream + fixes to packages) is even more permissive. It will strip a consistent + level of indentation from diffs before applying them. He quoted the + patch(1) manual page: "If the entire diff is indented by a + consistent amount, [...] this is taken into account." The i3 incident + had in fact been triggered by `patch`, not `git am`. + + Kristoffer Haugsbakk synthesized this into a clear summary of the + situation and immediately proposed documenting it. + + Matthias also highlighted the broader applicability beyond email + workflows: Linux distributions like NixOS routinely fetch patches + directly from upstream Git repositories and apply them to packages + using `patch`. He noted that even after 15 years of using Git and + being comfortable with email patch workflows, he himself had not known + about this behavior. + + Several directions were then explored to look for solutions. + + Peff observed the irony that `git format-patch` does have an `--attach` + option which puts the message and the patch in separate MIME parts — + making them unambiguous in principle. However, `git mailinfo` (which + powers `git am` under the hood) decodes both parts into a single + stream and still treats a `diff` line in the message part as the start + of a patch. Fixing this would require careful surgery to avoid + breaking the existing forgiving handling of patches received as a + single attachment. + + Patrick Steinhardt suggested that even if parsing cannot be made + unambiguous, `git am` could at least detect the ambiguity and bail by + default with an `--accept-ambiguous-patch` override. Jacob Keller + proposed going further: a new "unambiguous mode" where + `git format-patch` would produce output that new versions of `git am` + could distinguish unambiguously, while old versions would still handle + the common case the same way as before. + + Jacob had also sketched a concrete scheme: add a new unambiguous + marker after the `---` separator, so that old versions of `git am` + would still cut at the `---` and ignore everything up to the diff, while + new versions would wait for the new marker and correctly ignore any + diff appearing before it. Since the new marker would come after `---`, + it would not be inserted into the commit message when applied. + + Peff replied that this was trickier than it sounded: the new marker + would have to be something that could never appear legitimately in a + commit message, and both sides would need to complain if they saw + multiple markers. He explored further options: reversible quoting of + `---` and `diff` lines in the commit message (analogous to the `>From` + quoting used in mbox files), applied only when the message would + otherwise be ambiguous. This way, if an older `git am` received the + mail, the worst case would be visible quoting in the commit message — + ugly but readable. Junio Hamano, the Git maintainer, added another + thought: refusing to accept unsigned patches at all. + + Peff also proposed a simpler receiver-side improvement: a + `git am --strict` mode that would always require a `---` separator + before the diff, on the assumption that well-formatted patches from Git + always have one. This would not help with diffs that legitimately + appear before the `---`, but would eliminate the most common accidental + cases. + + None of these ideas led to an immediate implementation, as they all + involve backward compatibility tradeoffs that would need careful + thought. + + On February 8, Kristoffer sent a documentation patch titled "doc: add + caveat about round-tripping format-patch" which introduced a new + `Documentation/format-patch-caveats.adoc` file explaining the + behavior. The caveat was designed to be included in the documentation + for git-am(1), git-format-patch(1), and git-send-email(1). + + Junio reviewed + [version 1](https://lore.kernel.org/git/format-patch_caveats.281@msgid.xyz) + and offered a correction to the wording: rather than saying that an + unindented diff in the commit message "will not only cut the message + short but cause that very diff to be applied, along with the patch in + the patch section," Junio noted that the outcome is not so + deterministic. The diff in the commit message might get applied, or + the patch machinery might trip on something and fail outright. He also + flagged that the space after the `---` in the cover letter was + inconsistent with the project's conventions. + + Phillip Wood reviewed the patch and found the mention of + git-send-email(1) a bit distracting, since that command merely runs + git-format-patch(1) and does not do any formatting itself. He also + suggested wording improvements: replacing "One might want to use [...] + patch(1)" with "Given these limitations, one might be tempted to [...]". + + Kristoffer incorporated all of this in + [version 2](https://lore.kernel.org/git/V2_format-patch_caveats.34b@msgid.xyz), + which dropped the git-send-email(1) mention from the introductory + paragraph (while keeping the CAVEATS section in its documentation, for + users who encounter it there), removed example code blocks in favor of + clearer prose, and used the list of message-terminating patterns + already present in git-am(1)'s documentation. Junio reviewed it and + queued it with the comment "Nicely written." + + A third version, + [version 3](https://lore.kernel.org/git/V3_format-patch_caveats.354@msgid.xyz), + was submitted and received Junio's approval to go to `next`. + + Meanwhile, Phillip had observed that since the parsing cannot be fixed, + "perhaps we should update our sample `commit-msg` hook to reject + messages that will cause problems." On February 7, he sent a 3-patch + series titled "commit-msg.sample: reject messages that would confuse + `git am`". The series: + + 1. Added a `.gitattributes` rule for sample hooks (which are shell + scripts but have `.sample` extensions). + 2. Extended the sample `commit-msg` hook to scan the body of the commit + message for unindented `diff -` and `Index: ` lines and reject the + commit with a helpful error message. + 3. Added a further check to detect `---` separator lines in the message + body, which would cause `git am` to silently truncate the commit + message. + + Peff reacted with measured skepticism to patch 3 in + [version 1](https://lore.kernel.org/git/cover.1770476279.git.phillip.wood@dunelm.org.uk): + he and Junio both pointed out that they themselves sometimes use `---` + intentionally in commit messages to add notes that will appear in the + formatted patch email but not end up in the final commit message when + applied. Junio explained the trick: "when I know what I want to write + below the three-dash lines, I would commit with `---` and additional + notes below it, so that I do not forget during format-patch. When the + commit is turned into a patch email [...] `am` cuts at the first one, + and `apply` knows that the garbage lines at front, including + three-dash lines, do not matter until it sees `^diff`, this works out + perfectly well." + + Peff confirmed he used the same trick. Phillip, acknowledging that at + least three developers relied on this behavior, decided to drop patch 3 + entirely, reducing the series from three patches to two in + [version 2](https://lore.kernel.org/git/cover.1770993281.git.phillip.wood@dunelm.org.uk). + He also refined the diff detection in the body: the v2 correctly skips + the first paragraph of the message (which becomes the email Subject + header and so does not go through the patch boundary detection), skips + lines below a scissors line, and handles the `core.commentChar` and + `core.commentString` configuration options for determining which lines + are comments. Junio reviewed version 2 with detailed questions about + the scissors-line logic. + + Kristoffer verified that version 2 worked with `git commit + --cleanup=scissors --verbose` and was satisfied. + + The discussion did not lead to a fundamental fix to the ambiguous + parsing in `git am`, which remains an open problem with no obvious + backward-compatible solution. But it produced two concrete + improvements that were accepted and are now in `master`: a CAVEATS + section in the documentation for git-am(1), git-format-patch(1), and + git-send-email(1) spelling out exactly how commit messages can + inadvertently interfere with patch application, and an enhanced sample + `commit-msg` hook that rejects messages containing unindented diffs. + + The thread also served as a useful reminder that this problem is not + limited to email workflows: any project that generates patches from + Git commits using `git format-patch` and applies them with `patch` + or `git am` is exposed to it. The practical advice for authors is + simple: if you include diffs in commit messages for illustrative + purposes, make sure to indent them consistently, and be aware that + even that does not protect you from `patch`. + +## Developer Spotlight: Olamide Caleb Bello + +_Editor’s note: This edition features a retrospective interview with a +contributor who contributed to Git through a mentoring program. +We hope the reflections shared by the Outreachy contributor will +provide an insightful perspective that benefits the community. +As always, we welcome your thoughts and feedback!_ + +* **Who are you and what do you do?** + + I’m Olamide Caleb Bello, a software engineer based in Nigeria. I studied + Economics, but I’ve always been curious about technology and how + systems work behind the scenes. That curiosity led me to start teaching + myself web development, and over time I found myself drawn more + towards backend and systems-oriented work. + + I became especially interested in understanding how complex tools are + built and maintained, which led me to open source. I contributed to Git + as part of the Outreachy program, where I got to work on improving parts + of Git’s internal workflows. + + These days, I enjoy working on tools that make development smoother + for others, and I’m particularly interested in open source and + distributed systems. + +* **How did you initially become interested in contributing to Git, + and what motivated you to choose it as your Outreachy project?** + + I initially saw Git as just a tool I needed to get my work done. For a + long time, my workflow was basically just `git add`, `git commit`, `git push`, + and `git pull`, without thinking much about what was happening underneath. + That started to change when I ran into some particularly messy merge conflicts + that forced me to slow down and really question how Git was managing + history and combining changes. + + Around the same time, I was becoming more interested in systems in + general, thinking about tools like the kernel, systemd, and Git + itself, and how they work under the hood. That experience pushed me to + look deeper into Git’s internals, and I quickly realized how much + depth there was beneath the surface. + + When I came across the Outreachy project, choosing Git felt natural, I + wanted to challenge myself and contribute to a tool I had used for + years but didn’t fully understand, while learning from experienced + maintainers. + +* **How do you feel your contribution has impacted the Git community + or the broader open source ecosystem?** + + [My work](https://cloobtech.hashnode.dev/beginning-my-outreachy-opensource-internship-at-git-overview-and-project-description) + focused on reducing Git’s reliance on global state by refactoring + repository-specific variables into a more localized structure. Each repository + instance now manages its own configuration independently, improving modularity + and reducing the risk of cross-repository issues. + + Through this work, I came to appreciate how changes at this level contribute to + Git’s long-term direction, particularly efforts to make it more reusable as a + library. Even though these changes aren’t directly visible to users, they make + the system safer and easier to extend. + + Being part of that process gave me a deeper respect for the level of thought + and the care that goes into maintaining Git. + +* **Is there any aspect of Git that you now see differently after + having contributed to it?** + + Before contributing, I thought Git was just a bunch of commands I + typed every day. Working on it showed me a whole hidden world, + how configurations are saved and read, how each repository handles + its own settings, and what the index is really doing behind the scenes. + Some of it was so intricate I almost felt like Git was trolling me! + + Seeing all this up close turned what felt like a simple tool into a + carefully designed system, and it gave me a much deeper appreciation + for the thought and care behind every command. + +* **How do you balance your contributions with other responsibilities + like work or school?** + + At the moment, I’m not tied to a full-time job or school, but I spend a lot + of time learning new tech and doing freelance work. I usually dedicate small, + focused sessions to Git contributions, sometimes just an hour here or there, + and it’s surprising how much progress you can make that way. This rhythm lets + me keep learning, experimenting, and contributing without feeling overwhelmed. + +* **Can you share how Outreachy helped enhance your technical and + non-technical skills (like communication, project management, + etc.)?** + + Outreachy was a huge growth opportunity for me, both technically and personally. + On the technical side, I deepened my understanding of Git internals, learned to + work effectively in a large C codebase, and tackled complex refactoring of core + systems. On the non-technical side, I honed my communication skills by engaging + actively on the Git mailing list, responding to feedback, and documenting my + work clearly for others. The experience also helped me improve project + discipline, learning how to plan and iterate on tasks in a structured way. + +* **What was your biggest takeaway or learning from Outreachy that + you now apply regularly in your work?** + + My biggest takeaway from Outreachy was learning how even small, careful changes + can have a big impact in a large system like Git. During Outreachy, for even + the tiniest change, I had to run over 32,000 test cases just to be + sure it wouldn’t break anything! I approach my work by breaking tasks into + smaller steps, testing thoroughly, and thinking through the consequences + before making changes. This mindset has become a regular part of how I work, + whether I’m contributing to open source or building my own projects. + +* **What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it?** + + The toughest part of contributing to Git was navigating its huge and complex + C codebase. I had to wrap my head around global variables, repository-specific + state, and how configs were stored and read. At first, it felt overwhelming, + and I constantly worried that even a small change might break something. + + I overcame this by tackling one piece at a time, reading the code carefully, + testing thoroughly, and admittedly, disturbing my mentors quite a bit! 😂 I’m + especially grateful to Christian Couder and Usman Akinyemi, who guided me + patiently. Christian taught me how to ask questions properly, showed me how to + debug effectively, and always encouraged me to think through problems step by + step. Usman was equally supportive, often checking in and joining coding + sessions with me. Both helped me understand Git’s internal architecture and + gave me the confidence to contribute safely and effectively. + +* **Have you thought about mentoring new GSoC / Outreachy students?** + + Yes, I have thought about mentoring future GSoC or Outreachy students. Since I’m + still relatively new to open source myself, I want to focus on contributing and + learning for now. However, I do hope to co-mentor in the next Outreachy program, + sharing what I’ve learned and helping others navigate the experience. + +* **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?** + + If I had a team of expert developers working full time on Git for a year, I + would focus on further improving its modularity and internal architecture. + My goal would be to make Git easier to embed and reuse as a library, reducing + reliance on global state and improving the safety of multi-repository + operations. + + This would not only make Git more maintainable for contributors but also open + up new possibilities for other projects to integrate Git functionality + more easily. + +* **If you could remove something from Git without worrying about + backwards compatibility, what would it be?** + + If I could remove anything from Git without worrying about backwards + compatibility, I’d simplify some of the legacy parts of its internal state. + These older structures can be confusing and tricky to work with, and removing + them would make Git’s internals cleaner and easier to reason about. + +* **What upcoming features or changes in Git are you particularly + excited about?** + + I’m particularly excited about Git’s ongoing libification efforts, which make + it easier for other projects to embed and reuse Git functionality. Changes that + reduce global state and improve repository isolation also excite me, because + they make multi-repository operations safer and Git’s internals easier to work + with. I’m curious to see how these improvements will open up new possibilities + for both contributors and external tools that rely on Git. + +* **What is your favorite Git-related tool/library, outside of Git + itself?** + + I’d say my favorite Git-related tool is `gitingest`. It’s really handy for + exploring repositories programmatically and testing workflows. I’ve found it + especially useful while learning Git internals. + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I mainly use `git send-email` to submit patches, read threads on + [lore.kernel.org/git](https://lore.kernel.org/git), and reply via + Gmail. This setup helps me follow discussions and iterate on my + contributions smoothly. + +* **How do you envision your own involvement with Git or other open + source projects in the future?** + + I’m here to stay in open source. I want to keep contributing to Git and other + projects, learning as I go, taking on bigger challenges, and helping new + contributors find their footing. Open source has become a big part of how I + grow as a developer, and I hope to keep giving back for years to come. + +* **What is your advice for people who want to start Git development? + Where and how should they start?** + + My advice for anyone starting Git development is to begin small and be curious. + A great resource I found helpful is the [MyFirstContribution](https://git-scm.com/docs/MyFirstContribution) + document. Start by reading the guides, experimenting locally, and submitting + small patches. Interacting with the mailing list, asking questions, and iterating + on feedback will help you learn and grow as a contributor. + +* **Would you recommend other students or contributors to participate + in the GSoC, Outreachy or other mentoring programs, working on + Git? Why? Do you have advice for them?** + + Absolutely, I would recommend programs like GSoC or Outreachy for anyone + interested in Git or open source. These programs provide structured mentorship, + exposure to real-world projects, and the chance to learn directly from + experienced developers. My advice is to start small, be curious, ask questions, + and don’t be afraid to iterate on feedback. Every contribution, no matter how + minor it may seem, is a valuable learning experience. + + +## Other News + +__Various__ ++ [The forge is our new home.](https://communityblog.fedoraproject.org/the-forge-is-our-new-home/) + by Tomáš Hrčka on Fedora Community Blog.
+ After a full year of preparation, the Community Linux Engineering (CLE) team + announced that [Fedora Forge](https://forge.fedoraproject.org/explore/organizations), + powered by [Forgejo](https://forgejo.org/), is ready for use. + If you own a project at [pagure.io](https://pagure.io/), + you must migrate out of it before June 2026; the + [How to Migrate Repository from Pagure](https://docs.fedoraproject.org/en-US/forge-documentation/migration/pagure_repository/) + guide is there to help with this task. + Note that Fedora Forge is narrower in scope than pagure\.io; + it is provisioned to host the code, documentation, and tooling + that directly build, manage, and govern the Fedora Project. + Personal projects and general upstream development do not belong on Fedora Forge. ++ [GNOME GitLab Redirecting Some Git Traffic To GitHub For Reducing Costs](https://www.phoronix.com/news/GNOME-GitHub-GitLab-Redirect) + by Michael Larabel in GNOME on Phoronix. ++ [Radicle: Disclosure of Replay Attack Vulnerability in Signed References](https://radicle.xyz/2026/03/30/disclosure-of-vulnerability-in-signed-references) + + [Radicle](https://radicle.xyz) is a peer-to-peer, local-first + code collaboration stack built on Git. + It was first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/) + and most recently in [edition #131](https://git.github.io/rev_news/2026/01/31/edition-131/).
+ Compare with [Tangled](https://tangled.org/) (built on top of AT Protocol), + [Grasp](https://ngit.dev/grasp/) and [`git str`](https://github.com/fiatjaf/gitstr) (built on top of Nostr). ++ [b4's Review TUI With AI Integration Nearing Pre-Alpha Release](https://www.phoronix.com/news/b4-review-nears-pre-alpha) + by Michael Larabel in the Linux Kernel section on Phoronix. + +__Light reading__ ++ [The Comforting Lie Of SHA Pinning](https://www.vaines.org/posts/2026-03-24-the-comforting-lie-of-sha-pinning/) + by Aiden Vaines on Vaines\.org. + The recommendation to _pin your dependencies_ in GitHub Actions + translates to using commit SHAs, not tags - which can be moved + (though GitHub already has optional ‘Make tags immutable’ feature). + However, GitHub Actions does not meaningfully validate that + the commit SHA you reference belongs to the repository you think it does: + it can belong to a hostile fork. ++ [Git Remote Helpers](https://nesbitt.io/2026/03/18/git-remote-helpers.html): + how to create `git-remote-swh` that would let you `git clone` from a [SWHID](https://www.swhid.org/), + pulling source code directly from [Software Heritage](https://www.softwareheritage.org/)’s archive + by content hash rather than by URL. + Written by Andrew Nesbitt on his blog. + Also lists built-in remote helpers, and lists third-party helpers: + for cloud and object storage, for content-addressed storage, + for encryption, for VCS bridges, + for P2P and decentralised (though this list was missing `git-remote-rad` for Radicle), + for a different transport layer, for blockchain, for other storage backends. ++ [Git Bayesect](https://hauntsaninja.github.io/git_bayesect.html) + by Shantanu Jain (@hauntsaninja) on his blog. + It describes the idea behind [git bayesect](https://github.com/hauntsaninja/git_bayesect), + which is a generalisation of `git bisect` that uses Bayesian inference to solve + the problem of flaky, non-deterministic tests. ++ [Git Tricks with Tri and Difft](https://nabeelvalley.co.za/blog/2026/26-03/tri-x-git-tricks/) + by Nabeel Valley on their blog. + + [Tri](https://github.com/sftsrv/tri) is a TUI interactive directory tree browser, + and [difft, or Difftastic](https://difftastic.wilfred.me.uk/introduction.html) + is a structural diff tool that understands syntax. + Difftastic was first mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/), + and most recently in [Edition #131](https://git.github.io/rev_news/2026/01/31/edition-131/). ++ [Awesome Git Diffs with Delta, fzf and a Little Shell Scripting](https://nickjanetakis.com/blog/awesome-git-diffs-with-delta-fzf-and-a-little-shell-scripting) + by Nick Janetakis on his blog. + + [delta](https://dandavison.github.io/delta/) (from 'git-delta' package) + is a syntax-highlighting pager for git, diff, grep, and blame output, + first mentioned in [Git Rev News Edition #9](https://git.github.io/rev_news/2015/11/11/edition-9/), + and most recently in [Edition #131](https://git.github.io/rev_news/2026/01/31/edition-131/).
+ [fzf](https://github.com/junegunn/fzf) is a command-line fuzzy finder, + first mentioned directly in [Git Rev News Edition #74](https://git.github.io/rev_news/2021/04/30/edition-74/) + (in passing first in [Edition #64](https://git.github.io/rev_news/2020/06/25/edition-64/)), + and most recently in [Edition #130](https://git.github.io/rev_news/2025/12/31/edition-130/). ++ [Build Git helpers from scratch with Bash and fzf](https://oliviac.dev/blog/build-git-helpers-bash-fzf/) and + [Improve your Git CLI experience with Git aliases, delta, and custom functions](https://oliviac.dev/blog/customize-git-cli-aliases-delta/) + by Olivia Coumans on her blog. ++ [Taming a 486MB Git Repo](https://hsps.in/post/taming-a-486mb-git-repo/) + (with source code taking 6MB) by Harisankar P S on his HsPS\.in blog. ++ [CodeCity: Turning a Codebase into a Skyline](https://verial.xyz/posts/codecity), + about a polyglot (multi-language) CodeCity visualizer built in Rust, + rendering codebases as interactive 3D cities. In this tool, modules are shown + as buildings, grouped together in districts corresponding to top-level packages + (squarified treemap), with footprint corresponding to size in lines of code, + height corresponding to complexity, and color corresponding to "health". + Follows from the [Legibility: A Scaling Bottleneck of the Agentic Era](https://verial.xyz/essays/legibility) essay. ++ [“Use git worktrees,” they said. “It’ll be fun!” they said.](https://daveschumaker.net/use-git-worktrees-they-said-itll-be-fun-they-said/) + by Dave Schumaker on his blog. + This post describes a problem with often used solutions like + symlinked `node_modules` or `.venv` directories, Yarn’s hardlinks-global mode, + APFS Copy-on-Write (`cp -c`) - which is also supported by other filesystems. + Proposes keeping a fixed pool of 6 worktree slots, and recycling them as needed. ++ [Direnv is All You Need to Parallelize Agentic Programming with Git Worktrees](https://waldencui.com/post/direnv_is_all_you_need_to_parallelize_claude_code_with_git_worktrees/) + by Walden Cui on The Search Blog.
+ See also, for example: + + [I Built workz: The Zoxide for Git Worktrees That Finally Fixes .env + node\_modules Hell in 2026](https://dev.to/rohansx/i-built-workz-the-zoxide-for-git-worktrees-that-finally-fixes-env-nodemodules-hell-in-2026-2dpj), + mentioned in [Git Rev News Edition #132](https://git.github.io/rev_news/2026/02/28/edition-132/). + + [Git Worktrees with Claude Code, Laravel, and Herd](https://gause.cz/blog/git-worktrees-with-claude-code-laravel-and-herd/), + mentioned in [Git Rev News Edition #132](https://git.github.io/rev_news/2026/02/28/edition-132/). + + [Why You Should Be Using Git Worktrees](https://blog.randombits.host/why-you-should-be-using-git-worktrees/), + mentioned in [Git Rev News Edition #129](https://git.github.io/rev_news/2025/11/30/edition-129/). + + [tree-me: Because git worktrees shouldn't be a chore](https://haacked.com/archive/2025/11/21/tree-me/), + mentioned in [Git Rev News Edition #129](https://git.github.io/rev_news/2025/11/30/edition-129/). + + [Managing Multiple Claude Code Sessions Without Worktrees](https://blog.gitbutler.com/parallel-claude-code/), + mentioned in [Git Rev News Edition #125](https://git.github.io/rev_news/2025/07/31/edition-125/). + + [How to use git worktree effectively with Python projects](https://www.andreagrandi.it/posts/how-to-use-git-worktree-effectively-with-python-projects/), + mentioned in [Git Rev News Edition #125](https://git.github.io/rev_news/2025/07/31/edition-125/). ++ [Using Git with coding agents](https://simonwillison.net/guides/agentic-engineering-patterns/using-git-with-coding-agents/) + is a chapter from the guide [Agentic Engineering Patterns](https://simonwillison.net/guides/agentic-engineering-patterns/), + available on Simon Willison’s Weblog. ++ [How I organize git repos locally](https://blog.esc.sh/how-i-organize-git-repos-locally/) + by Mansoor Majeed on their Esc\.sh blog. ++ [SSH certificates and git signing](https://codon.org.uk/~mjg59/blog/p/ssh-certificates-and-git-signing/) + on Matthew Garrett's Blog. + + [Signing Git Commits with SSH Keys](https://blog.dbrgn.ch/2021/11/16/git-ssh-signatures/) + was first mentioned in [Git Rev News Edition #83](https://git.github.io/rev_news/2022/01/31/edition-83/). + + See also [Git signatures with SSH certificates](https://mjg59.dreamwidth.org/60916.html) + by Matthew Garret on his old mjg59's journal blog, + mentioned in [Git Rev News Edition #91](https://git.github.io/rev_news/2022/09/30/edition-91/). ++ [Choosing the best git branching strategy for continuous delivery in your team](https://geshan.com.np/blog/2026/03/git-branching-strategy-for-continuous-delivery/) + by Geshan Manandhar on his blog: compares Git-Flow, GitHub Flow, and Trunk-based development, + recommending GitHub Flow. + + See also [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) + by Martin Fowler (author of the [Refactoring: Improving the Design of Existing Code](https://martinfowler.com/books/refactoring.html) book), + which was first mentioned in [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/). ++ [Git: Remove Dead Branches](https://nathan-long.com/blog/git-remove-dead-branches/) + by Nathan Long on his blog. + The script described in detail should probably use `git for-each-ref` + rather than parse the user-facing `git branch` command, though. ++ [Selectively ignore lines in git diff](https://lornajane.net/posts/2026/selectively-ignore-lines-in-git-diff) + by using `git diff --ignore-matching-lines=` (or `-I` in short). + Article by Lorna Jane Mitchell on her LornaJane blog. ++ [Git: ignoring temporary changes](https://blog.narf.ssji.net/2026/03/18/git-ignoring-temporary-changes/) + by Olivier Mehani on Narf blog. + He proposes using `git update-index --assume-unchanged `, which is not safe; + a safer solution is to use `--skip-worktree` instead (won't lose changes, may prevent safe operation). + + Compare [Use skip-worktree to ignore modified files](https://www.brandonpugh.com/til/git/skip-worktree-ignore-modified-files/) + by Brandon Pugh, mentioned in [Git Rev News Edition #129](https://git.github.io/rev_news/2025/11/30/edition-129/). ++ [SQLite on Git, Prologue: Why do we need random access in git](https://blog.lysk.tech/sqlite-on-git-prologue/) and + [SQLite on Git, Part I: The .git folder - Falling down the Rabbithole](https://blog.lysk.tech/sqlite-on-git-part-1) + are the first two parts of an upcoming series of blogposts, where the author shares research + enabling one to have a version controlled filesystem + that allows running a versioned SQLite database on top of Git's internal storage. + Written by Martin R. Lysk on his blog. + + Contrast [Git in Postgres](https://nesbitt.io/2026/02/26/git-in-postgres.html) + by Andrew Nesbitt mentioned in [Git Rev News Edition #132](https://git.github.io/rev_news/2026/02/28/edition-132/). ++ [GotHub all the things](https://x61.sh/log/2026/03/14032026191148-gothub.html) + by 𝚐𝚘𝚗𝚣𝚊𝚕𝚘 on x61\.sh blog. + + The [Game of Trees Hub](https://gothub.org/) (GotHub) + is a transparently funded Git repository hosting service, + with infrastructure on OpenBSD and the [Game of Trees (GoT)](https://gameoftrees.org/) VCS, + mentioned in [Git Rev News Edition #131](https://git.github.io/rev_news/2026/01/31/edition-131/) + and [#132](https://git.github.io/rev_news/2026/02/28/edition-132/). ++ [An easy way to mirror git repositories](https://dyyni.org/posts/easy-way-to-mirror-git-repos/) + with the help of author's little shell script “[ferne](https://codeberg.org/2ug/shellscripts/src/branch/master/ferne)”. ++ [Rebasing in Magit](https://entropicthoughts.com/rebasing-in-magit) + by kqr (Chris) on Entropic Thoughts. + + [Magit](https://magit.vc/) is a popular [Emacs](https://www.gnu.org/software/emacs) editor interface to Git, + first mentioned in [Git Rev News Edition #6](https://git.github.io/rev_news/2015/08/05/edition-6/), + and most recently in [Edition #130](https://git.github.io/rev_news/2025/12/31/edition-130/) + and [#132](https://git.github.io/rev_news/2026/02/28/edition-132/). ++ [Reviewing large changes with Jujutsu](https://ben.gesoff.uk/posts/reviewing-large-changes-with-jj/) + by Ben Gesoff on his blog. + + [Jujutsu (`jj`)](https://jj-vcs.github.io/jj/) is a Git-compatible version control system, + written in Rust, which was first mentioned in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [Magit and Majutsu: discoverable version-control](https://lwn.net/Articles/1060024/) + by Daroc Alden on LWN\.net. + + [Majutsu](https://github.com/0WD0/majutsu) provides a [Magit](https://magit.vc/)-style + interface for [Jujutsu (`jj`)](https://www.jj-vcs.dev/) in GNU Emacs. + First mentioned in [Git Rev News Edition #132](https://git.github.io/rev_news/2026/02/28/edition-132/). ++ [Editing changes in patch format with Jujutsu VCS](https://www.knifepoint.net/~kat/kb-jj-patchedit.html) + by Katalin Rebhan (@dblsaiko) on her blog. ++ [Manyana: A Coherent Vision for the Future of Version Control](https://bramcohen.com/p/manyana) + and [More on Version Control: This may have some legs](https://bramcohen.com/p/more-on-version-control) + by Bram Cohen on Bram's Thoughts, + about his approach of using CRDTs (Conflict-free Replicated Data Types) for version control.
+ The ideas behind [Manyana](https://github.com/bramcohen/manyana), + with a prototype written in Python, looks a bit similar to [Codeville](https://web.archive.org/web/20070202014158/http://codeville.org/), + a distributed version control system created around 2005 by Ross and Bram Cohen, + with a unique merging algorithm, no longer existing. ++ [Development tools: Sashiko, b4 review, and API specification](https://lwn.net/Articles/1063303/) + by Jonathan Corbet on LWN\.net ([free link](https://lwn.net/SubscriberLink/1063303/c076cd05ab3bef54/)). + + Konstantin Ryabitsev's [b4 tool](https://b4.docs.kernel.org/en/latest/) + was first mentioned in [Git Rev News Edition #61](https://git.github.io/rev_news/2020/03/25/edition-61/), + and most recently in [Edition #127](https://git.github.io/rev_news/2025/09/30/edition-127/). + It is also listed on the [Hacking Git](https://git.github.io/Hacking-Git/) page. ++ [Mercurial at Google: Also known as Fig](https://mercurial.paris/download/Mercurial%20at%20Google.pdf), + slides by Martin von Zweigbergk, presented at 2023-04-06. + ++ Automate Your Code with GitHub Actions ([Part 1](https://www.git-tower.com/blog/github-actions-fundamentals) and [Part 2](https://www.git-tower.com/blog/github-actions-events-and-triggers)) by Bas Steins on Tower's Blog. + + + +__Scientific papers__ ++ Benedikt Schesch, Ryan Featherman, Kenneth J Yang, Ben Roberts, and Michael D. Ernst: + _"[Evaluation of Version Control Merge Tools.](https://homes.cs.washington.edu/~mernst/pubs/merge-evaluation-ase2024.pdf)"_ + at 39th IEEE/ACM International Conference on Automated Software Engineering (ASE '24). + Association for Computing Machinery, New York, NY, USA, 831–83. + + + Authors evaluated (using Java projects from + [GitHub’s Greatest Hits](https://archiveprogram.github.com/greatest-hits/) + and [RepoReapers / Reaper](https://reporeapers.github.io/) datasets) + the following CLI tools: + [different variants of the `git merge`](https://git-scm.com/docs/git-merge#_merge_strategies) algorithm, + [git-hires-merge](https://github.com/paulaltin/git-hires-merge), + [IntelliMerge](https://github.com/Symbolk/IntelliMerge) (Java only), + [Spork](https://github.com/ASSERT-KTH/spork) (Java only), + and their own [Plume-lib merging](https://github.com/plume-lib/merging). + + They considered, but did not evaluate + [JDime](https://github.com/se-sic/jdime) (Java only) because of its limitations, + as well as AutoMerge (also known as AutoMerge-PTM), DeepMerge, and MergeBERT + because those tools are not publicly available. + They could not evaluate tools based on GUI interaction, + like [RefMerge](https://github.com/ualberta-smr/RefMerge) (IntelliJ IDEA plugin) + or [FSTMerge](http://www.fosd.de/SSMerge/) (part of FeatureHouse, depends on KDiff3). + + [Mergiraf](https://mergiraf.org/) did not exist at the time this paper was written. + Mergiraf was mentioned in [Git Rev News Edition #117](https://git.github.io/rev_news/2024/11/30/edition-117/), + [#119](https://git.github.io/rev_news/2025/01/31/edition-119/) (in passing), + and [#129](https://git.github.io/rev_news/2025/11/30/edition-129/). + + [SemanticMerge](https://www.semanticmerge.com/semanticmerge-intro-guide), + a proprietary tool with a 15 or 30 day trial, might have been defunct then (since 2013); + nowadays its homepage page is taken by SEO spam. + It was mentioned in [Git Rev News Edition #38](https://git.github.io/rev_news/2018/04/18/edition-38/). ++ Joao Pedro Duarte, Paulo Borba, and Guilherme Cavalcanti: + _"LastMerge: A language-agnostic structured tool for code integration"_ + preprint on [arXiv:2507.19687](https://arxiv.org/abs/2507.19687) (25 July 2025). + It compares four structured merge tools: + two Java specific tools, JDime and Spork, and their generic counterparts, + Mergiraf and their own LastMerge tool (currently not available), respectively. + + They also mention [s3m](https://github.com/guilhermejccavalcanti/s3m) + ([Semistructured 3-Way Merge](https://pauloborba.cin.ufpe.br/project/s3m/)) for Java. ++ Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Chenxiong Qian: + _"WizardMerge—Save Us from Merging without Any Clues."_ + ACM Transactions on Software Engineering and Methodology, Volume 35, Issue 1; + Article No.: 22 (11 December 2025), 28 pages. + + + An open-source code-merging auxiliary prototype named + [WizardMerge](https://github.com/HKU-System-Security-Lab/WizardMerge), + together with evaluation datasets, is available on GitHub. + Written in C++. + +__Git tools and sites__ ++ [A Partial Extract of revctrl.org](https://tonyg.github.io/revctrl.org/index.html), + a Revision Control wiki, which has fallen victim to spam, and is now taken over. + Scraped, archived, and edited by Tony Garnock-Jones; + spam cleanup and improvements to formatting by Michael Haggerty. + Unfortunately, all the edit history of the wiki was lost, + and individual pages do not have clear authorship. ++ [Version Control with Git for Data Science](https://guides.nyu.edu/datascience/vcs), + a part of Research Guides for the data science community at New York University.
+ References [Software Carpentry "Version Control with Git"](https://swcarpentry.github.io/git-novice/), + mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/). ++ [git bayesect](https://github.com/hauntsaninja/git_bayesect): Bayesian git bisection. + You can use this tool to detect changes in likelihoods of events, for instance, + to isolate a commit where a slightly flaky test became very flaky. + You don't need to know the likelihoods (although you can provide priors), + just that something has changed at some point in some direction. + If your code has started gaslighting you, give it a try! + Written in Python, under MIT license. ++ [GitStats](https://github.com/em1208/GitStats) is a statistics generator for Git repositories. + Currently it produces only HTML output with tables and graphs, + providing total files, lines, commits, authors, commits by hour of day, day of week, etc. + Fork of . + Written in Python, under GPLv2 or older license.
+ Original version demo available at . ++ [GitTop](https://github.com/hjr265/gittop) is terminal UI tool + for visualizing Git repository statistics, inspired by htop/btop. + Written in Go, under BSD-3-Clause license. + + See also [My First Fully Agentic Coding Project: GitTop](https://hjr265.me/blog/building-gittop-with-agentic-coding/) + by Mahmud Ridwan on hjr265\.me. ++ [diffsoup](https://github.com/junglerobba/diffsoup) is a Gerrit-style + TUI patchset diff viewer for pull requests, using Jujutsu. + Written in Rust, under MIT license. ++ [fzf-git.sh](https://github.com/junegunn/fzf-git.sh): + bash, zsh, and fish key bindings for Git objects, + powered by [fzf](https://github.com/junegunn/fzf). + Each binding will allow you to browse through Git objects of a certain type, + and select from TUI the objects you want to paste to your command-line. + Under MIT license. ++ [Git X-Modules](https://gitmodules.com/) is a tool to manage modular Git projects. + Alternative to the built-in [`git submodule`](https://git-scm.com/docs/git-submodule) + (see also [Git Tools - Submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules) + chapter in "Pro Git" 2nd Ed.), [`git subtree`](https://github.com/apenwarr/git-subtree) + (which uses the built-in [subtree](https://git-scm.com/docs/git-merge#Documentation/git-merge.txt-subtreepath) merge strategy), + [`git stree`](https://github.com/deliciousinsights/git-stree), + and [`git subrepo`](https://github.com/ingydotnet/git-subrepo). ++ [GitBucket](https://gitbucket.github.io/) is an Open Source Git platform on JVM + (a software forge), with easy installation, high extensibility & GitHub API compatibility. + Written in Scala, under Apache License Version 2.0. ++ [CodebaseHQ](https://www.codebasehq.com/) by Krystal is a software forge that + offers Git, Mercurial and Subversion hosting, with project management tools. + No free tier, 15 day free trial. ++ [`git-memento`](https://github.com/mandel-macaque/memento) is a Git extension + that records the AI coding session used to produce a commit. + It attaches AI conversation transcripts as [git notes](https://git-scm.com/docs/git-notes), + creating an audit trail for AI-assisted development. + Written in F# and TypeScript, under MIT license. ++ [ChunkHound](https://chunkhound.github.io/) is a local-first codebase intelligence, + which researches your codebase, + extracting architecture, patterns, and institutional knowledge, + to give your AI assistant the context it needs - deep understanding + of your code, files, and architectural decisions. + Integrates via [MCP](https://spec.modelcontextprotocol.io/) (Model Context Protocol). + Written in Python, under MIT license. ++ [Sashiko](https://sashiko.dev/) is an agentic Linux kernel code review system, + using a LLM (Large Language Model). It monitors public mailing lists + to thoroughly evaluate proposed Linux kernel changes. + The system acts like a team of specialized reviewers covering domains + from high-level architecture verification and security audits + to low-level resource management and concurrency analysis. + It is an open-source project that belongs to the Linux Foundation, + licensed under the Apache License, Version 2.0. + + +## Releases + ++ Git for Windows [v2.52.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.52.0.windows.2), +[v2.51.2(2)](https://github.com/git-for-windows/git/releases/tag/v2.51.2.windows.2), +[v2.53.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.53.0.windows.2) ++ Bitbucket Data Center [10.2](https://confluence.atlassian.com/bitbucketserver/release-notes-872139866.html) ++ Gerrit Code Review [3.11.10](https://www.gerritcodereview.com/3.11.html#31110), +[3.11.9](https://www.gerritcodereview.com/3.11.html#3119), +[3.12.5](https://www.gerritcodereview.com/3.12.html#3125), +[3.12.6](https://www.gerritcodereview.com/3.12.html#3126), +[3.13.4](https://www.gerritcodereview.com/3.13.html#3134), +[3.13.5](https://www.gerritcodereview.com/3.13.html#3135), +[3.14.0-rc0](https://www.gerritcodereview.com/3.14.html#3140) ++ GitHub Enterprise [3.20.0](https://docs.github.com/enterprise-server@3.20/admin/release-notes#3.20.0), +[3.19.4](https://docs.github.com/enterprise-server@3.19/admin/release-notes#3.19.4), +[3.18.7](https://docs.github.com/enterprise-server@3.18/admin/release-notes#3.18.7), +[3.17.13](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.13), +[3.16.16](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.16), +[3.15.20](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.20), +[3.14.25](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.25) ++ GitLab [18.10.1, 18.9.3, 18.8.7](https://about.gitlab.com/releases/2026/03/25/patch-release-gitlab-18-10-1-released/), +[18.10](https://about.gitlab.com/releases/2026/03/19/gitlab-18-10-released/), +[18.9.2, 18.8.6, 18.7.6](https://about.gitlab.com/releases/2026/03/11/patch-release-gitlab-18-9-2-released/) ++ GitKraken [11.10.0](https://help.gitkraken.com/gitkraken-desktop/current/) ++ GitHub Desktop [3.5.6](https://desktop.github.com/release-notes/) ++ Garden [2.6.0](https://github.com/garden-rs/garden/releases/tag/v2.6.0) ++ Git Cola [4.18.2](https://github.com/git-cola/git-cola/releases/tag/v4.18.2), +[4.18.1](https://github.com/git-cola/git-cola/releases/tag/v4.18.1), +[4.18.0](https://github.com/git-cola/git-cola/releases/tag/v4.18.0) ++ GitButler [0.19.6](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.19.6), +[0.19.5](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.19.5) ++ Tower for Mac [16.0 (Beta)](https://www.git-tower.com/blog/tower-mac-16) ++ Tower for Windows [11.2](https://www.git-tower.com/release-notes?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 Olamide Caleb Bello, Bruno Brito, +Štěpán Němec and Kristoffer Haugsbakk. diff --git a/about.html b/about.html new file mode 100644 index 000000000..3a9711987 --- /dev/null +++ b/about.html @@ -0,0 +1,7 @@ +--- +permalink: /about +redirect_to: + - / +--- + + \ No newline at end of file diff --git a/about.md b/about.md deleted file mode 100644 index 762807ea1..000000000 --- a/about.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -layout: default -title: About -navbar: false ---- - -{% include README.md %} diff --git a/css/main.css b/css/main.css index 1afaf6264..07ab16a9c 100644 --- a/css/main.css +++ b/css/main.css @@ -20,11 +20,10 @@ time, mark, audio, video { } body { - font-family: sans-serif; line-height: 1; font-size: 14px; line-height: 22px; - font-family: "adelle", Georgia, "Times New Roman", serif; + font-family: Adelle, Roboto Slab, DejaVu Serif, Georgia, Times New Roman, sans-serif; color: #4e443c; background: #f0efe7; } @@ -36,16 +35,35 @@ body { -webkit-box-flex: 1; -webkit-flex: 1; -ms-flex: 1; - flex: 1; + max-width: 700px; } .navbar { float: left; + position: -webkit-sticky; + position: sticky; + top: 0; text-align: left; - width: 20em; + height: fit-content; + width: 15em; padding: 2em; } +.navbar > ul { + margin: 0; + list-style: none; + position: relative; + line-height: 0; +} + +.navbar > ul > li { + margin: .5rem 0; +} + +.navbar > ul > li.active { + font-weight: bold; +} + #menuLinkBar { background-color: #a09a93; text-align: right; @@ -63,7 +81,8 @@ body { display: -ms-flexbox; display: flex; margin: 0 auto; - max-width: 940px; + width: 100%; + justify-content: center; } @media (max-width: 700px) { @@ -79,6 +98,7 @@ body { -webkit-order: 2; -ms-flex-order: 2; order: 2; + padding: 1em; } .navbar { width: auto; @@ -86,6 +106,7 @@ body { -webkit-order:3; -ms-flex-order:3; order:3; + padding: 1em; } #menuLinkBar { display: block; @@ -123,20 +144,6 @@ article, aside, details, figcaption, figure, footer, header, hgroup, menu, nav, display: block; } -body { - font-size: 14px; - line-height: 22px; - font-family: "adelle", Georgia, "Times New Roman", serif; - color: #4e443c; - margin: 0; - padding: 0; -} - -.windows.chrome body, -.windows.ie8 body { - font-family: Georgia, "Times New Roman", serif !important; -} - .inner { overflow: hidden; *zoom: 1; @@ -808,10 +815,10 @@ pre { -moz-border-radius: 3px; -ms-border-radius: 3px; -o-border-radius: 3px; + white-space: pre-wrap; border-radius: 3px; display: block; padding: 10px 15px 13px 15px; - margin: 0 3em 1em 3em; background-color: #fff; border: solid 1px #efeee6; line-height: 18px; @@ -1013,18 +1020,12 @@ input.active { input, textarea { - font-family: "adelle", Georgia, "Times New Roman", serif; + font-family: Adelle, Roboto Slab, DejaVu Serif, Georgia, Times New Roman, sans-serif; font-size: 14px; outline: none; } -.windows.chrome input, .windows.chrome textarea, -.windows.ie8 input, .windows.chrome textarea { - font-family: Georgia, "Times New Roman", serif !important; -} - - form#search { position: absolute; z-index: 1000; @@ -1530,11 +1531,6 @@ pre.sh_sourceCode .sh_value { font-style: normal; } -.windows.chrome body *, -.windows.ie8 body * { - font-family: Georgia, "Times New Roman", serif !important; -} - header { margin-top: 20px; position: relative; @@ -2039,7 +2035,7 @@ th, td { } img { - max-width: 100%; + max-width: 50%; } /* Table of contents */ @@ -2086,3 +2082,30 @@ img { padding-left: 2em; text-indent: -2em; } + +@media screen and (min-width: 800px) { + img[alt$=">"] { + float: right; + } + + /* + * Below styles could be useful when we position + * images to left / center. They're commented now + * since we don't use images in our site much. + * + * Ref: https://stackoverflow.com/a/39614958/5614968 + */ + /* + img[alt$="<"] { + float: left; + } + + img[alt$="><"] { + display: block; + max-width: 100%; + height: auto; + margin: auto; + float: none!important; + } + */ +} diff --git a/images/git_merge_2020_cake.jpg b/images/git_merge_2020_cake.jpg new file mode 100644 index 000000000..a4132702f Binary files /dev/null and b/images/git_merge_2020_cake.jpg differ diff --git a/images/git_merge_2020_timeline.jpg b/images/git_merge_2020_timeline.jpg new file mode 100644 index 000000000..b734dcc4d Binary files /dev/null and b/images/git_merge_2020_timeline.jpg differ diff --git a/index.md b/index.md index 77a81ed78..7fb5a8653 100644 --- a/index.md +++ b/index.md @@ -6,19 +6,4 @@ navbar: false # {{ page.title }} -This is a tentative homepage for information on Git development. If you -stumbled into this by mistake, you may want: - - - , which has information on running - git and links to download the latest version - - - , the wiki that has historically - contained developer information - -These pages are intended to collect information useful to Git -developers, including collaborative editing of documents (i.e., it is an -alternative to us having a wiki, but one that is edited entirely via git -pushes). - -Note that this page is an experiment and a work in progress. It may go -away at any time if it turns out not to be useful. +{% include README.md %} diff --git a/links/dev/Hacking-Git.md b/links/dev/Hacking-Git.md new file mode 100644 index 000000000..7dd16d665 --- /dev/null +++ b/links/dev/Hacking-Git.md @@ -0,0 +1,146 @@ +--- +layout: default +title: Hacking Git +--- + +The goal of this document is not to be a tutorial, but rather to point +to interesting material that has already been written. + +The goal is also not to list all the articles, tools or resources +about Git or its internals. There are a lot of good resources, +including [free books](http://git-scm.com/book/en/v2/), and the +[archive of our newsletter](https://git.github.io/rev_news/archive/), +about that elsewhere. So on this page we focus on what is the most +interesting for developers starting to work on Git. + +Contributions are welcome though! Please contact us on the Git Mailing +list (at [git@vger.kernel.org](mailto:git@vger.kernel.org)) or open an +issue or a pull request on our +[GitHub repo](https://github.com/git/git.github.io/) to discuss or +suggest improvements. Thanks! + +## Building Git + +* ["`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 + +* [The top of the Makefile](https://github.com/git/git/blob/master/Makefile), for special "Makefile knobs" + +## Understanding the Git code base + +* ["A birds-eye view of Git’s source code"](https://git-scm.com/docs/user-manual#birdview-on-the-source-code) in the Git User’s Manual + +* [Fabien Sanglar's Git Source Code Review](https://fabiensanglard.net/git_code_review/architecture.php) + +* [DeepWiki git/git, an AI generated introduction level overview](https://deepwiki.com/git/git) + +* [Boost Your Programming Skills by Reading Git's Code](https://www.freecodecamp.org/news/boost-programming-skills-read-git-code/) + +## Getting started hacking and contributing + +* ["My First Contribution"](https://git-scm.com/docs/MyFirstContribution) + +* ["My First Object Walk"](https://github.com/git/git/blob/master/Documentation/MyFirstObjectWalk.adoc) + +* [Matheus' tutorial](https://matheustavares.gitlab.io/posts/first-steps-contributing-to-git) + +* [Eric Ju's "Contribute-to-Git: A beginner's Guide" wiki](https://gitlab.com/gitlab-org/git/-/wikis/Contribute-to-Git:-A-beginner's-Guide) + +* ["Hacking Git"](https://git-scm.com/docs/user-manual#hacking-git) in the Git User's Manual + +* ["`Documentation/technical`"](https://github.com/git/git/tree/master/Documentation/technical), technical documentation (also viewable at `https://git-scm.com/docs/`) + +* [Our General Microproject Information](https://git.github.io/General-Microproject-Information/) can help understand the process of contributing and find issues to work on. + +## Conventions and processes + +* ["`CodingGuidelines`"](https://github.com/git/git/blob/master/Documentation/CodingGuidelines) + +* ["`SubmittingPatches`"](https://git-scm.com/docs/SubmittingPatches/) + +* [Git for Windows' "Good commits"](https://gitforwindows.org/good-commits) + +## Process related tools and sites + +* [GitGitGadget](https://gitgitgadget.github.io/) makes it easy to send patches to the mailing list. + +* [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 preferred mailing list archive. + +* [public-inbox](https://public-inbox.org/README.html) is the software behind lore.kernel.org. + +* [lore+lei](https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started) helps take advantage of lore/public-inbox. + +* [b4](https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation) helps work with patches posted on lore/public-inbox. + +* [git-series](https://github.com/git-series/git-series) helps manage patch series. + +* [git-publish](https://github.com/stefanha/git-publish) helps manage patch series. + +* [git-related](https://github.com/felipec/git-related) finds people who might be interested in a patch. + +## Development status, news and events + +* [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, and possibly other events. + +* [Git Rev News](https://git.github.io/rev_news/archive/) newsletter. + +* [Git Merge conference](https://git-merge.com/). + +* [Discussions about Contributor(s) Summits on the list](https://lore.kernel.org/git/?q=s%3AContributor*+Summit) + +## Branching workflow + +* ["A note from the maintainer"](https://github.com/git/git/blob/todo/MaintNotes) + +* ["Large-Merging Workflows"](https://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project#_large_merging_workflows) in the Pro Git book + +* [`gitworkflows`](https://git-scm.com/docs/gitworkflows) manual page + +* ["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://gitforwindows.org/debugging-git) + +* [Launching GDB explanations in CodingGuidelines](https://github.com/git/git/blob/v2.27.0/Documentation/CodingGuidelines#L441-L445) + +* [Philippe Blain's "Debugging Git" Gist](https://gist.github.com/phil-blain/17c67740bd26e66f4851fe0c07230ea4) + +* [Debugging test failure using gdb example](https://public-inbox.org/git/CAP8UFD3Bd4Af1XZ00VyuHnQs=MFrdUufKeePO1tyedWoReRjwQ@mail.gmail.com/) + +## Tests + +* ["`t/README`"](https://github.com/git/git/blob/master/t/README) + +* ["`t/perf/README`"](https://github.com/git/git/blob/master/t/perf/README) + +## Community, getting help, mentoring + +* [git-scm community page](https://git-scm.com/community) + +* [web interface to #git-devel IRC channel on Libera Chat](https://web.libera.chat/#git-devel) + +* [#git-devel IRC channel archive](https://colabti.org/irclogger/irclogger_logs/git-devel) + +* [Git Community Discord Server](https://discord.gg/NKY7fFue) + +* [git-mentoring mailing list](https://groups.google.com/forum/#!forum/git-mentoring) + +* ["A note from the maintainer"](https://github.com/git/git/blob/todo/MaintNotes) + +## Mentoring programs + +* [Google Summer of Code](https://summerofcode.withgoogle.com/) + +* [Outreachy](https://www.outreachy.org/) + +* [General Application Information](https://git.github.io/General-Application-Information/) diff --git a/links/mentoring/common/General-Application-Information.md b/links/mentoring/common/General-Application-Information.md new file mode 100644 index 000000000..a58c14919 --- /dev/null +++ b/links/mentoring/common/General-Application-Information.md @@ -0,0 +1,372 @@ +--- +layout: default +title: General Application Information +--- + +This is the page where people who want to apply to the Git project for +the Google Summer of Code (GSoC), Outreachy, or other such mentoring +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. + Specifically, also read the "AI guidelines" section to know our + stance regarding the usage of AI tools.* + + +## Microproject (required) + +It is required that applicants who want to apply to the Git project +for the GSoC or Outreachy complete a tiny, code-related "microproject" +as part of their application. + +Please thoroughly read and refer to our +[general guidelines and suggestions for microprojects](https://git.github.io/General-Microproject-Information) +for more information. Especially make sure you have fully read the +whole "Only ONE quality focused microproject per applicant" section +in that document. + +Completing a microproject is not only an important way for us to get +experience with applicants, but it will also help applicants become +familiar with Git's development and submission process. + +## Reviewing (not required but appreciated) + +Also, working in Git project is not only about writing your own +patches. Constructively critiquing design and implementation of +patches by other people is also an important skill you need to learn +in order to effectively collaborate with others. So, if you have time +and inclination, it would be beneficial to read and understand other +applicants' patches (or any other patch submitted to the mailing-list), +think if you agree that the problem they are trying to solve is worth +solving, the approach they are taking is the best way (or if you think +of a better way to solve it), etc., and respond to their patches with +the result of your thinking as a review. + +## Application (required) + +A complete application should include a presentation of yourself +(include any argument that may convince mentors that you are able to +complete the project) and detailed explanations about your +project. See also the "Note about giving back and mentoring" below. + +Project ideas are just ... ideas! The list we provide is not +exhaustive, and more importantly each idea only includes a summary of +what is to be done. An application must include detailed plans on the +design, timeline ... A typical application takes several pages. + +If you are applying for the GSoC, you should already have read +[the GSoC Contributor Guide](https://google.github.io/gsocguides/student/writing-a-proposal) +by now, but re-read it if needed. + +If you are applying for Outreachy there is very likely similar +documentation on their web site that you should follow. + +Please, include link(s) to the mailing-list discussion(s) related to +your microproject in your application (e.g. linking to +[lore.kernel.org](https://lore.kernel.org/git/)). If you participate +in the review of other patches, then you may also include links to +discussions that would support your application. Please also describe +the status of the patches you have sent and maybe reviewed: Have they +been merged already in an official branch maintained by Junio? What +does [Junio's "What's cooking in git.git" emails](https://lore.kernel.org/git/?q=s%3A%22What%27s+cooking+in+git.git%22) +say about it? In general it's a good idea to describe all your Git +related work so far with a good amount of detail. + +If the mentoring program allows different project "sizes", like for +example 'Small', 'Medium' and 'Large', or different project +"duration", like from 12 weeks to 22 weeks, please tell us in you +application which project size or duration you prefer. It's usually +not difficult for us to adapt a project we propose to different sizes +or durations. + +Applicants must send drafts of their proposal on the mailing-list +before submitting it officially to GSoC or Outreachy to get feedback +from the community. They are strongly encouraged to publish a draft on +the official GSoC or Outreachy website *and* post it to the mailing +list for discussion. + +Getting your proposal right can follow the same process as usual patch +submission for Git, as described in the +[microprojects](https://git.github.io/General-Microproject-Information) page and +in `Documentation/SubmittingPatches` in Git's source code. It is also +expected that you will send several versions of your draft, responding +to comments on the list. Please plan to send the first draft early +enough so that a number of reviews and improvements cycles can happen. + +If you are not sure about your proposal, you can discuss that in the +same email where you introduce yourself or in separate emails. Please +use "[GSoC]" or "[Outreachy]" at the beginning of the subject of such +emails. + +## Summary + +In summary, all applicants must (not necessarily in this order): + +* Complete a [microproject](https://git.github.io/General-Microproject-Information). + +* Write a detailed application explaining their project. + +* Discuss their project by posting drafts of their application on the + mailing-list long before the deadline. See the "Note about getting + involved early" below. + +In your application, and in the discussions related to projects you +are interested in, it is a good idea to: + +* Include link(s) to the mailing-list discussion(s) related to the + project you chose in your application or you are interested in, for + example previous discussions or patch series about the topic. There + might be interesting discussions about the topics that are several + year old. It is also a good idea to summarize them. + +* Include link(s) to the mailing-list discussion(s) related to the + previous drafts of your application itself. + +* Include link(s) to the mailing-list discussion(s) related to your + microproject. If your microproject patches have been merged, please + give the merge commits. Otherwise give their branch names and + current status in the last "What's cooking in git.git" email from + Junio. + +* Include what is suggested in + [the GSoC Contributor Guide](https://google.github.io/gsocguides/student/writing-a-proposal) + or the equivalent guidelines for Outreachy. + +([lore.kernel.org](https://lore.kernel.org/git/) can be +used for searching the mailing list and linking to previous +discussions.) + +## AI guidelines + +The use of Artificial Intelligence related tools ("AI" or "AIs" for +short), like Large Language Models ("LLMs"), by developers is becoming +more and more popular, but that's not a reason to blindly use them, +especially when working on the Git project. + +### Legal issues + +In general, it's not clear if AI generated code or documentation are +acceptable in the Git project. Authors contributing to Git are +required to "sign off" the patches they contribute, and to agree with +the Developer’s Certificate of Origin, also called DCO, (see +), while the DCO +says basically that authors of a patch should be sure about the origin +of its content. + +As we cannot usually be sure how AIs have been trained and that they +are not just repeating proprietary existing code or documentation they +saw during their training, we cannot accept much AI generated code or +documentation in general. Now, if it's only a few lines to fix a bug +or to implement a common pattern or summarize something, and if that +looks specific enough to a current concrete problem a developer is +working on, that might be OK. + +Anyway as the situation is not clear for the Git project and probably +many other open source projects, you should be very prudent regarding +this. + +### Be very careful with AI output + +For a number of reasons, not just legal ones, developers should really +make sure that they treat what AIs produce very carefully. They +should: + + - triple check everything, especially regarding our guidelines + (indent, style, commit message guidelines, etc, see especially the + SubmittingPatches and CodingGuidelines docs as well as the other + pages on this website) and the feedback reviewers already gave + them or others, + + - build and test changes, using existing, new or manual tests, to + check that the changes are correct, perform well and don't produce + garbage output, + + - doubt anything they don't fully understand, or anything that might + not match our guidelines or feedback, and + + - fix, simplify, adapt, reword or change anything that is + suspicious, bloated, too formal, or that they don't understand, or + that doesn't match our guidelines or our feedback. + +Yeah, AIs still often hallucinate or just produce bad code, commit +messages, documentation or output, even when you point out their +mistakes. + +### We don't accept AI output as-is + +It's unacceptable to send us something that is obvious AI slop, or +that sounds overly formal or bloated, or that looks good on the +surface but makes no sense, or that senders don’t understand or cannot +explain. It just wastes our time and we cannot accept it. We want to +interact with and mentor humans, not AIs. + +For example, it's unacceptable to have an AI generate a commit message +where it just describes what the code in the commit does, instead of +the purpose of the change, and then send that to us. + +In general, it's unacceptable to send AI-generated patches or messages +as-is to the mailing list or to mentors' or developers' personal email +addresses. We won't consider candidates doing that. + +For another, unfortunately common, example, it's unacceptable to send +us an application that has obviously been AI generated and doesn't +follow our guidelines or the feedback we previously gave to other +applicants. Those applications will be dropped. + +### Blindly using AI is far worse than not applying + +As bad AI use is growing in general, not just to apply to mentoring +programs, more and more tools and ways are being developed to find out +and fight against bad AI use. + +So people who apply by sending us AI generated output as-is, not only +waste their time, and our time, for no result, but they also leave +evidence on our mailing list archive of their bad behavior. + +For example, employers already use social media screening tools or +candidate assessment software when hiring people, and it's likely that +those tools, which often already use AI, are, or will be able to find +out soon about such bad behavior. + +### Better ways to use AIs + +Developers would often likely get better results, learn more and have +a better overall experience by asking AIs to only explain things, and +guide them step by step towards producing a solution by themselves, +rather than by asking for a full solution that they would then mostly +copy-paste. + +They can also use AIs to help with debugging, or with checking for +obvious mistakes, things that can be improved, things that don't match +our style, guidelines or our feedback, before sending it to us. + +## Note about the number of slots + +The Git organization usually has very limited mentoring capacity. +These days we usually accept between around 1 to 3 GSoC contributors +(in the Summer) or Outreachy interns (in the Winter). + +## Note about giving back and mentoring + +We appreciate very much GSoC contributors and Outreachy interns who +stay around after the mentoring period is over. It is very nice to see +them on the mailing list, even if they don't contribute much. It's of +course better when they continue to contribute though, even by just +reviewing a patch from time to time. + +Some people have been around for more than 10 years, others have +become regular contributors and that's great! + +One very nice way to contribute and to give back is to mentor or +co-mentor other contributors or interns coming after you. It helps +create more opportunities for more contributors and interns like you, +as mentoring capacity is the main factor preventing us from accepting +more contributors and interns. If each contributor or intern accepted +to co-mentor twice (for example once in the Summer and once in the +Winter) just after they have been mentored, our mentoring capacity +could increase significantly each year. + +Even though successful former contributors/interns usually have +adequate technical ability to be a successful mentor, unfortunately +few of them have been willing to just co-mentor once along with an +experienced mentor. + +Other free or open source projects have done better than us on +this. At the Google Summer of Code Mentor Summit for example, more +than 30% of the mentors are usually former contributors. + +Here is a quote by a mentor (Carlos Fernandez Sanz) on the GSoC +Mentors List, that describes very well how we see GSoC and Outreachy: + +"GSoC is (for us, anyway) more about growing the community than +getting stuff done. If they don't stick around their value diminishes +a lot, even if they do a great job [...]. The [contributors] that did +a great job but completely left the community [...] are just a +memory... the ones that have been with us and that are now mentors +[...], long after they participated in GSoC, are the ones we love :-)" + +Consider showing us in your application previous mentoring, giving +back and community activities that you have done, especially related +to free or open source software. + +## Note about refactoring projects versus projects that implement new features + +Over the years we have been favoring refactoring projects over +possibly more interesting projects that implement new features. +Refactoring projects are usually easier to do step by step, and to get +code merged step by step which is encouraging. + +In general refactoring projects are worthwhile to do even if the +project is not finished at the end of the GSoC and even if the +contributor or intern stops contributing after that. In those cases it +is often a good idea to later finish the refactoring either by +ourselves or by proposing it to another GSoC contributor or Outreachy +intern. This way the work of contributors, interns and mentors is not +likely to be wasted. + +With a project that implements a feature, there is a risk, if it's too +complex or too difficult, that the feature will not be finished and +that nothing, or nearly nothing, will have been merged during the GSoC +or Outreachy internship. There is also the risk that another way to +implement the feature will appear later in the GSoC or Outreachy +internship, and all, or nearly all, the work of the contributor or +intern and mentors will have been mostly wasted. It could also appear +that the use cases the feature was envisioned to be used in, are +better addressed by other improvements or a different workflow. + +Another potential issue is that a new feature might be prone to naming +or user interface discussions which could last for a long time or +could not result in clear decisions. + +Therefore we think that we should be very careful before proposing to +an applicant, or accepting, a project that implements a new feature. +People suggesting such a project should at least carefully consider +the above potential issues and see if they can be mitigated before the +project is submitted. + +As [suggested by Google](https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list) +(but this is true for Outreachy internships too), we emphasize that an +applicant proposing something original must engage with the community +strongly before and during the application period to get feedback and +guidance to improve the proposal and avoid the above potential issues. + +## Note about getting involved early + +The process of reviewing microproject patches and applications on the +mailing list can take a lot of time. Depending on your experience and +the tools you are already familiar with or not, it can also take some +time to set up and get used to properly sending emails and patches to +the mailing list, interacting with people on the mailing list, reading +the documentation, getting used to the code base, etc. That's why we +strongly suggest getting involved very early, like several months, +before the deadline. + +The more we can see that you invest in learning and participating in +Git's development, the more we can be confident that you are motivated +and will likely stay in the community. + +That said sending your application more than one month before the +application deadline is not a good idea either, because discussions or +on going work might happen that make us change the project ideas a bit +in the meantime, and it would be a waste of effort for you and us to +aim at a moving target. The last month should be enough to discuss +your application. Before that, please work on other things. + +The fact that we like applicants getting involved early doesn't +necessarily mean that you have no chance at all of getting accepted if +you get involved quite late. It depends on how other applicants are +doing and how many available mentors we have or can find. But anyway +you start with a significant handicap compared to other applicants who +got involved early. + +It might therefore be a good idea to find a project idea that is not +yet being pursued by an applicant who started getting involved much +earlier than you. If there aren't, then finding a project idea that we +haven't proposed in our idea list might give you a chance. + +The good side of this is that this project idea along with your +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/links/mentoring/common/General-Microproject-Information.md b/links/mentoring/common/General-Microproject-Information.md new file mode 100644 index 000000000..f67285f8c --- /dev/null +++ b/links/mentoring/common/General-Microproject-Information.md @@ -0,0 +1,620 @@ +--- +layout: default +title: General Microproject Information +--- + +## Introduction + +It is strongly recommended that people who want to apply to the Git +project for the Google Summer of Code (GSoC), Outreachy, or other such +mentoring programs, called "applicants" in this document, submit a +small code-related patch to the Git project as part of their +application. We call the whole process of submitting such a small +code-related patch a "microproject". + +People who want to get involved in Git development outside mentoring +programs can also benefit from information on this page to get +started, though it might be a bit less relevant to them. If they want, +they can use something like "[FirstTimer]", "[Newbie]", "[Newcomer]" +instead of "[GSoC]" or "[Outreachy]" in the emails they send. + +Anyway if you want to work on a microproject, or more generally if you +want to start getting involved in Git development, please read on +*all* the rest of this page. + +## What is a microproject? + +Think of these microprojects as the "Hello, world" of getting involved +with the Git project; the coding aspect of the change can be almost +trivial, but to make the change the applicant has to become familiar +with many of the practical aspects of working on the Git project. + +Git development is based on sending successive versions of patches or +patch series to the mailing list until they are considered good and +correct by the reviewers and Junio Hamano, the maintainer, who will +merge them. This process usually takes quite some time. By sending +drafts of your microproject patches to the mailing list long before +the deadline, you can show us that you are willing and able to work +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 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](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 familiar with the flow, need for clarity on +both sides (i.e. you need to clearly explain your design, and need to +ask for clarifications when questions/suggestions you are offered are +not clear enough), the pace at which the discussion takes place, and +the general tone of the discussion, to learn what is expected of you. + +## Summary of the steps needed to complete a microproject + +To complete a microproject, you will have to go through approximately +the following steps: + +* Download the source code: clone the repository using the + [Git via Git](https://git-scm.com/downloads) instructions and read + the `README` file. + +* Build the source code: this is described in the file `INSTALL`. + +* Glance over our coding guidelines in the file + `Documentation/CodingGuidelines`. We take things like proper code + formatting very seriously. + +* Read about the process for submitting patches to Git: this is + 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](/Hacking-Git/)" page + could also serve as a handy resource. It points to resources + on various topics related to working on Git. + +* Select a microproject and check that it has not yet been taken or + discussed by searching the mailing list. Please read all the + sections below related to finding or selecting a microproject. + +* Send an email to the mailing list where you describe the + microproject you want to work on, the way you want to do it, and + maybe talk a bit about yourself. Make sure the email you send has a + subject that starts with "[GSoC]" or "[Outreachy]". + +* **Make the actual change.** (Funny, this is the only part they teach + you about in college.) + +* Run the test suite and make sure it passes 100%: this is described + in the file `t/README`. (If you have added new functionality, you + should also add new tests, but most microprojects will not add new + functionality.) + +* Commit your change. Surprise: we use Git for that, so you will need + to gain at least + [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 + ["Describe your changes well" section of the `SubmittingPatches` document](https://git-scm.com/docs/SubmittingPatches#describe-changes). + 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. Instructions + on how to add the sign-off is covered in the `SubmittingPatches` + document. + +* *Optional, but recommended:* + + With an account at GitHub or GitLab, you can use the CI to test your changes + on Linux, Mac and Windows. See + [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: + * **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 + download "Artifacts" which are tarred (or zipped) archives with test data + 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 + probably want to use the commands `git format-patch` and `git + send-email`. Make sure that your email is formatted correctly: send + a test version of the email to yourself and see if you can apply it + to your repository using `git am`. Alternatively you may use + [GitGitGadget](https://gitgitgadget.github.io/) or + [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 + that purpose. This will ensure that we take special care not to + overlook your application among the large pile of others. + +* Expect feedback, criticism, suggestions, etc. from the mailing list. + + *Respond to it!* and follow up with improved versions of your + change. Even for a trivial patch you shouldn't be surprised if it + takes two or more iterations before your patch is accepted. *This + is the best part of participating in the Git community; it is your + chance to get personalized instruction from very experienced peers!* + +The coding part of the microproject should be very small (say, 10-30 +minutes). We don't require that your patch be accepted into the +"master" branch by the time of your formal application; we mostly want +to see that you have a basic level of competence and especially the +ability to interact with the other Git developers. + +## Only ONE quality focused microproject per applicant + +Applicants please attempt only **ONE** microproject. We want quality, +not quantity! (Also, it takes work to collect the ideas, and it would +be nice to have enough microprojects for everybody.) + +### Change only a few files + +This means that for a microproject that consists in refactoring or +rewriting a small amount of code, your patch should change only +**ONE** file, or perhaps 2 files if they are closely related, like +"foo.c" and "foo.h". + +If you change a test file, the title of your patch (after the +"[GSoC PATCH ...]" or "[Outreachy PATCH ...]" part) should start +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: ". + +If you create a function to refactor existing code, it's possible that +more files would be changed, but the changes should be trivial in most +of them. + +### Research existing related work + +In general it's a good idea to check on the mailing list archive +([lore.kernel.org](https://lore.kernel.org/git/) and +[Public Inbox](https://public-inbox.org/git/) are your friends) what +other GSoC or Outreachy applicants attempting a microproject have +already been told this year or any previous year, as hopefully it will +help you avoid some mistakes. As some microproject ideas haven't +changed for years, some similar microprojects might have been +attempted many times already and you can learn a lot from these +attempts. + +The more you research your microproject and take advantage of that, +the more confident we can be that you will be able to solve many +problems when working on your real GSoC or Outreachy project. So it's +a very good thing to show that you have researched your microproject +and taken into account what you have found. + +### After the microproject is done, work on different things + +If you've already done a microproject and are itching to do more, then +get involved in other ways, like finding and fixing other problems in +the code, or improving the documentation or code comments, or helping +to review other people's patches on the mailing list, or answering +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. + +### Don't work on a proposed project right away + +In general, you shoudn't work directly on any project we propose for a +mentoring program before you have been accepted in the mentoring +program to work on the project. + +We don't want applicants to start stepping on each other's work, or +applicants who do the right thing and work on other things feel +discouraged. Also the project scope often evolves during the +application and discussion periods, as applicants and mentors discuss +project proposals. + +Try to find small improvements you can make in the area of your +project or in a nearby area instead. This way you can increase your +knowledge related to your project and prepare for it. Ask on the +mailing list in case of doubt. + +If you are interested in a project with a very wide scope, it might be +possible to start working on very small parts of it. For example if +the project is about a global refactoring of the code base that affect +many parts of it, like removing global state, it might be OK to do +that a little in a small corner of the code base. Make sure no one +already started working on the same thing though. + +## Be very careful when using AI tools + +There is an "AI guidelines" section on our +General-Application-Information page: + +https://git.github.io/General-Application-Information/ + +Please read it and make sure you use AI very carefully. + +## How to find ideas for microprojects + +First check the specific page(s) or information about Git +microprojects related to your program that should have been published +on this site or on the GSoC or Outreachy site. But then still read on +everything below! + +It's also possible that we haven't taken the time to put up a page +listing microprojects ideas for your program. The pages we used to +create for that were named "XXXX Applicant Microprojects" where XXXX +is the program name and a date, for example "SoC 2016 Applicant +Microprojects" for the GSoC in 2016, or "Outreachy Winter 2021-2022 +Applicant Microprojects" for Outreachy in 2021-2022. See the following +directory to find these old pages that might still be useful: + +https://git.github.io/Historical-SoC-Outreachy/ + +Any small code-related change would be suitable for a +microproject. Just remember to keep the change small! It is much +better for you to finish a small but complete change than to try +something too ambitious and not get it done. + +Though we don't require that your patch be accepted into the "master" +branch by the time of your formal application, we still expect that a +good number of iterations between discussions and improvements has +happened. Don't be surprised if we reject your application after you +send something out of the blue just before the deadline, even if what +you did is very significant and/or of high quality! + +If you don't like for some reason the microprojects that are proposed +related to your program, or if you just want more choice, you may find +other ideas for microprojects by searching the mailing list +() or the code base itself. In the code +base you could search the code itself or the tests (in the "t" +directory). + +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 straightforward, there could be hidden reasons why it is too +difficult or just inappropriate. + +You can also always send an email to the mailing list to ask if people +have other microproject ideas, but before that please check that +someone participating in the same program as you has not already done +that recently. + +### Searching for bug reports + +Git has no official bug tracker or bug list. On + we recommend that people report bugs +directly on the Git mailing list. + +On the mailing list people sending bug reports are likely to use +things like "[BUG]", "bug", "issue" or "crash" in the subject of their +emails. So it can be a good idea to search for that. + +Most bugs are usually fixed soon after they are reported or are well +known behaviors or limitations though. So don't expect too much. + +[GitGitGadget](https://gitgitgadget.github.io/), which can be used to +send patches from a GitHub repository to the Git mailing list, has its +own list of Git issues on: + + + +There are even a couple ideas marked as #leftoverbits, i.e. curated +and copied from the Git mailing list see: + + + +And there are a couple of project ideas marked as "good first issue": + + + +that might be interesting to look at. + +There is another non official bug tracker dedicated to Git issues on: + + + +Git for Windows also has it's own issue tracker: + + + +But of course the Git for Windows issues might not apply to Git +itself. Please check that before talking about them on the Git mailing +list. + +In general it's a very good idea to check that you can reproduce the +bug on the latest version of Git before working on it. + +Also some bugs are difficult to understand and require too much or too +difficult work for a microproject, so don't spend too much time on +them if it appears that they might not be simple to fix, and don't +hesitate to ask on the mailing list if they are a good microproject. + +### Searching for #leftoverbits in the mailing list + +People have recently started to add "#leftoverbits" to their emails +when they think further small work on the topic could be useful. + +You can easily search that using: + + + +But don't forget to search to check if what you find has already been +addressed. If it has not been addressed, please ask first on the +mailing list if it's a good idea to work on that. + +As for bugs, and many things really, you can also ask if you are not +sure it's simple enough to fix. + +### Searching the code base itself + +Your best bet is probably to search for strings like "FIXME", "TODO", +"NEEDSWORK", or maybe "NEED-WORK", and "BUG" (though not the "BUG()" +macro). + +You can also search (`git grep` is your friend) for common patterns in +the code and try to find or create a function to refactor them. + +### Searching the tests + +Tests are in the "t" directory and can be run by launching "make" in +this directory. Doing that you will see that there are a number of +tests that are marked with "# TODO known breakage", like for example: + +"not ok 28 - git checkout -f: replace submodule with a directory must fail # TODO known breakage + +These tests start with "test_expect_failure" instead of +"test_expect_success". They document that something is not working as +it should perhaps be working. And it might be an interesting +microproject to fix that. + +Note that it is especially wise to first search the mailing list and +then ask on the list before working on one of these +"test_expect_failure", because if we bothered to document a failure +but not fix it, that is often because the fix is non-trivial. + +You could also check if some commands have no test for some of their +options and it could be an interesting microproject to add a test for +one of those options. + +### Searching the mailing list for other ideas + +You can search the mailing list for words like "low hanging fruit", or +"low-hanging fruits", "hint, hint", "later", "we should", "I plan +to"... + +## How to introduce yourself to the community + +It's likely that you will introduce yourself to the community around +the same time you are going to start working on a micro-project. + +### Tell us about you, or not + +We don't require you to send us a special introductory email or to +tell us about your skills, interests, experience, background, +etc. Feel free to tell us what you want about yourself if you wish +though. + +Make sure to specify your mentoring program clearly as +[suggested below](#use-a-tag-like-gsoc-outreachy-etc-in-your-subject). + +### Thoroughly check your eligibility in the program + +Before you introduce yourself, it's very important that you thoroughly +check as soon as possible that you are eligible for the mentoring +program you are interested in. + +This is especially important for Outreachy, which has strict rules and +is enforcing them. Their rules are available on: + +https://www.outreachy.org/docs/applicant/#eligibility + +Especially if you are a student, please check the section about the +rules for students, and especially check this one: + +"University students must have 42 consecutive days free from school +and exams during the internship period." + +The Outreachy organizers will check this rule with your university. +They will disqualify you if there is any requirement, especially this +one, that you don't meet. + +If you start applying to the Git project, this will deter others from +applying. We usually have very few projects and can only accept very +few applicants. So if others want to apply, they know they will have +to compete with you and possibly others, and they might prefer to find +another project with less competition. + +It happened recently that only two people applied for a project we +proposed, and both were later found to not be eligible because of +their university requirements. So in the end, we couldn't mentor +anyone for the project we proposed, which is bad for everyone. + +So please thoroughly check your eligibility before introducing +yourself, and please confirm in your introduction that you have +checked all the requirements and that you indeed meet them all. + +### Don't ask us to find a micro-project for you + +As we usually don't know your interests, skills, experience, +background, etc, it's hard for us to select a micro-project for +you, and it's part of your job as an applicant to research a good +micro-project for you. It will show us that you will be able to +select a good project for you and properly research it. + +### Do ask for help, but be specific + +You can ask for help if there are things you don't understand in a +micro-project description, or if you have some trouble working on your +micro-project or even finding a micro-project. But please be very +specific in your questions and tell us in detail what you searched or +tried, what you expected and what didn't work as you +expected. Something like "I couldn't find a good micro-project for +me", for example, doesn't tell us much, and doesn't give us any idea +about how we could help you. + +## Why it's better to introduce yourself by directly emailing the mailing list + +We understand that some people are a bit shy or reluctant to email the +mailing list directly and interact with people there, but that's +something that is required to contribute to Git. So you will have to +do it at one point anyway. + +Also please understand that there are often a significant number of +people interested in participating in programs like GSoC or Outreachy, +and mentors prefer to answer questions once and for all on the mailing +list instead of many times privately to everyone interested in +participating. + +Emailing mentors privately will not give you any advantage. On the +contrary it might just signal potential mentors that you are not very +willing to interact with the mailing list. It will also increase the +workload of mentors for possibly no good reason which is not something +they like. + +Mentors will be willing to properly mentor those who have been +selected to participate in the mentoring program, but until then they +cannot, and don't want to, privately mentor several people to help +them be selected. It wouldn't be fair to those who are doing the right +thing and interacting with the mailing list directly. + +## Some conventions and tips + +It can be intimidating to introduce yourself or send your first patch +to the mailing list, but we hope that the following conventions and +tips will help you get properly started. + +### Start your own email thread + +When you introduce yourself to the Git mailing list, please start your +own email thread instead of replying to a thread where someone else +introduced themself, or worse a completely unrelated thread. + +### Use a tag, like [GSoC], [Outreachy], etc, in your subject + +Yeah, we insist on this because many applicants don't do it despite +the fact that it helps everyone, especially themselves. + +It helps because efficiently searching the mailing list is not so +easy. Having such a tag at the start in the subject makes it much +easier to find what applicants or contributors from a program have +done. And applicants should be very interested in searching for what +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 +usually reply inline instead, which is also called the "interleaved +posting" posting style. See +https://en.wikipedia.org/wiki/Posting_style for more information about +these styles. + +So please don't just reply on top of the email you are replying +to. Instead, just expand the email you are replying to and put your +comments in it. + +### Put ALL the co-mentors in To: or Cc: + +When emailing about something related to your program (GSoC or +Outreachy or ...) and when you know who are your possible +(co-)mentors, put them all in To: or Cc:. If you email or reply and +forget to put one of your (possible) co-mentors in the loop, it can +only create confusion or additional useless synchronization work for +your mentors and ultimately make it harder for them to help you. + +If you have something personal to say to only one of your mentors, +it's Ok to not put others in To: or Cc:, but otherwise, please, make +it a habit to put them all in the loop when you contact them. + +Tip: just use "Reply-all" when you reply to an email. + +### Don't be formal + +We are used to not using titles, like "Sir", "Mr", etc, and not being +formal. Yeah, it can be difficult, as in some areas or countries, +people are supposed to be formal with mentors, professors or people +older or more experienced than themself. But please try to be as +informal as us. + +### Tell us your first name or how you want to be called + +Most people on the mailing list like to call each other and to be +called using their first name, or sometimes a nickname. So that's how +we would like to call you. So let us know your firstname or how you +want to be called. + +Yeah, sometimes it seems obvious, but sometimes it's really not, as +for example in some countries people commonly have 4 different names, +in others they usually mention their first name after their last name +(instead of before), in yet others, first names are usually +abbreviated in non obvious ways, etc. + +So please make it clear. + +### Tell us the pronouns we should use + +Again, yeah, it's often obvious, but often it's not. So please tell us +if we should use "He/him/his", "She/her/her(s)", "They/them/their(s)", +or another pronoun to talk about you. + +### Confirm that you pass the requirements + +Programs like Outreachy or GSoC usually have requirements for +applicants. Sometimes applicants have to be accepted by the program +organizers after they have shown they satisfy the requirements. + +In any case it's interesting for us and others to know soon how you +currently stand regarding the requirements and maybe the acceptance +process. + +See also the "Thoroughly check your eligibility in the program" +section above. + +### Tell us what steps you have already taken + +We can better help you and suggest the next steps for you to take if +we know what steps you have already taken. + +So if you have read this documentation, tell us. If you have already +started or finished a Git tutorial, tell us too. If you have only +built Git from source, tell us. If you have already sent patches on +the Git mailing list to improve Git, tell us. + +We don't need to know about the computer science knowledge or C or +shell language programming experience you have, but telling us where +you are regarding developing Git is definitively helpful. diff --git a/SoC-Historical.md b/links/mentoring/common/Historical-SoC-Outreachy.md similarity index 62% rename from SoC-Historical.md rename to links/mentoring/common/Historical-SoC-Outreachy.md index 17daa7361..3741eb43e 100644 --- a/SoC-Historical.md +++ b/links/mentoring/common/Historical-SoC-Outreachy.md @@ -1,10 +1,10 @@ --- layout: default -title: Historical Summer of Code Materials +title: Historical SoC and Outreachy Materials --- -These pages are historical application materials for Summer of Code and -other programs. They are for reference only! +These pages are historical materials for Summer of Code and +Outreachy. They are for reference only!
    {% for node in site.pages reversed %} diff --git a/links/mentoring/common/Mentoring-Program-Guide.md b/links/mentoring/common/Mentoring-Program-Guide.md new file mode 100644 index 000000000..52d2b4796 --- /dev/null +++ b/links/mentoring/common/Mentoring-Program-Guide.md @@ -0,0 +1,649 @@ +--- +layout: default +title: Mentoring Program Guide +--- + +This is the page to help people, who got accepted in a Mentoring +Program like the Google Summer of Code (GSoC) or Outreachy, during the +program. It can also help those interested in applying to such a +program get an idea about how it goes. + +First congratulations for being accepted! + +# Introduction + +The way you will be mentored depends on a lot of different things, for +example how well you are doing, who are your mentors, what your +project is about, what the mentoring program (GSoC or Outreachy) +requires or suggests (which can significantly change each year), how +the mailing list responds to your patches, what currently happens in +your country or in your mentors' countries, etc. + +This document might give you an idea about how things usually go, but +don't be surprised if your mentors ask for things that are a bit +different than what is described here. It's also possible that things +change during the mentoring program. Typically your mentors will +expect that you become more autonomous. + +# Communication + +## Blogging + +One of the first things you might want to setup (if you haven't one +already), after you have been accepted, but before the working period +actually starts, (GSoC calls this the "Community Bonding" period,) is a +blog. + +You might want to check which blogging tools previous Outreachy +interns and GSoC contributors used. Using a Git related tools is of course +a good idea. + +- [Miriam Rubio's Outreachy intership experiences](https://mirucam.gitlab.io/outreachy_blog/) +- [Matheus Tavares's Blog](https://matheustavares.gitlab.io/) [ [source](https://gitlab.com/MatheusTavares/matheustavares.gitlab.io/) ] + +Using GitHub: + +- [Charvi Mendiratta's Outreachy Internship Experiences](https://charvi-077.github.io/) [ [source](https://github.com/charvi-077/charvi-077.github.io) ] + +If you already have something setup using other tools though, even if +it's not Git based, it's perfectly OK to use what you already have, +and focus on your project right away. + +Your blog should be a tool to improve communication between you and +the Git community, including your mentors. Your blog is also something +that can help you in your career by reflecting positively on your +abilities and dedication. A good example is Matheus' GSoC blog posts: + +[Matheus Tavares' GSoC posts](https://matheustavares.gitlab.io/tags/gsoc/) + +Tip: It's better if you can decide the day for your weekly blog post +as soon as you set up you blog. Then tell your mentors about that day +right away, and try as much as possible to post every week on that +day. This will help establish a routine, that will make things easier +for both you and your mentors. + +Tip: It's also better if you can prepare the content of your weekly +blog post during the week as you are working on your project. This way +it can also serve you as a todo list, a notebook, a list of current +issues, etc. + +## Social media and blog post content + +In general posting about your GSoC on social media (like LinkedIn) is +nice too. You can put links to your blog post in your social media +posts, as they are usually shorter than blog posts. + +You can start blogging as soon as your mentors contact you after you +have been officially selected to participate in the mentoring +program. It's in fact a nice idea to start blogging right after they +have contacted you. + +In all your posts (on your blog or social media), when you mention +your mentors and when they are mentoring you as part of their job, +it's nice to mention the companies they are working for too. Some +mentors could mentor you in their free time, and might not want their +employer mentioned though. So if you are not sure that it's part of +their job, just ask them before posting. In case of Outreachy if some +company sponsors your internship, it's a very good idea to mention +them too. + +The more these companies get good mentions in the media about your +GSoC, and the more good work you deliver during it, the more likely +they are to allow their employees to mentor others, or even to sponsor +mentoring programs (like Outreachy internships for example), or maybe +to hire or help you in the future. + +## Regular updates + +Mentors should be regularly updated about your work, so they can know +if you are stuck on something, what you have done, and what you are +planning to work on and how. + +The best way to update everyone about your work is probably to post on +your blog. We understand though that you might not want to put +everything you might want to say on your blog. + +People on the Git mailing list might be interested to know that you +published something on your blog, so that they can give you some help +or feedback about your next steps or problems you are facing. So we +think that you might want to email the mailing list to notify every +one about each new blog post. If you don't feel like doing that, +we might find an alternative solution, but letting people know is +often a good idea to get help and suggestions. You can also take +advantage of the notification email to ask for help or to ask +questions related to issues you have. + +Your mentors should be notified too that you posted something. To +notify your mentors, you can either cc them when you email the +mailing list, or you can send them a separate email. In a separate +email you might add things that you might not want to post on your +blog or to the mailing list. + +We require you to update your mentors at least every week. So the best +is if you can post on your blog weekly (and send the related +notifications discussed above). If sometimes for some reason (like a +vacation or exams or family issues) you cannot post a weekly update, +then it's OK to just email your mentors, or to ask them to have a chat +one way or another. Then please make sure you post on your blog the +following week. + +In the blog post update and your emails to your mentors and the +mailing list, it is important that you cover all the following topics: + +1. what you have done since last update and how +2. what is blocking you if anything +3. what you find difficult to do or understand +4. what things you think should be easier +5. what you are planning to work on and how + +The reason we ask for 2), 3) and 4) is that often interns or +contributors don't know about things, like existing documentation, +historical discussions, debugging scripts, features, tools or +techniques, that could help them understand what's going on, or work +in a more efficient way. If a mentor doesn't know that the intern or +contributor is blocked or slowed by something or has a hard time +moving forward, it's difficult for the mentor to help. So it's +important for interns or contributors to reflect on the issues, +blocks, inefficiencies, complex things that they are facing. + +Notifying the mailing list or your mentors about a blog post, should +not prevent you from emailing or contacting the mailing list or your +mentor when you might want to do that at other times. In general don't +be afraid of posting or contacting people early and often. + +## Chat + +It can help to sometimes have a chat (by that we mean a real-time +conversation) with your mentors. This can especially help you when you +are stuck or after you have reflected a bit on the status of your work +and internship, and have doubts or feelings that things aren't going +as well as they could. + +As we think it's best that you decide on your own the best time to +update your blog and send notifications, you should then also decide +when it's best to have a chat with your mentors. So, unless you prefer +to plan regular chats, your mentors might not ask for a chat, and +might just want you to pro-actively email them when you want a chat. + +Some mentors might not be always online on a chat platform, so you +might need to schedule chat discussions, and try to find a good time +for everyone. You can also propose the tools and media that work best +for you (instant messaging, phone call, video call, WhatsApp, Zoom, or +even email ...) and your mentors will likely do their best to adapt to +your preferences. + +Mentors usually look at their emails several times per day on week +days, so you can say for example in an email that you are free during +the next 2 hours to have a chat, and that could be enough to schedule +a chat to unblock you. You can also use a notification email after a +blog post to schedule a chat. In general if you are not blocked and +you have more than one mentor, it's better to schedule a chat a few +days in advance to increase the chances that all your mentors can +participate. + +In general for everything specifically related to your project and +internship, it's better to try to involve all of your mentors (for +example by Ccing all of them in emails, and by using an instant +messaging group they all belong to), though we know it's not always +possible or practical when you are blocked. + +It could be OK to discuss personal or technical things or anything not +directly related to your project with only one of your mentors (like +with anyone else). Just ask them. + +If you prefer to have a completely fixed schedule from the start as +you know each week well in advance when you will post on your blog and +when you want to have a chat with your mentors, that can work too +and you can probably set this up with them. + +It's also OK to have such conversations completely over email if you +prefer. We know that email is not usually considered really real-time, +but we think it is, or can be, close enough compared to instant +messaging chat for example. It sometimes happen on the Git mailing +list that people debug together or discuss together +something over email in a very real-time way (at least similar as +instant messaging chat). + +Such chats can sometimes help a contributor or intern (or even long +timers on the project) move very fast in a short amount of time. So +consider taking advantage of that. + +It's also easier for mentors to help (or understand how they could +help) when discussing informally using a real time or near real time +communication medium, rather than blog posts or emails, so don't +hesitate to ask for that even if you are not sure that they could +help. And don't hesitate to ask them to use a medium you haven't +already used with them, like Zoom for example to have a video chat, as +sometimes it's just easier to understand something by sharing a +screen. + +You are also encouraged to take advantage of the whole Git community +and its communication channels (https://git-scm.com/community), like +the #git-devel IRC channel. Some or all of your mentors might not be +on this channel or on alternative community channels you might want to +use, but if you want to discuss with your mentors there, that's +something they can consider. + +## Scheduling and other communication issues + +Some mentors cannot easily let you know in advance what days and times +they will be available to answer questions. They might not have a well +planned schedule. They should be able to schedule things or give you +time periods when they are more likely to be available though. + +Anyway you should usually not wait much before asking a question. If +you haven't found an answer or don't understand something after a 20 +minute search on the mailing list archive, the code, the documentation +and Google, it's high time to ask a question or ask to have a chat. +Please try to search for 5 to 10 minutes before asking though, and +please let your mentors know how you searched, so that they can +perhaps help you be more efficient in searching for answers. + +In general being as open as possible about everything related to your +work, like what you don't know or don't understand, possible mistakes +you have made and are still making, how you are searching when there +is something you don't understand, which commands you are running, and +even how you are feeling, helps a lot in resolving issues and moving +forward. + +If you plan to have a vacation or if something might prevent you from +contacting your mentors, from updating them weekly, or from working on +your project for some time, please let them know in advance. + +# Code + +## Repository + +We require that you store and regularly update your current work in +public repos on GitLab or GitHub (or maybe Gerrit, gitolite, etc, but +please discuss it with us before choosing something other than GitHub +or GitLab). Usually a single repo forked from an official git.git repo +maintained by Junio (like https://github.com/git/git) is enough, and +you probably already have one. + +It unfortunately happens that people stop working on their in progress +project, either after the mentoring program is finished, or sometimes +during the mentoring program, and we might want to reuse their work +later. Often for example it takes a number of mentoring programs to +finish a big project and you have to continue a project from where it +was left by someone else. + +Having everything in one, or a few, public repositories makes it +easier to continue some work and also to test or contribute to it +occasionally. So making your work available this way and frequently +linking to your repo and the branches and commits in it you have +worked on (for example from your blog posts and emails to the mailing +list and your mentors), can help you get comments, code contributions, +bug reports, etc, which will move your project forward. + +## Draft patch series and branches + +It's a good idea to have your mentors review your patches or patch +series or branches on your repo before sending them to the mailing +list. It's OK though if you want to sometimes send a draft patch or +patch series directly to the mailing list to get as much as possible +everyone's feedback on something. You should mark them as [RFC] +(request for comment) or [WIP] (work in progress) though. + +A good way to have your mentors review something is to send them a +link to it on your public repo. This way they can comment there and +maybe make suggestions that you can easily apply. You could also +directly send them your patches as emails if they are OK with it. + +When you update your work after having received feedback from your +mentors or others, it's nice if instead of updating the same branch, +you could make changes, on a new branch. For example, if you are +working on `git bisect` you could make some initial changes on a +branch named bisect1, then, after receiving some comments on it, make +further changes on bisect2, and so on. This way your mentors and +others could check what you did using a diff, or a range-diff, between +the branches. + +Before you ask your mentors to review something, even if it's in the +draft or work in progress state, it's a good idea to make sure that +you have put some effort in writing a good commit message for each of +the commits you'd like them to review. Without a commit message (with +a title and a body) explaining the purpose of your patch, it can be +difficult for your mentors (or anyone actually) to tell if it makes +sense. + +If you know that something is missing in your patch, it's a good idea +to add [WIP] or [RFC] in the title and to add comments somewhere about +things that are missing, (like /* TODO: XXX */ comments in the code +for example), so that your mentors know which parts of your work are +not finished. + +A good time to send a link to a branch you are working on to your +mentors and ask them to review it, is typically when the commit +message and the code look good, and when it compiles without warnings +and passes existing tests, but when you haven't yet written the +documentation and the new tests. You can then work on the new tests +and documentation while your mentors review the code. Even then, +please say that documentation and new tests are missing. + +That said, it's OK to send something when a number of parts are +missing, including maybe some parts of the commit message and when the +code does not even compile, as long as you describe clearly what you'd +like to do, what are the issues you are facing and what is missing or +not yet finished, so that your mentors don't have to guess or tell you +that things are missing or should be improved when you already know +it. + +The goal is really to have efficient discussions for both you and your +mentors, so that your project can move forward fast with as few +misunderstandings as possible and as little frustration as possible. + +As much as possible you should work on different parts of your work in +different branches, and avoid having similar commits you are working +on in different branches. + +It's much better to work on many small branches and patch series that +can be regularly sent or resent to the mailing list, rather than on a +single big one that can be sent only at the end when everything looks +good. + +## Sending patch series to the mailing list + +It's up to you if you prefer to wait until your mentors have reviewed +everything and found nothing wrong with your patches, which could be a +good thing as it would likely decrease the reviewers' work on the +mailing list, or if you prefer to send your patches when you think +they are ready. + +You might acknowledge your mentors' help with the work you are doing +by adding a "Mentored-by: Mentor Name " trailer for each +of your mentors in the commit message of all the patches you send. We +recommend doing this systematically instead of spending time finding +which mentor helped or not on which patch. + +Basically sending patch to the mailing list is the same process as +when working on a micro-project. + +A few things that you might want to do are: + +- Make sure your mentors are Cc'ed on all of your patches. + +- Make sure everyone who commented or got involved is also Cc'ed. + +- Make sure Junio is among the recipients (in the "To:" header) if + your patches have been reviewed. + +- Consider adding the "Mentored-by:" trailers discussed above. + +- Consider adding some "Helped-by:", "Reviewed-by:" or "Acked-by:" + trailers if relevant. + +- Don't forget bumping up the version of the patch series. + +- Don't forget using [GSoC] or [Outreachy]. + +- Don't forget using [RFC] or [WIP], if it's relevant. + +# Resources, rules, documentation and links + +We encourage you to get as much help as you can from your mentors and +the Git community according to the suggestions in the "Communication" +section above. + +Nevertheless you are also welcome to get help in many different ways +that might not be mentioned above. Such help can come from the +community, its people, tools, documentation or websites, as well as +other people, tools or websites. You have to do most of the actual +work and follow some rules though. + +The following sections list some of these resources (people, tools, +documentation, websites, etc.), sometimes along with suggestions about +when they might be useful. + +Some of these resources are also important as they can help you learn +about the rules. + +## People + +When communicating with other people, we encourage you to keep your +mentors (or perhaps the whole community) in the loop though, if +possible. + + - Individual contributors + + When someone contributed to something very relevant to your work, + you might want to privately ask for help from them as they might + know more and might be able to help you better than your mentors + in some areas of your work. + + - Org Admins (people responsible for Git being involved in the + mentoring program) + + They could be useful if, for example, you, along perhaps with your + mentors, want to extend or change the duration of your mentoring + program (if it is allowed by the mentoring program). + + - Mentoring Program organizers + + If you have issues related to the mentoring program, you can + likely reach out to them. + + - Git PLC (Project Leadership Committee) members + + They are responsible for communicating with the + [Software Freedom Conservancy](https://sfconservancy.org/), + which is Git's parent nonprofit organization. They are also + responsible for enforcing Git's Code of Conduct, especially on the + Git mailing list. + +## Important community documentation and rules + +Please read, and try to keep in mind, the important documentation +below: + + - [Git's Code of Conduct](https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md) + + This can be useful if others' behavior annoys you or if your + behavior might annoy other people. + + - [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://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) + + It makes sure that Git, and the contribution you make to it, are + free and open source software. You also have to know about it to + fully make sense of the DCO above. + +## Other community websites + +Please take a quick tour of those websites, if you haven't already, to +know about all the resources that they make available to you. + +Also note that you are very much encouraged to contribute to improving +these sites during your mentoring program. It's very much appreciated, +as it shows that you care about those who will come after you, even if +it's not part of your main work. + + - [Git Developer Pages](https://git.github.io/) + + This is the home of this very documentation and Git's mentoring + program related documentation. It also contains the + [Hacking-Git page](https://git.github.io/Hacking-Git/) + which has a number of helpful links. + + This website is maintained through + [its GitHub repo](https://github.com/git/git.github.io). + + - [Git Documentation website](https://git-scm.com/) + + This is the main Git website, with Git reference documentation + automatically generated from the + [Documentation folder](https://github.com/git/git/tree/master/Documentation) + of the Git repo, as well as a free book, and general information + about Git, including community information. + + This website is maintained through + [its GitHub repo](https://github.com/git/git-scm.com). + +## Other links + + - [Outreachy website](https://www.outreachy.org) + + - [GSoC website](https://summerofcode.withgoogle.com) + +# Roadblocks and Benefits + +Successfully participating in a mentoring program with Git can boost +your career in a number of different ways. Also even if it requires +working regularly and being open to mentoring, it's not very +difficult. We estimate that around 80% or more of the people we accept +succeed. + +## Roadblocks + +It's possible that you will encounter difficulties in moving forward +in your project. We try to list a few common ones here, along with +some advice to help overcome them. + +In general it's a good idea to discuss such issues with your mentor(s) +as early as possible. This way you might get some help and be able to +try different solutions before it's too late. One possible way to +alleviate some issues could be to extend the mentoring period if the +mentoring program allows it. + +### Dedicated time + +The main thing that could prevent you from succeeding is not having or +dedicating enough time to work on your project. Some people we +mentored had university classes, or found a full time job, or took +some long vacation, or spent a lot of time with their family, which +prevented them from dedicating enough time to their project. This +resulted in us having to fail them, which is sad for everyone. + +If you are planning to spend a significant amount of time doing other +things than working on your project during the mentoring program, it +might be better to not participate in it in the first place. You will +save yourself and your mentor(s) a significant amount of frustration, +and you will likely allow someone else to be successfully mentored and +gain a lot from that experience. + +Other roadblocks can more easily be overcome than not dedicating +enough time. Even if you can work a lot, you will need a bit of free +time during the mentoring program, so you may make things very +difficult for yourself if you are planning to work on both your +project and other things at the same time. Be considerate towards +yourself and do not put yourself in such a bad situation in the first +place. + +### Asking for help + +Another thing that could slow you is if it's difficult for you to +share with your mentor(s) about the technical hurdles you face. It +could be that you have trouble debugging or understanding how things +work or are supposed to work, and are afraid of asking for help. + +When we review your work, we provide technical suggestions, but when +you are starting it or in the middle of it, you are usually alone and +it can be difficult for you to ask your mentor(s) to take a look at +it. Please consider that the more transparent you are about your work, +and the more precise and specific you are in your questions, the +easier it is for us to help you, and for you to move forward. + +We only request that you spend around 10 minutes trying to find a +solution by yourself before you ask us about something. When you have +tried to find a solution, it's also a good idea to tell us what you +have tried or how you searched, as we can often help you be more +efficient in this too. + +### Personal issues + +Yet another roadblock that could sometimes prevent you from succeeding +is personal issues of different kinds. They are sometimes related to +your family or your partner. They are sometimes related to the other +potential roadblocks above. + +In general it's a good idea to talk about them early with your mentor, +as we just cannot properly handle difficult personal situations we are +not aware of. And regular communication, even using video chat, might +not be enough to suspect that your personal situation might be +difficult, if you are not explicit about it. + +## Benefits + +There are a lot of benefits in participating in mentoring programs +with the Git project, not just the fact that the programs pay the +participants a significant amount of money. + +And it's not limited to the first time you participate. The more you +participate, the more benefits you will reap. Participating as a +mentor or a co-mentor after you have been mentored, or becoming a +regular contributor, will also reflect very well on you and increase a +number of benefits you get. It's also relatively easy, as you have +already overcome the most difficult parts. + +### Career boost + +A number of former participants in a mentoring program with us have +reported that it significantly boost their career, as they much more +easily got job interviews, and then job offers with more well known +companies. + +### Improved technical skills + +Former participants also reported that they felt their software +engineering skills improved significantly. + +This is not just that they became more proficient with Git and source +code management in general. It's a also at least about improved +programming, testing, reviewing and collaborating skills. + +### Improved self confidence + +We believe that being able to contribute significantly to a well known +project like Git, also helps improve participants' self-confidence. +They are likely to be less afraid to participate in and contribute to +more complex software projects. + +### Improved Internet credibility + +We strongly encourage the participants we mentor to create a blog +about their work and regularly post on their blog, as we believe that +it helps them in many ways. We encourage them to post on social media +too. + +We also mention participants in our Git Rev News newsletter both after +they have been selected into a mentoring program, and after they +successfully finished it. + +Sometimes they get mentioned, or interviewed, in the blog posts of +some well known Git related companies too, like for example: + + - [this GitLab blog post about Outreachy](https://about.gitlab.com/blog/2021/04/15/outreachy-sponsorship-winter-2020/), or + - [this GitHub blog post about the Git 2.43 release](https://github.blog/2023-11-20-highlights-from-git-2-43/), + where Kousik's GSoC 2023 work is mentioned. + +### Meeting us at some conferences + +We try to help successful participants come to the +[Git Merge conference](https://git-merge.com/) +and meet the community, often including their mentor(s), there. For +that the Git project offers to reimburse the participants' travel +expenses. + +This is sometimes not possible due to visa issues, or the fact that +the Git Merge unfortunately doesn't happen every year, though. + +# Conclusion + +We hope you got an idea about how you will likely work with your +mentor(s) and how things usually go during the mentoring period of a +program such as GSoC or Outreachy. We hope you are also aware of the +people, communication means and resources available to help you, as +well as the rules you have to follow, the roadblocks you might +encounter and the benefits you may reap. + +As a reminder, don't be surprised if your mentors ask for things that +are a bit different than what is described here. Typically your +mentors will expect that you become more autonomous over time and will +adjust things depending on how autonomous you already are. + +Wishing you luck during your mentoring period! diff --git a/Outreachy-2016-May.md b/links/mentoring/outreachy/Outreachy-12.md similarity index 90% rename from Outreachy-2016-May.md rename to links/mentoring/outreachy/Outreachy-12.md index da1f77d68..427e610ce 100644 --- a/Outreachy-2016-May.md +++ b/links/mentoring/outreachy/Outreachy-12.md @@ -1,6 +1,6 @@ --- layout: default -title: Outreachy May 2016 +title: Outreachy Round 12 (May 2016) navbar: false --- @@ -25,14 +25,14 @@ Before then, you should fill out an and complete a small [coding project](https://wiki.gnome.org/action/show/Outreachy?action=show&redirect=OutreachProgramForWomen#Make_a_Small_Contribution). We have a list of -[microprojects](../SoC-2016-Microprojects), but +[microprojects](https://git.github.io/SoC-2016-Microprojects), but you may also work with a potential mentor to come up with a contribution related to your proposed project. ## Project Ideas You can find a list of project ideas on our [ideas -page](../SoC-2016-Ideas). Note that this just a list of suggested +page](https://git.github.io/SoC-2016-Ideas). Note that this just a list of suggested projects; we are happy to hear proposals for new projects. If you would like to propose an idea, please make sure to solicit feedback from the mailing list (see below) and find someone willing to be a mentor for it. diff --git a/Outreachy-15.md b/links/mentoring/outreachy/Outreachy-15.md similarity index 99% rename from Outreachy-15.md rename to links/mentoring/outreachy/Outreachy-15.md index 89903c8d4..9c75f46ab 100644 --- a/Outreachy-15.md +++ b/links/mentoring/outreachy/Outreachy-15.md @@ -1,6 +1,6 @@ --- layout: default -title: Outreachy Round 15: September 2017 +title: Outreachy Round 15 (September 2017) navbar: false --- diff --git a/Outreachy-17.md b/links/mentoring/outreachy/Outreachy-17.md similarity index 98% rename from Outreachy-17.md rename to links/mentoring/outreachy/Outreachy-17.md index 87274459d..09575b60a 100644 --- a/Outreachy-17.md +++ b/links/mentoring/outreachy/Outreachy-17.md @@ -1,6 +1,6 @@ --- layout: default -title: Outreachy Round 17: September 2018 +title: Outreachy Round 17 (September 2018) navbar: false --- diff --git a/links/mentoring/outreachy/Outreachy-21-Microprojects.md b/links/mentoring/outreachy/Outreachy-21-Microprojects.md new file mode 100644 index 000000000..cffa96590 --- /dev/null +++ b/links/mentoring/outreachy/Outreachy-21-Microprojects.md @@ -0,0 +1,94 @@ +--- +layout: default +title: Outreachy Winter 2020-2021 Applicant Microprojects +navbar: false +--- + +## Introduction + +First make sure you read and understand +[our general guidelines and suggestions for microprojects](https://git.github.io/General-Microproject-Information). + +There are some suggestions on how you can find some microprojects on your own in the document. + +## Ideas for microprojects + +### Add more builtin patterns for userdiff + +"git diff" shows the function name corresponding to each hunk after +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...), +the way to find the function name is built-in Git's source code as +regular expressions (see userdiff.c). A few languages are common +enough to deserve a built-in driver, but are not yet recognized. For +example, shell. + +This project requires a very good knowledge of regular expressions. + +It is easy though to find examples of how this can be done by +searching the code base and the mailing list archive, as this has +already been done for a number of languages. + +### Use `test_path_is_*` functions in test scripts + +Find one test script that verifies the presence/absence of +files/directories with 'test -(e|f|d|...)' and replace them with the +appropriate `test_path_is_file`, `test_path_is_dir`, etc. helper +functions. + +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 pipes in git related commands in test scripts + +See the commit +[c6f44e1da5](https://github.com/git/git/commit/c6f44e1da5e88e34) +for example, and then do the same thing in one other test script. + +The git command should be on the left side of the pipe. + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +### Use 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. + +### Unify the meaning of `-dirty` between `diff` and `describe` + +`git diff` reports a submodule directory, whose tracked contents match +the commit at the `HEAD` in the submodule, as `-dirty` when there is an +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 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/links/mentoring/outreachy/Outreachy-23-Microprojects.md b/links/mentoring/outreachy/Outreachy-23-Microprojects.md new file mode 100644 index 000000000..353f179b6 --- /dev/null +++ b/links/mentoring/outreachy/Outreachy-23-Microprojects.md @@ -0,0 +1,113 @@ +--- +layout: default +title: Outreachy Winter 2021-2022 Applicant Microprojects +navbar: false +--- + +## Introduction + +First make sure you read and understand +[our general guidelines and suggestions for microprojects](https://git.github.io/General-Microproject-Information). + +There are some suggestions on how you can find some microprojects on your own in the document. + +## Ideas for microprojects + +### Add more builtin patterns for userdiff + +"git diff" shows the function name corresponding to each hunk after +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...), +the way to find the function name is built-in Git's source code as +regular expressions (see userdiff.c). A few languages are common +enough to deserve a built-in driver, but are not yet recognized. For +example, shell. + +This project requires a very good knowledge of regular expressions. + +It is easy though to find examples of how this can be done by +searching the code base and the mailing list archive, as this has +already been done for a number of languages. + +### Replace a run_command*() call by direct calls to C functions + +See for example what Junio did in +[ffcb4e94d3](https://github.com/git/git/commit/ffcb4e94d3) (bisect: do +not run show-branch just to show the current commit, 2021-07-27). + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +### Use `test_path_is_*` functions in test scripts + +Find one test script that verifies the presence/absence of +files/directories with 'test -(e|f|d|...)' and replace them with the +appropriate `test_path_is_file`, `test_path_is_dir`, etc. helper +functions. + +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 pipes in git related commands in test scripts + +See the commit +[c6f44e1da5](https://github.com/git/git/commit/c6f44e1da5e88e34) +for example, and then do the same thing in one other test script. + +The git command should be on the left side of the pipe. + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +### Use 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. + +### Add --no-sort option for git-for-each-ref + +In "git for-each-ref", `ref_array_sort()` is used to sort ref_array with +sorting options. Even if the user does not provide any `--sort` option, +`ref_default_sorting()` will also provide the default sorting options with +the sort key "refname". + +But it turns out that the ref_array we get through `filter_refs()` is +already sorted by "refname". So providing a `--no-sort` option may +improve the performance of git for-each-ref when we don't provide any +sorting options on the command line. [thread](https://lore.kernel.org/git/YTNpeH+jO0zQgAVT@coredump.intra.peff.net/), +[thread](https://lore.kernel.org/git/YTTARcEvpXWSDfYW@coredump.intra.peff.net/) + +But the `--no-sort` option seems to be disabled in "git for-each-ref", +see "NEEDWORK" hint in `parse_opt_ref_sorting()`. You may need a new +list api to replace the original linked list implementation for ref_sorting. +You can refer to the implementation of this patch: +[thread](https://lore.kernel.org/git/e68635cda515a9cd504c1d7366e9c353ab2adb2e.1629882532.git.gitgitgadget@gmail.com/) + +You can use t/perf for performance testing between upstream and your patches. +[t/perf/README](https://github.com/git/git/blob/master/t/perf/README) diff --git a/links/mentoring/outreachy/Outreachy-Participants.md b/links/mentoring/outreachy/Outreachy-Participants.md new file mode 100644 index 000000000..bd938acee --- /dev/null +++ b/links/mentoring/outreachy/Outreachy-Participants.md @@ -0,0 +1,64 @@ +--- +layout: default +title: Outreachy participants +--- + +This document collects the list of contributors who've contributed +to Git via Outreachy. + +### Winter 2025-2026 + +1. Bello Caleb Olamide [ [blog](https://cloobtech.hashnode.dev/) ] + +### Winter 2024-2025 + +1. Seyi Kuforiji [ [blog](https://seyi-kuforiji-902b48.gitlab.io/) ] [ [retrsopective interview](https://git.github.io/rev_news/2025/08/31/edition-126/#developer-spotlight-seyi-kuforiji) ] +2. Usman Akinyemi [ [blog](https://uniqueusman.hashnode.dev/tag/outreachy) ] [ [retrsopective interview](https://git.github.io/rev_news/2025/07/31/edition-125/#developer-spotlight-usman-akinyemi) ] + +#### References + +- [Rev News - Dec 2024](https://git.github.io/rev_news/2024/12/31/edition-118/) + +### Winter 2023-2024 + +1. Achu Luma [ [blog](https://lumap.gitlab.io/posts/) ] + +#### References + +- [Rev News - Dec 2023](https://git.github.io/rev_news/2023/11/30/edition-105/) + +### Winter 2020-2021 + +1. Sangeeta [ [blog](https://sangu09.github.io) ] +2. Joey Salazar [ [blog](https://jsal.home.blog/) ] +3. Charvi Mendiratta [ [blog](https://charvi-077.github.io/blog/) ] + +#### References + +- [Rev News - Dec 2020](https://git.github.io/rev_news/2020/12/26/edition-70/) + +### Winter 2019-2020 + +1. Heba W. [ [blog](https://medium.com/@heba.waly) ] +2. Miriam Rubio [ [blog](https://mirucam.gitlab.io/outreachy_blog/) ] + +#### References + +- [Rev News - Dec 2019](https://git.github.io/rev_news/2019/12/25/edition-58/) + +### Winter 2018-2019 + +1. Slavica Đukić [ [blog](https://slavicadj.github.io/blog/) ] +2. Tanushree Tumane [ [blog](https://tanu1596.blogspot.com/) ] + +#### References + +- [Rev News - Nov 2018](https://git.github.io/rev_news/2018/11/21/edition-45/) + +### Winter 2017-2018 + +1. Olga Telezhnaia [ [blog](https://medium.com/@olyatelezhnaya) ] + +#### References + +- [Rev News - Nov 2017](https://git.github.io/rev_news/2017/11/22/edition-33/) diff --git a/SoC-2014-Ideas.md b/links/mentoring/soc/SoC-2014-Ideas.md similarity index 97% rename from SoC-2014-Ideas.md rename to links/mentoring/soc/SoC-2014-Ideas.md index a1dababfc..a8d2d840a 100644 --- a/SoC-2014-Ideas.md +++ b/links/mentoring/soc/SoC-2014-Ideas.md @@ -11,7 +11,7 @@ This is the idea page for Summer of Code 2014 for Git and libgit2. It is strongly recommended that students who want to apply to the Git project for the Summer of Code 2014 complete a tiny, code-related "microproject" as part of their application. Please refer to our -[guidelines and suggestions for microprojects](https://git.github.io/SoC-2014-Microprojects.html) +[guidelines and suggestions for microprojects](https://git.github.io/SoC-2014-Microprojects/) for more information. Completing a microproject is not a strict requirement, but we will definitely give more attention to applicants who do so. Doing a microproject will also help get you started in @@ -250,7 +250,7 @@ by allowing the commands to take options. Maybe ``` See [this -discussion](http://thread.gmane.org/gmane.comp.version-control.git/242701) +discussion](https://public-inbox.org/git/530DA00E.4090402%40alum.mit.edu/) on the mailing list for more related ideas. The goal of this project would be (1) to add the infrastructure for @@ -298,9 +298,9 @@ to invalidate the cache correctly in the case that the configuration is changed while `git` is executing. See [this mailing list -thread](http://article.gmane.org/gmane.comp.version-control.git/242952) +thread](https://public-inbox.org/git/53108650.2020708%40alum.mit.edu/) and [this -email](http://article.gmane.org/gmane.comp.version-control.git/243542) +email](https://public-inbox.org/git/20140306194654.GA28203%40sigill.intra.peff.net/) for some discussion about this and related ideas. - Language: C diff --git a/SoC-2014-Microprojects.md b/links/mentoring/soc/SoC-2014-Microprojects.md similarity index 98% rename from SoC-2014-Microprojects.md rename to links/mentoring/soc/SoC-2014-Microprojects.md index 922f5cf9f..f735a8a30 100644 --- a/SoC-2014-Microprojects.md +++ b/links/mentoring/soc/SoC-2014-Microprojects.md @@ -21,14 +21,14 @@ projects](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md) rather than the list below.* Consider [a sample email -thread](http://thread.gmane.org/gmane.comp.version-control.git/239068), +thread](https://public-inbox.org/git/1386590745-4412-1-git-send-email-t.gummerer%40gmail.com/), 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 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-2014-Org-Application.md b/links/mentoring/soc/SoC-2014-Org-Application.md similarity index 99% rename from SoC-2014-Org-Application.md rename to links/mentoring/soc/SoC-2014-Org-Application.md index a3ea432de..f1b9f65a2 100644 --- a/SoC-2014-Org-Application.md +++ b/links/mentoring/soc/SoC-2014-Org-Application.md @@ -31,11 +31,11 @@ GPLv2 ## Logo URL -![Git Logo](/images/logo.png) +![Git Logo](https://git.github.io/images/logo.png) ## Ideas list - + ## Mailing list diff --git a/SoC-2015-Ideas.md b/links/mentoring/soc/SoC-2015-Ideas.md similarity index 85% rename from SoC-2015-Ideas.md rename to links/mentoring/soc/SoC-2015-Ideas.md index 728de697f..512f81e4a 100644 --- a/SoC-2015-Ideas.md +++ b/links/mentoring/soc/SoC-2015-Ideas.md @@ -11,7 +11,7 @@ This is the idea page for Summer of Code 2015 for Git and libgit2. It is required that students who want to apply to the Git project for the Summer of Code 2015 complete a tiny, code-related "microproject" as part of their application. Please refer to our -[guidelines and suggestions for microprojects](https://git.github.io/SoC-2015-Microprojects.html) +[guidelines and suggestions for microprojects](https://git.github.io/SoC-2015-Microprojects/) for more information. Completing a microproject is not only an important way for us to get experience with applicants, but it will also help applicants become familiar with Git's development and submission @@ -48,7 +48,7 @@ proposals for other ideas related to Git or libgit2. ### Tighten configuration and hook execution based on the file ownership. In addition to what we discussed, I think files named by include.path -should be honored without checking the ownership. Cf. +should be honored without checking the ownership. Cf. ### "git apply --fix-mta-corruption". @@ -67,7 +67,7 @@ When your project is strictly "new features are merged into trunk, never the other way around", it is handy to be able to first find a merge on the trunk that merged a topic to point fingers at when a bug appears, instead of having to drill down to the individual -commit on the faulty side branch. Cf. +commit on the faulty side branch. Cf. #### "git bisect fixed/unfixed" @@ -77,33 +77,33 @@ 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". A patch for this feature was sent to the mailing list in this thread a few years ago by Dscho: - + Unfortunately there were some problems with the patch and no one tried to fix them. So the same problem/suggestion is often reported on the mailing list, for example: - - - - - - + - + - + - A patch series to let "old/new" be used instead of "good/bad" was started here: - + There is still work to be done to complete it. Note than another feature with the name "git bisect fix" was suggested to do something else: - + Since there have already been discussions and patches, the remaining work is probably less than a GSoC, so this project should be grouped @@ -133,15 +133,15 @@ formatting, and use it consistently in the three commands. "git config", when removing the last variable in a section, leaves an empty section header behind. Anybody who wants to improve this needs to consider ramifications of leaving or removing comments. -Cf. +Cf. ### "git fetch --deepen"? -Cf. +Cf. ### Introduce threading to checkout codepath, possibly helping Windows folks. -Cf. +Cf. ### Be nicer to the user on tracked/untracked merge conflicts diff --git a/SoC-2015-Microprojects.md b/links/mentoring/soc/SoC-2015-Microprojects.md similarity index 99% rename from SoC-2015-Microprojects.md rename to links/mentoring/soc/SoC-2015-Microprojects.md index b8df3a6ed..de0a0a729 100644 --- a/SoC-2015-Microprojects.md +++ b/links/mentoring/soc/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-2015-Org-Application.md b/links/mentoring/soc/SoC-2015-Org-Application.md similarity index 99% rename from SoC-2015-Org-Application.md rename to links/mentoring/soc/SoC-2015-Org-Application.md index 1f4e70714..edb9ee7cb 100644 --- a/SoC-2015-Org-Application.md +++ b/links/mentoring/soc/SoC-2015-Org-Application.md @@ -31,11 +31,11 @@ GPLv2 ## Logo URL -![Git Logo](/images/logo.png) +![Git Logo](https://git.github.io/images/logo.png) ## Ideas list - + ## Mailing list diff --git a/SoC-2016-Ideas.md b/links/mentoring/soc/SoC-2016-Ideas.md similarity index 96% rename from SoC-2016-Ideas.md rename to links/mentoring/soc/SoC-2016-Ideas.md index 6125ba174..c5044c32c 100644 --- a/SoC-2016-Ideas.md +++ b/links/mentoring/soc/SoC-2016-Ideas.md @@ -113,7 +113,7 @@ should be honored without checking the ownership. Cf. +the end of line, with updates to "am". Cf. ### git bisect improvements @@ -149,7 +149,7 @@ error message if 'fast' is the new term, 'slow' the old one, and if C is 'fast'. Instead of failing, it could offer the user to reverse the terms and continue the bisection. -See discussion on the subject [here](http://thread.gmane.org/gmane.comp.version-control.git/272792/focus=272869). +See discussion on the subject [here](https://public-inbox.org/git/1435337896-20709-1-git-send-email-Matthieu.Moy%40imag.fr/). The change is controversial, hence a substantial part of the project would be to define what is the right behavior (should it be activated @@ -208,11 +208,11 @@ another one to give a proper GSoC project. "git config", when removing the last variable in a section, leaves an empty section header behind. Anybody who wants to improve this needs to consider ramifications of leaving or removing comments. -Cf. +Cf. ### Introduce threading to checkout codepath, possibly helping Windows folks. -Cf. +Cf. ### Be nicer to the user on tracked/untracked merge conflicts @@ -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 @@ -334,7 +334,7 @@ deep understanding of Git: how each command is meant to be used, what are the potential dangers, ... Reaching a solution that effectively protects beginners without harming anyone is much harder than it seems. See for example [this -thread](http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286614) +thread](https://public-inbox.org/git/vpqoabox66p.fsf%40anie.imag.fr/) for example potential objections. If chosen, this project should be discussed in depth on the list before and after the student application. diff --git a/SoC-2016-Microprojects.md b/links/mentoring/soc/SoC-2016-Microprojects.md similarity index 99% rename from SoC-2016-Microprojects.md rename to links/mentoring/soc/SoC-2016-Microprojects.md index 3d3bebda5..54c5184b1 100644 --- a/SoC-2016-Microprojects.md +++ b/links/mentoring/soc/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-2016-Org-Application.md b/links/mentoring/soc/SoC-2016-Org-Application.md similarity index 99% rename from SoC-2016-Org-Application.md rename to links/mentoring/soc/SoC-2016-Org-Application.md index ce4e27a1d..1fbd9b975 100644 --- a/SoC-2016-Org-Application.md +++ b/links/mentoring/soc/SoC-2016-Org-Application.md @@ -18,7 +18,7 @@ fast, scalable, distributed revision control system ## Logo -![Git Logo](/images/Git-Logo-1788C.png) +![Git Logo](https://git.github.io/images/Git-Logo-1788C.png) ## Primary Open Source License diff --git a/SoC-2017-Ideas.md b/links/mentoring/soc/SoC-2017-Ideas.md similarity index 99% rename from SoC-2017-Ideas.md rename to links/mentoring/soc/SoC-2017-Ideas.md index e58e76e42..8aaaa56aa 100644 --- a/SoC-2017-Ideas.md +++ b/links/mentoring/soc/SoC-2017-Ideas.md @@ -1,6 +1,7 @@ --- layout: default title: SoC 2017 Ideas +navbar: false --- This is the idea page for Summer of Code 2017 for Git. diff --git a/SoC-2017-Microprojects.md b/links/mentoring/soc/SoC-2017-Microprojects.md similarity index 99% rename from SoC-2017-Microprojects.md rename to links/mentoring/soc/SoC-2017-Microprojects.md index d74e628c0..ef4a09b3e 100644 --- a/SoC-2017-Microprojects.md +++ b/links/mentoring/soc/SoC-2017-Microprojects.md @@ -1,6 +1,7 @@ --- layout: default title: SoC 2017 Applicant Microprojects +navbar: false --- ## Introduction @@ -32,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 @@ -261,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-2017-Org-Application.md b/links/mentoring/soc/SoC-2017-Org-Application.md similarity index 99% rename from SoC-2017-Org-Application.md rename to links/mentoring/soc/SoC-2017-Org-Application.md index 7837a2de1..580872b40 100644 --- a/SoC-2017-Org-Application.md +++ b/links/mentoring/soc/SoC-2017-Org-Application.md @@ -1,6 +1,7 @@ --- layout: default title: SoC 2017 Organization Application +navbar: false --- This is a draft of git's application to Google's Summer of Code 2017. @@ -17,7 +18,7 @@ fast, scalable, distributed revision control system ## Logo -![Git Logo](/images/Git-Logo-1788C.png) +![Git Logo](https://git.github.io/images/Git-Logo-1788C.png) ## Primary Open Source License diff --git a/SoC-2018-Ideas.md b/links/mentoring/soc/SoC-2018-Ideas.md similarity index 99% rename from SoC-2018-Ideas.md rename to links/mentoring/soc/SoC-2018-Ideas.md index ba1047068..44a80233e 100644 --- a/SoC-2018-Ideas.md +++ b/links/mentoring/soc/SoC-2018-Ideas.md @@ -1,6 +1,7 @@ --- layout: default title: SoC 2018 Ideas +navbar: false --- This is the idea page for Summer of Code 2018 for Git. diff --git a/SoC-2018-Microprojects.md b/links/mentoring/soc/SoC-2018-Microprojects.md similarity index 99% rename from SoC-2018-Microprojects.md rename to links/mentoring/soc/SoC-2018-Microprojects.md index 2febfeb0d..8a33938ff 100644 --- a/SoC-2018-Microprojects.md +++ b/links/mentoring/soc/SoC-2018-Microprojects.md @@ -1,6 +1,7 @@ --- layout: default title: SoC 2018 Applicant Microprojects +navbar: false --- ## Introduction @@ -32,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-2018-Org-Application.md b/links/mentoring/soc/SoC-2018-Org-Application.md similarity index 99% rename from SoC-2018-Org-Application.md rename to links/mentoring/soc/SoC-2018-Org-Application.md index d78ad47ff..3b39c6d11 100644 --- a/SoC-2018-Org-Application.md +++ b/links/mentoring/soc/SoC-2018-Org-Application.md @@ -1,6 +1,7 @@ --- layout: default title: SoC 2018 Organization Application +navbar: false --- This is a draft of git's application to Google's Summer of Code 2018. @@ -17,7 +18,7 @@ fast, scalable, distributed revision control system ## Logo -![Git Logo](/images/Git-Logo-1788C.png) +![Git Logo](https://git.github.io/images/Git-Logo-1788C.png) ## Primary Open Source License diff --git a/links/mentoring/soc/SoC-2019-Ideas.md b/links/mentoring/soc/SoC-2019-Ideas.md new file mode 100644 index 000000000..da3b6c8f3 --- /dev/null +++ b/links/mentoring/soc/SoC-2019-Ideas.md @@ -0,0 +1,309 @@ +--- +layout: default +title: SoC 2019 Ideas +navbar: false +--- + +This is the idea page for Summer of Code 2019 for Git. + +## About applying for SoC with the Git project + +*Please read this section completely before reading the idea list + below.* + +It is required that students who want to apply to the Git +project for the Summer of Code 2019 complete a tiny, code-related +"microproject" as part of their application. Please refer to our +[guidelines and suggestions for microprojects](https://git.github.io/SoC-2019-Microprojects) +for more information. Completing a microproject is not only an important +way for us to get experience with applicants, but it will also help +applicants become familiar with Git's development and submission +process. + +A complete GSoC application should include a presentation of yourself +(include any argument that may convince mentors that you are able to +complete the project) and detailed explanations about your project. +Ideas below are just ... ideas! The list is not exhaustive, and more +importantly each idea only includes a summary of what is to be done. +An application must include detailed plans on the design, timeline ... +A typical application takes several pages. You should already have read +[the GSoC Student Guide](http://write.flossmanuals.net/gsocstudentguide/writing-a-proposal/) +by now, but re-read it if needed. + +Also, working in Git project is not only about writing your own +patches. Constructively critiquing design and implementation of +patches by other people is also an important skill you need to learn +in order to effectively collaborate with others. So, if you have time +and inclination, it would be beneficial to read and understand other +applicants' patches (or any other patch submitted to the mailing-list), +think if you agree that the problem they are trying to solve is worth +solving, the approach they are taking is the best way (or if you think +of a better way to solve it), etc., and respond to their patches with +the result of your thinking as a review. + +Please, include link(s) to the mailing-list discussion(s) related to +your microproject in your application (e.g. linking to +[public-inbox](https://public-inbox.org/git/)). If you +participate in the review of other patches, then you may also include +links to discussions that would support your application. + +Students must send drafts of their proposal on the mailing-list before +submitting it officially to GSoC to get feedback from the +community. They are strongly encouraged to publish a draft on the +official GSoC website *and* post it to the mailing list for +discussion. + +Getting your proposal right can follow the same process as usual patch +submission for Git, as described in the +[microprojects](https://git.github.io/SoC-2019-Microprojects) page and +in `Documentation/SubmittingPatches` in Git's source code. It is also +expected that you will send several versions of your draft, responding +to comments on the list. Please plan to send the first draft early +enough so that a number of reviews and improvements cycles can happen. + +If you are not sure about your proposal, you can discuss that in the +same email where you introduce yourself or in separate emails. Please +use "[GSoC]" at the beginning of such emails. + +In summary, all applicants must (not necessarily in this order): + +* Complete a [microproject](https://git.github.io/SoC-2019-Microprojects). + +* Write a detailed application explaining their project. + +* Discuss their project by posting drafts of their application on the + mailing-list long before the deadline. + +In your application, and in the discussions related to projects you +are interested in, it is a good idea to: + +* Include link(s) to the mailing-list discussion(s) related to the + project you chose in your application or you are interested in, for + example previous discussions or patch series about the topic. There + might be interesting discussions about the topics that are several + year old. It is also a good idea to summarize them. + +* Include link(s) to the mailing-list discussion(s) related to the + previous drafts of your application itself. + +* Include link(s) to the mailing-list discussion(s) related to your + microproject. If your microproject patches have been merged, please + give the merge commits. Otherwise give their branch names and + current status in the last "What's cooking in git.git" email from + Junio. + +* Include what is suggested in + [the GSoC Student Guide](http://write.flossmanuals.net/gsocstudentguide/writing-a-proposal/) + +([public-inbox](https://public-inbox.org/git/) can be +used for searching the mailing list and linking to previous +discussions.) + +## Note about the number of slots + +In 2019, the Git organization has very limited mentoring capacity. +These days we usually accept between 0 and 3 students per year. + +## 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. Read the note below about refactoring +projects versus projects that implement new features though. + +### Unify ref-filter formats with other `--pretty` formats + + - Language: C, shell (bash) + - Difficulty: medium + - Possible mentors: Christian Couder, Olga Telezhnaya, Thomas Gummerer + +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 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 +[pretty](https://github.com/git/git/blob/master/pretty.h). + +See discussion in: + + + +### `git log --oneline` improvements + + - Language: C, shell (bash) + - Difficulty: medium + - 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.adoc). +Such formats though don't yet support some features that users would +like, for example to display a log like the following: + +``` + b9df16a4c (HEAD -> master) + pathspec: don't error out on all-exclusionary pathspec patterns + 91a491f05 pathspec magic: add '^' as alias for '!' + c8e05fd6d ls-remote: add "--diff" option to show only refs that differ + 20769079d (tag: v2.12.0-rc2, origin/master, origin/HEAD) + Git 2.12-rc2 + 076c05393 Hopefully the final batch of mini-topics before the final +``` + +See discussions in: + + + + +### Convert scripts to builtins + + - Language: C, shell (bash), possibly Perl + - Difficulty: medium + - Possible mentors: Christian Couder, Thomas Gummerer + +A few components of Git are still in the form of shell and sometimes +Perl scripts. This causes problems in production code – in particular +on multiple platforms, e.g. Windows (think: POSIX-to-Windows path +conversion issues). + +The idea of this project is to dive into the Git source code and +convert a couple of shell and/or Perl scripts into portable and +performant C code, making it a so-called "built-in". + +(Un)fortunately, the important and easy to port scripts like +`git-pull.sh` are already ported by now. It should still be possible +to start with something small by porting portions of existing +shell-scripts to C using a C helper inside the existing shell-script. + +It will be an important part of the project to discuss and find the +most interesting scripts or parts of scripts to be ported. + +### Improve consistency of sequencer commands + + - Language: C, shell (bash) + - Difficulty: medium + - Possible mentors: Elijah Newren, Christian Couder, Thomas Gummerer + +This would consist in taking care of the following issues: + +* The suggestion to fix an interrupted rebase-i or cherry-pick due to + a commit that became empty via `git reset HEAD` (in + builtin/commit.c) instead of `git rebase --skip` or + `git cherry-pick --skip` ranges from annoying to confusing. + (Especially since other interrupted am's and rebases both point to + am/rebase --skip.). Note that `git cherry-pick --skip` is not yet + implemented, so that would have to be added first. + +* There are a handful of flags that am-based rebases support that are + not available to interactive/merge-based rebases; it'd be nice to + implement them for the interactive machinery. (There are also + numerous flags that only the interactive machinery supports that are + unavailable to am-based rebases, but we don't care; we want to + deprecate am-based rebases.) + + * `--ignore-whitespace` (transliterate to `-Xignore-space-change`?) + * `--whitespace=...` + * `--committer-date-is-author-date`/`--ignore-date` + * `-C4` + +* [There's also some empty handling (from "Behavioral Differences" in + Documentation/git-rebase.txt) that would be nice to address, though + that might be contentious and we might try to tackle that piece + before GSoC gets rolling...] + +* Bonus: Make a flag to allow rebase to rewrite commit messages that + refer to older commits that were also rebased. (i.e. if rebasing + commits A and B, and commit B says `This reverts commit `, + then rewritten B's commit message should say + `This reverts commit `.) + Do this for both sha1sums and sha1sum abbreviations in commit messages. + +### `git revert --drop` and `git commit --reword` + + - Language: C, shell (bash) + - Difficulty: medium + - Possible mentors: Thomas Gummerer + +The interactive rebase already supports the special oneline prefixes +`fixup!` and `squash!` in the `--autosquash` mode; these commits will +be reordered in the todo list and their `pick` commands adjusted +accordingly. + +These commits can be crafted conveniently via the `--fixup` and +`--squash` options of `git commit`. + +The idea of this project is to add two more actions, `drop!` and +`reword!`: + +* The `drop!` action (for convenience, `git revert --drop `) + would not only revert the commit, but a subsequent `git rebase -i + --autosquash` would reorder the `drop!` commit directly after the + matching commit, then change the matching commit's `pick` to `drop` + and comment out the `drop!` one. + +* The `reword!` action (for convenience, `git commit --reword `) + would let the user edit the commit message of the referenced commit, + and add an "empty" commit (i.e. a commit that does not modify any + files) with that commit message, prefixed with the `reword!` oneline. + The next `git rebase -i --autosquash` would then not only reorder + that commit after verifying that it is indeed an empty commit, it + would then also replace the `pick` command with an appropriate new + command (say, by extending the `squash` command to accept a `--reword` + option). + +This project will need to begin by implementing test cases to define +the expected outcome, and then implement the actual functionality. + +### Teach `git stash` to handle unmerged index entries + + - Language: C, shell (bash) + - Difficulty: medium + - Possible mentors: Thomas Gummerer + +When the index is unmerged, `git stash` refuses to do anything. That is +unnecessary, though, as it could easily craft e.g. an octopus merge +of the various stages. A subsequent `git stash apply` can detect that +octopus and re-generate the unmerged index. + +See also the discussion in [this Git mailing list +thread](https://public-inbox.org/git/nycvar.QRO.7.76.6.1902072023250.41@tvgsbejvaqbjf.bet/). + +## Note about refactoring projects versus projects that implement new features + +Over the years we have been favoring refactoring projects over +possibly more interesting projects that implement new features. +Refactoring projects are usually easier to do step by step, and to get +code merged step by step which is encouraging. + +In general refactoring projects are worthwhile to do even if the +project is not finished at the end of the GSoC and even if the student +stops contributing after that. In those cases it is often a good idea +to later finish the refactoring either by ourselves or by proposing it +to another GSoC student or Outreachy intern. This way the work of both +students and mentors is not likely to be wasted. + +With a project that implements a feature, there is a risk, if it's too +complex or too difficult, that the feature will not be finished and +that nothing, or nearly nothing, will have been merged during the +GSoC. There is also the risk that another way to implement the feature +will appear later in the GSoC and all, or nearly all, the work of the +student and mentors will have been mostly wasted. It could also appear +that the use cases the feature was envisioned to be used in, are +better addressed by other improvements or a different workflow. + +Another potential issue is that a new feature might be prone to naming +or user interface discussions which could last for a long time or +could not result in clear decisions. + +Therefore we think that we should be very careful before proposing to +a student, or accepting, a project that implements a new feature. +People suggesting such a project should at least carefully consider +the above potential issues and see if they can be mitigated before the +project is submitted. + +As [suggested by Google](https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list) +we emphasize that a student proposing something original must engage +with the community strongly before and during the application period +to get feedback and guidance to improve the proposal and avoid the +above potential issues. diff --git a/links/mentoring/soc/SoC-2019-Microprojects.md b/links/mentoring/soc/SoC-2019-Microprojects.md new file mode 100644 index 000000000..9bec90f90 --- /dev/null +++ b/links/mentoring/soc/SoC-2019-Microprojects.md @@ -0,0 +1,284 @@ +--- +layout: default +title: SoC 2019 Applicant Microprojects +navbar: false +--- + +## Introduction + +It is strongly recommended that students who want to apply to the Git +project for the Summer of Code 2019 submit a small code-related patch +to the Git project as part of their application. Think of these +microprojects as the "Hello, world" of getting involved with the Git +project; the coding aspect of the change can be almost trivial, but to +make the change the student has to become familiar with many of the +practical aspects of working on the Git project. + +Git development is based on sending successive versions of patches or +patch series to the mailing list until they are considered good and +correct by the reviewers and Junio Hamano, the maintainer, who will +merge them. This process usually takes quite some time. By sending +drafts of your microproject patches to the +mailing list long before the deadline, you can show us that you are +willing and able to work 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]" at the beginning of its subject. + +Consider [a sample email thread](http://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 student, you will be playing +the role of the developer and engaging in a similar discussion. Get +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 +discussion, to learn what is expected of you. + +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 + the `README` file. + +* Build the source code: this is described in the file `INSTALL`. + +* Glance over our coding guidelines in the file + `Documentation/CodingGuidelines`. We take things like proper code + formatting very seriously. + +* Read about the process for submitting patches to Git: this is + described in `Documentation/SubmittingPatches`. + +* Select a microproject and check that it has not yet been taken or + discussed by searching the mailing list. + [Public Inbox](http://public-inbox.org/git/) is your friend. + +* Send an email to the mailing list where you describe the + microproject you want to work on, the way you want to do it, and + maybe talk a bit about yourself. Make sure the email you send has a + subject that starts with "[GSoC]". + +* **Make the actual change.** (Funny, this is the only part they teach + you about in college.) + +* Run the test suite and make sure it passes 100%: this is described + in the file `t/README`. (If you have added new functionality, you + should also add new tests, but most microprojects will not add new + functionality.) + +* 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 + Git. Make sure to write a good commit message that explains the + reason for the change and any ramifications. 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. + +* *Optional, but recommended:* + Create a fork of [Git](https://github.com/git/git) on github.com, + [sign in to Travis CI](https://travis-ci.org/auth) with your GitHub + account, accepting the GitHub + [access permissions confirmation](https://docs.travis-ci.com/user/github-oauth-scopes), + and enable builds of your Git fork in your Travis CI profile + (you only have to do these steps once). Afterwards you can push + your changes to your fork and on https://travis-ci.org/your-github-name/git/builds + (example [here](https://travis-ci.org/git/git/builds)) you can see + if your changes pass the Git test suite on Ubuntu Linux and on Mac OS X. + +* Submit your change to the Git mailing list. For this step you + probably want to use the commands `git format-patch` and `git + send-email`. Make sure that your email is formatted correctly: send + a test version of the email to yourself and see if you can apply it + to your repository using `git am`. Alternatively you may use + [GitGitGadget](https://gitgitgadget.github.io/) or + [submitGit](https://submitgit.herokuapp.com/). + + When you submit your patch, please mention that you plan to apply + for the GSoC. You can use "[GSoC][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. + +* Expect feedback, criticism, suggestions, etc. from the mailing list. + + *Respond to it!* and follow up with improved versions of your + change. Even for a trivial patch you shouldn't be surprised if it + takes two or more iterations before your patch is accepted. *This + is the best part of participating in the Git community; it is your + chance to get personalized instruction from very experienced peers!* + +The coding part of the microproject should be very small (say, 10-30 +minutes). We don't require that your patch be accepted into master by +the time of your formal application; we mostly want to see that you +have a basic level of competence and especially the ability to +interact with the other Git developers. + +## Only ONE quality focused microproject per student + +Students, please attempt only **ONE** microproject. We want quality, +not quantity! (Also, it takes work to collect the ideas, and it would +be nice to have enough microprojects for everybody.) + +This means that for a microproject that consist in refactoring or +rewriting a small amount of code, your patch should change only +**ONE** file, or perhaps 2 files if they are closely related, like +"foo.c" and "foo.h". + +If you change a test file, the title of your patch should start with +"tXXXX: " where tXXXX is the start of the filename of the test script +you change. If you change "foo.c" or "foo.h", the title of your patch +should probably start with "foo: ". + +In general it's a good idea to check on the mailing list archive what +other GSoC students 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 changed for years, +some microprojects might have been attempted many times already and +you can learn a lot from these attempts. + +The more you research your microproject and take advantage of that, +the more confident we can be that you will be able to solve many +problems when working on your real GSoC project. So it's a very good +thing to show that you have researched your microproject and taken +into account what you have found. + +If you've already done a microproject and are itching to do more, then +get involved in other ways, like finding and fixing other problems in +the code, or improving the documentation or code comments, or helping +to review other people's patches on the mailing list, or answering +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](https://git.github.io/SoC-2019-Ideas). + +## Ideas for microprojects + +The following are just ideas. Any small code-related change would be +suitable. Just remember to keep the change small! It is much better +for you to finish a small but complete change than to try something +too ambitious and not get it done. + +### 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. + +### Use `test_path_is_*` functions in test scripts + +Find one test script that verifies the presence/absence of +files/directories with 'test -(e|f|d|...)' and replace them with the +appropriate `test_path_is_file`, `test_path_is_dir`, etc. helper +functions. + +### Avoid pipes in git related commands in test scripts + +See the commit +[c6f44e1da5](https://github.com/git/git/commit/c6f44e1da5e88e34) +for example, and then do the same thing in one other test script. + +### 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. + +### Add configuration options for some commonly used command-line options + +Many have already been added (e.g. "git am -3" in e97a5e7). + +Some people always run the command with these options, and would +prefer to be able to activate them by default in ~/.gitconfig. + +### Use dir-iterator to avoid explicit recursive directory traversal + +Some places in git use raw API opendir/readdir/closedir to traverse a +directory recursively, which usually involves function recursion. Now +that we have `struct dir_iterator` (see dir-iterator.h), convert these +to use the dir-iterator to simplify the code. Do only one conversion +per microproject. + +## How to find other ideas for microprojects + +If you don't like for some reason the above microprojects or if you +just want more choice, you may find other ideas for microprojects by +searching the mailing list (https://public-inbox.org/git/) or the +code base itself. In the code base you could search the code itself or +the tests (in the "t" directory). + +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 straightforward, there could be hidden reasons why it is too +difficult or just inappropriate. + +### Searching for #leftoverbits in the mailing list + +People have recently started to add "#leftoverbits" to their emails +when they think further small work on the topic could be useful. + +You can easily search that using: + +https://public-inbox.org/git/?q=leftoverbits + +But don't forget to search to check if what you find has already been +addressed. If it has not been addressed, please ask first on the +mailing list if it's a good idea to work on that. + +### Searching the code base itself + +Your best bet is probably to search for strings like "FIXME", "TODO", +"NEEDSWORK", or maybe "NEED-WORK", and "BUG" (though not the "BUG()" +macro). + +You can also search for common patterns in the code and try to find or +create a function to refactor them. + +### Searching the tests + +Tests are in the "t" directory and can be run by launching "make" in +this directory. Doing that you will see that there are a number of +tests that are marked with "# TODO known breakage", like for example: + +"not ok 28 - git checkout -f: replace submodule with a directory must fail # TODO known breakage + +These tests start with "test_expect_failure" instead of +"test_expect_success". They document that something is not working as +it should perhaps be working. And it might be an interesting +microproject to fix that. + +Note that it is especially wise to first search the mailing list and +then ask on the list before working on one of these +"test_expect_failure", because if we bothered to document a failure +but not fix it, that is often because the fix is non-trivial. + +You could also check if some commands have no test for some of their +options and it could be an interesting microproject to add a test for +one of those options. + +### Searching the mailing list for other ideas + +You can search the mailing list for words like "low hanging fruit", or +"low-hanging fruits", "hint, hint", "later", "we should", "I plan +to"... diff --git a/links/mentoring/soc/SoC-2019-Org-Application.md b/links/mentoring/soc/SoC-2019-Org-Application.md new file mode 100644 index 000000000..e03fec155 --- /dev/null +++ b/links/mentoring/soc/SoC-2019-Org-Application.md @@ -0,0 +1,290 @@ +--- +layout: default +title: SoC 2019 Organization Application +navbar: false +--- + +This is a draft of git's application to Google's Summer of Code 2019. + +# Git Profile + +## Website URL + + + +## Tagline + +fast, scalable, distributed revision control system + +## Logo + +![Git Logo](https://git.github.io/images/Git-Logo-1788C.png) + +## Primary Open Source License + +GPLv2 + +## Organization Category + +Programming Languages and Development Tools + +## Technology Tags + +c, shell script, git + +## Topic Tags + +version control, dvcs + +## Ideas List + + + +## Short Description (180 chars max) + +Git is the most widely-used revision control system in Open Source. It +is a distributed system with an emphasis on speed, data integrity, and +support for many workflows. + +## Long Description + +Git is the most widely-used revision control system in Open Source. It +is a distributed system with an emphasis on speed, data integrity, and +support for distributed, non-linear workflows. + +Many large and successful projects use Git, including the Linux +Kernel, Perl, Eclipse, Gnome, KDE, Qt, Ruby on Rails, Android, +PostgreSQL, Debian, and X.org. + +This organization covers projects for +[Git](https://github.com/git/git) itself. Other git-based software or +services are not covered by this organization. + +## Application Instructions + +``` +Guidance for students on how to apply to your organization. Should +include any prerequisites or requirements. You may wish to include a +template or tips for their proposals. May include limited Markdown. +``` + +Please read the "About applying for SoC with the Git project" section +in the ideas page: https://git.github.io/SoC-2019-Ideas/ + +The primary way to contact the Git community is through the Git +mailing list git@vger.kernel.org. Please discuss your application on +this list. + +## Proposal Tags + +``` +Enter tags that students can select (one) from and apply to their own +proposals to help organize them. Examples: New Feature, Optimization. +You can also use these to designate "sub-organizations" if you are an +umbrella organization. +``` + +new feature, refactoring, bug fix + +## Contact Methods + +``` +You must complete at least one of the following three contact options. +``` + +Chat: http://git-scm.com/community + +Mailing List: http://git-scm.com/community + +General Email: git@vger.kernel.org + +# 2019 Application Form + +## Why does your org want to participate in Google Summer of Code? + +With the exception of 2013, Git has participated in GSoC every year +since 2007. We have appreciated not only the code contributions (both +new features and internal refactoring to reduce the maintenance effort), but +also the increased project visibility and the addition of new long-term +contributors. We also believe strongly in helping students become +comfortable contributing to open source in general, even if they do not +remain involved with Git itself. + +## How many potential mentors have agreed to mentor this year? + +dropdown list => 1-5. + +Text below unused: + +``` +We have 3 potential co-mentors this year. This is a small number, and +we expect to take a correspondingly smaller number of projects +(probably only 1). + +All mentors are volunteers for the specific projects that they can +contribute the most to (i.e., ones that meet their interests and +abilities). All mentors are active contributors within the Git +development community, and well-known to the project leadership. + +Active contributors are defined to be those who have submitted and have +had accepted into a shipped release a substantial amount of code, where +substantial is defined to be equal to or larger than what might be +expected of a student working on a Google Summer of Code project. +``` + +## How will you keep mentors engaged with their students? + +``` +1000 characters. +``` + +We think that the most important part of GSoC is integrating the +student into the normal communication channels used by other project +members. The first step in dealing with disappearing students is to +make sure they are engaging with the community on design and code +issues, and reaching small milestones on the way to the project. Then +if they do disappear, we know quickly and can react, rather than being +surprised at the end. + +If they do disappear, we'll obviously contact them and find out +what's going on. But ultimately, non-communication is grounds for a +failing evaluation, regardless of any code produced. + +We plan to take fewer projects than we have as mentors. We usually +have two co-mentors per students, so that one mentor being unavailable +would have a limited impact on the project. Most of our projects can +be mentored by any of the mentors, and by keeping student progress +public and reviewed on-list, another mentor (or the community at +large) can pick up the slack if needed. + +## How will you help your students stay on schedule to complete their projects? + +``` +1000 characters. +``` + +There are several ways to do this, and they have been successful in +the past: + +* Prepare students to submit patches before they started. We use a + microproject system prior to the student application where students + must submit at least a patch, and respond to reviews. This means + that on day 1 of their project, students already know how long + review cycles are, and how important it is to work with the + mailing-list. + +* Split the work into small patch series. We don't expect regular + developers to go silent for 3 months and then dump 10,000 lines of + code on us to review, and we don't want students to do that to us + either. Even if the first patch series are only preparatory steps + that do not bring a real added value to Git, it is important to get + them merged as early as possible. Even if the project is not + "completed", useful pieces of code are validated all along the + project. + +## How will you get your students involved in your community during GSoC? + +``` +1000 characters. +``` + +Students will be required to join the main development mailing list +and post their patches for discussion (in addition to posting their +work as a Git repository on a publicly available server). All current +contributors already do this, so students will be able to see +experienced hands performing the same tasks and learn by example. We +also feel that the list-based discussions will help the student to +become and stay a member of the community. + +Mentors will also exchange direct email with students on at least a +weekly basis. Students will be required to provide weekly progress +reports back to their mentors, so that mentors are aware of the +current difficulties. Progress reports give the mentors a chance to +provide suggestions for problem resolution back to the student. + +Frequent email and IRC interaction with mentors and other developers +will be strongly encouraged by suggesting students post their questions +and ideas to the mailing list, and to discuss them on #git. + +``` +Unused text (did not fit the characters limit): + + +The traffic on the list is focused around Git development. We +expect the students to stay current by at least skimming the messages, +and participating in discussions that are close to their area of work. + +Many developers either already hold "office-hours" on IRC, or have +agreed to do so during the GSoC period. +``` + +## How will you keep students involved with your community after GSoC? + +Ultimately we have no leverage over the students after they leave, so +the best we can do is to help them form habits of interaction that they +might find rewarding and want to continue with. We specifically don't +want to give the student a "half project" that needs more work after the +GSoC period is done. That's not fair to the student, nor to the project. + +Instead, we'd prefer to get the student involved in the day-to-day of +interacting on the mailing list, reviewing code, and commenting on other +people's ideas and problems. Those are things they can continue to do +after GSoC ends, and those discussions can often spur more coding. + +## Has your org been accepted as a mentoring org in Google Summer of Code before? + +### Has your org been accepted as a mentoring org in Google Summer of Code before? + +Yes + +### Which years did your org participate in GSoC? + +Every year since 2007 except 2013. + +### What is your success/fail rate per year? + +``` +500 characters +``` + +Here are the numbers of passed (p), failed (f) and retained (r) students (where "retained" means "still participating on the mailing list a year or more after their GSoC") for each year: + + - 2007: 2 p, 1 f, 1 r + - 2008: 4 p, 2 f, 3 r + - 2009: 1 p, 1 f, 0 r + - 2010: 3 p, 1 f, 3 r + - 2011: 5 p, 0 f, 4 r + - 2012: 3 p, 0 f, 2 r + - 2014: 2 p, 1 f, 0 r + - 2015: 2 p, 0 f, 2 r + - 2016: 1 p, 0 f, 1 r + - 2017: 1 p, 0 f, 1 r + - 2018: 3 p, 0 f, 2 r + +### If your org has applied for GSoC before but not been accepted, select the years: + +None. + +## Provide a reference (optional) + + + +## What year was your project started? + +2005 + +## Where does your code live: + +http://github.com/git/git + +## Anything else we should know (optional)? + +We sometimes write about the GSoC in our Git Rev News newsletter +(https://git.github.io/rev_news/archive/). + +# Remarks on the current state of the application + +The 2015 application had a question "If you chose "veteran" in the +organization profile dropdown, please summarize your involvement and +the successes and challenges of your participation. Please also list +your pass/fail rate for each year." with a very detailed answer. diff --git a/links/mentoring/soc/SoC-2020-Ideas.md b/links/mentoring/soc/SoC-2020-Ideas.md new file mode 100644 index 000000000..ce6d43cd6 --- /dev/null +++ b/links/mentoring/soc/SoC-2020-Ideas.md @@ -0,0 +1,241 @@ +--- +layout: default +title: SoC 2020 Ideas +navbar: false +--- + +This is the idea page for Summer of Code 2020 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. + +### Unify ref-filter formats with other `--pretty` formats + + - Language: C, shell (bash) + - Difficulty: medium + - Possible mentors: Christian Couder + +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 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 +[pretty](https://github.com/git/git/blob/master/pretty.h). + +See discussion in: + + + +### `git log --oneline` improvements + + - Language: C, shell (bash) + - Difficulty: medium + - Possible mentors: Christian Couder + +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.adoc). +Such formats though don't yet support some features that users would +like, for example to display a log like the following: + +``` + b9df16a4c (HEAD -> master) + pathspec: don't error out on all-exclusionary pathspec patterns + 91a491f05 pathspec magic: add '^' as alias for '!' + c8e05fd6d ls-remote: add "--diff" option to show only refs that differ + 20769079d (tag: v2.12.0-rc2, origin/master, origin/HEAD) + Git 2.12-rc2 + 076c05393 Hopefully the final batch of mini-topics before the final +``` + +See discussions in: + + + + +### Convert scripts to builtins + + - Language: C, shell (bash), possibly Perl + - Difficulty: medium + - Possible mentors: Christian Couder + +A few components of Git are still in the form of shell and sometimes +Perl scripts. This causes problems in production code – in particular +on multiple platforms, e.g. Windows (think: POSIX-to-Windows path +conversion issues). + +The idea of this project is to dive into the Git source code and +convert a couple of shell and/or Perl scripts into portable and +performant C code, making it a so-called "built-in". + +It will be an important part of the project to discuss and find the +most interesting scripts or parts of scripts to be ported. + +See discussion in: + + + +### Commit graph labeling for speeding up git commands + + - Language: C + - Difficulty: hard + - Possible mentors: Jakub Narębski + - Possible co-mentors: Heba Waly, Derrick Stolee + +Git uses various clever methods for making operations on very large +repositories faster, from bitmap indices for `git fetch`[[1][]], to generation +numbers (also known as topological levels) in the commit-graph file for +commit graph traversal operations like `git log --graph`[[2][]]. + +Unfortunately it turned out that we can get worse performance when +using those generation numbers than without them, with using +committerdate as a heuristics[[8][],[3][]] (and for selecting which +commits to walk first). It can lead to a large increase in number of +commits walked. The example we saw in the Linux kernel repository was +a bug fix created on top of a very old commit, so there was a commit +of low generation with very high commit-date that caused extra +walking. (See [[9][]] for a detailed description of the data shape in +this case.) + +Therefore the need for **generation number v2** was born. Various +candidates were examined (see e.g. +for initial list). New generation number needed to provide good +performance, incremental updates, and (due to unfortunate +problem[[10][],[3][]]) also backward compatibility. + +The generation number v2 that fulfills those requirements is 'backward +compatible date ceiling' or 'corrected commit date with monotonically +increasing offsets[[11][],[3][]]. What is stored in the commit-graph +in place of generation number is value of date offset; it is chosen to +be at least 1 more than maximum offsets of the parents of the commit, +while committerdate+offset (corrected commit date) also meets this +condition. + +The task would be then to update the generation number to "v2" based +on the referenced definition. A part of this task would be moving the +`generation` member of `struct commit` into a slab before making it a +64-bit value. (To learn how to store data on a slab one can see +ongoing work on adding Bloom filter for changed files to the commit +graph [[12][]].) This part could be done with help of [Coccinelle][] +scripts, like the ones in [`contrib/coccinelle`](https://github.com/git/git/tree/master/contrib/coccinelle). + +Another part of this task could be examining performance +improvements, like in +(perhaps extending it with `--contains`/`--merged` test). + +An _alternative_ would be examining other possible improvements that +can make Git even faster than just using generation numbers, like +using min-post **intervals labeling**[[3][]]. The basis of this +labeling is post-visit order of a depth-first search (DFS) traversal +tree of a commit graph, let's call it 'post(v)'. + +If for each commit 'v' we would compute and store in the commit-graph +file two numbers: 'post(v)' and the minimum of 'post(u)' for all commits +reachable from 'v', let's call the latter 'min_graph(v)', then the +following condition is true: + +> if 'v' can reach 'u', then min_graph(v) <= post(u) <= post(v) + +This labeling can be used to quickly find which commits are +unreachable (it is so called negative-cut filter). + +If for each commit 'v' we would compute and store in the commit-graph +file two numbers: 'post(v)' and the minimum of 'post(u)' for commits +that were visited during the part of depth-first search that started +from 'v' (which is the minimum of post-order number for subtree of a +spanning tree that starts at 'v'), let's call the later 'min_tree(v)', +then the following condition is true: + +> if min_tree(v) <= post(u) <= post(v), then 'v' can reach 'u' + +This labeling can be used to quickly find which commits are +reachable, because if they are reachable in the spanning tree for +commit graph, then they are reachable in commit graph itself. (Such +labeling is called positive-cut filter). + +The task would be to implement computing such labeling (or a more +involved variant of it, for example as described in [[4][],[5][],[6][]]), store it +in the commit-graph file, and then use it for speeding up git +commands, such as[[3][]]: + + - `git merge-base --is-ancestor` + - `git branch --contains` + - `git tag --contains` + - `git branch --merged` + - `git tag --merged` + - `git merge-base --all` + - `git log --topo-sort` + +Before starting on this task, at the beginning of the GSoC, it might +be good idea to have an exploration period, to determine which methods +brings which performance improvements. This _could_ be done with the +help of "Reachability labels for version control graphs.ipynb" Jupyter +Notebook on Google Colaboratory[[6][]] (in Python). This notebook was +created to answer such questions, though the exploration didn't get +finished. It would be possible with this notebook to at least find +the amount of false negatives for min-post interval labeling in +git.git or Linux kernel repo. Alternatively this could be done by +creating prototypes and perhaps examining performance in portable and +repeatable way using [trace2 API][api-trace2], like it was done +for [gen-test][] (experimenting with candidates for generation number +v2, see above). + +One can start this task with using min-post interval labeling for +making selected single command faster, for example for `--contains` +queries (as it was done for generation numbers). + +Next task would be, time permitting, to make it possible to update the +labeling without recomputing it from scratch, and to make it +compatible with incremental update of the commit-graph file[[7][],[3][]]. + +References: + +1. +2. +3. + - + - +4. + section 3.3 "Pruning Based on DFS Numbering" +5. and +6. +7. +8. +9. +10. +11. +12. + +[1]: https://githubengineering.com/counting-objects/ "Counting Objects | The GitHub Blog" +[2]: https://devblogs.microsoft.com/devops/supercharging-the-git-commit-graph-iii-generations/ "Supercharging the Git Commit Graph III: Generations and Graph Algorithms | Azure DevOps Blog" +[3]: https://drive.google.com/open?id=1psMBVfcRHcZeJ7AewGpdoymrEfFVdXoK "Graph operations in Git version control system (PDF)" +[4]: https://arxiv.org/abs/1404.4465 "[arXiv:1404.4465] PReaCH: A Fast Lightweight Reachability Index using Pruning and Contraction Hierarchies" +[5]: https://arxiv.org/abs/1211.3375 "[arXiv:1211.3375] High-Performance Reachability Query Processing under Index Size Restrictions" +[6]: https://colab.research.google.com/drive/1V-U7_slu5Z3s5iEEMFKhLXtaxSu5xyzg "Reachability labels for version control graphs.ipynb | Colaboratory" +[7]: https://devblogs.microsoft.com/devops/updates-to-the-git-commit-graph-feature/ "Updates to the Git Commit Graph Feature | Azure DevOps Blog" +[8]: https://git.github.io/rev_news/2018/11/21/edition-45/#general "Git Rev News: Edition 45 (November 21st, 2018) :: [RFC] Generation Number v2" +[9]: https://lore.kernel.org/git/efa3720fb40638e5d61c6130b55e3348d8e4339e.1535633886.git.gitgitgadget@gmail.com/ "[PATCH 1/1] commit: don't use generation numbers if not needed" +[10]: https://git.github.io/rev_news/2019/06/28/edition-52/#reviews "Git Rev News: Edition 52 (June 28th, 2019) :: [PATCH 00/17] [RFC] Commit-graph: Write incremental files" +[11]: https://lore.kernel.org/git/86o8ziatb2.fsf_-_@gmail.com/ "[RFC/PATCH] commit-graph: generation v5 (backward compatible date ceiling)" +[12]: https://public-inbox.org/git/pull.497.git.1576879520.gitgitgadget@gmail.com/t/#u "[PATCH 0/9] [RFC] Changed Paths Bloom Filters" + +[Coccinelle]: http://coccinelle.lip6.fr/ "Coccinelle: A Program Matching and Transformation Tool for Systems Code" +[api-trace2]: https://git-scm.com/docs/api-trace2 "Trace2 API | Documentation/technical/api-trace2.txt" +[gen-test]: https://github.com/derrickstolee/gen-test "Generation Number Performance Test - Test scripts for testing new versions of generation numbers" + +See also discussion in: + + + + diff --git a/links/mentoring/soc/SoC-2020-Microprojects.md b/links/mentoring/soc/SoC-2020-Microprojects.md new file mode 100644 index 000000000..5fe04cc5c --- /dev/null +++ b/links/mentoring/soc/SoC-2020-Microprojects.md @@ -0,0 +1,73 @@ +--- +layout: default +title: SoC 2020 Applicant Microprojects +navbar: false +--- + +## Introduction + +First make sure you read and understand +[our general guidelines and suggestions for microprojects](https://git.github.io/General-Microproject-Information). + +There are some suggestions on how you can find some microprojects on your own in the document. + +## Ideas for microprojects + +### Add more builtin patterns for userdiff + +"git diff" shows the function name corresponding to each hunk after +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...), +the way to find the function name is built-in Git's source code as +regular expressions (see userdiff.c). A few languages are common +enough to deserve a built-in driver, but are not yet recognized. For +example, shell. + +This project requires a very good knowledge of regular expressions. + +It is easy though to find examples of how this can be done by +searching the code base and the mailing list archive, as this has +already been done for a number of languages. + +### Use `test_path_is_*` functions in test scripts + +Find one test script that verifies the presence/absence of +files/directories with 'test -(e|f|d|...)' and replace them with the +appropriate `test_path_is_file`, `test_path_is_dir`, etc. helper +functions. + +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 pipes in git related commands in test scripts + +See the commit +[c6f44e1da5](https://github.com/git/git/commit/c6f44e1da5e88e34) +for example, and then do the same thing in one other test script. + +The git command should be on the left side of the pipe. + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +### Use 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. + +### Add configuration options for some commonly used command-line options + +Many have already been added (e.g. "git am -3" in e97a5e7). + +Some people always run the command with these options, and would +prefer to be able to activate them by default in ~/.gitconfig. + +For some options though, we have made a deliberate choice to not +provide a configuration option. So ask on the mailing list if it's ok +before working on this. + diff --git a/links/mentoring/soc/SoC-2020-Org-Application.md b/links/mentoring/soc/SoC-2020-Org-Application.md new file mode 100644 index 000000000..f1f70c080 --- /dev/null +++ b/links/mentoring/soc/SoC-2020-Org-Application.md @@ -0,0 +1,305 @@ +--- +layout: default +title: SoC 2020 Organization Application +navbar: false +--- + +This is a draft of git's application to Google's Summer of Code 2020. + +# Git Profile + +## Website URL + + + +## Tagline + +fast, scalable, distributed revision control system + +## Logo + +![Git Logo](https://git.github.io/images/Git-Logo-1788C.png) + +## Primary Open Source License + +GPLv2 + +## Organization Category + +Programming Languages and Development Tools + +## Technology Tags + +c, shell script, git + +## Topic Tags + +version control, dvcs + +## Ideas List + + + +## Short Description (180 chars max) + +Git is the most widely-used revision control system in Open Source. It +is a distributed system with an emphasis on speed, data integrity, and +support for many workflows. + +## Long Description + +Git is the most widely-used revision control system in Open Source. It +is a distributed system with an emphasis on speed, data integrity, and +support for distributed, non-linear workflows. + +Many large and successful projects use Git, including the Linux +Kernel, Perl, Eclipse, Gnome, KDE, Qt, Ruby on Rails, Android, +PostgreSQL, Debian, and X.org. + +This organization covers projects for +[Git](https://github.com/git/git) itself. Other git-based software or +services are not covered by this organization. + +## Application Instructions + +``` +Guidance for students on how to apply to your organization. Should +include any prerequisites or requirements. You may wish to include a +template or tips for their proposals. May include limited Markdown. +``` + +Please read the "General Application Information" page: +https://git.github.io/General-Application-Information/ + +The primary way to contact the Git community is through the Git +mailing list git@vger.kernel.org. Please discuss your application on +this list. + +## Proposal Tags + +``` +Enter tags that students can select (one) from and apply to their own +proposals to help organize them. Examples: New Feature, Optimization. +You can also use these to designate "sub-organizations" if you are an +umbrella organization. +``` + +new feature, refactoring, bug fix + +## Contact Methods + +``` +You must complete at least one of the following three contact options. +``` + +Chat: https://git-scm.com/community + +Mailing List: https://git-scm.com/community + +General Email: git@vger.kernel.org + +## Twitter URL (optional) + +(Left blank) + +## Blog URL (optional) + +(Left blank) + +# 2020 Application Form + +## Why does your org want to participate in Google Summer of Code? + +With the exception of 2013, Git has participated in GSoC every year +since 2007. We have appreciated not only the code contributions (both +new features and internal refactoring to reduce the maintenance effort), but +also the increased project visibility and the addition of new long-term +contributors. We also believe strongly in helping students become +comfortable contributing to open source in general, even if they do not +remain involved with Git itself. + +## How many potential mentors have agreed to mentor this year? + +dropdown list => 1-5. + +Text below unused: + +``` +We have 3 potential co-mentors this year. This is a small number, and +we expect to take a correspondingly smaller number of projects +(probably only 1). + +All mentors are volunteers for the specific projects that they can +contribute the most to (i.e., ones that meet their interests and +abilities). All mentors are active contributors within the Git +development community, and well-known to the project leadership. + +Active contributors are defined to be those who have submitted and have +had accepted into a shipped release a substantial amount of code, where +substantial is defined to be equal to or larger than what might be +expected of a student working on a Google Summer of Code project. +``` + +## How will you keep mentors engaged with their students? + +``` +1000 characters. +``` + +We think that the most important part of GSoC is integrating the +student into the normal communication channels used by other project +members. The first step in dealing with disappearing students is to +make sure they are engaging with the community on design and code +issues, and reaching small milestones on the way to the project. Then +if they do disappear, we know quickly and can react, rather than being +surprised at the end. + +If they do disappear, we'll obviously contact them and find out +what's going on. But ultimately, non-communication is grounds for a +failing evaluation, regardless of any code produced. + +We plan to take fewer projects than we have as mentors. We usually +have two co-mentors per students, so that one mentor being unavailable +would have a limited impact on the project. Most of our projects can +be mentored by any of the mentors, and by keeping student progress +public and reviewed on-list, another mentor (or the community at +large) can pick up the slack if needed. + +## How will you help your students stay on schedule to complete their projects? + +``` +1000 characters. +``` + +There are several ways to do this, and they have been successful in +the past: + +* Prepare students to submit patches before they started. We use a + microproject system prior to the student application where students + must submit at least a patch, and respond to reviews. This means + that on day 1 of their project, students already know how long + review cycles are, and how important it is to work with the + mailing-list. + +* Split the work into small patch series. We don't expect regular + developers to go silent for 3 months and then dump 10,000 lines of + code on us to review, and we don't want students to do that to us + either. Even if the first patch series are only preparatory steps + that do not bring a real added value to Git, it is important to get + them merged as early as possible. Even if the project is not + "completed", useful pieces of code are validated all along the + project. + +## How will you get your students involved in your community during GSoC? + +``` +1000 characters. +``` + +Students will be required to join the main development mailing list +and post their patches for discussion (in addition to posting their +work as a Git repository on a publicly available server). All current +contributors already do this, so students will be able to see +experienced hands performing the same tasks and learn by example. We +also feel that the list-based discussions will help the student to +become and stay a member of the community. + +Mentors will also exchange direct email with students on at least a +weekly basis. Students will be required to provide weekly progress +reports back to their mentors, so that mentors are aware of the +current difficulties. Progress reports give the mentors a chance to +provide suggestions for problem resolution back to the student. + +Frequent email and IRC interaction with mentors and other developers +will be strongly encouraged by suggesting students post their questions +and ideas to the mailing list, and to discuss them on #git. + +``` +Unused text (did not fit the characters limit): + + +The traffic on the list is focused around Git development. We +expect the students to stay current by at least skimming the messages, +and participating in discussions that are close to their area of work. + +Many developers either already hold "office-hours" on IRC, or have +agreed to do so during the GSoC period. +``` + +## How will you keep students involved with your community after GSoC? + +Ultimately we have no leverage over the students after they leave, so +the best we can do is to help them form habits of interaction that they +might find rewarding and want to continue with. We specifically don't +want to give the student a "half project" that needs more work after the +GSoC period is done. That's not fair to the student, nor to the project. + +Instead, we'd prefer to get the student involved in the day-to-day of +interacting on the mailing list, reviewing code, and commenting on other +people's ideas and problems. Those are things they can continue to do +after GSoC ends, and those discussions can often spur more coding. + +## Has your org been accepted as a mentoring org in Google Summer of Code before? + +### Has your org been accepted as a mentoring org in Google Summer of Code before? + +Yes + +### Which years did your org participate in GSoC? + +Every year since 2007 except 2013. + +### For each year your organization has participated, provide the counts of successful and total students. (e.g. 2016: 3/4) + +``` +500 characters +``` +2007: 2/3 +2008: 4/6 +2009: 1/2 +2010: 3/4 +2011: 5/5 +2012: 3/3 +2014: 2/3 +2015: 2/2 +2016: 1/1 +2017: 1/1 +2018: 3/3 +2019: 2/2 + +### Refer an organization (optional) + +(Left blank) + + +### If your org has applied for GSoC before but not been accepted, select the years: + +None. + +## Provide a reference (optional) + +(Left blank) + +## What year was your project started? + +2005 + +## Where does your code live: + +http://github.com/git/git + +## Is your organization part of any government? + +No + +## Anything else we should know (optional)? + +We sometimes write about the GSoC in our Git Rev News newsletter +(https://git.github.io/rev_news/archive/). + +# Remarks on the current state of the application + +The 2015 application had a question "If you chose "veteran" in the +organization profile dropdown, please summarize your involvement and +the successes and challenges of your participation. Please also list +your pass/fail rate for each year." with a very detailed answer. diff --git a/links/mentoring/soc/SoC-2021-Ideas.md b/links/mentoring/soc/SoC-2021-Ideas.md new file mode 100644 index 000000000..9a69ccb00 --- /dev/null +++ b/links/mentoring/soc/SoC-2021-Ideas.md @@ -0,0 +1,64 @@ +--- +layout: default +title: SoC 2021 Ideas +navbar: false +--- + +This is the idea page for Summer of Code 2021 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. + +### Use ref-filter formats in `git cat-file` + + - Language: C, shell (bash) + - Difficulty: medium + - Possible mentors: Hariom Verma, Christian Couder + +`git cat-file` has options `--batch[=]` and +`--batch-check[=]` that can take a ``. It would be nice +if the implementation of this `` would use the as much as +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 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, especially Olga's work (see +) and reuse ref-filter formatting +logic in `git cat-file`. + +### Finish convert `git submodule` script to builtin + + - Language: C, shell (bash) + - Difficulty: medium + - Possible mentors: Christian Couder, Shourya Shukla + +A few components of Git, like `git-submodule.sh`, are still in the +form of shell scripts. This causes problems in production code – in +particular on multiple platforms, e.g. Windows (think: +POSIX-to-Windows path conversion issues). + +The idea of this project is to dive into the Git source code and +finish converting `git-submodule.sh` into portable and performant C +code, making it a so-called "built-in". + +Shourya Shukla is the latest GSoC student to have been working on +this. + +See: + + + diff --git a/links/mentoring/soc/SoC-2021-Org-Application.md b/links/mentoring/soc/SoC-2021-Org-Application.md new file mode 100644 index 000000000..74d87e31d --- /dev/null +++ b/links/mentoring/soc/SoC-2021-Org-Application.md @@ -0,0 +1,291 @@ +--- +layout: default +title: SoC 2021 Organization Application +navbar: false +--- + +This is a draft of git's application to Google's Summer of Code 2021. + + +# Organization Application + +## Why does your org want to participate in Google Summer of Code? + +With the exception of 2013, Git has participated in GSoC every year +since 2007. We have appreciated not only the code contributions (both +new features and internal refactoring to reduce the maintenance +effort), but also the increased project visibility and the addition of +new long-term contributors. We also believe strongly in helping +students become comfortable contributing to open source in general, +even if they do not remain involved with Git itself. + +## What would your org consider to be a successful summer? + +Students enjoying contributing improvements, learning and +participating in the community. It would be even better if they +continue to contribute and are willing to mentor other people after +the Summer. + +## How many potential mentors have agreed to mentor this year? + +dropdown list => 1-5. + +Text below unused: + +``` +We have 3 potential co-mentors this year. This is a small number, and +we expect to take a correspondingly smaller number of projects +(probably only 1). + +All mentors are volunteers for the specific projects that they can +contribute the most to (i.e., ones that meet their interests and +abilities). All mentors are active contributors within the Git +development community, and well-known to the project leadership. + +Active contributors are defined to be those who have submitted and have +had accepted into a shipped release a substantial amount of code, where +substantial is defined to be equal to or larger than what might be +expected of a student working on a Google Summer of Code project. +``` + +## How will you keep mentors engaged with their students? + +We think that the most important part of GSoC is integrating the +students into the normal communication channels used by other project +members. The first step in dealing with disappearing students is to +make sure they are engaging with the community on design and code +issues, and reaching small milestones on the way to the project. Then +if they do disappear, we know quickly and can react, rather than being +surprised at the end. + +If they do disappear, we'll obviously contact them and find out +what's going on. But ultimately, non-communication is grounds for a +failing evaluation, regardless of any code produced. + +We plan to take fewer projects than we have as mentors. We usually +have two co-mentors per students, so that one mentor being unavailable +would have a limited impact on the project. Most of our projects can +be mentored by any of the mentors, and by keeping student progress +public and reviewed on-list, another mentor (or the community at +large) can pick up the slack if needed. + +## How will you help your students stay on schedule to complete their projects? + +There are several ways to do this, and they have been successful in +the past: + +* Prepare students to submit patches before they started. We use a + microproject system prior to the student application where students + must submit at least a patch, and respond to reviews. This means + that on day 1 of their project, students already know how long + review cycles are, and how important it is to work with the + mailing-list. + +* Split the work into small patch series. We don't expect regular + developers to go silent for 3 months and then dump 10,000 lines of + code on us to review, and we don't want students to do that to us + either. Even if the first patch series are only preparatory steps + that do not bring a real added value to Git, it is important to get + them merged as early as possible. Even if the project is not + "completed", useful pieces of code are validated all along the + project. + +## How will you get your students involved in your community during GSoC? + +Students will be required to join the main development mailing list +and post their patches for discussion (in addition to posting their +work as a Git repository on a publicly available server). All current +contributors already do this, so students will be able to see +experienced hands performing the same tasks and learn by example. We +also feel that the list-based discussions will help the student to +become and stay a member of the community. + +Mentors will also exchange direct email with students on at least a +weekly basis. Students will be required to provide weekly progress +reports back to their mentors, so that mentors are aware of the +current difficulties. Progress reports give the mentors a chance to +provide suggestions for problem resolution back to the student. + +Frequent email and IRC interaction with mentors and other developers +will be strongly encouraged by suggesting students post their questions +and ideas to the mailing list, and to discuss them on #git. + +## How will you keep students involved with your community after GSoC? + +Ultimately we have no leverage over the students after they leave, so +the best we can do is to help them form habits of interaction that they +might find rewarding and want to continue with. We specifically don't +want to give the student a "half project" that needs more work after the +GSoC period is done. That's not fair to the student, nor to the project. + +Instead, we'd prefer to get the student involved in the day-to-day of +interacting on the mailing list, reviewing code, and commenting on other +people's ideas and problems. Those are things they can continue to do +after GSoC ends, and those discussions can often spur more coding. + +## Has your org been accepted as a mentor org in Google Summer of Code before? + +### Has your org been accepted as a mentor org in Google Summer of Code before? + +Yes + +### Which years did your org participate in GSoC? + +Every year since 2007 except 2013. + +### How many students did your org accept for 2020? + +3 + +### How many of your org's 2020 students have been active in your community in the past 60 days? + +3 + +### For each year your organization has participated, provide the counts of successful and total students. (e.g. 2016: 3/4) + +2007: 2/3 +2008: 4/6 +2009: 1/2 +2010: 3/4 +2011: 5/5 +2012: 3/3 +2014: 2/3 +2015: 2/2 +2016: 1/1 +2017: 1/1 +2018: 3/3 +2019: 2/2 +2020: 3/3 + +### Is there an organization new to GSoC that you would like to refer to the program for 2021? Feel free to add a few words about why they'd be a good fit. + +(Left blank) + +### If your org has applied for GSoC before but not been accepted, select the years: + +None. + + +### If you are a new organization to GSoC, is there a Google employee or previously participating organization who will vouch for you? If so, please enter their name, contact email, and relationship to your organization. + +(Left blank) + +## What year was your project started? + +2005 + +## Where does your source code live? + +http://github.com/git/git + +## Is your organization part of any government? + +No + +## Anything else we should know (optional)? + +We sometimes write about the GSoC in our Git Rev News newsletter +(https://git.github.io/rev_news/archive/). + + +# Organization Profile + +## Website URL + + + +## Tagline + +fast, scalable, distributed revision control system + +## Logo + +![Git Logo](https://git.github.io/images/Git-Logo-1788C.png) + +## Primary Open Source License + +GNU General Public License version 2.0 (GPL-2.0) + +## Organization Category + +Programming Languages and Development Tools + +## Technology Tags + +c language, shell script, git + +## Topic Tags + +version control, dvcs + +## Ideas List + + + +## Short Description (180 chars max) + +Git is the most widely-used revision control system in Open Source. It +is a distributed system with an emphasis on speed, data integrity, and +support for many workflows. + +## Long Description + +Git is the most widely-used revision control system in Open Source. It +is a distributed system with an emphasis on speed, data integrity, and +support for distributed, non-linear workflows. + +Many large and successful projects use Git, including the Linux +Kernel, Perl, Eclipse, Gnome, KDE, Qt, Ruby on Rails, Android, +PostgreSQL, Debian, and X.org. + +This organization covers projects for +[Git](https://github.com/git/git) itself. Other git-based software or +services are not covered by this organization. + +## Application Instructions + +``` +Guidance for students on how to apply to your organization. Should +include any prerequisites or requirements. You may wish to include a +template or tips for their proposals. May include limited Markdown. +``` + +Please read the "General Application Information" page: +https://git.github.io/General-Application-Information/ + +The primary way to contact the Git community is through the Git +mailing list git@vger.kernel.org. Please discuss your application on +this list. + +## Proposal Tags + +``` + +Enter tags that students can select (one) from and apply to their own +proposals to help organize them. Examples: New Feature, +Optimization. You can also use these to designate "sub-organizations" +if you are an umbrella organization. +``` + +new feature, refactoring, bug fix + +## Contact Methods + +``` +You must complete at least one of the following three contact options. +``` + +Chat: https://git-scm.com/community + +Mailing List: https://git-scm.com/community + +General Email: git@vger.kernel.org + +## Twitter URL (optional) + +(Left blank) + +## Blog URL (optional) + +(Left blank) + diff --git a/links/mentoring/soc/SoC-2022-Ideas.md b/links/mentoring/soc/SoC-2022-Ideas.md new file mode 100644 index 000000000..90a0ab1cb --- /dev/null +++ b/links/mentoring/soc/SoC-2022-Ideas.md @@ -0,0 +1,191 @@ +--- +layout: default +title: SoC 2022 Ideas +navbar: false +--- + +This is the idea page for Summer of Code 2022 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. + +### More Sparse Index Integrations + +The [spare index feature](https://github.blog/2021-11-10-make-your-monorepo-feel-small-with-gits-sparse-index/) +accelerates Git commands when using +[sparse-checkout in cone mode](https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/). +This works by modifying the on-disk index file in a way that includes +"sparse directory" entries instead of only file entries. This requires +care when enabling the sparse index for different commands, as custom +logic might be necessary. At minimum, interaction with the sparse index +needs to be carefully tested in the Git test suite when enabling it. + +The most-used commands have already been integrated with the sparse +index feature. This process usually takes a few steps: + +1. Add tests to [`t1092-sparse-checkout-compatibility.sh`](https://github.com/git/git/blob/master/t/t1092-sparse-checkout-compatibility.sh) + for the builtin, with a focus on what happens for paths outside of the + sparse-checkout cone. +2. Disable [the `command_requires_full_index` setting](https://github.com/git/git/blob/master/repository.h#L35) + in the builtin and ensure the tests pass. +3. If the tests do not pass, then alter the logic to work with the sparse index. +4. Add tests to [check that a sparse index stays sparse](https://github.com/git/git/blob/38062e73e009f27ea192d50481fcb5e7b0e9d6eb/t/t1092-sparse-checkout-compatibility.sh#L873-L939). +5. Add [performance tests](https://github.com/git/git/blob/master/t/perf/p2000-sparse-operations.sh) + to demonstrate speedup. + +Here is a list of builtins that could be integrated with the sparse index. +They are generally organized in order of least-difficult to most-difficult. +This allows the student to gain partial success early in the project and +the student can complete as many as possible in the timeframe (without +expectation that _all_ will be completed during the project). + +* `git mv` +* `git rm` +* `git grep` +* `git rev-parse` +* `git fsck` +* `git check-attr` +* `git describe` +* `git diff-files` +* `git diff-index` +* `git diff-tree` +* `git worktree` +* `git write-tree` +* `git apply` +* `git am` +* `git checkout--worker` (for parallel checkout) +* `git merge-index` +* `git rerere` + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Derrick Stolee < > +* Victoria Dye < > + +### Unify ref-filter formats with other pretty formats + +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 +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 +[pretty](https://github.com/git/git/blob/master/pretty.h). + +See: + + - this discussion + - Hariom Verma's GSoC 2020 final report + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Christian Couder < > +* Hariom Verma < > + +### Reachability bitmap improvements + +[Reachability bitmaps][vmg-bitmaps] allow Git to quickly answer queries about +which objects are reachable from a given commit. Instead of a commits parents +and its root tree recursively, we can use a precomputed set of objects encoded +as a bit-string and stored in a `.bitmap` file to answer the query near +instantaneously. + +There are a couple of areas where bitmap performance itself could be improved: + + - Individual bitmaps are stored compressed (with [EWAH][ewah]), but we have + some sense that it can be slow to decompress individual bitmaps (which we + have to do in order to read them, but also to do things like negate them, OR + and AND them together, etc). + + One possible project could be to explore using an alternative compression + scheme (like the more modern [Roaring+Run][roaring-run] technique) to see if + we can improve overall bitmap performance by reducing the amount of time it + takes to read an individual bitmap. + + This project would entail designing a suite of performance tests, along with + any necessary changes to the `.bitmap` format necessary to accommodate the + new compression scheme, making those changes, and then running the + performance tests to measure the resulting speed-up. + + - Loading a `.bitmap` file can be slow for large bitmaps. This is because we + have to read the file sequentially in order to discover the offset of each + bitmap within the file. + + It should be possible to shave off some time from this step by including a + small "table of contents" that indicates which commits have bitmaps, and + where to find them in the `.bitmap` file. In the past [some efforts have + been made][ttaylorr-commit-table] to do this. But we should undertake more + performance testing to prove whether this is or isn't a good idea before + submitting a patch series in this area. + + - [Recent changes][ttaylorr-bitmaps] have made it possible to repack a + repository's objects into a sequence of packs whose object count forms a + geometric progression (e.g., if the first pack has `N` objects, the next + pack will have at least `2N` objects, then `4N` objects and so on). + + But even when repacking a repository in this way, regenerating its bitmaps + can still take a long time. One possible approach to this would be a new + mode of generating bitmaps that is more "incremental" in nature. In other + words, a mode which only adds new bitmaps for commits introduced between + successive bitmap generations. + + Because of how individual bitmaps are generated, this will result in only + having to traverse objects between the new bitmap tips and old ones, + resulting in overall faster bitmap generation. + + Like the above, this project would involve designing a set of performance + tests, implementing the changes required to introduce this new type of + bitmap generation, and then running those tests against your new code. + + - Other (larger, longer-term) ideas include: rethinking how we select which + commits receive bitmaps (and/or having bitmaps represent multiple commits + instead of just one to "summarize" small sets of commits), or improving how + we handle queries that use a bitmap but do not have complete coverage. + GSoC students should consider these projects more advanced, and thus they + are not explained in as much detail here. Instead, this point serves to + illustrate that there are opportunities to explore larger projects should we + decide they are more interesting than the above or we have time to take them + on. + +This project will give GSoC students a broad overview of reachability bitmaps, +with the goal of improving their performance in some way or another. Students +can expect hands-on mentorship, but will have the agency to pick one or more of +the above sub-projects (or create their own!) that interests them most. + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell + +Possible mentors: +* Taylor Blau < > +* Kaartic Sivaraam < > + +[vmg-bitmaps]: https://github.blog/2015-09-22-counting-objects/ +[ewah]: https://arxiv.org/abs/0901.3751 +[roaring-run]: https://roaringbitmap.org/about/ +[ttaylorr-commit-table]: https://lore.kernel.org/git/YNuiM8TR5evSeNsN@nand.local/ +[ttaylorr-bitmaps]: https://github.blog/2021-04-29-scaling-monorepo-maintenance/ diff --git a/links/mentoring/soc/SoC-2022-Microprojects.md b/links/mentoring/soc/SoC-2022-Microprojects.md new file mode 100644 index 000000000..6def7c11d --- /dev/null +++ b/links/mentoring/soc/SoC-2022-Microprojects.md @@ -0,0 +1,139 @@ +--- +layout: default +title: SoC 2022 Applicant Microprojects +navbar: false +--- + +## Introduction + +First make sure you read and understand +[our general guidelines and suggestions for microprojects](https://git.github.io/General-Microproject-Information). + +There are some suggestions on how you can find some microprojects on your own in the document. + +## Ideas for microprojects + +### Add more builtin patterns for userdiff + +"git diff" shows the function name corresponding to each hunk after +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...), +the way to find the function name is built-in Git's source code as +regular expressions (see userdiff.c). A few languages are common +enough to deserve a built-in driver, but are not yet recognized. For +example, shell. + +This project requires a very good knowledge of regular expressions. + +It is easy though to find examples of how this can be done by +searching the code base and the mailing list archive, as this has +already been done for a number of languages. + +### Replace a run_command*() call by direct calls to C functions + +See for example what Junio did in +[ffcb4e94d3](https://github.com/git/git/commit/ffcb4e94d3) (bisect: do +not run show-branch just to show the current commit, 2021-07-27). + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +### Use `test_path_is_*` functions in test scripts + +Find one test script that verifies the presence/absence of +files/directories with 'test -(e|f|d|...)' and replace them with the +appropriate `test_path_is_file`, `test_path_is_dir`, etc. helper +functions. + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +### Avoid suppressing `git`'s exit code in test scripts + +The Git project uses a large collection of integration tests written in +Shell to guard against regressions when adding new features or fixing +bugs. The scripts in question can be found in the `t` directory +[here][git-t]. + +While it is perfectly OK to use [pipes][wikipedia-pipes] when writing +integration tests, we must be careful to avoid writing a pipeline that +suppresses the exit code of a Git process, like so: + +``` +git | +``` + +...since the exit code of `git ` would be suppressed by the +pipe. If `git ` crashed, we would not catch it in the above +example when running the integration suite. + +Other examples to avoid include: + +``` +# bad: + $(git ) + +# also bad: + <) +EOF +``` + +...since the exit code of `git ` is hidden behind the +subshell in both instances. + +On the other hand, both of the following examples are OK, since neither +hides the exit code of running `git `: + +``` +# good: +var=$(git ) + +# also good: + | | git +``` + +(provided that neither `` or `` are +`git`). + +See the commit +[c6f44e1da5](https://github.com/git/git/commit/c6f44e1da5e88e34) +for example, and then do the same thing in one other test script. + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +[git-t]: https://github.com/git/git/tree/master/t +[wikipedia-pipes]: https://en.wikipedia.org/wiki/Pipeline_(Unix) + +### Use unsigned integral type for collection of bits. + +Pick one field of a structure that (1) is of signed integral type and (2) is +used as a collection of multiple bits. Discuss if there is a good reason +why it has to be a signed integral field and change it to an unsigned +type otherwise. [[thread](https://public-inbox.org/git/xmqqsiebrlez.fsf@gitster.dls.corp.google.com)] + +Even though the amount of code to write is small, these projects +involve a lot of prior work to understand the specification and deal +with all potential corner-cases. + +### Modernize a test script + +A number of our test scripts have been written a long time ago in a +style that is now outdated. + +In the following email it is explained in details how to modernize and +clean up the t7001 test script: + + + +t7001 is not the only test script where similar changes could be made +though. + +Find one test script that needs some of the same changes and make +them. Please make sure that the test script is not already being +worked on by asking on the mailing list before starting to work on it. + +There should be only one kind of change per commit. For example if one +of your commits indents test bodies with TABs, instead of spaces, then +this should be the only kind of change in this commit. diff --git a/links/mentoring/soc/SoC-2022-Org-Application.md b/links/mentoring/soc/SoC-2022-Org-Application.md new file mode 100644 index 000000000..4ac715015 --- /dev/null +++ b/links/mentoring/soc/SoC-2022-Org-Application.md @@ -0,0 +1,229 @@ +--- +layout: default +title: SoC 2022 Organization Application +navbar: false +--- + +This is a draft of git's application to Google's Summer of Code 2022. + +# Initial form + +## Organization Name + +Git + +## Is this organization an established Open Source project or organization that releases code under an OSI approved license ? An OSI License is required for program participation. + +Yes + +## Has your organization participated in Google Summer of Code before? + +Yes + +## Please select all years in which your organization participated prior to 2022. + +Every year since 2007 except 2013. + +## [Agreement](https://summerofcode.withgoogle.com/terms/org) + +Accepted + + +# Organization Profile + +## Website URL for Organization + +https://git-scm.com/ + + +## Logo + +![Git Logo](/images/Git-Logo-1788C.png) + + +## Tagline + +fast,scalable,distributed revision control system + + +## Primary Open Source License + +GNU General Public License version 2.0 (GPL-2.0) + + +## When year was your project started? + +2005 + + +## Link to your source code location + +http://github.com/git/git + + +## Organization Categories + +Programming Languages and Development Tools + + +## Technology tags + +c language, shell script, git + + +## Topic Tags + +version control, dvcs + + +## Organization Description + +Git is the most widely-used revision control system in Open Source. It +is a distributed system with an emphasis on speed, data integrity, and +support for distributed, non-linear workflows. + +Many large and successful projects use Git, including the Linux +Kernel, Perl, Eclipse, Gnome, KDE, Qt, Ruby on Rails, Android, +PostgreSQL, Debian, and X.org. + +This organization covers projects for +[Git](https://github.com/git/git) itself. Other git-based software or +services are not covered by this organization. + + +## Contributor Guidance + +https://git.github.io/General-Application-Information/ + + +## Communication Methods + +Chat: https://git-scm.com/community + +Mailing List / Forum: https://git-scm.com/community + +General Email: git@vger.kernel.org + + +# Organization Questionnaire + +## Why does your org want to participate in Google Summer of Code? + +With the exception of 2013, Git has participated in GSoC every year +since 2007. We have appreciated not only the code contributions (both +new features and internal refactoring to reduce the maintenance +effort), but also the increased project visibility and the addition of +new long-term contributors. We also believe strongly in helping +students become comfortable contributing to open source in general, +even if they do not remain involved with Git itself. + + +## What would your organization consider to be a successful GSoC program? + +Students enjoying contributing improvements, learning and +participating in the community. It would be even better if they +continue to contribute and are willing to mentor other people after +the Summer. + + +## How will you keep mentors engaged with their students? + +We think that the most important part of GSoC is integrating the +students into the normal communication channels used by other project +members. The first step in dealing with disappearing students is to +make sure they are engaging with the community on design and code +issues, and reaching small milestones on the way to the project. Then +if they do disappear, we know quickly and can react, rather than being +surprised at the end. + +If they do disappear, we'll obviously contact them and find out +what's going on. But ultimately, non-communication is grounds for a +failing evaluation, regardless of any code produced. + +We plan to take fewer projects than we have as mentors. We usually +have two co-mentors per students, so that one mentor being unavailable +would have a limited impact on the project. Most of our projects can +be mentored by any of the mentors, and by keeping student progress +public and reviewed on-list, another mentor (or the community at +large) can pick up the slack if needed. + + +## How will you help your students stay on schedule to complete their projects? + +There are several ways to do this, and they have been successful in +the past: + +* Prepare students to submit patches before they started. We use a + microproject system prior to the student application where students + must submit at least a patch, and respond to reviews. This means + that on day 1 of their project, students already know how long + review cycles are, and how important it is to work with the + mailing-list. + +* Split the work into small patch series. We don't expect regular + developers to go silent for 3 months and then dump 10,000 lines of + code on us to review, and we don't want students to do that to us + either. Even if the first patch series are only preparatory steps + that do not bring a real added value to Git, it is important to get + them merged as early as possible. Even if the project is not + "completed", useful pieces of code are validated all along the + project. + + +## How will you get your students involved in your community during GSoC? + +Students will be required to join the main development mailing list +and post their patches for discussion (in addition to posting their +work as a Git repository on a publicly available server). All current +contributors already do this, so students will be able to see +experienced hands performing the same tasks and learn by example. We +also feel that the list-based discussions will help the student to +become and stay a member of the community. + +Mentors will also exchange direct email with students on at least a +weekly basis. Students will be required to provide weekly progress +reports back to their mentors, so that mentors are aware of the +current difficulties. Progress reports give the mentors a chance to +provide suggestions for problem resolution back to the student. + +Frequent email and IRC interaction with mentors and other developers +will be strongly encouraged by suggesting students post their questions +and ideas to the mailing list, and to discuss them on #git. + + +## Anything else we should know (optional)? + +We sometimes write about the GSoC in our Git Rev News newsletter +(https://git.github.io/rev_news/archive/). + + +## Is your organization part of any government? + +No + + +# Program Application + +## Ideas List URL + + + + +## Mentors + +``` +How many Mentors does your Organization have available to participate in this program? +``` + +5 + + +### How many students did your org accept for 2021? + +2 + + +### How many of your org's 2021 students are active today? + +1 + diff --git a/links/mentoring/soc/SoC-2023-Ideas.md b/links/mentoring/soc/SoC-2023-Ideas.md new file mode 100644 index 000000000..582cfcd75 --- /dev/null +++ b/links/mentoring/soc/SoC-2023-Ideas.md @@ -0,0 +1,101 @@ +--- +layout: default +title: SoC 2023 Ideas +navbar: false +--- + +This is the idea page for Summer of Code 2023 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. + +### More Sparse Index Integrations + +The [spare index feature](https://github.blog/2021-11-10-make-your-monorepo-feel-small-with-gits-sparse-index/) +accelerates Git commands when using +[sparse-checkout in cone mode](https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/). +This works by modifying the on-disk index file in a way that includes +"sparse directory" entries instead of only file entries. This requires +care when enabling the sparse index for different commands, as custom +logic might be necessary. At minimum, interaction with the sparse index +needs to be carefully tested in the Git test suite when enabling it. + +The most-used commands have already been integrated with the sparse +index feature. This process usually takes a few steps: + +1. Add tests to [`t1092-sparse-checkout-compatibility.sh`](https://github.com/git/git/blob/master/t/t1092-sparse-checkout-compatibility.sh) + for the builtin, with a focus on what happens for paths outside of the + sparse-checkout cone. +2. Disable [the `command_requires_full_index` setting](https://github.com/git/git/blob/master/repository.h#L35) + in the builtin and ensure the tests pass. +3. If the tests do not pass, then alter the logic to work with the sparse index. +4. Add tests to [check that a sparse index stays sparse](https://github.com/git/git/blob/38062e73e009f27ea192d50481fcb5e7b0e9d6eb/t/t1092-sparse-checkout-compatibility.sh#L873-L939). +5. Add [performance tests](https://github.com/git/git/blob/master/t/perf/p2000-sparse-operations.sh) + to demonstrate speedup. + +Here is a list of builtins that could be integrated with the sparse index. +They are generally organized in order of least-difficult to most-difficult. +This allows the student to gain partial success early in the project and +the student can complete as many as possible in the timeframe (without +expectation that _all_ will be completed during the project). + +* `git describe` +* `git write-tree` +* `git diff-files` +* `git diff-index` +* `git diff-tree` +* `git worktree` +* `git check-attr` +* `git checkout--worker` (for parallel checkout) +* `git apply` +* `git am` +* `git fsck` +* `git merge-index` +* `git rerere` + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentor: Victoria Dye < > + +### Unify ref-filter formats with other pretty formats + +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 +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 +[pretty](https://github.com/git/git/blob/master/pretty.h). + +See: + + - this discussion + - Hariom Verma's GSoC 2020 final report + - Nsengiyumva Wilberforce's recent work on this + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Christian Couder < > +* Hariom Verma < > + diff --git a/links/mentoring/soc/SoC-2024-Ideas.md b/links/mentoring/soc/SoC-2024-Ideas.md new file mode 100644 index 000000000..041eba592 --- /dev/null +++ b/links/mentoring/soc/SoC-2024-Ideas.md @@ -0,0 +1,207 @@ +--- +layout: default +title: SoC 2024 Ideas +navbar: false +--- + +![git logo >](https://git-scm.com/images/logos/downloads/Git-Logo-2Color.svg) + +This is the idea page for Summer of Code 2024 for Git. + +*Please completely read the [general application information](https://git.github.io/General-Application-Information) +page before reading the idea list below.* + +## Summer of code main project ideas + +**Students**: Please consider these ideas as starting points for +generating proposals. We are also more than happy to receive proposals +for other ideas related to Git. Make sure you have read the "Note +about refactoring projects versus projects that implement new +features" in the [general application information](https://git.github.io/General-Application-Information) +page though. + +### Note about limit of project selection + +Kindly note that considering the bandwidth of available mentors, the +Git project would only mentor up to 3 contributors this year. + +This is not a hard and fast rule. It may change if more community members are +willing to mentor in the coming days. For instance, this may happen when +a new project is proposed and some community member volunteers to mentor +the same. + +### Move existing tests to a unit testing framework + +Git has a lot of test cases that need to be migrated to use a new unit +testing framework. This typically involves moving code from both: + + - a "t/helper/test-*.c" test helper in C, and + - a "t/*.sh" test script in shell that invokes the test helper + +over to a single "t/unit-tests/t-*.c" in C using the unit testing +framework. + +Our Outreachy intern ported some of the unit tests. + +**Note**: Owing to additional care needed to convert +reftable unit tests in `t0032-reftable-unittest.sh`, +it is covered as a separate project below. +So, this project solely focuses on unit tests _other than_ +the reftable ones. + +- See: + + - this discussion + - + - + - + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Christian Couder < > +* Kaartic Sivaraam < > + +### Convert reftable unit tests to use the unit testing framework + +The "reftable" unit tests in `t0032-reftable-unittest.sh` +predate the unit testing framework that was recently +introduced into Git. These tests should be converted to use +the new framework. + +See: + + - this discussion + - + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Low + +Languages: C, shell(bash) + +Possible mentors: +* Patrick Steinhardt < > +* Karthik Nayak < > +* Christian Couder < > + +### Implement consistency checks for refs + +The git-fsck(1) command is used to check various data +structures for consistency. Notably missing though are +consistency checks for the refdb. While git-fsck(1) +implicitly checks some of the properties of the refdb +because it uses its refs for a connectivity check, these +checks aren't sufficient to properly ensure that all refs +are properly consistent. + +The goal of this project would be to introduce consistency +checks that can be implemented by the ref backend. Initially +these checks may only apply to the "files" backend. With the +ongoing efforts to upstream a new "reftable" backend the +effort may be extended. + +See: + + - + - + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Patrick Steinhardt < > +* Karthik Nayak < > + +### Refactor git-bisect(1) to make its state self-contained + +The git-bisect(1) command is used to find a commit in a +range of commits that introduced a specific bug. Starting a +bisection run creates a set of state files into the Git +repository which record various different parameters like +".git/BISECT_START". These files look almost like refs +due to their names being all-uppercase. This has led to +confusion with the new "reftable" backend because it wasn't +quite clear whether those files are in fact refs or not. + +As it turns out they are not refs and should never be +treated like one. Overall, it has been concluded that the +way those files are currently stored is not ideal. Instead +of having a proliferation of files in the Git directory, it +was discussed whether the bisect state should be moved into +its own "bisect-state" subdirectory. This would make it more +self-contained and thereby avoid future confusion. It is +also aligned with the sequencer state used by rebases, which +is neatly contained in the "rebase-apply" and "rebase-merge" +directories. + +The goal of this project would be to realize this change. +While rearchitecting the layout should be comparatively easy +to do, the harder part will be to hash out how to handle +backwards compatibility. + +See: + + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Patrick Steinhardt < > +* Karthik Nayak < > +* Christian Couder < > + +### Implement support for reftables in "dumb" HTTP transport + +Fetching Git repositories uses one of two major protocols: + + - The "dumb" protocol works without requiring any kind of + interactive negotiation like a CGI module. It can thus + be served by a static web server. + + - The "smart" protocol works by having the client and + server exchange multiple messages with each other. It is + more efficient, but requires support for Git in the + server. + +While almost all servers nowadays use the "smart" protocol, +there are still some that use the "dumb" protocol. + +The "dumb" protocol cannot serve repositories which use the +"reftable" backend though. While there exists a "info/refs" +file that is supposed to be backend-agnostic, this file does +not contain information about the default branch. Instead, +clients are expected to download the "HEAD" file and derive +the default branch like that. This file is a mere stub in +the "reftable" backend though, which breaks this protocol. + +The goal of this project is to implement "reftable" support +for "dumb" fetches. + +See: + + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Patrick Steinhardt < > +* Karthik Nayak < > diff --git a/links/mentoring/soc/SoC-2024-Microprojects.md b/links/mentoring/soc/SoC-2024-Microprojects.md new file mode 100644 index 000000000..c832f49f3 --- /dev/null +++ b/links/mentoring/soc/SoC-2024-Microprojects.md @@ -0,0 +1,144 @@ +--- +layout: default +title: SoC 2024 Applicant Microprojects +navbar: false +--- + +## Introduction + +First make sure you read and understand +[our general guidelines and suggestions for microprojects](https://git.github.io/General-Microproject-Information). + +There are some suggestions on how you can find some microprojects on your own in the document. + +## Ideas for microprojects + +### Add more builtin patterns for userdiff + +"git diff" shows the function name corresponding to each hunk after +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...), +the way to find the function name is built-in Git's source code as +regular expressions (see userdiff.c). A few languages are common +enough to deserve a built-in driver, but are not yet recognized. For +example, shell. + +This project requires a very good knowledge of regular expressions. + +It is easy though to find examples of how this can be done by +searching the code base and the mailing list archive, as this has +already been done for a number of languages. + +### Replace a run_command*() call by direct calls to C functions + +See for example what Junio did in +[ffcb4e94d3](https://github.com/git/git/commit/ffcb4e94d3) (bisect: do +not run show-branch just to show the current commit, 2021-07-27). + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +### Use `test_path_is_*` functions in test scripts + +Find one test script that verifies the presence/absence of +files/directories with 'test -(e|f|d|...)' and replace them with the +appropriate `test_path_is_file`, `test_path_is_dir`, etc. helper +functions. Note that this conversion does not directly apply to control +flow constructs like `if test -e ./path; then ...; fi` because the +replacements are intended to assert the condition instead of merely +testing for it. Check [this link](https://public-inbox.org/git/CAPig+cRfO8t1tdCL6MB4b9XopF3HkZ==hU83AFZ38b-2zsXDjQ@mail.gmail.com/) +for an elaborate clarification on identifying `test -e` +instances that should / should not be replaced. + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +### Avoid suppressing `git`'s exit code in test scripts + +The Git project uses a large collection of integration tests written in +Shell to guard against regressions when adding new features or fixing +bugs. The scripts in question can be found in the `t` directory +[here][git-t]. + +While it is perfectly OK to use [pipes][wikipedia-pipes] when writing +integration tests, we must be careful to avoid writing a pipeline that +suppresses the exit code of a Git process, like so: + +``` +git | +``` + +...since the exit code of `git ` would be suppressed by the +pipe. If `git ` crashed, we would not catch it in the above +example when running the integration suite. + +Other examples to avoid include: + +``` +# bad: + $(git ) + +# also bad: + <) +EOF +``` + +...since the exit code of `git ` is hidden behind the +subshell in both instances. + +On the other hand, both of the following examples are OK, since neither +hides the exit code of running `git `: + +``` +# good: +var=$(git ) + +# also good: + | | git +``` + +(provided that neither `` or `` are +`git`). + +See the commit +[c6f44e1da5](https://github.com/git/git/commit/c6f44e1da5e88e34) +for example, and then do the same thing in one other test script. + +If you can't find one please tell us, along with the command you used +to search, so that we can remove this microproject idea. + +[git-t]: https://github.com/git/git/tree/master/t +[wikipedia-pipes]: https://en.wikipedia.org/wiki/Pipeline_(Unix) + +### Use unsigned integral type for collection of bits. + +Pick one field of a structure that (1) is of signed integral type and (2) is +used as a collection of multiple bits. Discuss if there is a good reason +why it has to be a signed integral field and change it to an unsigned +type otherwise. [[thread](https://public-inbox.org/git/xmqqsiebrlez.fsf@gitster.dls.corp.google.com)] + +Even though the amount of code to write is small, these projects +involve a lot of prior work to understand the specification and deal +with all potential corner-cases. + +### Modernize a test script + +A number of our test scripts have been written a long time ago in a +style that is now outdated. + +In the following email it is explained in details how to modernize and +clean up the t7001 test script: + + + +t7001 is not the only test script where similar changes could be made +though. + +Find one test script that needs some of the same changes and make +them. Please make sure that the test script is not already being +worked on by asking on the mailing list before starting to work on it. + +There should be only one kind of change per commit. For example if one +of your commits indents test bodies with TABs, instead of spaces, then +this should be the only kind of change in this commit. diff --git a/links/mentoring/soc/SoC-2025-Ideas.md b/links/mentoring/soc/SoC-2025-Ideas.md new file mode 100644 index 000000000..df46f21ad --- /dev/null +++ b/links/mentoring/soc/SoC-2025-Ideas.md @@ -0,0 +1,173 @@ +--- +layout: default +title: SoC 2025 Ideas +navbar: false +--- + +![git logo >](https://git-scm.com/images/logos/downloads/Git-Logo-2Color.svg) + +This is the idea page for Summer of Code 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/links/mentoring/soc/SoC-2025-Microprojects.md b/links/mentoring/soc/SoC-2025-Microprojects.md new file mode 100644 index 000000000..0c46ae09b --- /dev/null +++ b/links/mentoring/soc/SoC-2025-Microprojects.md @@ -0,0 +1,182 @@ +--- +layout: default +title: SoC 2025 Applicant Microprojects +navbar: false +--- + +## Introduction + +First make sure you read and understand +[our general guidelines and suggestions for microprojects](https://git.github.io/General-Microproject-Information). + +There are some suggestions on how you can find some microprojects on your own in the document. + +## Ideas for microprojects + +### 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/links/mentoring/soc/SoC-2026-Ideas.md b/links/mentoring/soc/SoC-2026-Ideas.md new file mode 100644 index 000000000..ad755fea5 --- /dev/null +++ b/links/mentoring/soc/SoC-2026-Ideas.md @@ -0,0 +1,343 @@ +--- +layout: default +title: SoC 2026 Ideas +--- + +![git logo >](https://git-scm.com/images/logos/downloads/Git-Logo-2Color.svg) + +This is the idea page for Summer of Code 2026 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 or 4 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. + +### 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. +This architectural improvement will make the codebase more maintainable and +potentially enable better multi-repository handling in the future. + +> Note: While `struct repository` / `struct repository_settings` may seem like a +> natural target for this refactoring, contributors should be cautious about moving +> settings there. `struct repository_settings` was originally designed to hold +> config settings that are lazily parsed. Moving eagerly parsed config settings +> into that struct can cause Git to die in unexpected places when lazy parsing +> fails on an invalid config setting. Any such move requires careful analysis +> and should not be done as a blanket approach. + +The project involves careful refactoring of Git's core environment handling code, +requiring strong C programming skills and attention to detail. Design discussions +on the mailing list to find the best way to refactor individual variables will +likely happen. + +The contributor 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. + +**Getting started**: Build Git from source, study the `environment.c` file and its +global variables, and understand how `struct repository` and `struct repository_settings` +work. For a concrete example of the kind of work this project involves, review +[Bello Caleb Olamide's Outreachy project](https://lore.kernel.org/all/48821a3848bef25c13038be8377ad73e7c17a924.1771258573.git.belkid98@gmail.com/) +to get a sense of the approach and subtleties involved. Submit a micro-patch +to demonstrate familiarity with the codebase, and review recent mailing +list discussions about reducing global state. + +_Expected Project Size_: 90 or 175 hours or 350 hours + +_Difficulty_: Medium + +_Languages_: C, shell(bash) + +_Possible mentors_: + +* Christian Couder < > +* Karthik Nayak < > +* Justin Tobler < > +* Ayush Chandekar < > +* Siddharth Asthana < > + +### Improve the new `git repo` command + +The `git repo` command was introduced as part of GSoC 2025 (released in Git 2.52.0) +to provide a cleaner interface for querying repository metadata and configuration. +The command currently has two sub-commands: `git repo info` for retrieving repository +information in machine-readable formats, and `git repo structure` for displaying +repository statistics. + +See the [mailing list discussion](https://public-inbox.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/t/#u) +introducing the command and the [official documentation](https://git-scm.com/docs/git-repo) +for current functionality. + +A number of improvements could be made to both sub-commands: + +**For `git repo info`**, potential improvements include: + +- Remove the dependency on `the_repository` global variable +- Use the category as key (e.g., `git repo info layout` would return all layout-related values) +- Add path-related values currently obtained through `git rev-parse` (see "Options for Files" in git-rev-parse documentation): + - git-dir + - common-dir + - toplevel + - superproject-working-tree +- Add more values currently obtained through `git rev-parse --git-path`: + - grafts file + - index file + - objects directory + - hooks directory + - git-prefix + - other paths adjusted by `update_common_dir()` + +Some work to add path-related values +[has already started](https://github.com/lucasoshiro/git/compare/master...repo-info-path/), +so completing that work might be a good starting point. A major design decision +will need to be made on whether to use relative or absolute paths. + +**For `git repo structure`**, functionality from +[git-sizer](https://github.com/github/git-sizer) could be added to provide +more detailed repository analysis and statistics. + +The goal of this project is to discuss possible improvements to +`git repo` with the community, reach an agreement about the best +potential improvements, and then implement them. It requires the +desire to be involved in design discussions on the mailing list. + +**Getting started:** Build Git from source, experiment with `git repo info` and +`git repo structure` commands, study the implementation in `builtin/repo.c`, +review the initial GSoC proposal and discussions, compare functionality with +`git rev-parse` and identify gaps, and submit a micro-patch to demonstrate +familiarity with the codebase. + +**Resources:** +- [Initial implementation discussion](https://public-inbox.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/t/#u) +- [Official git-repo documentation](https://git-scm.com/docs/git-repo) +- [git-rev-parse documentation](https://git-scm.com/docs/git-rev-parse) +- [git-sizer tool](https://github.com/github/git-sizer) +- [Work-in-progress branch for path-related values](https://github.com/lucasoshiro/git/compare/master...repo-info-path/) + +_Expected Project Size_: 90 or 175 hours or 350 hours + +_Difficulty_: Medium + +_Languages_: C, shell(bash) + +_Possible mentors_: + +* Karthik Nayak < > +* Justin Tobler < > +* Ayush Chandekar < > +* Siddharth Asthana < > + +### Improve disk space recovery for partial clones + +Git's partial clone feature allows users to clone repositories without downloading +all objects immediately, which is particularly useful for very large repositories. +Objects are fetched on-demand from "promisor remotes" as needed. However, over time, +clients may accumulate large local blobs that are no longer needed but remain on disk, +and currently there's no easy way to reclaim this space. + +This project aims to improve `git backfill` (or create a new command) to allow +clients to remove large local blobs when they are available on a promisor remote. +This would help users who want to get back disk space while maintaining the ability +to re-fetch objects when needed. + +The project involves: +- Designing a safe mechanism to identify which blobs can be removed +- Implementing the removal process while maintaining repository integrity +- Ensuring removed objects can be transparently re-fetched when needed +- Adding appropriate safeguards and user controls + +**Important note:** While the project mentions `git backfill`, it is not yet +decided that it is right place to have this command. Other potential candidates +for placement are `git gc` / `git repack` / `git maintenance`. A design discussion +with the community is imminent as part of this project to finalize the most +appropriate placement and for this command. + +**Getting started:** Build Git from source, set up a partial clone and experiment +with promisor remotes, study the existing `git-backfill` command (if available) +or related functionality, understand how Git tracks and fetches objects from +promisor remotes, review documentation on partial clones in +`Documentation/technical/partial-clone.txt`, and submit a micro-patch to +demonstrate familiarity with the codebase. + +**Resources:** +- [Partial clone documentation](https://git-scm.com/docs/partial-clone) +- [Git Protocol v2 documentation](https://git-scm.com/docs/gitprotocol-v2) + +_Expected Project Size_: 175 hours or 350 hours + +_Difficulty_: Medium to Hard + +_Languages_: C, shell(bash) + +_Possible mentors_: + +* Christian Couder < > +* Karthik Nayak < > +* Justin Tobler < > +* Siddharth Asthana < > +* Ayush Chandekar < > + +### Implement promisor remote fetch ordering + +When a Git repository is configured with multiple promisor remotes, there's +currently no mechanism to specify or optimize the order in which these remotes +should be queried when fetching missing objects. Different remotes may have +different performance characteristics, costs, or reliability, making fetch +order an important consideration. + +This project aims to implement a fetch ordering mechanism for multiple promisor +remotes. The order could be: +- Configured locally by the client +- Advertised by servers through the promisor-remote protocol + +The key challenge is designing a flexible system that allows servers to +communicate their preferred fetch order to clients (to ensure optimal +performance and cost management). + +As this area is being worked on these days, coordination with others will likely +be required. + +**Getting started:** Build Git from source, set up a repository with multiple +promisor remotes and experiment with object fetching, study how Git currently +handles multiple remotes, review the promisor-remote protocol in +`Documentation/gitprotocol-v2.txt`, understand partial clone implementation, +and submit a micro-patch to demonstrate familiarity with the codebase. + +**Resources:** +- [Partial clone documentation](https://git-scm.com/docs/partial-clone) +- [Git Protocol v2 documentation](https://git-scm.com/docs/gitprotocol-v2) + +_Expected Project Size_: 175 hours or 350 hours + +_Difficulty_: Medium to Hard + +_Languages_: C, shell(bash) + +_Possible mentors_: + +* Christian Couder < > +* Karthik Nayak < > +* Justin Tobler < > +* Siddharth Asthana < > +* Ayush Chandekar < > + +### Enhance promisor-remote protocol for better-connected remotes + +Currently, the promisor-remote protocol allows servers to advertise remotes +that the server itself uses as promisor remotes. However, as suggested by +Junio Hamano, it would be useful in some cases if servers could advertise +"better-connected" remotes - remotes that might not be promisor remotes +for the server but would be good choices for the client. + +This enhancement would allow servers to guide clients toward optimal remote +configurations, potentially improving performance and reducing load on +individual servers by distributing requests across a network of remotes. + +This project involves: +- Extending the promisor-remote protocol to support advertising + better-connected remotes +- Implementing server-side logic to determine and advertise appropriate remotes +- Implementing client-side handling of these advertisements +- Designing the protocol extension with backward compatibility in mind +- Testing with various network topologies + +As this area is being worked on these days, coordination with others will likely +be required. + +**Getting started:** Build Git from source, study the current promisor-remote +protocol implementation, read Junio's suggestion in `Documentation/gitprotocol-v2.txt`, +understand how Git currently advertises and uses promisor remotes, set up test +scenarios with multiple interconnected remotes, and submit a micro-patch to +demonstrate familiarity with the codebase. + +**Resources:** +- [Partial clone documentation](https://git-scm.com/docs/partial-clone) +- [Git Protocol v2 documentation - promisor remote section](https://git-scm.com/docs/gitprotocol-v2#_promisor_remotepr_info) + +_Expected Project Size_: 175 hours or 350 hours + +_Difficulty_: Hard + +_Languages_: C, shell(bash) + +_Possible mentors_: + +* Christian Couder < > +* Karthik Nayak < > +* Justin Tobler < > +* Siddharth Asthana < > +* Ayush Chandekar < > + +### Complete and extend the `remote-object-info` command for `git cat-file` + +From around June 2024 to March 2025, work was undertaken by Eric Ju to add a +`remote-object-info` sub-command to `git cat-file`. This client-side work +builds upon previous server-side work by Calvin Wan that was merged in 2021. +The feature allows clients to request information about objects from a remote +repository without downloading the full object content, which can be especially +useful for partial clones and large repositories. + +See the [initial patch series](https://lore.kernel.org/git/20240628190503.67389-1-eric.peijian@gmail.com/) +for the original proposal and discussion. + +**The first goal** of this project is to rebase and finalize Eric Ju's +patch series by addressing the remaining feedback from the community review, +so that the improved series can be merged into Git. + +**The second goal** is to build on top of that work to add support for +object type information (`%(objecttype)`). This support should be +added both on the server side and on the client side, extending the +protocol to include this metadata and making it available to users. + +This project involves both protocol design and implementation work, requiring +careful attention to backward compatibility and performance considerations. + +**Getting started:** Build Git from source, study the existing `git cat-file` +command and its batch modes (particularly `--batch` and `--batch-check`), +review Eric Ju's patch series and the community feedback in detail, understand +Calvin Wan's merged server-side work from 2021, study the object-info protocol +extension in `Documentation/gitprotocol-v2.txt`, and submit a micro-patch to +demonstrate familiarity with the codebase. + +**Resources:** +- [Eric Ju's patch series (June 2024)](https://lore.kernel.org/git/20240628190503.67389-1-eric.peijian@gmail.com/) +- [git-cat-file documentation](https://git-scm.com/docs/git-cat-file) +- [Git Protocol v2 documentation](https://git-scm.com/docs/gitprotocol-v2) +- Calvin Wan's server-side work (2021) - search Git mailing list archives + +_Expected Project Size_: 90 or 175 hours or 350 hours + +_Difficulty_: Medium + +_Languages_: C, shell(bash) + +_Possible mentors_: + +* Christian Couder < christian.couder@gmail.com > +* Karthik Nayak < karthik.188@gmail.com > +* Justin Tobler < jltobler@gmail.com > +* Ayush Chandekar < ayu.chandekar@gmail.com > +* Siddharth Asthana < siddharthasthana31@gmail.com > +* Chandra Pratap < chandrapratap3519@gmail.com > + diff --git a/links/mentoring/soc/SoC-2026-Microprojects.md b/links/mentoring/soc/SoC-2026-Microprojects.md new file mode 100644 index 000000000..188fe3e02 --- /dev/null +++ b/links/mentoring/soc/SoC-2026-Microprojects.md @@ -0,0 +1,242 @@ +--- +layout: default +title: SoC 2026 Applicant Microprojects +--- + +## Introduction + +First make sure you read and understand +[our general guidelines and suggestions for microprojects](https://git.github.io/General-Microproject-Information). + +There are some suggestions on how you can find some microprojects on your own in the document. + +## Ideas for microprojects + +### Modernize Test Path Checking in Git's Test Suite + +Help improve Git's test suite by converting old-style path checks to use modern +helper functions. We'll be replacing basic shell test commands like `test -f` +with Git's dedicated test helpers like `test_path_is_file`. + +#### Steps to Complete +1. Find a test script using old-style path checks: + ```sh + git grep "test -[efd]" t/ + ``` + +2. Look for patterns like: + ```sh + test -f path/to/file # old way + test_path_is_file path/to/file # new way + + test -d some/directory # old way + test_path_is_dir some/directory # new way + ``` + +3. Important: Only replace checks that are actually testing for conditions, not + those used in flow control. For example: + ```sh + # DON'T change this - it's flow control + if test -e "file.txt"; then + do_something + fi + + # DO change this - it's a test assertion + test -e "file.txt" || error "file.txt should exist" + ``` + +#### Notes +- Start small: Pick a test file with just a few instances to convert +- Run the test suite after your changes to ensure nothing breaks +- Follow Git's commit message style +- Include which command you used to find the instances in your commit message + +#### Need Help? +- Reference [this discussion](https://public-inbox.org/git/CAPig+cRfO8t1tdCL6MB4b9XopF3HkZ==hU83AFZ38b-2zsXDjQ@mail.gmail.com/) + for detailed examples. +- If you can't find any instances to fix, let us know what search command you + used + +### Fix Improper Pluralization to Use `ngettext()` + +Help improve Git's internationalization (i18n) support by finding +translatable strings that include a numeric placeholder (`%d` or +`%i`) but use `_()` instead of `Q_()`. This matters because +some languages (like Polish) have more than two plural forms, and +`Q_()` is the only correct way to handle them. + +For example, the Polish word for "file" changes form depending on count: + +- 1 → *plik* +- 2 - 4 → *pliki* +- 5 - 21 → *plików* +- 22 - 24 → *pliki* +- 25 - 31 → *plików* + +A call like `_("Split into %d hunks.")` cannot be correctly translated +for all counts. It must be rewritten using `Q_()` which is an alias +for `ngettext()`. + +#### Steps to Complete + +1. Find candidate strings using: + +```bash +git grep '[^Q]_("[^"]*%[id]' -- '*.c' +``` + +2. Review the results and identify strings where the number genuinely + controls a **count of things** (hunks, branches, objects, etc.). Skip + messages where `%d` refers to something that is never pluralized, + such as an error code, a line number, or a timeout value: + +```c +// NOT a pluralization candidate — error code is never "plural" +die_errno(_("unable to get credential storage lock in %d ms"), timeout_ms); + +// IS a candidate — hunk count should be pluralized +_("Split into %d hunks.") +``` + +3. Rewrite the candidate using `ngettext()`: + +```c +// Before: +printf(_("Split into %d hunks."), n); + +// After: +printf(Q_("Split into %d hunk.", + "Split into %d hunks.", n), n); +``` + +4. Build and run the relevant tests to confirm nothing is broken. + +#### Notes + +- Pick **one source file** with a small number of instances to keep + the patch focused and reviewable. +- There are known candidates in `add-patch.c`, `archive-zip.c`, + `builtin/checkout.c`, `builtin/describe.c`, `builtin/fsck.c` — so + there should be plenty to choose from. +- Each logical change (e.g., one function or one file) should ideally + be its own commit. +- Follow Git's commit message conventions. +- Before starting, ask on the mailing list to confirm no one else is + working on the same file. + +#### Need Help? + +- See the [gettext manual on plural forms](https://www.gnu.org/software/gettext/manual/gettext.html#Plural-forms) + for background on why `ngettext()` is necessary. +- Search the codebase for existing `Q_()` usages as examples + of the correct pattern: + +```bash +git grep -3 'Q_(' -- '*.c' +``` + +- If you can't find any unfixed instances, let us know the search command + you used so we can retire this microproject idea. + + +### 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. + +### 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) + +### 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/links/mentoring/soc/SoC-Participants.md b/links/mentoring/soc/SoC-Participants.md new file mode 100644 index 000000000..b06bdc66f --- /dev/null +++ b/links/mentoring/soc/SoC-Participants.md @@ -0,0 +1,211 @@ +--- +layout: default +title: SoC participants +--- + +This document collects the list of contributors who've contributed +to Git via GSoC. + + + +### 2025 + +1. Ayush Chandekar [ [project](https://summerofcode.withgoogle.com/programs/2025/projects/no7dVMeG) ] [ [final report](https://ayu-ch.github.io/2025/08/29/gsoc-final-report.html) ] [ [blog](https://ayu-ch.github.io/) ] [ [retrsopective interview](https://git.github.io/rev_news/2025/11/30/edition-129/#developer-spotlight-ayush-chandekar) ] +2. Lucas Seiki Oshiro [ [project](https://summerofcode.withgoogle.com/programs/2025/projects/fGgMYHwl) ] [ [final report](https://lucasoshiro.github.io/gsoc-en/#final-report) ] [ [blog](https://lucasoshiro.github.io/gsoc-en/#weeks) ] [ [retrospective interview](https://git.github.io/rev_news/2025/12/31/edition-130#developer-spotlight-lucas-seiki-oshiro) ] +3. Meet Soni [ [project](https://summerofcode.withgoogle.com/programs/2025/projects/xVrT5e2q) ] [ [final report](https://inosmeet.github.io/posts/gsoc25/gsoc25_final/) ] [ [blog](https://inosmeet.github.io/posts/gsoc25/) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/programs/2025/organizations/git) +- [Rev News article](https://git.github.io/rev_news/2025/05/31/edition-123/) + +### 2024 + +1. Jialuo She [ [project](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF) ] [ [final report](https://luolibrary.com/2024/08/25/GSoC-Final-Report/) ] [ [blog](https://luolibrary.com/) ] [ [retrsopective interview](https://git.github.io/rev_news/2024/09/30/edition-115/#developer-spotlight-jialuo-she) ] +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/) ] [ [retrsopective interview](https://git.github.io/rev_news/2024/11/30/edition-117#developer-spotlight-ghanshyam-thakkar) ] +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/) ] [ [retrsopective interview](https://git.github.io/rev_news/2024/10/31/edition-116/#developer-spotlight-chandra-pratap) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2024/organizations/git) +- [Rev News article](https://git.github.io/rev_news/2024/05/31/edition-111/) + +### 2023 + +1. Shuqi Liang [ [project](https://summerofcode.withgoogle.com/archive/2023/projects/Rkbc1Abe) ] [ [final report](https://cheskaqiqi.github.io/2023/08/22/Final/) ] [ [blog](https://cheskaqiqi.github.io/tags/GSoC/) ] +2. Kousik Sanagavarapu [ [project](https://summerofcode.withgoogle.com/archive/2023/projects/rck3kmq2) ] [ [final report](https://five-sh.github.io/2023/08/26/the-final-report) ] [ [blog](https://five-sh.github.io/blog) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2023/organizations/git) +- [Rev News article](https://git.github.io/rev_news/2023/06/30/edition-100/) + +### 2022 + +1. Shaoxuan Yuan [ [project](https://summerofcode.withgoogle.com/archive/2022/projects/hz4rcOUB) ] [ [final report](https://ffyuanda.github.io/blog/GSoC-final-blog/) ] [ [blog](https://ffyuanda.github.io/tags/#learn) ] +2. Abhradeep Chakraborty [ [project](https://summerofcode.withgoogle.com/archive/2022/projects/UPtA6qdf) ] [ [final report](https://medium.com/@abhra303/gsoc-final-report-feaaacfae737) ] [ [blog](https://medium.com/@abhra303) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2022/organizations/git) +- [Rev News article](https://git.github.io/rev_news/2022/06/30/edition-88/) + + +### 2021 + +1. ZheNing Hu [ [project](https://summerofcode.withgoogle.com/archive/2021/projects/5443907994779648) ] [ [final report](https://github.com/adlternative/adlternative.github.io/blob/gh-pages/blogs/gsoc/GSOC-Git-Final-Blog.md) ] [ [blog](https://github.com/adlternative/adlternative.github.io/tree/gh-pages/blogs/gsoc/) ] [ [retrsopective interview](https://git.github.io/rev_news/2022/12/31/edition-94/#developer-spotlight-zhening-hu) ] +2. Atharva Raykar [ [project](https://summerofcode.withgoogle.com/archive/2021/projects/5071550033690624) ] [ [final report](https://github.com/tfidfwastaken/gitnotes/blob/main/final-report.md) ] [ [blog](https://github.com/tfidfwastaken/gitnotes/tree/main) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2021/organizations/6398200235163648) +- [Rev News article](https://git.github.io/rev_news/2021/05/27/edition-75/) + + +### 2020 + +1. Shourya Shukla [ [project](https://summerofcode.withgoogle.com/archive/2020/projects/4541259818991616) ] [ [final report](https://shouryashukla.blogspot.com/2020/08/the-final-report.html) ] [ [blog](https://shouryashukla.blogspot.com/search/label/GSoC) ] +2. Abhishek Kumar [ [project](https://summerofcode.withgoogle.com/archive/2020/projects/6510085276172288) ] [ [final report](https://github.com/abhishekkumar2718/GSoC20/blob/master/README.md) ] [ [blog](https://abhishekkumar2718.github.io/gsoc/) ] +3. Hariom Verma [ [project](https://summerofcode.withgoogle.com/archive/2020/projects/6123927484497920) ] [ [final report](https://harry-hov.github.io/blogs/posts/the-final-report) ] [ [blog](https://harry-hov.github.io/blogs/posts/) ] + + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2020/organizations/5445576591671296) +- [Rev News article](https://git.github.io/rev_news/2020/05/28/edition-63/) + + +### 2019 + +1. Rohit Ashiwal [ [project](https://summerofcode.withgoogle.com/archive/2019/projects/5390155215536128) ] [ [final report](https://web.archive.org/web/20210727190950/https://rashiwal.me/2019/final-report/) ] [ [blog](https://web.archive.org/web/20210515085551/https://rashiwal.me/) ] +2. Matheus Tavares [ [project](https://summerofcode.withgoogle.com/archive/2019/projects/4787791739748352) ] [ [final report](https://matheustavares.gitlab.io/posts/gsoc-final-report) ] [ [blog](https://matheustavares.gitlab.io/tags/git/) ] [ [retrsopective interview](https://git.github.io/rev_news/2020/10/30/edition-68/#developer-spotlight-matheus-tavares-bernardino) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2019/organizations/6548634445807616) +- [Rev News - May 2019](https://git.github.io/rev_news/2019/05/22/edition-51/) + + +### 2018 + +1. Pratik Karki [ [project](https://summerofcode.withgoogle.com/archive/2018/projects/5389615745728512) ] [ [final report](https://github.com/prertik/GSoC2018?tab=readme-ov-file) ] [ [blogs](https://prertik.github.io/categories/git/) ] +2. Paul-Sebastian Ungureanu [ [project](https://summerofcode.withgoogle.com/archive/2018/projects/6700324135895040) ] [ [final report and blogs](https://github.com/ungps/gsoc2018?tab=readme-ov-file) ] +3. Alban Gruin [ [project](https://summerofcode.withgoogle.com/archive/2018/projects/6165469845258240) ] [ [final report](https://github.com/agrn/gsoc2018?tab=readme-ov-file) ] [ [blogs](https://blog.pa1ch.fr/category/gsoc-2018.html) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2018/organizations/4840889583140864) +- [Rev News - May 2018](https://git.github.io/rev_news/2018/05/16/edition-39/) + +### 2017 + +1. Prathamesh Chavan [ [project](https://summerofcode.withgoogle.com/archive/2017/projects/5434523185577984) ] [ [final report](https://docs.google.com/document/d/1RmUvJBf4x8TI71Fltg8xWP-s7zkhz3bGPyEJMgRx91Y/edit#heading=h.5r7i4cugqwi3) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2017/organizations/5061577619275776) +- [Rev News - Oct 2017](https://git.github.io/rev_news/2017/10/11/edition-32/) + +### 2016 + +1. Pranit Bauva [ [project](https://summerofcode.withgoogle.com/archive/2016/projects/5595001820020736) ] [ [final report](https://docs.google.com/document/d/1Uir0a8cRYlWANuzoU4iTDtEvPukvtTJcC_dB3KJUgqM/edit#heading=h.mipx2w79za4f) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2016/organizations/5532648021688320#projects-list) +- [Rev News - Oct 2016](https://git.github.io/rev_news/2016/09/14/edition-19/) + +### 2015 + +1. Karthik Nayak [ [project](https://www.google-melange.com/archive/gsoc/2015/orgs/git/projects/karthiknayak94.html) ] [ [fork](https://github.com/KarthikNayak/git) ] [ [a mailing list mail](https://public-inbox.org/git/553F7A50.1080907@gmail.com/) ] +2. Paul Tan [ [project](https://www.google-melange.com/archive/gsoc/2015/orgs/git/projects/pyokagan.html) ] [ [fork](https://github.com/pyokagan/git) ] [ [a mailing list mail](https://public-inbox.org/git/CACRoPnQ5_r-26J4gBHc27KZt3X9KAU7eFkA3vz_GE6_dP-Uyug@mail.gmail.com/) ] + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2015/orgs/git) +- [Rev News - May 2015](https://git.github.io/rev_news/2015/05/13/edition-3/#other-news) + +### 2014 + +1. Tanay Abhra [ [project](https://www.google-melange.com/archive/gsoc/2014/orgs/git/projects/tanayabh.html) ] +2. Fabian Ruch [ [project](https://www.google-melange.com/archive/gsoc/2014/orgs/git/projects/bafain.html) ] + + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2014/orgs/git) +- [GSoC retrospective](https://public-inbox.org/git/vpqsik1yg1l.fsf@anie.imag.fr/) + + +### 2013 + +***Did not participate*** + + +### 2012 + +1. Thomas Gummerer [ [project](https://www.google-melange.com/archive/gsoc/2012/orgs/git/projects/tgummerer.html) ] [ [retrsopective interview](https://git.github.io/rev_news/2016/02/10/edition-12/#developer-spotlight-thomas-gummerer) ] +1. Michael Schubert [ [project](https://www.google-melange.com/archive/gsoc/2012/orgs/git/projects/schu.html) ] +1. Florian Achleitner [ [project](https://www.google-melange.com/archive/gsoc/2012/orgs/git/projects/flyingflo.html) ] + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2012/orgs/git) + + +### 2011 + +1. Carlos Martín Nieto [ [project](https://www.google-melange.com/archive/gsoc/2011/orgs/git/projects/carlosmn.html) ] +1. Ramkumar Ramachandra [ [project](https://www.google-melange.com/archive/gsoc/2011/orgs/git/projects/artagnon.html) ] +1. Fredrik Gustafsson [ [project](https://www.google-melange.com/archive/gsoc/2011/orgs/git/projects/iveqy.html) ] + + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2011/orgs/git) + + +### 2010 + +1. Vicent Marti [ [project](https://www.google-melange.com/archive/gsoc/2010/orgs/git/projects/tanoku.html) ] +1. Ramkumar Ramachandra [ [project](https://www.google-melange.com/archive/gsoc/2010/orgs/git/projects/artagnon.html) ] +1. Bo Yang [ [project](https://www.google-melange.com/archive/gsoc/2010/orgs/git/projects/struggleyb.html) ] + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2010/orgs/git) + +### 2009 + +1. Nick Edelen [ [project](https://www.google-melange.com/archive/gsoc/2009/orgs/git/projects/sirnot.html) ] + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2009/orgs/git) + + +### 2008 + +1. Joshua Roys (_project_: GitTorrent) [ [final e-mail](https://lore.kernel.org/git/48C05FB5.3010901@gmail.com/) ] +2. Sverre Rabbelier (_project_: git-statistics) [ [final e-mail](https://lore.kernel.org/git/bd6139dc0809041544o427356c9i40a28b1c182817eb@mail.gmail.com/) ] +3. Lea Wiemann (_project_: Gitweb caching) [ [idea discussion](https://lore.kernel.org/git/483C4CFF.2070101@gmail.com/#t) ] +4. Marek Zawirski (_project_: Eclipse plugin push support) [ [final e-mail](https://lore.kernel.org/git/48C564ED.7050402@gmail.com/) ] +5. Miklos Vajna (_project_: git-merge builtin) [ [final e-mail](https://lore.kernel.org/git/20080904225559.GP16514@genesis.frugalware.org/) ] +6. Stephan Beyer (_project_: git-sequencer) [ [final e-mail](https://lore.kernel.org/git/20080904223653.GA15170@leksak.fem-net/) ] + +#### References + +- [GSoC archive](https://developers.google.com/open-source/gsoc/2008?csw=1#git-development-community) +- [Mail about GSoC participant summary](https://lore.kernel.org/git/200809042315.58898.jnareb@gmail.com/) +- [GSoC selection summary](https://lore.kernel.org/git/20080422013201.GA4828@spearce.org/) + + +### 2007 + +1. Carlos Rica (_project_: Shell script to C builtin conversions) +2. Luiz Capitulino (_project_: Libification) + +#### References + +- [GSoC archive](https://developers.google.com/open-source/gsoc/2007?csw=1#git-development-community) +- [GSoC report](https://lore.kernel.org/git/20070903034201.GP18160@spearce.org/) diff --git a/rev_news/archive.md b/rev_news/archive.md index a02bf67f6..bd113725c 100644 --- a/rev_news/archive.md +++ b/rev_news/archive.md @@ -1,11 +1,12 @@ --- layout: default title: Git Rev News Archive +order: 3 --- # Archive -Here you can see all the previous editions. See [About Git Rev News](/rev_news/rev_news/) for ways you can subscribe. +Here you can see all the previous editions. See [About Git Rev News](https://git.github.io/rev_news/rev_news/) for ways you can subscribe.
      {% for post in site.posts %} diff --git a/rev_news/drafts/edition-46.md b/rev_news/drafts/edition-134.md similarity index 60% rename from rev_news/drafts/edition-46.md rename to rev_news/drafts/edition-134.md index 3dcfa98de..0d238ad44 100644 --- a/rev_news/drafts/edition-46.md +++ b/rev_news/drafts/edition-134.md @@ -1,19 +1,19 @@ --- -title: Git Rev News Edition 46 (XXX, 2018) +title: Git Rev News Edition 134 (April 30th, 2026) layout: default -date: 2018-12-19 12:06:51 +0100 +date: 2026-04-30 12:06:51 +0100 author: chriscool categories: [news] navbar: false --- -## Git Rev News: Edition 46 (XXX, 2018) +## Git Rev News: Edition 134 (April 30th, 2026) -Welcome to the 46th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +Welcome to the 134th 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). +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). -This edition covers what happened during the month of November 2018. +This edition covers what happened during the months of March and April 2026. ## Discussions @@ -33,9 +33,6 @@ This edition covers what happened during the month of November 2018. ## Developer Spotlight: --> -## Releases - - ## Other News __Various__ @@ -43,15 +40,21 @@ __Various__ __Light reading__ + __Git tools and sites__ +## Releases + + ## Credits This edition of Git Rev News was curated by Christian Couder <>, Jakub Narębski <>, Markus Jansen <> and -Gabriel Alcaras <> +Kaartic Sivaraam <> with help from XXX. diff --git a/rev_news/edition-1.md b/rev_news/edition-1.md index c1c9ff28f..ecc486f64 100644 --- a/rev_news/edition-1.md +++ b/rev_news/edition-1.md @@ -27,7 +27,7 @@ requests](https://github.com/git/git.github.io/pulls) or opening ### General -* [Promoting Git developers](http://thread.gmane.org/gmane.comp.version-control.git/265165) (*written by Junio C Hamano*) +* [Promoting Git developers](https://public-inbox.org/git/54FDA6B5.8050505%40drmicha.warpmail.net/) (*written by Junio C Hamano*) Following up to a message from David Kastrup, a discussion was initiated by Christian Couder where Michael J Gruber noted @@ -46,15 +46,14 @@ contributors and thank for their help for each release. ### Reviews -* [make git-pull a builtin](http://thread.gmane.org/gmane.comp.version-control.git/265628/) +* [make git-pull a builtin](https://public-inbox.org/git/1426600662-32276-1-git-send-email-pyokagan%40gmail.com/) Paul Tan, who will probably apply to be a [Google Summer of Code (GSoC)](https://developers.google.com/open-source/soc/) student for Git this year, anticipated the start of the GSoC and sent a patch to rewrite git-pull.sh as a built-in. -Indeed as stated in [the GSoC idea -page](https://git.github.io/SoC-2015-Ideas.html): +Indeed as stated in [the GSoC idea page](https://git.github.io/SoC-2015-Ideas/): ``` Many components of Git are still in the form of shell and Perl @@ -116,13 +115,13 @@ they do, add a failing test that passes again once you uncomment the code. ``` -* [Forbid "log --graph --no-walk"](http://thread.gmane.org/gmane.comp.version-control.git/264899/) +* [Forbid "log --graph --no-walk"](https://public-inbox.org/git/1425632110-31863-1-git-send-email-dongcan.jiang%40gmail.com/) Dongcan Jiang, who will also probably apply to be a GSoC student for Git this year, sent a patch to prevent `git log` from being used with both the `--graph` and the `--no-walk` option. He sent this patch because the Git community asks potential students to work on a -[microproject](https://git.github.io/SoC-2015-Microprojects.html) to +[microproject](https://git.github.io/SoC-2015-Microprojects/) to make sure that they can work properly with the community. Eric Sunshine made some good general suggestions that are often made @@ -144,7 +143,7 @@ or: Okay. You might also want to cite the wider discussion[1]. -[1]: http://article.gmane.org/gmane.comp.version-control.git/216083 +[1]: https://public-inbox.org/git/7vvc9ylh97.fsf%40alter.siamese.dyndns.org/ > revision.c: Judge whether --graph and --no-walk come together when running git-log. > buildin/log.c: Set git-log cmd flag. @@ -167,7 +166,7 @@ command about a connected history. Otherwise, it is a command about discrete point(s). ``` -* [War on broken &&-chain](http://thread.gmane.org/gmane.comp.version-control.git/265874) (*written by Junio C Hamano*) +* [War on broken &&-chain](https://public-inbox.org/git/20150320100429.GA17354%40peff.net/) (*written by Junio C Hamano*) We often see review comments on test scripts that points out a breakage in the &&-chain, but what does that mean? @@ -212,7 +211,7 @@ runs only on a case insensitive filesystem a few days later. ### Support -* [Git with Lader logic](http://thread.gmane.org/gmane.comp.version-control.git/265679/) +* [Git with Lader logic](https://public-inbox.org/git/5F9B9EBF-CD4D-42A8-8A0C-9806702231A1%40icloud.com/) People often ask the Git mailing list whether they can use Git to manage special content. Fortunately, the list is monitored by many experts in different @@ -282,7 +281,7 @@ The latest maintenance release Git v2.3.2 is now available at the usual places. ``` -* [Commandline GUI-tool *tig* version 2.1](http://article.gmane.org/gmane.comp.version-control.git/265298), March 11th: +* [Commandline GUI-tool *tig* version 2.1](https://public-inbox.org/git/CAFuPQ1%2BD3QY8MxNRX87R6-nUR9eP3JRTq_yuWfRq1upQT7iC8w%40mail.gmail.com/), March 11th: ``` I just released version 2.1 of Tig which brings a lot of improvements to speed @@ -300,7 +299,7 @@ noteworthy is the change to how certificate errors are handled during authentica For more details check out the change log: http://www.nodegit.org/changelog/#v0-3-0 ``` -* [Git v.2.3.3](http://permalink.gmane.org/gmane.linux.kernel/1908634), March 14th: +* [Git v.2.3.3](https://public-inbox.org/git/xmqqzj7gvyrn.fsf%40gitster.dls.corp.google.com/), March 14th: ``` The latest maintenance release Git v2.3.3 is now available at @@ -308,7 +307,7 @@ the usual places. It is comprised of 26 non-merge commits since v2.3.2, contributed by 11 people, 1 of which is a new contributor. ``` -* [Git v2.3.4](http://permalink.gmane.org/gmane.linux.kernel/1915412), March 23rd: +* [Git v2.3.4](https://public-inbox.org/git/xmqqlhin8kh9.fsf%40gitster.dls.corp.google.com/), March 23rd: ``` The latest maintenance release Git v2.3.4 is now available at the diff --git a/rev_news/index.md b/rev_news/index.md index 35353e4ee..c729e65d4 100644 --- a/rev_news/index.md +++ b/rev_news/index.md @@ -1,6 +1,7 @@ --- layout: default -title: Git Rev News +title: Git Rev News Latest +order: 2 --- # Latest edition diff --git a/rev_news/news_sources.md b/rev_news/news_sources.md index 3e3f4a995..38bfc3913 100644 --- a/rev_news/news_sources.md +++ b/rev_news/news_sources.md @@ -1,6 +1,7 @@ --- layout: default title: Git Rev News Sources +order: 4 --- # Sources @@ -28,7 +29,6 @@ Some ideas on where we can go to gather Git Rev News material. [here](https://hn.algolia.com/?query=git&sort=byPopularity&prefix=false&page=0&dateRange=last24h&type=story) or [here](http://newscombinator.com/)) * [Reddit/git](http://www.reddit.com/r/git) (offers RSS) -* [Git community on Google+](https://plus.google.com/communities/112688280189071733518) * [The Changelog/Git](https://changelog.com/topic/git/) * ... @@ -51,6 +51,6 @@ For every upcoming edition, do the following: Everyone from the editor team should have account access. Links can be handily collected using a browser extension like [diigo](https://www.diigo.com/user/Tfnico/gitrevnews), -but note that popular may be duplicated by other contributors. +but note that popular links may be duplicated by other contributors. When adding links, this is a great tool: [chitsaou/copy-as-markdown](https://github.com/chitsaou/copy-as-markdown/) diff --git a/rev_news/rev_news.md b/rev_news/rev_news.md index 598cf1869..1e348c8a5 100644 --- a/rev_news/rev_news.md +++ b/rev_news/rev_news.md @@ -1,6 +1,7 @@ --- layout: default title: About Git Rev News +order: 1 --- # About Git Rev News @@ -14,12 +15,17 @@ some of the interesting Git-related articles, tools and projects we come across. ## Subscribe -Subscribe to Git Rev News by [RSS/atom](/feed.xml) or by signing up for the +Subscribe to Git Rev News by [RSS/atom](https://git.github.io/feed.xml) or by signing up for the [Email Newsletter](http://eepurl.com/bjP2WT). ## Archives -You can find a listing of all previous editions on the [Git Rev News Archive](/rev_news/archive/) page. +You can find a listing of all previous editions on the [Git Rev News Archive](https://git.github.io/rev_news/archive/) page. + +The web page is autogenerated based on the files stored in the `_posts` directory. +The basic mapping is edition https://git.github.io/rev_news/YYYY/MM/DD/edition-NN/ +will be found in repo at +https://github.com/git/git.github.io/blob/master/_posts/YYYY-MM-DD-edition-NN.markdown ## Contribute @@ -28,7 +34,8 @@ or opening [issues](https://github.com/git/git.github.io/issues). There is usually an issue opened for the upcoming edition. This issue should have near its top a link to a sometimes very rough draft of the -upcoming edition. +upcoming edition. The draft for the next edition is usually +[here](https://github.com/git/git.github.io/tree/master/rev_news/drafts) Don't hesitate to use the `edit` button that looks like a pen to edit this draft and to change whatever you want. When you are done, you diff --git a/script/script.js b/script/script.js new file mode 100644 index 000000000..4e0dfb012 --- /dev/null +++ b/script/script.js @@ -0,0 +1,9 @@ +const NAVBAR_LI_ELEMENTS = document.getElementById('navbar').firstElementChild.children; // Access all the
    • in side navigation + +// check for a match with the
    • element and SITE_URL, then make it active +Array.from(NAVBAR_LI_ELEMENTS).forEach((liElement) => { + if (liElement.firstElementChild.href == location.href) { + liElement.classList.add('active'); + return; + } +}) \ No newline at end of file