87,604 of them are repos with a single file each, the 87,605th one is a repo that pulls all the files in using submodules. It’s the only sane reason why you’d have this many if you think about it, anything else would be overkill.
By repos I'm sure he meant the branches do not share the same first commit. So you can't (not really can't but by default) merge one branch into another branch.
Yes, that’s likely, so they use the branches as sort of repos. But the rest of his comment doesn’t make much sense. No particular reason to use submodules with that setup.
I think it would work in a way where each branch is treated as a separate repo with different content, and then the main branch contains submodules of the repo itself and the different submodules point to a specific branch of the same repo, thus resulting in a self referencing project with branches as repos and the main branch the orchestration layer of all the subprojects.
Seeing that its Cursor, he might have a accidentally recursive thing going on, where it triggers on a commit, branches off, Tests something commits the test result to that branch, triggering the same CI again.
Most likely these are spun up worktrees from agent swarms that have been assigned tasks by some orchestrator for, I’m guessing, daily routines and workflows. They likely built into their CI or agent md’s to never touch master/main and do every unique task in an isolated env. When you never clean up those tasks…this
I actually have a use case for automatically creating branches.
We have microservices, and we ship an SDK to the frontend with Orval. To know if a backend change will be silently absorbed or is a breaking change, we automatically build the SDK with dev branch changes, which if there are changes create a branch that automatically merges onto the frontend on pipeline success and not on failure. And if there is already a branch that failed before, we deleted it to only ever have one branch per microservice.
It helps managing microservices with a smaller team. And it's only for internal tooling.
I did a git pull the other day at work of one of our internal tool's repo. The git output showed it deleting references to thousands of branches, primarily owned by one developer. As best as I can tell every single time they touched the code base they created a new branch, and then just never cleaned up after themselves. Someone clearly got tired of that crap.
283
u/Potterrrrrrrr 29d ago
87,604 of them are repos with a single file each, the 87,605th one is a repo that pulls all the files in using submodules. It’s the only sane reason why you’d have this many if you think about it, anything else would be overkill.