[Feature Request] Commit size indicator/column in All Commits view

[juraj-blahunka]

Problem

When scanning the commit history (All Commits), there's no way to tell how large a commit is without clicking into it and inspecting the diff. This makes it tedious to spot big-bang merges, large refactors, or otherwise abnormal commits when scrolling through a long history - especially on branches with mixed commit sizes (small fixes next to sweeping refactors).

Proposed solution

Add a commit size gauge, shown as a column in the commit history table (similar to how other Git clients surface additions/deletions inline).

• Represent relative size visually, e.g. a small bar/sparkline or a stacked +/- indicator, scaled relative to other commits in view (not just raw line count) so outliers are immediately visible at a glance.
• Could be based on lines changed (insertions + deletions) or files changed - insertions/deletions is probably more useful for spotting refactors vs. new feature work.
• Since this adds a column to an already busy view, make it optional/hideable via the existing column configuration (Fork already lets you show/hide columns like Author, Date, SHA, etc.), so users who don't want it aren't affected.

Why this is useful

• Quickly spot commits that deserve closer review (large refactors, accidental big-bang merges, vendored/generated files committed by mistake).
• Useful during code review or when auditing a branch's history before a merge.
• No need to click through every single commit just to gauge its size.

Alternatives considered

• Color-coding commit rows by size instead of a dedicated column - simpler but less precise and harder to hide/toggle.

[DanPristupov]

Add a commit size gauge, shown as a column in the commit history table

Those numbers are not free. That would need to perform full diff for each commit.

2. [feature request] commit stats #1547 [Feature Request] Show diff summary between branches (files changed, insertions and deletions) #2595

[juraj-blahunka]

Thank you for investigating and considering how this could be implemented in an already amazing app!

[DanPristupov]

Just to avoid possible confusion.

Those numbers are not free. That would need to perform full diff for each commit.

I meant, this will definitely not be implemented.

[juraj-blahunka]

Understood and thank you for the clarification.

Though even lazy-loading the stats for just the visible rows with a slight delay might still give decent performance without hindering loading of the full git log. But maybe you already tried and the UX wasn't so great.