Welcome to the 117th 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 October and November 2024.
Bug report: v2.47.0 cannot fetch version 1 pack indexes
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 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.
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
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 and send-email/format-patch
for email interactions. And for development, I use Neovim
and clangd LSP
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 and SubmittingPatches. And then start with some #leftoverbits 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.
Light reading
--path-walk option to git repack
and the pack.usePathWalk config option to Git,
and to the new experimental git survey command
(that for now is present in Microsoft’s fork of Git),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”)..git-blame-ignore-revs)
by Marijke Luttekes on her blog.Git tools and sites
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.
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 Ghanshyam Thakkar, Johannes Schindelin, Štěpán Němec, Bruno Brito and Toon Claes.