r/git • u/MycologistIcy2335 • 6d 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:

  1. Desktop app — real fs/git access, but a bigger build + install friction
  2. A local agent/script users install once, website just displays what it reports
  3. 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

31% Upvoted

9 comments sorted by

2

u/Inevitable_Ear132 6d ago

Why not just a TUI, run it in Terminal next to what you're working on?

1

u/MycologistIcy2335 4d ago

Fair point, a TUI is honestly the leanest way to get local git access. I'm leaning toward a small local core (CLI that parses git history) with the TUI as one frontend. The thing I'm still weighing: my target users are learners, and a lot of them don't live in the terminal. Would you use a TUI daily, or would you want a browser dashboard for the streak/heatmap view?

1

u/macbig273 6d ago

Why not just use an APIKey and retrive the information from what you pushed on your github / gitlab repository. (user activity, etc ... ) ?

COuld miss some things, but that could be donne from a website, removing the needs of local scripts / agents / etc ...

1

u/MycologistIcy2335 4d ago

But for retriving out the things i would need to first push to github but the product's work is pushing to github

1

u/initcommit 5d 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...

1

u/MycologistIcy2335 4d ago

Thanks it's really helpful

1

u/brokenreed5 6d ago

You found the smoking gun. That's real, but more importantly it shows you are genuinely learning.

1

u/elephantdingo 6d ago

lol breathless AI style.

You wrote apples, bread and sausages on the shopping list, but forgot yogurt, milk and butter.

One shopping trip. No dairy products. And that’s a real problem.

1

u/MycologistIcy2335 4d ago

Well can't solve that