5 ms·

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

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.

_qrpb 2y ago
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.
aftbit 2y ago
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.
- foota 2y ago
  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.
- no_wizard 2y ago
  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 2y ago
    Github werent terribly happy with the number of branches we created for this type of use case at one point.
    - 0zymandiass 2y ago
      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
      - dizhn 2y ago
        It might be something silly like the number of items in the Branches dropbox menu.
        justincormack 2y ago
        That actually worked really well, and provides great branch search features when you have lots.
      - JasonSage 2y ago
        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.
      - justincormack 2y ago
        We appeared on a list of the top 10 most egregious users of github so I assume they had database entries for these…
  - aphantastic 2y ago
    Why not just keep the sha of the release in the big report?
shivasaxena 2y ago
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.
creatonez 2y ago
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.

_qrpb 2y ago

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.

aftbit 2y ago

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.

foota 2y ago
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.
no_wizard 2y ago
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 2y ago
  Github werent terribly happy with the number of branches we created for this type of use case at one point.
  - 0zymandiass 2y ago
    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
    - dizhn 2y ago
      It might be something silly like the number of items in the Branches dropbox menu.
      - justincormack 2y ago
        That actually worked really well, and provides great branch search features when you have lots.
    - JasonSage 2y ago
      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.
    - justincormack 2y ago
      We appeared on a list of the top 10 most egregious users of github so I assume they had database entries for these…
- aphantastic 2y ago
  Why not just keep the sha of the release in the big report?

shivasaxena 2y ago

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.

creatonez 2y ago

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.