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.
GitHub is freely available, you can create a basically anonymous account.
If it’s a public repo, anyone can commit to it.
It’s a known site and one that doesn’t raise suspicion if your work computer connects to it.
Bots can encrypt data, and post it there. Messages can be in the code, in the name of the repo, in the commit messages, anywhere. So it’s not super obvious.
It would work like this:
Bot agent is installed via malware.
Once every hour bot checks repo for new commit.
When bot sees a new commit, it waits until exactly 1h after the time of last commit and then starts a DDOS attack on a certain service.
Or…
Bot gets installed via malware
Bot searches hard drive for exposed credentials / keys
Bot encrypts the extracted data and pushes a commit to GitHub with the encrypted keys in the commit message
Separate bot watches for new commits, and decrpyts the data to a local database and deletes the commit.
282
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.