[Feature]: Implement History Based Indexing

[Kavirubc]

Problem Statement

As of now, VecGrep can walk through the latest VDB and give answers to the user. But it can not answer questions such as,

1. Before doing this what was there?
2. Why did the developer change this here and how that change affected the application ?

Proposed Solution

My suggestion is to give the story telling ability to VecGrep. Need to think about how we can do this but hope the problem statement clarifies the requirement

Alternatives Considered

No response

Additional Context

No response

[iamvirul]

Interesting direction — this is essentially asking VecGrep to index git history alongside current code so Claude can answer temporal questions like "what changed here and why."

What this would require technically:

1. Commit-linked chunk storage — each chunk would need to store the git commit hash, author, timestamp, and commit message it was introduced/last modified in. Schema change: add commit_hash, commit_message, author, committed_at columns.

2. Git blame/log integration — during indexing, run git log --follow -p <file> or git blame to map each chunk's line range to its originating commit.

3. Historical chunk versions — to answer "what was here before", we'd need to store previous versions of chunks, not just the current state. This means chunks can't be keyed by current content alone — we'd need versioned storage.

4. Semantic search across history — queries like "what was the auth module before the refactor" need to search across historical chunk versions, not just the latest.

My concern: This is a fundamentally different scope from VecGrep's current purpose. VecGrep today is a point-in-time semantic search tool — it gives Claude the most relevant current code for a query. History indexing turns it into a temporal code intelligence tool, which is a much larger problem.

A more practical middle ground before building full history indexing:

• Add a lightweight get_file_history(path) tool that runs git log --oneline <file> and git blame <file> and returns the output. This is cheap to implement and already gives Claude the "why did this change" story without storing historical embeddings.
• The heavy version (storing all historical chunk versions) would multiply index size significantly — a repo with 100 commits and 10k chunks would need up to 1M historical chunk entries.

Questions to scope this properly:

1. Do you need full historical search, or just "what was the last version of this chunk before it changed"?
2. Is this targeting git repos only, or all projects?
3. What's an acceptable index size increase?

Happy to revisit once we have clearer requirements. Labelling as priority: low for now since it's a significant scope expansion and there are more pressing items in the backlog.

[iamvirul]

Moving this to a discussion for broader community input: #26 — cc @Kavirubc