vtemian

Git was designed for humans.

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.

That's why we built https://github.com/wunderlabs-dev/claudebin.com. A free and open-source Claude Code session sharing tool, which allows other humans to better understand decisions.

Those sessions can be shared in PR https://github.com/vtemian/blog.vtemian.com/pull/21, embedded https://blog.vtemian.com/post/vibe-infer/ or just shared with other humans.

why was this post removed? it was #1

> 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.

This nails what vibe coding actually is. The model handles execution, but intent and taste stay human. That’s where the real leverage is.

PING google.com (172.217.17.142): 56 data bytes

Request timeout for icmp_seq 0

Request timeout for icmp_seq 1

Request timeout for icmp_seq 2

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.

What's the actual magnitude of this outage? Is there a way to estimate how many machines were down?

Serverless all the way. There are a lot of good options out there, with AWS being quite flexible.

The onboarding for other developers is also painless. I've recently experiment with AWS Amplify and even if is not quite there yet, is pretty close.

Lambda, cloudfunctions, https://supabase.com/, https://hasura.io/, AWS Amplify, https://aws.amazon.com/serverless/.

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.

Thanks for reminding us ^_^

Yes, it can be scary, but usually this is the safest strategy. You can implement your own strategy and use it very easily (https://github.com/PressLabs/gitfs/tree/master/gitfs/merges).

Also, you can see how conflicts are solved, directly in the implementation (https://github.com/PressLabs/gitfs/blob/master/gitfs/merges/...).

Do you want to know something more specific?

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.

You can fork it https://github.com/PressLabs/gitfs and start hacking around.

It's the first video I found on Youtube: https://www.youtube.com/watch?v=LqDbh-JRl6I The gameplay is usually much faster paced, but they still seem to be having fun.

nice and simple tool :D GJ

You need libgit2 >= 0.21.2 compiled(with libssh2 if you want support for ssh).

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.

You are right about large binary files and gitfs currently has an option limiting the maximum file size.

Yep.

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.

If you work on the same file the content will get versioned like it would when you use command line git. Also you will get some sort of accountability for changes.

It is intended for non-developers so that they can integrate their workflow with developers working on the same content. It can be used by multiple persons of course but it's not generally targeted for people developing apps or for replacing git.

Currently it follows a single branch. The merge strategy is to merge with local changes taking priority over remote ones but this can be plugged-in. Rollbacks can be done by copying from history to current version. The only thing shaky thing is when there is a force push because local commits will be pushed back.

We are using it to expose website code through SFTP to non-developers. Another possible use case can be publishing static sites using jekyll or another tool.

The files are queued and are committed in batches after some idle time.

Yeap! Check https://github.com/vtemian/gitfs-demo/commits/master and you can see how the commit messages look

Did you check https://news.ycombinator.com/item?id=8735937?

Awesome!!! Congratz and good luck!

Really nice list! How many can you attend?