Please don't call it "gmap" as it is a very commonly known name for another service; maybe "gitmap" or something that conveys the use would fit better?

Good point, and I appreciate the heads-up. Naming is tricky. I’ll definitely consider renaming or at least making the distinction clear in the README

> When you’re dropped into a new codebase, or even trying to clean up your own, questions like these matter: Which files change the most? Who made most of the changes last month? Are there dormant areas of the code? What’s the trend of contributions over time? Where is most of the churn?

Do those questions matter to you? They don't matter to me at all, so I'm curious to hear about why they matter to you. What do they matter to you for?

Knowing which code changes frequently or infrequently doesn't actually tell you anything about what code should change, because recency and frequency are not valid proxies for importance.

Thanks for the thoughtful question. The tool doesn’t aim to declare what’s “important,” but rather to highlight patterns. like hotspots, dormant code, or contributor trends. that can guide refactoring, onboarding, or even just curiosity. For some workflows (e.g. legacy cleanup, team handover, bug tracking), that context can be quite valuable.

> The tool doesn’t aim to declare what’s “important,” but rather to highlight patterns

I guess my question then is why should someone care about these patterns that are explicitly not what's "important"?

You say things like

"can guide refactoring, onboarding"

and

"For some workflows (e.g. legacy cleanup, team handover, bug tracking), that context can be quite valuable."

But those are vague hand-wavy statements that don't explain themselves. I don't understand why it would be valuable for those tasks, and I could use some explanation of what concrete problem is solved by looking at these details.

I tried the tool and would like to use it to track team KPIs such as 'Commit regularly in small increments' with the JSON export it provides. Or to track pairing and mobbing. Currently, we use a script that goes through the commits and searches for >1 authors.

What information helps you to get onboarded into a new codebase?

I'm not sure there's anything better than manually tracing hotpaths and making changes. Maybe an INTERNALS.md to document architecture would be nice. And reading through recent PRs too. Curious about your approach.

You’re right. What I’m working on is meant to complement that, especially early on. The goal isn’t to replace judgment or deep dives, but to surface patterns that can guide where to look: areas with a lot of churn, untouched files, contributors active in a specific part of the code, etc.

It’s still early, but I’d like to evolve it to make those insights more actionable, maybe even link recent PRs, show how files evolved, or highlight ownership boundaries. Feedback like yours helps shape that, so thanks again.

> I'm not sure there's anything better than manually tracing hotpaths

Ok, and code hotpaths are not represented by repo metadata.

(I posted a version of this earlier, but this is a proper “Show HN” with updates and full context.)