Most of the time, I use Git for a practical reason: I need to know what changed, preserve versions of the code, collaborate safely, and recover when an experiment goes wrong.
But the longer I worked with repositories, the more interesting another question became: what does a Git history remember that the final code no longer shows?
The final state of a project is only the latest answer. It does not naturally explain the path that produced that answer. Commits contain fragments of that path: messages, timestamps, changed files, diffs, sequences of revisions, and patterns in how the project evolved.
That idea led me to work on GitTrace, a project intended to transform Git commit history into a more understandable development logbook. I also experimented with using LLMs to turn that source material into readable summaries, including Indonesian-language internship or project reports.
The project made me stop thinking of a repository only as storage for source code. A repository can also be evidence of development over time.
Git is good at recording change, not explaining a story
Git answers certain questions extremely well.
Which commit introduced this line? Which files changed? What was the state of the project before a particular revision? What is the difference between two points in history?
Those are precise questions, and precision is one of Git's strengths.
Human reporting often asks something different. What did I work on this week? How did the project move from one feature to another? Which technical areas consumed most of the effort? Why did a series of small commits matter as one larger development task?
A chronological list of commit messages is not automatically a useful answer.
That gap is where I became interested in treating Git history as raw material rather than finished documentation.
A commit is a useful record, but an incomplete explanation
Commit messages are written for many different purposes. Some are careful and descriptive. Some are short. Some describe implementation instead of intent. Some make sense only when the author still remembers the context.
The diff itself has a similar limitation. It can show that a model changed, a view was added, or a configuration file was updated. It cannot reliably tell me the business reason for that change unless the reason is encoded somewhere in the history.
That is important because it establishes a boundary for any automated reporting system. Git contains evidence, but evidence is not the same as complete context.
GitTrace therefore cannot be valuable by pretending to recover information that was never recorded. Its value has to come from organizing what actually exists and making the uncertainty visible.
From raw history to a development narrative
The useful transformation begins by structuring the history.
Instead of sending an entire repository to an AI model and asking, "What happened?", I can think in smaller records: commit identifier, timestamp, commit message, changed files, and a controlled representation of the diff or change summary.
Those records can then be grouped into useful windows or themes. A set of commits touching the same feature area may represent one larger task. Several small fixes after a deployment may form a maintenance phase. Changes across configuration and application code may belong to the same technical decision.
The goal is not to rewrite history. The goal is to make the relationships inside the recorded history easier to read.
This is where an LLM becomes interesting, because language models are good at transforming structured input into human-readable language. But that ability also creates the central risk of the project.
The problem with a confident summary
LLMs can produce fluent text even when the source material is incomplete.
For a development logbook, that is dangerous. A polished paragraph can sound more authoritative than the evidence it came from. If the model invents a reason for a code change, merges two unrelated commits into one explanation, or claims a result that is not present in the history, the report becomes easier to read and less trustworthy at the same time.
That is why I do not want AI to be the authority in this workflow.
The source data must remain the authority.
The model should be constrained to summarize supplied records. Important statements should be traceable back to commits or other explicit inputs. When information is missing, the system should prefer uncertainty over invention.
This changes how I think about AI integration. The interesting work is not simply calling an LLM API. It is designing the boundaries around the model.
Grounding is more important than impressive prose
For this kind of system, grounding means making the relationship between output and source data explicit.
The input can be structured so the model knows which commit produced which changes. A generated section can retain references to the commits it summarizes. The pipeline can separate extraction from interpretation, so the raw Git data remains available even after a higher-level narrative is generated.
Validation matters too. If a summary claims that a feature was completed, there should be evidence in the input that supports that wording. If the source only shows partial implementation, the report should not convert that into a completed outcome.
The better the prose becomes, the more important this discipline is. Fluency should never be confused with accuracy.
Development memory is larger than documentation
The idea of "development memory" became useful to me because documentation usually describes the system as it should be understood now. Git history describes how the system changed.
Those are complementary views.
A README can explain how to run the project. Architecture documentation can explain the intended boundaries between components. An issue tracker can explain planned work. Git can show what actually changed in the repository over time.
None of those sources is complete by itself.
A tool like GitTrace is interesting because it can sit between raw repository history and human reporting. For a student, that might mean generating a more accurate weekly internship log from recorded work. For a team, it might mean summarizing development activity before a review. For an organization, it could support institutional memory when a developer leaves and someone else needs to understand the evolution of a codebase.
Those use cases are only valuable if the report remains grounded in the underlying history.
Automation should reduce reporting work, not erase responsibility
I do not think automated reports should remove the need for humans to review what they communicate.
A commit history can be messy. A good report often needs context that Git cannot know: why a decision was made, what a user requested, what failed outside the repository, or what was discussed in a meeting.
The system can reduce repetitive work by organizing and summarizing the recorded evidence. The human can then correct, add context, or reject interpretations that are not justified.
That division of labor feels more realistic to me than asking AI to "understand the whole project" from code alone.
What GitTrace taught me about AI systems
Working on this idea changed my view of AI-assisted developer tools.
The most interesting problem is not how to generate more text. It is how to build a reliable path from source data to generated text.
That path needs extraction, structure, boundaries, and validation. It needs a clear answer to the question, "Where did this statement come from?" It also needs a way to preserve the raw evidence so the generated narrative does not become the only version of history people see.
In that sense, GitTrace is as much a software engineering problem as an AI problem.
A repository as evidence of becoming
The final codebase tells me what the project is. The Git history tells me something about how it became that way.
That difference matters to me because development is a process that is easy to forget once a feature works. The abandoned attempt disappears. The refactor becomes normal. The sequence of decisions collapses into the current implementation.
Git keeps traces of that movement.
I do not think every commit deserves a narrative, and I do not think an LLM should turn every repository into a long story. But I do think there is useful information inside development history that ordinary version-control workflows leave difficult to read.
Exploring that idea made me see Git differently. It is still version control first. But it can also be a form of memory—provided that any system interpreting that memory respects the evidence it was built from.