How gitglimpse estimates effort from git history

The problem

I work across multiple services — frontend, mobile, backend. With AI-assisted coding, the number of files that change in a single day has gone up dramatically. By the end of the day, I can't reliably reconstruct what I did. Not because I wasn't paying attention — because the volume of changes now exceeds what any developer can hold in their head.

This used to be manageable. A handful of commits, a couple of features, maybe one repo. Now it's dozens of files across multiple codebases, often touched in parallel. The mental model breaks down.

I tried using git history as a source of truth for standups — "what did I actually do today?" In theory, it should work. In practice, it doesn't. Reconstructing a coherent narrative from raw commits is slow, incomplete, and often misleading.

What I wanted instead

After, I run one command and get structured context — tasks grouped by branch, effort estimates, file lists. Something I can actually read and use.

That's what I wanted to exist. So I built gitglimpse — an open-source CLI that extracts structured context from your git activity. It's a personal tool. It's not for managers. What you do with the output is your business.

Commit messages are mostly useless in practice

With an LLM, you can throw commits and diffs at it and get a decent summary. Without one, all you have are commit messages. And commit messages are, overwhelmingly, garbage. "fix", "wip", "update", "stuff" — this is what real git history looks like. Anyone who's built tooling on top of git knows this.

I built a fallback system: when messages are vague, the tool infers meaning from file paths and change patterns. "Changes in auth/middleware.py, tokens.py" is less useful than an LLM summary, but it's honest and instant. With an LLM connected — local or cloud — gitglimpse sends actual diffs for deeper context. The tool works on a spectrum: good commits give you good template output, bad commits benefit most from LLM analysis.

Effort estimation is a fundamentally unsolvable problem

I wanted effort estimates. The idea seems simple: look at the gap between commits. Committed at 9 AM, again at 11 AM — that's 2 hours. Right?

No. A 2-hour gap could be 2 hours of coding, or 30 minutes of coding plus a meeting, lunch, and Slack. Coding is mostly thinking. The commit is just the save point. You cannot derive time spent from timestamps alone.

I built a heuristic anyway: gaps under 2 hours count as work time, gaps over 2 hours get capped at 45 minutes, first commits get 30 minutes of assumed prior work, large diffs get a multiplier. It's rough and I know it's rough. I called it "estimated effort" instead of "time spent" deliberately. The estimation problem is more interesting than I expected — there's no clean solution without data that git simply doesn't have.

Small LLMs ignore your instructions

I added local LLM support via Ollama so everything stays on your machine. The first model I tested — qwen2.5-coder — completely ignored the prompt. Instead of a summary, it produced a full code review with markdown tables and "Would you like me to help with anything else?" at the end.

Stricter prompts didn't help. The model was too eager to be "helpful" in the wrong way. So I built output validation — if the response contains code blocks, markdown tables, or phrases like "would you like" or "next steps," the output gets discarded and the tool falls back to templates. Smaller instruction-following models worked far better than larger general-purpose ones. The lesson: for structured extraction tasks, a small focused model beats a large chatty one.

Git history is mostly noise

When I first ran the tool on my own repos, the output was cluttered with merge commits, lock file updates, and formatting fixes. Half the commits in a typical repo are noise. This wasn't obvious until I actually tried to extract meaning from a raw git log at scale.

Noise filtering is now on by default. If all files in a commit match noise patterns (lock files, minified assets, CI configs) or the message matches known throwaway phrases (merge commits, lint fixes, version bumps), the commit gets excluded. Mixed commits — noise files plus real files — are kept. This single change improved output quality more than anything else I built.

The repo as distribution channel

gitglimpse supports Claude Code and Cursor through slash commands. Run `glimpse init` and it generates .claude/commands/standup.md in your repo. Type /standup in Claude Code and the tool runs.

The interesting part: commit that file and every developer who pulls the repo gets the command automatically. One developer sets it up, the whole team gets it. The repo becomes the distribution channel — no one needs to be convinced to adopt a new tool.

What actually stuck

I don't use this for standups the way I originally imagined. What stuck is context reconstruction — reminding myself what I worked on without re-reading code. At the end of the week, `glimpse week` reconstructs my entire week across repos. That turned out to be the real use case: git as memory, not git as reporting.

The tool runs in four modes: template (instant, offline, no LLM), local LLM via Ollama, cloud API with your own key, or JSON output that pipes into Claude Code or Cursor. Template mode is the default because the first experience should just work — no setup, no API key, no waiting.

It's open source and staying that way. Contributions welcome — especially if you have better ideas for the estimation algorithm.

pip install gitglimpse

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