Commits, branches, and the entire model works really well for human-to-human collaboration, but it starts to be too much for agent-to-human interactions.
Sharing the entire session, in a human, readble way, offering a rich experiences to other humans to understand, is way better then having git annotations.
> For me, the joy of programming is understanding a problem in full depth, so that when considering a change, I can follow the ripples through the connected components of the system.
100%. The fun is in understanding, creating, exaplaining.
Is not in typing, boilerplating, fixing missing imports, and API mismatch etc.
I'm still searching for successful vibe coding examples.
Each time I tried it, with custom rules, git, and all the best practices I found, it went amazingly well initially, and garbage afterward.
Using the same technique, after a while, it generates a lot more shitty code than helpful.
> So, it’s shit and you’ll spend a long time fixing it.
It just takes more time overall to make it functional.
Fixing, debugging and improving vibed code takes more mental resources and time than just writing it from scratch.
Also, there's the flow aspect. Each time you let it "vibe", you're losing the flow state that is important while creating and thinking about complex work.
For frontend, I would go with either React or Vue, both with a huge community and already a lot of builtin solutions.
I would 100% start with a design system, maybe material UI.
Nothing fancy, low maintenance and painless onboarding/development experience.
Yeah...we know, but there is a plan of rewriting / refactoring some parts and we hope to port as much as we can from Python 2 to 3 by the end of this summer.
I agree, the main page is a little bit outdated.
You can mount remotes with where you have only read access, gitfs will fail to push something on the remote, and will put the entire repository in read-only. Right now, you don't have a read-only option, but it would be nice to have :)
Great idea about tags and commits directories. It would be nice to specify at mount point, if you also want tags and/or commits etc.
As with performance it really depends on your workload. For mostly reads the performance should be quite good since access is mostly passtrough. This is almost true with writes.
Reading on "history" has a small performance penalty since if you are reading files which are packed they need to be unpacked on the fly.
Listing the "history" is quite fast. We tested on the WordPress repository that has around 17k commits and it takes ~4s first time and less than 1s afterwards.
Merging is pluggable and the currently implemented strategy is to merge always accepting the local changes. Actually we are currently using it in an environment in which multiple edits on the same file can be made and as in the case of "regular" filesystem the last one closing the file wins. The advantage is that you will have all the revisions.
Yes, it batches changes. Improving the commit messages is in the pipeline and what you have described sounds interesting. Right now the focus is to get the right semantics for git operations in the context of a filesystem.