Live data from Hacker News

Show HN: Git Heat Map – a tool for visualising git repo activity for each file

github.com

11–20 of 42 posts

Re: Show HN: Git Heat Map – a tool for visualising git repo activity for each file

#11
I wonder if this can somehow be used as a tool for quick visual inspection of architecture compliance. Maybe the size of the box could be selected before display to denote a custom metric. For example, if the size of the box for each file was proportional to the (number_of_lines_edited) * (current_date - file_creation_date), then modularity could demand that the size of the boxes remain small. (pardon the musings of a non software engineer on a Saturday night)

Re: Show HN: Git Heat Map – a tool for visualising git repo activity for each file

#12

I wonder if this can somehow be used as a tool for quick visual inspection of architecture compliance. Maybe the size of the box could be selected before display to denote a custom metric. For example, if the size of the box for each file was proportional to the (number_of_lines_edited) * (current_date - file_creation_date), then modularity could demand that the size of the boxes remain small. (pardon the musings of…

The size of the boxes is fairly customisable on the back end, the webpage just needs to be sent the right JSON data, and the only real criteria is that the size of each directory is the sum of the sizes of its children.

Re: Show HN: Git Heat Map – a tool for visualising git repo activity for each file

#14
This is similar to the Structure dashboard in Repography [1] which is a web app I built, with the added advantage that it's kept up to date automatically so you can embed it in your README.md and not have to keep updating it yourself.

[1] https://repography.com/app/0/strawberry-graphql/strawberry/s...

Re: Show HN: Git Heat Map – a tool for visualising git repo activity for each file

#18

How much faster are your benchmarks using WAL mode? https://www.sqlite.org/wal.html

I experimented earlier to push the limits of SQLite inserts and wrote a blog post[0] about it. We can apply some of the learnings here.

I reviewed the OP's code and did some benchmarks; SQLite is not the bottleneck here. The code first generates the commit info from the git log, prints that to stdin [1] and the python script reads from it one by one in a loop [2]. Each of the commit info is written to SQLite. So, with or without WAL, the time is almost the same.

To confirm my hypothesis, I ran the project without insert calls. On my machine, for cpython, it took 160 seconds and without sqlite inserts 159 ish.

I believe the git log will be fast anyway, so other ways to make it faster would be to read a bunch of commits at once and then do batch inserts. We can also make it run in parallel since each commit info is independent, and we don't need to care about ordering while inserting.

[0] - https://avi.im/blag/2021/fast-sqlite-inserts/

[1] - https://github.com/jmforsythe/Git-Heat-Map/blob/bd9bc22/git-...

[2] - https://github.com/jmforsythe/Git-Heat-Map/blob/bd9bc22/git-...

Re: Show HN: Git Heat Map – a tool for visualising git repo activity for each file

#19

If you are an org with a large codebase and want to get many more insights, there is Seerene, it's commercial but takes the idea of repo analysis to the extremes (not affiliated, just a happy user) https://www.seerene.com/

There's also Adam Tornhill's [0] Codescene. [1]

[0] https://www.amazon.com/Books-Adam-Tornhill/s?rh=n%3A283155%2... [1] https://codescene.com/

Re: Show HN: Git Heat Map – a tool for visualising git repo activity for each file

#20
post #9

This is cool. The visualization reminds me of the visualization of QDirStat/WinDirStat. Also shout out to the (mostly useless but cool looking) git history visualizer, Gource[0]. https://gource.io/

> Also shout out to the (mostly useless but cool looking) git history visualizer, Gource[0].

I'd say that Gource is actually pretty useful for figuring out where most of the effort has been concentrated recently! For example, when added to a new project, I might run it against the repo to see which packages in the project have been changed the most in the past month, what people are working on and so on.

Post reply on HN