[alganet]

What Í'm doing a lot is vibe coding and stashing. Not even a public branch, just git stash the whole thing the LLM writes.

Also, I stack the stash. When I vibe code, I pop it, let it work on its own mess, then I stash it again.

One project has almost 13.000 lines of vibe mess, all stashed.

One good thing, is that the stash builds. It's just that I don't want to release more code than I can read. It's a long review queue that is pre-merged somehow.

Once in a while I pick something from there, then I review it and integrate into the codebase more seriously. I don't have the throughput to review it all, and not all projects can be yolo'd.

[afarviral]

How can you maintain that much stashed code between commits? I assume you refer to it and manually code using the "mess" as inspo? I don't know stash works much deeper than stashing things I might need later so I can pull from remote.

[alganet]

It works quite well for me.

I don't use it as inspiration. It's like I said: code that is not reviewed yet.

It takes the idea of 50 juniors working for you one step ahead. I manage the workflow in a way that they already made the code they wrote merge and build before I review it. When it doesn't, I delete it from the stash.

I could keep a branch for this. Or go even deeper on the temptation and keep multiple branches. But that's more of my throughput I have to spent on merging and ensuring things build after merging. It's only me. One branch, plus an extra "WIP". Stash is perfect for that.

Also, it's one level of stashing. It's stacked in the sense that it keeps growing, but it's not several `git stash pop`s that I do.

One thing that helps is that I already used this to keep stuff like automation for repos that I maintain. Stuff the owner doesn't want or isn't good enough to be reused. Sometimes it was hundreds of lines, now it's thousands.

[verdverm]

I just force push the same commits, so you won't know if it was me or the ai that wrote various parts /s

I actually lead my commit messages with (human) or (agent) now

You could try using a git worktree that never gets pushed

[alganet]

I prefer working with the one commit per PR philosophy, linear history and every commit buildable, so I always force push (to the PR branch, but never to master). Been doing it for ages. Bisecting this kind of history is a powerful tool.

[verdverm]

yup, this is my preferred method as well, but I will wait to squash the commits at PR merging time, depending on project / code host

I have one client where force push and rebase are not allowed, knots of history are preferred for regulatory compliance, so I'm told. Bisecting is not something I've heard done there before

[alganet]

Squashing works great for bisecting.

I like rebasing! It works great for bisecting, reverting (squash messes that up), almost everything. It just doesn't play well with micro commits (which unfortunatelly have become the norm).

The force pushing to the PR branch is mostly a consequence of that rebase choice, in order to not pollute the main branch. Each change in main/master must be meaningful and atomic. Feature branches are other way to achieve this, but lots of steps involved.

[hatthew]

why not make many local commits and then squash before rebase/push/merge?

[alganet]

You mean generally? Yes, sure. As long as sloppy concatenated micro-messages don't end up in the main branch, I'm game.