{"id":92344,"date":"2025-11-17T09:54:31","date_gmt":"2025-11-17T17:54:31","guid":{"rendered":"https:\/\/github.blog\/?p=92344"},"modified":"2025-11-17T10:18:15","modified_gmt":"2025-11-17T18:18:15","slug":"highlights-from-git-2-52","status":"publish","type":"post","link":"https:\/\/github.blog\/open-source\/git\/highlights-from-git-2-52\/","title":{"rendered":"Highlights from Git 2.52"},"content":{"rendered":"\n

The open source Git project just released Git 2.52<\/a> with features and bug fixes from over 94 contributors, 33 of them new. We last caught up with you on the latest in Git back when 2.51 was released<\/a>.<\/p>\n\n\n\n

To celebrate this most recent release, here is GitHub’s look at some of the most interesting features and changes introduced since last time.<\/p>\n\n\n\n

Tree-level blame information<\/h1>\n\n\n\n

<\/p>

If you’re a seasoned Git user, then you are no doubt familiar with git blame, Git’s tool for figuring out which commit most recently modified each line at a given filepath. Git’s blame functionality is great for figuring out when a bug was introduced, or why some code was written the way it was.<\/p>

\nIf you want to know which commit last modified any portion of a given filepath, that’s easy enough to do with git log -1 -- path\/to\/my\/file<\/code>, since -1<\/code> will give us only the first commit which modifies that path. But what if instead you want to know which commit most recently modified every file in some directory? Answering that question may seem contrived, but it’s not. If you’ve ever looked at a repository’s file listing on GitHub, the middle column of information has a link to the commit which most recently modified that path, along with (part of) its commit message.<\/p>\n\n\n\n

\"Screenshot
GitHub’s repository file listing, showing tree-level blame information.<\/em><\/figcaption><\/figure>\n\n\n\n

The question remains: how do we efficiently determine which commit most recently modified each file in a given directory? You could imagine that you might enumerate each tree entry, feeding it to git log -1<\/code> and collecting the output there, like so:<\/p>\n\n\n

\n
$ git ls-tree -z --name-only HEAD^{tree} | xargs -0 -I{} sh -c '\n    git log -1 --format=\"$1 %h %s\" -- $1\n  ' -- {}  | column -t -l3 \n.cirrus.yml     1e77de10810  ci: update FreeBSD image to 14.3\n.clang-format   37215410730  clang-format: exclude control macros from SpaceBeforeParens\n.editorconfig   c84209a0529  editorconfig: add .bash extension\n.gitattributes  d3b58320923  merge-file doc: set conflict-marker-size attribute\n.github         5db9d35a28f  Merge branch 'js\/ci-github-actions-update'\n[...]<\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
That works, but not efficiently. To see why, consider a case with files A<\/code>, B<\/code>, and C<\/code> introduced by commits C1<\/code>, C2<\/code>, and C3<\/code>, respectively. To blame A<\/code>, we walk from C3<\/code> back to C1<\/code> in order to determine that C1<\/code> was the most recent commit to modify A<\/code>. That traversal passed through C2<\/code> and C3<\/code>, but since we were only looking for modifications to A<\/code>, we’ll end up revisiting those commits when trying to blame B<\/code> and C<\/code>. In this example, we visit those three commits six times in total, which is twice the necessary number of history traversals.<\/p>\n\n\n\n
Git 2.52 introduces a new command which comes up with the same information in a fraction of the time: git last-modified<\/code>. To get a sense for how much faster last-modified<\/code> is than the example above, here are some hyperfine<\/a> results:<\/p>\n\n\n
\n
Benchmark 1: git ls-tree + log\n  Time (mean ± σ):      3.962 s ±  0.011 s    [User: 2.676 s, System: 1.330 s]\n  Range (min … max):    3.940 s …  3.984 s    10 runs\n\nBenchmark 2: git last-modified\n  Time (mean ± σ):     722.7 ms ±   4.6 ms    [User: 682.4 ms, System: 40.1 ms]\n  Range (min … max):   717.3 ms … 731.3 ms    10 runs\n\nSummary\n  git last-modified ran\n    5.48 ± 0.04 times faster than git ls-tree + log<\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
The core functionality behind git last-modified<\/code> was written by GitHub over many years (originally called blame-tree<\/code> in GitHub’s fork of Git), and is what has powered our tree-level blame since 2012. Earlier this year, we shared those patches<\/a> with engineers at GitLab, who tidied up years of development<\/a> into a reviewable series<\/a> of patches which landed in this release.<\/p>\n\n\n\n
There are still some features in GitHub’s version of this command that have yet to make their way into a Git release, including an on-disk format to cache the results of previous runs. In the meantime, check out git last-modified<\/code><\/a>, available in Git 2.52.<\/p>\n\n\n\n
[source<\/a>, source<\/a>, source<\/a>]<\/p>\n\n\n\n
Advanced repository maintenance strategies<\/h1>\n\n\n\n
Returning readers of this series may recall<\/a> our coverage of the git maintenance<\/code> command. If this is your first time reading along, or you could use a refresher, we’ve got you covered.<\/p>\n\n\n\n
git maintenance<\/code> is a Git command which can perform repository housekeeping tasks either on a scheduled or ad-hoc basis. The maintenance<\/code> command can perform a variety of tasks<\/a>, like repacking the contents of your repository, updating commit-graphs, expiring stale reflog entries, and much more. Put together, maintenance<\/code> ensures that your repository continues to operate smoothly and efficiently.<\/p>\n\n\n\n
By default (or when running the gc<\/code> task), git maintenance<\/code> relies on git gc<\/code> internally to repack your repository, and remove any unreachable objects. This has a couple of drawbacks, namely that git gc<\/code> performs “all-into-one” repacks to consolidate the contents of your repository, which can be sluggish for very large repositories. As an alternative, git maintenance<\/code> has an incremental-repack<\/code> strategy, but this never prunes out any unreachable objects.<\/p>\n\n\n\n
Git 2.52 bridges this gap by introducing a new geometric<\/code> task within git maintenance<\/code> that avoids all-into-one repacks when possible, and prunes unreachable objects on a less frequent basis. This new task uses tools (like geometric repacking) that were designed at GitHub and have powered GitHub’s own repository maintenance<\/a> for many years. Those tools have been in Git since 2.33<\/a>, but were awkward to use or discover since their implementation was buried within git repack<\/code>, not git gc<\/code>.<\/p>\n\n\n\n
The geometric<\/code> task here works by inspecting the contents of your repository to determine if we can combine some number of packfiles<\/a> to form a geometric progression<\/a> by object count. If it can, it performs a geometric repack, condensing the contents of your repository without pruning any objects. Alternatively, if a geometric repack would pack the entirety of your repository into a single pack, then a full git gc<\/code> is performed instead, which consolidates the contents of your repository and prunes out unreachable objects.<\/p>\n\n\n\n
Git 2.52 makes it a breeze to keep even your largest repositories running smoothly. Check out the new geometric<\/code> strategy, or any of the many other capabilities of git maintenance<\/code> can do in 2.52.<\/p>\n\n\n\n
[source<\/a>]<\/p>\n\n\n\n
\n\n\n\n
The tip of the iceberg…<\/h1>\n\n\n\n
Now that we’ve covered some of the larger changes in more detail, let’s take a closer look at a selection of some other new features and updates in this release.<\/p>\n\n\n\n