Highlights from Git 2.40
The first Git release of the year is here! Take a look at some of our highlights on what’s new in Git 2.40.
![](https://github.blog/wp-content/uploads/2023/03/git-240-2.png?resize=1600%2C850)
The open source Git project just released Git 2.40 with features and bug fixes from over 88 contributors, 30 of them new.
We last caught up with you on the latest in Git when 2.39 was released. To celebrate this most recent release, here’s GitHub’s look at some of the most interesting features and changes introduced since last time.
- Longtime readers will recall our coverage of
git jump
from way back in our Highlights from Git 2.19 post. If you’re new around here, don’t worry: here’s a brief refresher.git jump
is an optional tool that ships with Git in itscontrib directory
.git jump
wraps other Git commands, likegit grep
and feeds their results into Vim’s quickfix list. This makes it possible to write something likegit jump grep foo
and have Vim be able to quickly navigate between all matches of “foo” in your project.git jump
also works withdiff
andmerge
. When invoked indiff
mode, the quickfix list is populated with the beginning of each changed hunk in your repository, allowing you to quickly scan your changes in your editor before committing them.git jump merge
, on the other hand, opens Vim to the list of merge conflicts.In Git 2.40,
git jump
now supports Emacs in addition to Vim, allowing you to usegit jump
to populate a list of locations to your Emacs client. If you’re an Emacs user, you can try outgit jump
by running:M-x grep
git jump --stdout grep foo [source]
-
If you’ve ever scripted around a Git repository, you may be familiar with Git’s
cat-file
tool, which can be used to print out the contents of arbitrary objects.Back when v2.38.0 was released, we talked about how
cat-file
gained support to apply Git’s mailmap rules when printing out the contents of a commit. To summarize, Git allows rewriting name and email pairs according to a repository’s mailmap. In v2.38.0,git cat-file
learned how to apply those transformations before printing out object contents with the new--use-mailmap
option.But what if you don’t care about the contents of a particular object, and instead want to know the size? For that, you might turn to something like
--batch-check=%(objectsize)
, or-s
if you’re just checking a single object.But you’d be mistaken! In previous versions of Git, both the
--batch-check
and-s
options togit cat-file
ignored the presence of--use-mailmap
, leading to potentially incorrect results when the name/email pairs on either side of a mailmap rewrite were different lengths.In Git 2.40, this has been corrected, and
git cat-file -s
and--batch-check
with will faithfully report the object size as if it had been written using the replacement identities when invoked with--use-mailmap
.[source]
-
While we’re talking about scripting, here’s a lesser-known Git command that you might not have used:
git check-attr
.check-attr
is used to determine whichgitattributes
are set for a given path.These attributes are defined and set by one or more
.gitattributes
file(s) in your repository. For simple examples, it’s easy enough to read them off from a.gitattributes
file, like this:$ head -n 2 .gitattributes * whitespace=!indent,trail,space *.[ch] whitespace=indent,trail,space diff=cpp
Here, it’s relatively easy to see that any file ending in
*.c
or*.h
will have the attributes set above. But what happens when there are more complex rules at play, or your project is using multiple.gitattributes
files? For those tasks, we can usecheck-attr
:$ git check-attr -a git.c git.c: diff: cpp git.c: whitespace: indent,trail,space
In the past, one crucial limitation of
check-attr
is that it required an index, meaning that if you wanted to usecheck-attr
in a bare repository, you had to resort to temporarily reading in the index, like so:TEMP_INDEX="$(mktemp ...)" git read-tree --index-output="$TEMP_INDEX" HEAD GIT_INDEX_FILE="$TEMP_INDEX" git check-attr ...
This kind of workaround is no longer required in Git 2.40 and newer. In Git 2.40,
check-attr
supports a new--source=
to scan for.gitattributes
in, meaning that the following will work as an alternative to the above, even in a bare repository:$ git check-attr -a --source=HEAD^{tree} git.c git.c: diff: cpp git.c: whitespace: indent,trail,space
[source]
-
Over the years, there has been a long-running effort to rewrite old parts of Git from their original Perl or Shell implementations into more modern C equivalents. Aside from being able to use Git’s own APIs natively, consolidating Git commands into a single process means that they are able to run much more quickly on platforms that have a high process start-up cost, such as Windows.
On that front, there are a couple of highlights worth mentioning in this release:
In Git 2.40,
git bisect
is now fully implemented in C as a native builtin. This is the result of years of effort from many Git contributors, including a large handful of Google Summer of Code and Outreachy students.Similarly, Git 2.40 retired the legacy implementation of
git add --interactive
, which also began as a Shell script and was re-introduced as a native builtin back in version 2.26, supporting both the new and old implementation behind an experimentaladd.interactive.useBuiltin
configuration.Since that default has been “true” since version 2.37, the Git project has decided that it is time to get rid of the now-legacy implementation entirely, marking the end of another years-long effort to improve Git’s performance and reduce the footprint of legacy scripts.
-
Last but not least, there are a few under-the-hood improvements to Git’s CI infrastructure. Git has a handful of long-running Windows-specific CI builds that have been disabled in this release (outside of the
git-for-windows
repository). If you’re a Git developer, this means that your CI runs should complete more quickly, and consume fewer resources per push.On a similar front, you can now configure whether or not pushes to branches that already have active CI jobs running should cancel those jobs or not. This may be useful when pushing to the same branch multiple times while working on a topic.
This can be configured using Git’s
ci-config
mechanism, by adding a special script calledskip-concurrent
to a branch calledci-config
. If your fork of Git has that branch then Git will consult the relevant scripts there to determine whether CI should be run concurrently or not based on which branch you’re working on.
The rest of the iceberg
That’s just a sample of changes from the latest release. For more, check out the release notes for 2.40, or any previous version in the Git repository.
Tags:
Written by
Related posts
![](https://github.blog/wp-content/uploads/2024/05/Collaboration-LightMode-3.png?resize=400%2C212)
How to build an open source metrics dashboard
How GitHub volunteers built an open source metrics dashboard for the World Health Organization and some best practices they picked up along the way.
![](https://github.blog/wp-content/uploads/2024/05/Collaboration-LightMode-2-1.png?resize=400%2C212)
Automating open source: How Ersilia distributes AI models to advance global health equity
Discover how the Ersilia Open Source Initiative accelerates drug discovery by using GitHub Actions to disseminate AI/ML models.
![Orange rectangle with the Git logo and white text overlaid, which reads "Git 2.46 is here!"](https://github.blog/wp-content/uploads/2024/07/git-246.png?resize=400%2C212)
Highlights from Git 2.46
Git 2.46 is here with new features like pseudo-merge bitmaps, more capable credential helpers, and a new git config command. Check out our coverage on some of the highlights here.