u/Some_Scientist5385

I've been experimenting with git-history analysis and found an interesting problem.

In one project, a directory showed ~65% ownership concentration around a historical contributor who hasn't committed in 2 years.

In another project, a directory showed ~70% ownership concentration around a contributor who committed 4 months ago.

Same concentration number, completely different maintenance story.

It made me realize ownership concentration alone is probably not enough.

If you wanted to estimate "who currently understands this part of the codebase well enough to review and maintain it safely", what signals would you look at?

Commit history?
Review activity?
Churn?
Bug-fix commits?
Something else?

Most coding agents understand source code, file structure, embeddings, and dependency graphs.

What they generally don't understand is:

• Ownership concentration
• Change coupling between files
• Long-term maintenance patterns
• Historical hotspots
• How responsibility shifts over time

I've been experimenting with extracting these signals from Git history across large OSS repositories and found some surprising patterns.

For example, projects with vastly different contributor counts often show similar ownership concentration, while some large codebases remain heavily dependent on a small number of maintainers.

For people building AI coding systems:

• Have you experimented with Git history as context?
• Which historical signals turned out useful?
• What important information is missing from commit history alone?

Project: https://github.com/SushantVerma7969/git-archaeologist

Interested in where this idea breaks down and where it might actually help.

I've been experimenting with Cline on a personal project and ended up building a CLI that analyzes Git history to find things like:

- ownership concentration

- bus-factor risks

- files that frequently change together

- high-churn areas of a repository

One thing I found interesting was that repositories with similar contributor counts often had very different ownership concentration patterns.

For people using Cline for larger projects:

- How do you use AI to understand unfamiliar codebases?

- Do you rely on git history, architecture docs, code search, or something else?

- What's worked best for you?

I'm more interested in discussing workflows than promoting the tool itself.

Projects with similar contributor counts often had very different ownership concentration patterns.

For example, some repositories with hundreds of contributors still had a handful of files where most historical commit activity came from a very small group of people.

I built a tool to explore this using Git history and generated reports across projects like Kubernetes, VS Code, Rails, React, Express, and Vite.

I'm more interested in whether the methodology is useful than promoting the tool itself.

What do you think are the biggest flaws of using commit history as a signal for ownership concentration or maintenance risk?

GitHub: https://github.com/SushantVerma7969/git-archaeologist

I've been experimenting with a CLI called git-archaeologist that analyzes git history to estimate ownership concentration within a repository.

To test the idea, I ran it across 26 open-source projects including Kubernetes, VS Code, Rails, React, Express, and Vite.

One thing I found interesting is that projects with similar contributor counts often showed very different ownership concentration patterns.

Report:
https://sushantverma7969.github.io/git-archaeologist/

I'm less interested in promoting the tool and more interested in whether experienced developers think commit history is a useful signal for ownership concentration, bus factor risk, or project sustainability.

If you've worked on large repositories, what would you consider the biggest flaw in this approach?

I've been experimenting with a CLI called git-archaeologist that analyzes git history to estimate ownership concentration.

To test the idea, I ran it across 26 open-source projects including VS Code, Kubernetes, Rails, React, Express and Vite.

One thing I found interesting is that projects with similar contributor counts often showed very different ownership concentration patterns.

Report:

https://sushantverma7969.github.io/git-archaeologist/

I'm not posting this to promote the tool. I'm mainly interested in whether experienced maintainers think commit history is a useful signal for ownership concentration, or whether there are better approaches.

What would you consider the biggest flaw in this methodology?

Similar tools I've looked at include CodeScene and git-fame, but this experiment focuses specifically on ownership concentration at the module/file level using git history rather than overall contribution statistics.

Built a CLI called git-archaeologist that analyzes ownership
concentration from git history.

As a benchmark, I ran it across 26 major OSS projects including
Kubernetes, Rails, VSCode, Express, React and Vite.

One interesting result: Vite had 236 contributors but only 1 module
crossed the concentration threshold used in the report.

Report:
https://sushantverma7969.github.io/git-archaeologist/

Repo:
https://github.com/SushantVerma7969/git-archaeologist

Looking for feedback on the methodology and whether there are
better signals than commit history alone.

I've been working on a CLI called git-archaeologist that mines git history to surface:

• Bus factor
• Ownership concentration
• Coupled files
• High-risk files
• Historical churn patterns
• PR risk

To test it, I benchmarked 26 major open source repositories including Kubernetes, React, VS Code, PostgreSQL, TensorFlow, and Node.js.

I'd appreciate feedback from people who spend a lot of time working directly with git history and repository analytics.