4 ms·

Show HN: Gmap: Explore Git Repos Visually from the CLI

26 points by seeyebe 1y ago

I built gmap, a command-line tool to visualize Git activity, weekly heatmaps, file churn, authorship stats, and more, right from your terminal. Install with: cargo install gmap Or on Arch via AUR: yay -S gmap Repo: https://github.com/seeyebe/gmap https://github.com/seeyebe/gmap Feedback is welcome. Contributions too. if you’re into Git internals, CLIs, or terminal UX.

seeyebe 1y ago
(I posted a version of this earlier, but this is a proper “Show HN” with updates and full context.)
BugsJustFindMe 1y ago
> 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.
- seeyebe 1y ago
  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.
  - BugsJustFindMe 1y ago
    > 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.
    - exiguus 1y ago
      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.
- wonger_ 1y ago
  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.
  - seeyebe 1y ago
    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.
  - BugsJustFindMe 1y ago
    > I'm not sure there's anything better than manually tracing hotpaths Ok, and code hotpaths are not represented by repo metadata.
gregoriol 1y ago
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?
- seeyebe 1y ago
  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

26 points by seeyebe 1y ago

seeyebe 1y ago

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

BugsJustFindMe 1y ago

> 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.

seeyebe 1y ago
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.
- BugsJustFindMe 1y ago
  > 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.
  - exiguus 1y ago
    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.
wonger_ 1y ago
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.
- seeyebe 1y ago
  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.
- BugsJustFindMe 1y ago
  > I'm not sure there's anything better than manually tracing hotpaths Ok, and code hotpaths are not represented by repo metadata.

gregoriol 1y ago

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?

seeyebe 1y ago
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