Skip to main content

Speed up your Git experience by enabling the commit graph algorithm

While working in Visual Studio today I noticed a message appear at the top my idea. The message stated the following:

Speed up your git experience in Visual Studio by enabling the git commit graph algorithm.

No idea what that exactly means but that sounds promising… so let’s find out

Why this commit graph algorithm?

Git repositories can become sluggish as they grow in size and complexity. If you've ever waited impatiently for git log to load or noticed that branch operations take longer than they should, you're not alone. Recently, Git introduced a powerful feature that can dramatically improve performance: the commit graph algorithm.

The commit graph is a data structure that Git uses to store precomputed information about your repository's commit history. Instead of traversing the entire commit tree every time you run commands like git log, git merge-base, or git show-branch, Git can use this precomputed graph to answer queries much faster.

Think of it as an index for your commit history—similar to how a database index speeds up queries by avoiding full table scans.

The commit graph algorithm precomputes and stores several key pieces of information:

  1. Generation numbers: How far each commit is from the root commits
  2. Commit dates: Timestamp information for faster chronological queries
  3. Tree and parent hashes: Direct access to commit metadata
  4. Reachability bloom filters: Probabilistic data structures for quick ancestor checks

This precomputed data allows Git to:

  • Skip unnecessary commit traversals
  • Use mathematical shortcuts for common queries
  • Provide O(1) or O(log n) performance for operations that previously required O(n) time

Enabling the Commit Graph

Visual Studio will try to predict when enabling the commit graph could enhance performance. In that case the notification I mentioned in the intro is shown and you only need to click on enable.

You can also manually enable the commit-graph by going to Git > Settings > Enable commit graph for better Git performance.

Remark: When the commit graph is enabled, it can take several seconds up to a couple of minutes depending on the size of your repository before the commit graph is generated. So be patient!

As this is a git feature not specifically linked to Visual Studio, you can also activate this directly at the git level:

  • First, configure Git to automatically maintain the commit graph:

git config core.commitGraph true

  • This tells Git to use the commit graph for read operations when available.
  • To keep the commit graph up-to-date automatically:

git config gc.writeCommitGraph true

  • This ensures the commit graph gets updated during garbage collection operations.
  • As a last step for existing repositories, you'll need to generate the commit graph manually:

git commit-graph write --reachable

Remark: Starting from Git version 2.24.0, core.commitGraph and gc.writeCommitGraph are on by default, so you don’t need to set the config manually.

More information

Supercharge your Git experience in VS - Visual Studio Blog

Updates to the Git Commit Graph Feature - Azure DevOps Blog

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.