Welcome to the 111th edition of Git 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 on git.github.io.
This edition covers what happened during the months of April and May 2024.
[GSoC] Welcoming our 2024 contributors and thanking our applicants
The Git project was accepted in the Google Summer of Code (GSoC) this year again, and 3 applicants were selected:
Jialuo She will work on the “Implement consistency check for refs” project mentored by Karthik Nayak and Patrick Steinhardt. He already started posting on his blog, and will push his work to his Git repo.
Ghanshyam Thakkar will work on the “Move existing tests to a unit testing framework” project mentored by Kaartic Sivaraam and Christian Couder. He already started posting on his blog, and will push his work to his Git repo.
Chandra Pratap will work on the “Move and improve reftable tests in the unit testing framework” project mentored by Patrick Steinhardt and Christian Couder. He already started posting on his blog, and will push his work to his Git repo.
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 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.
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.
[PATCH 0/3] color: add support for 12-bit RGB colors
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 allow users to customize how Git colorizes its output.
Before Beat’s patch series, the code supported the following:
normal, blue, red, etc,[1;38;5;254;48;5;255m , and#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 that incorporated Junio’s patch. Both Junio and Peff approved of it, so it was later merged into the ‘master’ branch.
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,
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.
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 and 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, 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 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 and the rest of the beginner’s documentation, 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 😉
Various
Light reading
actions/checkout.Easy watching
Git tools and sites
/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).This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Jakub Narębski <jnareb@gmail.com>, Markus Jansen <mja@jansen-preisler.de> and Kaartic Sivaraam <kaartic.sivaraam@gmail.com> with help from Beat Bolli, Sven Strickroth, David Aguilar, Bruno Brito and Štěpán Němec.