INindigodaddy·Jul 16, 2025Submission
Gitplay: Learn how a software project (using Git) evolved over time
2 points · Open discussionpixlie
gitplay
TypeScript2021–2025
pixlie / gitplay
gitplay
Learn how a software project (using git) evolved over time from its commit log. Its like YouTube for a git project. Desktop app built with Rust and SolidJS
3Distinct people
5Mentions
0Explicit recommenders
32GitHub stars
What to know before exploring
What it is
Learn how a software project (using git) evolved over time from its commit log. Its like YouTube for a git project. Desktop app built with Rust and SolidJS
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year5 dated mentions
Observed mentions: 2021-07-19 05:05:51 UTC to 2025-07-16 19:26:30 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
5 sourcesThis is such a lovely article and I relate to the idea as I have thought of something similar when I was building a passion project (https://github.com/pixlie/gitplay).
The idea was to use the Git commit log to show how a software evolved into what it is today. I needed to think of zooming in and out of context, where there are thousands of commits involved. I am not a good UI person so I will definitely take inspiration from this.
In LLM abstraction levels inspired by fish eye lensgitPlay: I am working on a desktop application to learn about the structure and evolution of a software project from its git history. Helpful for developers and PMs in onboarding new members, seeing how a project evolved and decision making.
As a mentor/engineering leader, I have always resorted to recording videos about how a project is structured, what decisions led to the current status and thought process behind this. I felt that much of this information is already there in the git commit log and perhaps project management software like JIRA.
gitPlay starts at the first commit instead of the head of the log. And you see a video player like interface. When you hit play, you see the folder structure evolve. I am adding file viewers, support for multiple folder browsers.
Future ideas:
- Show hot spots across the entire file structure in
Read the rest
the whole timeline
- Visualize folder/file chances over time as a tree (instead of explorers at the moment)
- Integrate with project management to overlay tickets with correspond to pull/merge requests
- Overlay a video with a file documenting sections of the video related to commits so gitplay will show contents as you play the video
How I wish to maintain/monetize:
- Keep core software open source, free for anyone, runs locally on your git repo
- Pay to tap into private project management data or explainer videos (point 4 above)
https://github.com/brainless/gitplay
Group changes into commits and rebase to build a better Git history
You can read the markdown version [here](https://github.com/brainless/gitplay/issues/5)
## Problem statement
We all have worked on a feature intensively and had to refractor a lot of the code base (in early projects). But can't spend the mental expense to context switch from `writing code` to `make meaningful commit messages`.
A good commit history is at the expense of the developer, which results in breaking the "flow". As pg mentioned in his blog post [Holding a program in one's head][1], it be better to work in long stretches to have better developer productivity. And it is very common for devs to have to make code cleanups which are unrelated to the feature they are working on ([example tweet][2])
* Commit small and commit often
* Writing good git commit messages goes a long way
* get gud at git
## Scenario
Lets say you are building a
Read the rest
feature and mid way you came across a variable name that could be fixed. Or a piece of code that is no longer needed. But you don't want to include this unrelated changes in your working commit. So for good practice you need to create a new commit for those changes.
## Current solution
1. git-worktree
We can currently use [git-worktree](https://git-scm.com/docs/git-worktree) to create a parellel repo in your local directory and make the changes in that, push a commit, pull the changes in the feature working tree and continue. *This is long and hard*
2. stash and make changes
Make a stash of the current feature changes and then make the required changes, commit and pop the stash. *So bad my eyes are bleeding*
3. Make the changes in the current working tree and use `git add -p` to make patches when creating a commit
This is what works the best. But the flaw of this approach is that it looses the essense of story-telling, You may make changes that don't show a history, instead shows a bunch of unrelated changes on top of each other.
## The solution
If we could `patch` changes into `commit groups` and then finally commit those changes when all the related changes are ready, it will let the developer write code in a long stretch [1] and also build a story for the commit history.
### Why commit groups?
We can currently create patches. But using this new feature we can add patches into groups as we read the code to make patches. We will have *more than one stages files* "area".
[1]: http://www.paulgraham.com/head.html
[2]: https://twitter.com/awesomekling/status/1390950309669781505?s=20
What are you starting with? I re-started my Rust learning last month. I am very slow at learning but Rust makes digging into systems stuff so much fun. I am from Python/JS background. I start with Rustlings every time.
Now building a Git player - basically watch a Git repo history unfold like a movie, for learning purposes [1].
Please ping me if you have some ideas, looking for learning peers.
1. https://github.com/brainless/gitplay
In ToyDB: Distributed SQL Database in Rust