Git Rev News: Edition 64 (June 25th, 2020)
Welcome to the 64th 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 month of May 2020.
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
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
1as 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.repositoryFormatVersionconfig option to
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.partialcloneis 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.repositoryFormatVersionupgrade by suggesting the following criteria:
(1) if upgrading from v0, there must be no
(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.repositoryFormatVersionhas been upgraded to
So for example if
extensions.worktreeConfigis set to
core.repositoryFormatVersionisn’t set, then with the patch Git will behave as if
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’.
- Git 2.27.0
- Git for Windows 2.27.0(1)
- git-filter-repo 2.27.1, 2.27.0
- libgit2 1.0.1
- GitLab 13.0.6, 12.10.11, 12.9.10, 12.10.10, 13.0.5, 13.0.4, 12.10.9, 12.9.9, 12.10.8, 13.0.3, 13.0.1, 12.10.7, 12.9.8
- Bitbucket Server 7.3
- Gerrit Code Review 3.2.2, 3.1.7, 3.0.11, 3.2.1, 3.1.6, 3.0.10, 2.16.21, 2.15.19, 2.14.21, 3.2.0, 2.16.20, 3.1.5, 3.0.9
- GitHub Enterprise 2.21.0, 2.20.9, 2.19.15, 2.18.20
- GitKraken 7.0.1
- GitHub Desktop 2.5.2, 2.5.1
- The Git PLC (Project Leadership Committee) announced
that it drafted a statement “regarding Git and branch naming” with
the Software Freedom Conservancy that
has been posted at Conservancy’s site.
Articles related to this issue include:
- Proposal to Rename the ‘Master’ Branch of WordPress-Owned Git Repositories
- Loaded terms in free software [LWN.net]
- Replacing master in git
- Migrating your default git branch to ‘main’
- 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, implemented a read-only IMAP/IMAPS server, 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.
A new Hacking Git page lists documents helpful to develop Git.
Introducing GitHub Super Linter: one linter to rule them all by Lucas Gravley on GitHub Blog.
- DVC 1.0 release: new features for MLOps; the 1.0 Pre-release was mentioned in a previous edition of Git Rev News.
- Using GitHub Actions for MLOps (Machine Learning Operations) & Data Science by Hamel Husain on GitHub Blog.
- How to squash git commits by Srebalaji Thirumalai.
- Rebase and retag and Rebase and retag, but manually 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 by Mark Dominus (a very specific use-case).
- Speeding up a Git monorepo at Dropbox with <200 lines of code by Utsav Shah on Dropbox.Tech .
git difffor a simple and powerful test harness by Chris Morgan
- Git Explained: Proper Team Etiquette by Milu.
Git tools and sites
- Piranha by Uber is an Open Source tool for automated clean up of stale code caused by feature flags that are no longer required. It currently supports Java, Swift, and Objective-C.
- git-fuzzy is a CLI interface to Git that relies heavily on the fzf general-purpose command-line fuzzy finder (version 0.21.0 or higher).
This edition of Git Rev News was curated by Christian Couder <email@example.com>, Jakub Narębski <firstname.lastname@example.org>, Markus Jansen <email@example.com> and Kaartic Sivaraam <firstname.lastname@example.org>.