What is Git's commit-graph file, and which operations does it make faster?

## The problem it solves Every question about history shape — what are the parents of this commit, which commits are common ancestors, is A an ancestor of B, how far ahead is this branch — is a walk over the commit DAG. To take one step of that walk from a plain object store, Git must locate the commit object (a `.idx` lookup), read it out of the packfile (possibly reconstructing a delta chain), zlib-inflate it, and parse the text to find the `parent` lines and the committer date. That is a lot of work for a few dozen bytes of structure, repeated once per commit, in a repository that may have hundreds of thousands of them. ## What the file contains The commit-graph is a purpose-built binary file recording, for each commit it covers: the commit's object ID, its root tree's object ID, the list of parent object IDs (encoded compactly, with an overflow representation for octopus merges), the commit date, and a **generation number**. Entries are laid out for direct indexed access, so a parent lookup is a pointer chase in a memory-mapped file rather than an object read. The generation number is the interesting part. In its basic form it is one plus the maximum generation of the commit's parents — the length of the longest path back to a root commit. Because a commit can never reach an ancestor with a generation greater than or equal to its own, Git can prune huge parts of a traversal without visiting them: if you are asking whether A reaches B and B's generation exceeds A's, the answer is no, immediately. Recent Git also records corrected commit dates so that traversals ordered by date get the same early-exit benefit even when clock skew has produced commits whose recorded dates lie. ## Which commands get faster Anything reachability-shaped: `git log --graph` and `git log --topo-order`, which need to know the DAG shape before printing anything; `git merge-base` and therefore every merge and rebase that has to find one; `git branch --contains` and `git tag --contains`; ahead/behind counts, such as the "your branch is ahead by N commits" line; and `git log --oneline` over deep history. Commands dominated by *content* — diffs, blame on a large file, checkout — see much less, because their cost is in trees and blobs, which the commit-graph does not describe. ## Writing and reading it `git commit-graph write --reachable` writes a file covering every commit reachable from refs. `--split` writes an incremental layer instead of a full rewrite, producing a chain of files under `.git/objects/info/commit-graphs/` with a `commit-graph-chain` listing them; the layers are merged occasionally so the chain does not grow without bound. Modern Git writes the graph as part of `git gc` when `gc.writeCommitGraph` is enabled, and `fetch.writeCommitGraph` updates it after fetching. The `git maintenance` machinery includes a commit-graph task for scheduled background upkeep. On the read side, `core.commitGraph` decides whether Git consults the file at all; turning it off is the first diagnostic step if you suspect the cache. ## It is a cache, and that has consequences Nothing in the commit-graph is unique data — every field is derivable from the commit objects themselves. Deleting the file is always safe and costs only speed. Because it is written at a point in time, it covers the commits that existed then: commits created afterwards are parsed the old way, so a repository is never "stale" in a correctness sense, merely partially accelerated until the next write. For the same reason the graph only ever describes commits, not trees, tags or blobs, and it is not part of what a clone transfers — each repository builds its own. One related but distinct file deserves separating in an interview: the **multi-pack-index** (`git multi-pack-index write`) accelerates *object lookup* across many packfiles, and pack **bitmaps** (`git repack --write-bitmap-index`) accelerate computing which objects to send. All three are derived acceleration structures living beside the object store, but only the commit-graph is about the shape of history. ## How to talk about it The interview-grade summary is: it is a derived index over commit metadata with generation numbers that enable early termination in reachability queries; it makes DAG-shaped commands fast on large repositories; it is written by gc, fetch or maintenance and read under `core.commitGraph`; and because it is pure cache, the correct response to any suspicion about it is to disable or delete it and compare.