Git history as project time tracking

Time tracking usually fails in the same boring place: memory.

At the end of a day, or worse, at the end of a week, I try to reconstruct what happened. I remember the large task. I vaguely remember the annoying edge case. I do not remember the order, the exact days, or which work belonged to which chunk of the project.

Git remembers more calmly than I do.

Every commit already contains a small project record: a date, a time, a message, and a list of files that changed. That is not a full timesheet, but it is enough structure to become one.

The useful part of Git history

We showed that work progress can be reconstructed surprisingly well from git log.

The pattern is simple: choose a time range, filter by your own author, group the commits by day, and turn each day into a short list of activities. If the result needs to fit into a more formal reporting format, standardize it. For example, four bullet points per day can be enough to make the output consistent without pretending it is more precise than it is.

That gives you something much stronger than a blank timesheet.

Instead of asking, "What did I do last Tuesday?", the question becomes, "What do these commits say happened last Tuesday?"

Git history is not a perfect record of work. It is a very good record of committed progress.

Where the agent helps

Raw commit history is not something I want to paste into a customer report.

A commit message might be technically accurate and still useless as a time entry. A changed file list might explain the area of work, but not the human-readable activity. This is where the AI agent becomes useful.

The agent can read the log, extract the activities, combine related commits, and rewrite the result in plain English. More importantly, it can shape the output into a format that is easy to move into Excel or any other reporting tool.

A rough daily record can become something like this:

2026-05-07
- Reconstructed project work from commit history
- Grouped activities by day and affected area
- Standardized daily notes into four reporting points
- Marked missing non-commit work for manual completion

That is not magic. It is just the right division of labor. Git provides the evidence. The agent turns the evidence into readable notes. I review the result and add the parts Git could never know.

The missing work still matters

The important limitation is obvious, but easy to forget: Git only sees committed work.

It does not know about a meeting. It does not know about a long debugging session that ended without a commit. It does not know about planning, coordination, research, or a task that stayed uncommitted at the end of the day.

So the agent should not be treated as an oracle. The output is a draft, not the final truth. It reduces the memory gap, but it does not remove responsibility.

The best workflow is a two-step one: let the agent reconstruct the committed work, then add the missing context manually. That small review step keeps the result honest.

Why this is interesting

The interesting part is not that Git can show old commits. Every developer knows that.

The interesting part is that an AI agent can turn that history into a practical project artifact. It can translate the low-level record of development into documentation that a team, a customer, or a future version of myself can actually read.

That changes the feeling of time tracking. It becomes less about remembering everything from scratch and more about correcting a strong first draft.

For project work, that is useful in a very concrete way: fewer gaps, more consistent documentation, and faster reporting when someone asks what happened in a given period.

The takeaway

Git history plus an AI agent is not a complete time tracking system. It is better described as a reconstruction tool.

That distinction matters. A reconstruction tool does not claim to know everything. It gives you a reliable starting point from the work that was actually committed, then asks you to fill in the human parts around it.

For me, that is the central learning: the most useful AI workflows often do not replace judgment. They remove the blank page before judgment starts.