How gitglimpse estimates effort from git history

The question

How long did you actually work today? Git knows when you committed, but it doesn't know when you started thinking. The gap between two commits could be deep focus or it could be lunch. gitglimpse tries to give a reasonable answer anyway — here's exactly how.

The rules

The algorithm is a set of heuristics, not a time tracker. It uses commit timestamps and diff sizes to produce an estimate that's directionally useful. The core rules: (1) the first commit of the day gets 30 minutes of assumed prior work, (2) gaps under 2 hours between commits count as work time, (3) gaps over 2 hours get capped at 45 minutes — you probably weren't coding that whole time, (4) large diffs get a small multiplier because big changes usually take longer than small ones.

A worked example

Let's walk through a real day with 5 commits and see what the algorithm produces.

Commit 1 at 09:00 — "Add JWT rotation middleware" (12 files, +340/-82). This is the first commit of the day, so it gets the default 30 minutes of assumed prior work. Estimate: 30 min.

Commit 2 at 10:15 — "Fix token refresh edge case" (3 files, +28/-12). The gap from Commit 1 is 75 minutes, which is under the 2-hour threshold, so it counts as work time. Estimate: 75 min.

Commit 3 at 14:30 — "Update rate limiter for batch endpoints" (4 files, +65/-20). The gap from Commit 2 is 4 hours and 15 minutes — well over the 2-hour cap. This almost certainly includes lunch and meetings. Capped at 45 min.

Commit 4 at 15:10 — "Add rate limiter tests" (2 files, +95/-0). Gap of 40 minutes from Commit 3, under the threshold. Estimate: 40 min.

Commit 5 at 15:45 — "Update OpenAPI spec" (1 file, +8/-3). Gap of 35 minutes, under the threshold. Estimate: 35 min.

Total estimated effort: 30 + 75 + 45 + 40 + 35 = 225 minutes ≈ 3.75 hours. The actual time at the keyboard was probably somewhere between 3 and 5 hours. The estimate won't be perfect, but it's in the right ballpark — and it took zero manual tracking.

Why "estimated effort" and not "time spent"

The label matters. Calling it "time spent" implies precision that doesn't exist. A 4-hour gap could be 30 minutes of coding and 3.5 hours of meetings, or it could be 3 hours of deep research followed by a quick commit. Git doesn't have the data to distinguish these cases, and pretending otherwise would be dishonest. "Estimated effort" signals that this is a rough heuristic, not a timesheet.

Where it breaks down

The algorithm struggles with certain patterns. Developers who commit once at end of day get a single 30-minute estimate for potentially 8 hours of work. Pair programming sessions where one person drives produce no commits for the navigator. Rebased or squashed histories compress multiple sessions into single timestamps. These are fundamental limitations — without external data (calendar, activity tracking, screen time), git timestamps are all we have.

LLMs didn't help here

I tried using local LLMs to improve estimates — feeding them the diffs and asking "how long would this change take?" The results were wildly inconsistent. qwen3.5 ignored the estimation prompt entirely and produced code reviews instead. Even models that followed instructions, like qwen2.5-coder, gave estimates that varied 3x between identical runs. The problem isn't the model — it's that estimating effort from code changes is genuinely ambiguous. A 500-line diff could be 10 minutes of auto-generated boilerplate or 4 hours of careful refactoring. The heuristic approach is crude but at least it's deterministic.

The diff size multiplier

One refinement that helped: large diffs get a small boost. If a commit touches significantly more lines than average, the estimated time gets a multiplier. This handles the case where someone makes a huge change right before a short gap — 15 minutes between commits but 400 lines changed probably means more than 15 minutes of actual work. The multiplier is conservative (1.2x–1.5x) to avoid inflating estimates.

Good enough beats perfect

The estimation algorithm is the part of gitglimpse I'm least satisfied with and most frequently asked about. It's imprecise by nature. But it turns out that "roughly 3 hours across 5 commits" is vastly more useful than nothing when you're writing a standup at 9 AM and can't remember yesterday. Perfect effort tracking requires invasive tooling. A rough estimate from git history requires zero setup and is right enough to be useful.

# See effort estimates in action
glimpse standup

# Detailed per-commit breakdown
glimpse report

# GitHub: https://github.com/dino-zecevic/gitglimpse