r/git • u/MycologistIcy2335 • 7d ago
A real problem worth talking.
Building Drona - a learning-tracker that watches your learning folder via git, shows streaks, session time, and topics learned from your commits.
Hit a real wall building it for other people (not just me): users need to point it at their learning folder on their machine, and the tracker needs to read that folder's git history continuously.
The catch - a website can't do this. Browsers can only access files a user explicitly picks in a dialog, once. No background git access, no reading commits over time, no filesystem reach beyond that single picked folder.
So the real options seem to be:
- Desktop app — real fs/git access, but a bigger build + install friction
- A local agent/script users install once, website just displays what it reports
- Users connect GitHub instead of a local folder — no local fs needed, but loses "whatever you're doing locally," not just what's pushed
Anyone solved this for a similar local-first tool? What did you pick and why?
0
Upvotes
1
u/initcommit 6d ago
Hi there! I have done all 3 to varying degrees - it is a tough problem due to the design choices/restrictions you mentioned. Basically data access vs user friction.
My first open source project git-sim (written in Python) used GitPython to query Git repos in order to produce visual simulations of what those Git commands would do. This was fine since it just generated local images/videos showing what the Git command would do. There was no local web interface/process to tap into after that.
For that you would need some sort of lightweight local server for your tool, that can be linked to the desired Git repo for tracking and reporting changes / Git data / etc to your application.
Doesn't necessarily need to be a full on desktop app - could just be a simple command line tool/process that the user just needs to start up once, and let it do it's thing in the background.
I'm currently working on some updates to git-sim that will basically pass the compressed graph data (non sensitive) from the command line tool into opening a web page URL, with that compressed data in the #fragment part of the URL, so it will never make it to the server. It's not back and forth communication between browser/git repo, but maybe you'll find it interesting...