The open source Git project justreleased 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 Gitwhen 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 ofgit jump from way back in ourHighlights 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’squickfix 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 grepgit jump --stdout grep foo

  [source]

• If you’ve ever scripted around a Git repository, you may be familiar with Git’scat-file tool, which can be used to print out the contents of arbitrary objects.

  Back when v2.38.0was released, we talked about howcat-file gained support to apply Git’smailmap 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, andgit 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 ofcheck-attr is that it required anindex, meaning that if you wanted to usecheck-attr in abare 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 ofgit 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.

  [source,source]

• 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 thegit-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’sci-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.

  [source,source]

The rest of the iceberg

That’s just a sample of changes from the latest release. For more, check out the release notes for2.40, orany previous version in the Git repository.

Written by

Taylor Blau

@ttaylorr

Taylor Blau is a Staff Software Engineer at GitHub where he works on Git.

• Git