This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine. A repository can forget a feature without losing its fingerprints.
I know the feeling of opening an old project, spotting a strange workaround, and wondering: Why on earth did we do it this way? The person who wrote it might have moved on. The documentation might be missing. But buried underneath today's code is a quieter version of the project - one preserved commit at a time.
So I built RepoGhost, a local AI archaeologist that helps developers explore their project's forgotten history.
Instead of creating a fictional ghost that makes things up, it listens to the ghosts we already have: real Git commits. Ask “Why did we stop caching login sessions?” and RepoGhost searches commit messages, changed paths, and snippets of actual diffs. The result comes with a commit hash, date, paths, and a historical patch you can verify. It also has a Lost Files area where you can inspect deleted text files without restoring or modifying the repository.
The little twist is intentional: the interface is spooky, but the evidence is not supernatural. I wanted to celebrate the past without pretending an AI knows more than the archive contains.
Developers onboarding into an unfamiliar codebase, maintainers revisiting an old side project, and anyone hunting for the reason behind an abandoned feature. A phrase like “that old warehouse callback” may not appear in a commit exactly that way; semantic search provides another route in.
Video walkthrough: https://drive.google.com/file/d/1MyrQZYGUPOZNxV-LM5n03-OvdBkHa0op/view?usp=sharing I made a fictional 12-commit project, LanternLedger, so I could demonstrate the app without exposing anyone's private repository.
In the walkthrough, I will:
src/token_cache.py as it existed before deletion, and download a read-only copy.
GitHub: https://github.com/DinukaEk/repoghost.git The project includes the Streamlit interface, local Git reader, semantic retrieval layer, a deterministic fictional Git-history generator, comparison script, automated tests, and GitHub Actions CI.
RepoGhost has two parts that work together:
The archive: Python invokes Git's built-in history commands to collect actual commit metadata, file changes, and bounded text diff excerpts. It never checks out history or executes old code. Deleted-file previews are read directly from a commit's parent revision.
The AI: I used sentence-transformers/all-MiniLM-L6-v2, an open-weight Apache-2.0 model. Sentence Transformers maps a question and the indexed commit text to embeddings. Cosine similarity ranks the results. I show the source evidence rather than ask a language model to invent an explanation.
The app also includes a simple keyword-matching baseline. That matters because the interesting question isn't “Can I put AI in a Halloween-themed UI?” It's “Does semantic matching retrieve useful evidence when developers describe a problem differently from the original author?”
To make sure RepoGhost works reliably, I tested its core functionality and compared AI-powered semantic search against traditional keyword matching.
Automated Testing
The project successfully passed 34 automated tests in the initial development environment. These tests cover Git history parsing, read-only repository access, deleted-file recovery restrictions, search calculations, and retrieval logic.
The automated tests use a simulated embedding interface, so I also ran a separate evaluation with the actual open-weight AI model.
Real-Model Evaluation
I evaluated RepoGhost using six natural-language questions against a fictional Git repository containing historical development decisions.
Here are the results:
| Search Method | Correct Matches | Accuracy |
|---|---|---|
| Open-weight AI embeddings | 5/6 | 83.3% |
| Traditional keyword matching | 4/6 | 66.7% |
The AI-powered approach performed 16.7 percentage points better than the keyword baseline on this small test set.
One interesting example was the question:
"Why did we stop keeping login credentials in memory?"
The AI correctly identified the commit "Retire token cache after authentication security review," while keyword matching returned an unrelated network outage incident.
Another example involved a billing precision issue. The AI correctly found the commit fixing currency rounding discrepancies, whereas keyword matching suggested an unrelated CSV import change.
However, the AI wasn't perfect. For a question about messages lost during a connection failure, it selected a network outage incident instead of the expected retry-queue implementation.
This was a useful reminder that semantic search can uncover relationships that simple keyword matching misses, but its suggestions still need to be checked against the original Git history.
These results come from a small, fictional dataset and should not be interpreted as production accuracy measurements. Search similarity scores are not calibrated confidence values.
Offline Verification
RepoGhost successfully loaded and ran the downloaded open-weight model locally. Full offline operation is being verified separately to confirm that the application can search repository history without an internet connection.
Git history can be deeply personal to a development team. Old commits may contain internal names, architecture mistakes, incident discussions, and code that should never leave a machine. Searching that archive through a hosted AI API can create an unnecessary privacy tradeoff.
Using an open-weight embedding model means RepoGhost can do its central task locally, without paying per-question inference charges. Once the model is downloaded, it is designed to work with the internet disconnected. I can inspect the retrieval logic, replace the model, change what gets indexed, and debug the ranking rather than accept a mystery answer from a black-box endpoint. There is another advantage: traceability. I don't need a chatbot to say what a former developer “would have thought.” RepoGhost directs me to actual evidence - the SHA, commit message and patch - so I can decide for myself what the historical change means.
That felt like the right way to interpret Ghost in the Machine: not faking the dead coming back, but helping the work they left behind stay understandable.
My favorite moment in the fictional demo is finding a file that no longer exists in the project folder. The current working tree says it's gone. Git says: Here is what it looked like just before the deletion.
In a small way, that's the whole project. A codebase is more than its current files. The patches, abandoned ideas and notes from earlier developers are part of its memory.