[ecshafer]

Github doesn't stop me from making an infinite number of git repos. Or maybe they do, but I have never hit the limit. And if I am hitting that limit, and become a large enterprise customer, I am sure they would work with me on getting around that limit.

Where does this fit into a product? Maybe I am blind, but while this is cool, I don't really see where I would want this.

[aftbit]

Github would definitely reach out if you tried to make 100k+ Github repos. We once automatically opened issues in response to exceptions (sort of a ghetto Bugsnag / Sentry) and received a nice email from an engineer asking us if we really needed to do that when we hit around the 200k mark.

[no_wizard]

Oh here’s an interesting idea.

What if these bug reporting platforms could create a branch and tag it for each issue.

This would be particularly useful for point and time things where you have an immutable deployment branch. So it could create a branch off that immutable deployment branch and tag it, so you always have a point in time code reference for bugs.

Would that be useful? I feel like what you’re doing here isn’t that different if I get what’s going on (basically creating one repository per bug?)

[justincormack]

Github werent terribly happy with the number of branches we created for this type of use case at one point.

[0zymandiass]

A branch doesn't use any more space than a commit... I'm curious what their complaint was with a large number of branches?

There are various repositories with 500k+ commits

[JasonSage]

I’m assuming GitHub has a fair amount of database/cache overhead for most things, especially branches. I think that most things the web client sees are all database content and that there’s no usage of git/filesystem in any hot paths for web views.

So I can easily see why having many branches is more storage than the same number of commits.

[dizhn]

It might be something silly like the number of items in the Branches dropbox menu.

[justincormack]

That actually worked really well, and provides great branch search features when you have lots.

[justincormack]

We appeared on a list of the top 10 most egregious users of github so I assume they had database entries for these…

[aphantastic]

Why not just keep the sha of the release in the big report?

[foota]

In some ways, you could imagine repos might be more scalable than issues within a repo, since you could reasonably assume a bound on the number of issues in a single repo.

[_qrpb]

OP here. We’re building a new kind of Git platform. "Infinity" is more beneficial for us as platform builders (simplifying infrastructure) but less relevant to our customers as users.

[creatonez]

Read the article. It's not literally a foray into creating endless git repositories or anything fancy like highly strategic git-specific data compression, they are just using "infinite" as a buzzword for 'highly horizontally scalable. The product is something like Github.

[shivasaxena]

Imagine every notion docs or every airtable base being a a git repo. Imagine the PR workflow that we developers love being available to everyone.