---
id: BB-RESEARCH-C4LYIYLA
type: research
title: Luigit Git visualization state of the art
---

# Luigit Git visualization state of the art

## Scope

Survey minimal Git browsers, commit graphs, branch-state displays, diff viewers, and repository-level history visuals.
Extract patterns suitable for a public, read-only interface rather than forge workflows.

## Facts

### Minimal repository surfaces

SourceHut centers repository browsing on summary, tree, log, and refs.
Its summary combines description, recent commits, refs, clone URLs, and README content.
Gitiles explicitly rejects write access and elaborate JavaScript while rendering revision-bound trees and Markdown.
Stagit covers logs, commit diffstats, trees, line links, refs, submodules, and feeds, but documents poor fit above roughly 2,000 commits, large trees, or branch-heavy history.

Sources: [SourceHut repository](https://git.sr.ht/~sircmpwn/scdoc), [Gitiles](https://gerrit.googlesource.com/gitiles/+/HEAD/README.md), [Stagit](https://git.codemadness.org/stagit/file/README.html).

### Commit history and branch topology

Git's native graph is a narrow left gutter beside ordered commit rows.
Topological order guarantees that parents do not appear before children and avoids intermixing parallel development lines.

GitLab, GitKraken, Tower, Fork, GitUp, Sapling, Jujutsu, and Tig retain commit rows while varying scope and graph detail.
The strongest repeated clutter controls are selected-ref scope, hide or solo filters, elided mainline stretches, and collapsible merged history.
Fork supports per-merge collapse and keyboard expansion.
Sapling Smartlog hides irrelevant commits, preserves important refs and relationships, and marks the current position explicitly.

Githru addresses large DAGs through topology-preserving reconstruction, clustering, and summary plus comparison views.
Its controlled study compared Githru with earlier tools using 12 developers and reported better task-completion time.

GitHub's network graph is specialized for fork networks rather than ordinary history.
It shows at most 100 recently pushed branches and uses drag navigation for older history.

GitUp reports rendering the Git project's 40,000-commit graph in under one second, but this is a vendor claim rather than independent evidence.

Sources: [Git log](https://git-scm.com/docs/git-log), [GitLab repository graph](https://docs.gitlab.com/user/project/repository/), [GitKraken hide and solo](https://help.gitkraken.com/gitkraken-desktop/hiding-and-soloing/), [Fork collapsible graph](https://git-fork.com/blog/posts/collapsible-graph/), [Sapling Smartlog](https://sapling-scm.com/docs/overview/smartlog/), [Tig](https://jonas.github.io/tig/doc/manual.html), [Githru](https://arxiv.org/abs/2009.03115), [GitHub network graph](https://docs.github.com/en/repositories/viewing-activity-and-data-for-your-repository/understanding-connections-between-repositories), [GitUp](https://gitup.co/).

### Diff presentation

GitHub, GitLab, and Gerrit provide unified and side-by-side layouts, file navigation, whitespace controls, and syntax highlighting.
Successful viewers retain independent old and new line numbers and add within-line emphasis to line-level insertion and deletion state.

Review Board links both ends of detected moved lines and permits bounded context expansion.
Git itself can detect moved blocks.
A moved-code color without source-to-destination navigation loses the main explanatory value.

Difftastic parses supported languages with Tree-sitter to compare syntax rather than lines.
Its useful visual ideas include real old and new line numbers, stable matching through wrapping changes, and reduced emphasis on formatting-only changes.
Structural diff is a separate capability from syntax highlighting.

The RAID field study reports that refactoring-aware review reduced median reviewed lines from 14.5 to 2 for moves and from 113 to 55 for extractions across eight professional developers.
The evidence supports further experimentation, not a general claim that every semantic diff is superior.

Sources: [GitHub diff review](https://docs.github.com/en/pull-requests/how-tos/review-pull-requests/reviewing-proposed-changes-in-a-pull-request), [GitLab changes](https://docs.gitlab.com/user/project/merge_requests/changes/), [Gerrit review UI](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html), [Review Board diffs](https://www.reviewboard.org/docs/manual/latest/users/reviews/reviewing-diffs/), [Git diff](https://git-scm.com/docs/git-diff), [Difftastic](https://difftastic.wilfred.me.uk/), [RAID](https://arxiv.org/abs/2103.11453).

### Large diffs and uncertainty

GitLab collapses files when a diff reaches 10 percent of configured patch, file-count, or line-count limits.
Content beyond a hard limit is marked “Too large” and cannot be expanded in the UI.
The distinction between collapsed and unavailable prevents a false promise of completeness.

GitHub, GitLab, Gerrit, and Review Board reduce diff density with file navigation, per-file disclosure, hunk navigation, and context expansion.
No surveyed source establishes that accurate arbitrary viewport-only diff computation is feasible.
Viewport rendering and per-file lazy computation remain distinct from whole-file diff calculation.

Filtered, truncated, shallow, binary, generated, unavailable, or oversized evidence must be marked at its affected scope.

Sources: [GitLab diff limits](https://docs.gitlab.com/administration/diff_limits/), [GitLab diff internals](https://docs.gitlab.com/development/merge_request_concepts/diffs/), [WAI-ARIA disclosure](https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/).

### Repository-level visuals

CodeScene defines hotspots as files receiving concentrated development activity.
It combines that signal with a separate code-health model before making quality claims.
Git activity alone does not establish defect risk or complexity.

GitHub's code-frequency view shows weekly additions and deletions and offers table, CSV, and PNG alternatives.
GitHub documents a 10,000-commit ceiling for some repository insights.

Git author analysis requires identity normalization.
Git-of-Theseus recommends `.mailmap` and warns that full-history analysis may take substantial time.
Commit authors touching a path are contributors, not owners.

Submodule relationships have direct Git evidence: path and URL from `.gitmodules`, plus a pinned commit from the superproject gitlink.
They support a truthful project relationship graph without parsing programming languages.

Sources: [CodeScene hotspots](https://community.codescene.com/p/what-is-a-hotspot-in-codescene), [GitHub repository content analysis](https://docs.github.com/en/repositories/viewing-activity-and-data-for-your-repository/analyzing-changes-to-a-repositorys-content), [Git-of-Theseus](https://raw.githubusercontent.com/erikbern/git-of-theseus/master/README.md), [Git submodules](https://raw.githubusercontent.com/git/git/master/Documentation/gitsubmodules.adoc), [Gitmodules](https://raw.githubusercontent.com/git/git/master/Documentation/gitmodules.adoc).

### Visual accessibility

WCAG requires meaning beyond color, sufficient contrast, narrow-screen reflow, and usable target sizes.
Disclosure controls have established button semantics and keyboard behavior.
These remain relevant even without a formal screen-reader conformance target.

Sources: [WCAG 2.2](https://www.w3.org/TR/WCAG22/), [use of color](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color), [reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow), [target size](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum).

## Conclusions

### History

Use a scoped vertical commit list with a narrow topology gutter.
The list remains primary; the graph explains ancestry, divergence, and merges.

Show branch tips, tags, signature state, and note presence as landmarks attached to commit rows.
Pair every visual mark with text, shape, or icon.
Keep commit metadata and navigation reachable without hover.

Default to one selected ref.
Permit merged side history and per-merge collapse rather than drawing every advertised ref at once.
Preserve immutable commit links and sequential keyboard navigation.

For narrow screens, retain ordered commit rows and replace dense lanes with parent count, merge state, and ancestry summaries.
Do not squeeze a desktop DAG into mobile width.

### Branch and comparison state

A branch comparison should expose base, head, merge base, ahead and behind counts, unique commits, changed-file summary, and the chosen comparison semantics.
The branch-state visual should answer “where did these refs diverge?” before showing the full diff.

A compact change-shape glyph may summarize changed files and insertion or deletion distribution.
It needs direct visual experimentation because no surveyed interface validates the proposed vertical histogram encoding.

### Diffs

Lead with changed-file summary and a filterable file navigator.
Render files independently with stable file, hunk, and line links.
Provide previous and next file plus hunk navigation.

Unified view is the resilient baseline.
Side-by-side view is valuable on sufficient width and should become unified on narrow screens.
Both need old and new line numbers, within-line emphasis, syntax highlighting, bounded context expansion, and explicit binary or oversized states.

Moved-code visualization is worthwhile only with trustworthy detection and bidirectional origin-to-destination navigation.
Structural diff remains an optional enhancement with textual fallback.

Large diffs require truthful limits, progressive per-file work, cancellation, and bounded DOM rendering.
“Not loaded”, “collapsed”, and “cannot render” are distinct states.

### Repository insights

Use a ranked, sortable “most changed paths” view before attempting a treemap.
Expose metric definition, selected ref, time range, and path scope.
Link every aggregate back to files and commits.

Treat churn as additions and deletions over time.
Treat contributor activity as commit authors touching a path, apply `.mailmap` when present, and never call it ownership.

Use submodule relationships as the first architecture graph.
Show local and external repositories, pinned commits, and unresolved states without inferring package dependencies.

Charts require inspectable textual equivalents.
Animated repository theater, decorative metrics, and dashboard collections do not answer the selected browsing task.

## Rejected patterns

- Graph-only or free-form history as the default view.
- Rendering all refs and all history before narrowing scope.
- Color-only lanes, refs, statuses, insertions, or deletions.
- Metadata available only through hover.
- Silent omission or truncation.
- One unbounded multi-file diff document.
- Hotspot claims about quality or defects without independent evidence.
- Contributor activity labeled as ownership.
- Moved-code color without linked origin and destination.
- General dependency graphs inferred without explicit source evidence.
- Desktop DAGs and split diffs compressed into narrow screens.

## Unresolved questions

- What commit, ref, file, and diff sizes occur across the actual repository corpus?
- Should history use topological order or date order within ancestry constraints?
- Should merged side history begin collapsed or expanded?
- When should graph windowing or topology-preserving aggregation replace ordinary lanes?
- Which comparison, merge, rename, copy, binary, and generated-file cases need visual fixtures?
- Which URL state must preserve selected ref, commit, file, hunk, line range, layout, and filters?
- What visual encoding makes the proposed change-shape glyph immediately legible?
- Which hotspot metric and time scope answer a real Luigit task?
- How should merge commits affect churn and hotspot aggregation?
- Can moved-block or structural diff libraries produce trustworthy, bounded results for Luigit's repository mix?
- Which rendering strategy keeps large diffs responsive without implying viewport-only diff correctness?
- What narrow-screen breakpoint preserves history and diff comprehension?