Live data from Hacker News

Disabled at 22 million commits

programming.dev

141–145 of 145 posts

Re: Disabled at 22 million commits

#141
post #110
post #41

Earlier quoted context omitted.

I understood the comment, but that's not what OP was testing. They were doing the commits via merging pull requests. Git has no concept of a pull request and no HTTP API. From the post: > The GitHub API has periodic issues merging/creating PRs. (I use PRs since that is more reliable than keeping a local master up to date via pulling at this point).

> Git has no concept of a pull request. You are confidently wrong. Git, including pull requests, was developed years before GitHub ever existed. GitHub borrowed the term from git. Pull requests originally (before GitHub) are requests sent via email that one developer pull changes from another. https://www.git-scm.com/docs/git-request-pull The request pull command has been part of git since 2005: https://github.com/gi…

I'm not saying that you need GitHub for things like including parts of other repositories, but rather that the way GitHub implemented it is not code included in the git that you apt install.

I didn't know of the specific "request-pull" subcommand so thanks for that link. Still, both things you link are a bit different from how GitHub implements it, and I'd be very surprised if the HTTP API you link includes an endpoint for triggering the request-pull the way that GitHub has such APIs for their pull request mechanism.

If you meant to say that git can do anything GitHub can and we needn't use GitHub, I agree. I've used git in peer-to-peer fashion before, and especially now that it's Microsoft's, I think twice before opening repositories there. But if your main point was rather that git includes the same functionality as GitHub and that OP could have just tested the regular git instead of doing it on GitHub itself, I still think that's a rather different test target.

Re: Disabled at 22 million commits

#142
post #134

Earlier quoted context omitted.

[flagged]

> Wow, you’ve really done a crack up job ruining any possibility of interesting discussion here. What interesting discussion? Any owner of any service in production is well aware of how mundane it is to have third parties poking and prodding around to assess service limits. Some people have too much idle time on their hands.

The interesting discussion is that apparently ~no one did this for well over a decade, and now we have information about where service degrades. We didn’t have that to talk about before, now we do.

Re: Disabled at 22 million commits

#143
post #141
post #110

Earlier quoted context omitted.

> Git has no concept of a pull request. You are confidently wrong. Git, including pull requests, was developed years before GitHub ever existed. GitHub borrowed the term from git. Pull requests originally (before GitHub) are requests sent via email that one developer pull changes from another. https://www.git-scm.com/docs/git-request-pull The request pull command has been part of git since 2005: https://github.com/gi…

I'm not saying that you need GitHub for things like including parts of other repositories, but rather that the way GitHub implemented it is not code included in the git that you apt install. I didn't know of the specific "request-pull" subcommand so thanks for that link. Still, both things you link are a bit different from how GitHub implements it, and I'd be very surprised if the HTTP API you link includes an endpoi…

Just to make sure we're not talking past each other: OP wanted to test both "GitHub (and git)". OP could have tested the git portion locally.

But to engage you about the GitHub part: I believe that under the covers, GitHub is still using something substantially similar to git as the repo storage format. Git has no inherit limitations on number of commits. Eventually you run out of disk space, and possibly memory and/or CPU during repacking. You could turn off GC and let the repo remain unpacked. You might eventually run out of inodes. During cloning (and pulling), git implicitly creates pack files, so a clone/pull will also take a long time (CPU and or memory again) on an unpacked repo. This is why git periodically repacks.

If I had to guess, GitHub also has no inherit limits. Creating commits was probably periodically repacking on the git backend, consuming increasing amounts of resources.

I would be surprised if the GitHub API (the Ruby on Rails code) takes much resources at all.

Creating endless PRs is something you can simulate locally with two copies of a repo. You can use "git ls-remote" against a GitHub-hosted repo with PRs in it to see how it exposes PRs as references that are not normally cloned.

Regardless, I think that OP could and should have satisfied their curiosity about how git works locally, especially with respect to whether it has an inherent limits. And they could have satisfied their request about GitHub resource limits with a support request.

Re: Disabled at 22 million commits

#144

Earlier quoted context omitted.

Someone potentially taking the service down for everyone, you know, just out of curiosity. Which part of this curiosity you need GitHub for? I'm curious how well GitHub handles DDoS attacks, what's their limit. Let's DDoS and find out, it will be fun!

You really think one lone repo could take down all of GitHub? If GitHub doesn’t have stops in place to prevent that then they honestly deserve it.

So doing a DoS attacks from a single machine is fine, because "your servers can handle that"? Really? Of course GitHub can handle this, but if the sole purpose is to see where's the limit, you're stressing our servers and wasting our resources for nothing. I'd ban you no questions asked. Go test perf/scalability issues on someone else's live site.

Re: Disabled at 22 million commits

#145

Earlier quoted context omitted.

Someone potentially taking the service down for everyone, you know, just out of curiosity. Which part of this curiosity you need GitHub for? I'm curious how well GitHub handles DDoS attacks, what's their limit. Let's DDoS and find out, it will be fun!

> Someone potentially taking the service down for everyone, you know, just out of curiosity. I think this is exactly why it's great, and it's basically turned into a GitHub advertisement. Either GitHub is simply unable to handle weird abuse methods and/or the abuse prevention is improved. As an enterprise, wouldn't it be a bit concerning if your git host was unable to function (or respond appropriately) when presente…

GitHub is very much able to handle one person doing this. Doesn't matter if you had bad intentions or you were just ignorant to bad side effects.
Post reply on HN