Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Disabled at 22 million commits

programming.dev

Post reply on HN
Print view View original

31–40 of 145 posts

Re: Disabled at 22 million commits

#31

Post by lucb1e »

throwuxiytayq wrote: post #8

This feels slightly malicious, but I can’t help but admire the curiosity that takes someone to actually see what happens if . That said, now we know, so nobody else needs to bother GitHub engineers by doing this again, hopefully.

Not like it would take a lot of code to check on push if the repository has more than 10k commits per day since its creation date or something, to stop such abuse. Doesn't thwart existing repositories with millions of commits (Linux is at ~2M) and gives time to formulate a long-term plan for what's allowed and what's paid or just disallowed.

So even if people were to try, I don't see that being a big bother. Not that it's not malicious to do this now

Re: Disabled at 22 million commits

#32

Post by littlestymaar »

olavfosse wrote: post #5
DocTomoe wrote: post #3

[flagged]

While it's correct that each Git commit is a snapshot of the worktree, and not a diff, Git uses copy-on-write / structural sharing, which means that generally speaking adding a commit to your repository is a very cheap operation storage wise. Recommended reading if you're interested in Git's data model, it's pretty easy to understand compared to Git's UI: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

That's my favorite fun fact about git: the diff you see isn't really a diff under the hood, but in fact it kind of is if you look one more layer under.

Re: Disabled at 22 million commits

#34

Post by js2 »

lucb1e wrote: post #24
iBotPeaches wrote: post #7

> I decided to see how many commits GitHub (and git) could take before acting kind of wonky. At ~19 million commits (and counting) to master: it’s wonky. This just doesn't seem right to me. Why? Its obvious at some point you'll harm the service. If the goal was to test it, why not try locally with git.

> why not try locally with git. Because you can't. GitHub is not open source, you'd need to steal the source code to try it locally. This comment is for educational purposes only, not trying to give OP ideas!!1 But you're right in spirit of course. Would be more interesting to install Forgejo/Gitea, GitLab, GitWeb, gitolite, TortoiseGit, etc., test them on various limits, and write that up in a nice blog post for mag…

> "GitHub (and git)"

The "(and git)" portion can of course be tested locally. What OP will find out is that there is no more inherent limit on the number of commits in a repo than there is an inherent limit in the number of nodes in a linked list.

You can go on forever till you run out of disk space. Possibly repacking will eventually require more than available memory.

Re: Disabled at 22 million commits

#36

Post by RexM »

lucb1e wrote: post #24
iBotPeaches wrote: post #7

> I decided to see how many commits GitHub (and git) could take before acting kind of wonky. At ~19 million commits (and counting) to master: it’s wonky. This just doesn't seem right to me. Why? Its obvious at some point you'll harm the service. If the goal was to test it, why not try locally with git.

> why not try locally with git. Because you can't. GitHub is not open source, you'd need to steal the source code to try it locally. This comment is for educational purposes only, not trying to give OP ideas!!1 But you're right in spirit of course. Would be more interesting to install Forgejo/Gitea, GitLab, GitWeb, gitolite, TortoiseGit, etc., test them on various limits, and write that up in a nice blog post for mag…

git runs outside of GitHub, which is what the comment you responded to was saying.

Test the behavior of git locally, without testing GitHub.

Re: Disabled at 22 million commits

#37

Post by thewataccount »

lucb1e wrote: post #31
throwuxiytayq wrote: post #8

This feels slightly malicious, but I can’t help but admire the curiosity that takes someone to actually see what happens if . That said, now we know, so nobody else needs to bother GitHub engineers by doing this again, hopefully.

Not like it would take a lot of code to check on push if the repository has more than 10k commits per day since its creation date or something, to stop such abuse. Doesn't thwart existing repositories with millions of commits (Linux is at ~2M) and gives time to formulate a long-term plan for what's allowed and what's paid or just disallowed. So even if people were to try, I don't see that being a big bother. Not that…

I don't think you can limit pure commit counts though, because you can push many commits/massive history changes in one go.

Monorepo's in particular could be impacted

Re: Disabled at 22 million commits

#38

Post by ronsor »

lucb1e wrote: post #24
iBotPeaches wrote: post #7

> I decided to see how many commits GitHub (and git) could take before acting kind of wonky. At ~19 million commits (and counting) to master: it’s wonky. This just doesn't seem right to me. Why? Its obvious at some point you'll harm the service. If the goal was to test it, why not try locally with git.

> why not try locally with git. Because you can't. GitHub is not open source, you'd need to steal the source code to try it locally. This comment is for educational purposes only, not trying to give OP ideas!!1 But you're right in spirit of course. Would be more interesting to install Forgejo/Gitea, GitLab, GitWeb, gitolite, TortoiseGit, etc., test them on various limits, and write that up in a nice blog post for mag…

You can download GitHub Enterprise Server for free.

Re: Disabled at 22 million commits

#39

Post by TechBro8615 »

iBotPeaches wrote: post #7

> I decided to see how many commits GitHub (and git) could take before acting kind of wonky. At ~19 million commits (and counting) to master: it’s wonky. This just doesn't seem right to me. Why? Its obvious at some point you'll harm the service. If the goal was to test it, why not try locally with git.

GitHub offers the service for free and doesn't publish or enforce any specific limit on number of commits. I see nothing wrong with a user pushing as many commits to it as possible. It's not his problem when to stop it.

This is also how I feel about the Tor project getting their knickers twisted over people who do research on the live network. If the network can't handle it, then it's not resilient to attack. Asking people nicely not to do stuff that degrades your product will not make the product suddenly anti-fragile.

Post reply on HN