Git Repository Viewer: Commit Graph, Diffs & Blame

About the Git Repository Viewer: Commit Graph, Diffs & Blame

Open a Git repository from your computer and read it like a desktop Git client would: the commit graph of every branch and tag with its lanes and merges, each commit with its message, author, parents and the changes of every file side by side or inline, the files at any commit with each file’s history and blame, a comparison of two branches, tags or commits (the commits each side has and the files that differ from the merge base, as on a pull request), insights (commits per author with .mailmap applied, commits per week, a punch card, churn and the files changed most) and the largest files anywhere in the history.

The page reads the repository’s own files, exactly as Git stores them: loose objects, pack files with their deltas, branches, tags and packed-refs. Everything runs in your browser, in a background worker; nothing is uploaded and nothing is written to the folder. No folder at hand? Paste the output of git log --graph or git log --numstat.

Without a pass the result is a free preview: every count in full, the newest commits of the graph with their changes (half of them, up to 10) and the first rows of every other list by the same rule. The rest of the history, the lists in full and the downloads unlock with a Pro pass.

Common uses

• Reading the history of a project you just cloned without installing a Git client.
• Reviewing what a branch changes before you merge it, file by file.
• Finding who changed a line, and in which commit, from a computer where you cannot install software.
• Seeing who works on a project and when, and which files change most often.
• Finding the large files that make a repository slow to clone.

What the viewer reads, and how

• Objects: loose objects (zlib-compressed, under objects/) and pack files through their version 2 index, including both kinds of delta Git uses: an offset delta against an earlier object of the same pack and a reference delta against an object named by its id. Only the objects a view needs are read, so a large repository costs only what you look at.
• Refs: branches, remote branches and tags as loose files and in packed-refs, annotated tags followed to their commit, and HEAD (a branch, or a detached commit), as the repository layout describes them.
• The graph order is git log’s --date-order: “Show no parents before all of its children are shown, but otherwise show commits in the commit timestamp order.” The lanes are drawn like git log --graph: a branch keeps its lane, a merge opens one for its other parent, and lanes join where histories meet.
• Authors are merged with the repository’s .mailmap, which, in Git’s words, is “used to map author and committer names and email addresses to canonical real names and email addresses” (gitmailmap).

Diffs, history and blame

• A commit’s changes are shown against its first parent (for a merge, what the merge brought to that branch), in Git’s unified format with function names in the hunk headers. A file moved without changes shows as a rename; a file moved and edited shows as deleted and added.
• History lists the commits whose version of the file differs from every parent: the commits git log -- <file> shows, without following renames.
• Blame follows each line back through the history to the commit that last changed it, as git blame does; a line it could not follow further (a shallow clone, or the walk’s limit of 5,000 commits) is marked with ^.

Opening a repository

• A folder: choose the repository’s folder, the .git folder itself or a bare repository (project.git). Only the files inside .git are read; your working files are not opened. Some browsers leave hidden folders such as .git out of a folder you choose with the button: then choose the .git folder itself, or drop the folder on the page.
• A ZIP of a cloned folder (the .git folder must be inside it), up to 768 MB per file in the ZIP. GitHub’s “Download ZIP” does not work: “Snapshots don’t contain the entire repository history” (GitHub Docs). Clone the repository instead and open its folder.
• Pasted output of git log --graph --oneline --all shows the graph, and git log --numstat the insights, for a repository you can run git in but cannot open here.

Large files and the size of a repository

Largest files measures every version of every file in the newest 20,000 commits, and lists each content once with the newest commit that has it. Every clone downloads all of them, so large binaries slow every clone even after they are deleted. GitHub warns above 50 MiB and “GitHub blocks files larger than 100 MiB”; for larger files it points to Git LFS. Removing a file from the history needs a history rewrite on your own computer, with a tool such as git filter-repo, and everyone who cloned the repository has to clone it again.

Limitations

• Repositories that use SHA-256 object names (extensions.objectFormat = sha256) cannot be read yet. Neither can refs kept in the reftable format: git refs migrate --ref-format=files converts a copy back to loose files with packed-refs.
• Rename detection matches files with exactly the same content only, and a file’s history does not follow renames (git log --follow does).
• Diffs, line counts and blame line up changes without git’s own tie-breaking rules: where a change can be lined up two ways (around blank lines or closing braces), a hunk or a blamed line can differ slightly from what git shows.
• A partial clone (git clone --filter) lacks the objects it did not download, and a shallow clone stops at its boundary: those parts of the history are missing here too. Objects borrowed from another repository through objects/info/alternates are not read.
• Signed commits are shown as signed; the signature is not verified, which would need the signer’s public key.
• The graph holds the newest 200,000 commits; line counts for insights cover the number of commits you choose, and a commit’s line counts cover its first 300 files. Very large repositories can be slow, or too large for the browser’s memory: open a fresh, smaller clone then.
• A linked worktree’s .git is a file that points elsewhere: open the main repository folder. Submodules show as entries pointing at a commit; open each submodule’s own repository to browse it. Files kept in Git LFS show as the small pointer files the repository stores.

Privacy

On this device: nothing is sent

The repository is read in your browser, in a background worker. Nothing is uploaded, stored or written to the folder; closing the page forgets it.