Celebração pela criação do bilionésimo repositório no GitHub

 (github.com/AasishPokhrel)
2 pontos por GN⁺ 2025-06-12 | 1 comentários | Compartilhar no WhatsApp
  • O usuário do GitHub jonmagic celebrou, na Issue #1, a criação do bilionésimo repositório do GitHub, informando que o repositório shit tem esse ID
  • Como evidência, foi apresentada a resposta de curl -s, que inclui id 1000000000, node_id R_kgDOOO5rKAA, name shit, full_name AasishPokhrel/shit
  • O fluxo de comentários seguiu principalmente com parabéns e piadas usando o nome do repositório e o emoji 💩, e a postagem inicial recebeu milhares de reações de 👍·😄·🎉
  • jonmagic deixou links da documentação do GitHub dizendo que o dono do repositório pode usar bloqueio da conversa ou cancelar a inscrição, se necessário
  • Em 28 de junho de 2025, o dono do repositório restringiu a conversa a colaboradores e a bloqueou, e um comentário foi removido no mesmo dia

shit, apontado como o bilionésimo repositório

  • O título da issue é Congratulations on creating the one billionth repository on GitHub!, com uma mensagem parabenizando pela criação do bilionésimo repositório no GitHub
  • jonmagic parabeniza o criador do repositório e apresenta como base parte do resultado da seguinte chamada de API
  • A mensagem de parabéns inclui uma piada com o nome do repositório, em tom de “espero que você tenha a chance de criar um 💩 incrível”

Reações nos comentários e sequência de piadas

  • Os comentários iniciais foram compostos, em sua maioria, por parabéns e trocadilhos
    • “Estou ansioso para ver que 💩 incrível vai sair daqui”
    • “Mal posso esperar para esse 💩 estourar”
    • “Vou fazer um fork disso”
    • “Deixando um comentário antes que esta issue seja bloqueada”
  • MangoCubes comentou que ficou tranquilo ao ver que jonmagic é funcionário do GitHub
  • jordigh parodiou o formato típico de comentários em issues, perguntando algo como “há previsão de correção ou alguma solução alternativa?”
  • Depois disso, continuaram aparecendo comentários curtos como 💩, sssssssshit e “peak shit”

Aviso sobre avalanche de notificações

Escala da participação e reações

  • O corpo da issue original mostra milhares de reações
    • 👍 4524
    • 😄 2116
    • 🎉 2638
    • ❤️ 945
    • 🚀 1201
    • 👀 611
  • No meio da lista de comentários, aparece a indicação de que ainda há mais 1136 itens, mostrando que apenas parte dos comentários está visível
  • Nos metadados, aparecem alguns participantes e +1092

Bloqueio e estado posterior

  • Em 28 de junho de 2025, o dono do repositório bloqueou a conversa e a restringiu a colaboradores
  • No mesmo dia, um comentário de luckydonald foi removido
  • No rodapé da issue, aparece o aviso de que é preciso se cadastrar ou fazer login para participar da conversa no GitHub

Leituras relacionadas

1 comentários

 
GN⁺ 2025-06-12
Opiniões do Hacker News

  • Isso me lembrou o 100 milhõesº changeset do OpenStreetMap
    Algumas pessoas, inclusive eu, tentaram meio de brincadeira, mas no fim acabou ficando com alguém que não estava mirando isso, e sim mapeando a África com dedicação
    Olhando em retrospecto, foi um desfecho muito mais caloroso, e essa pessoa já tinha até sido indicada antes como candidata a algo no OSM
    No OpenStreetMap, tudo é dado real de operação, então é difícil criar dados lixo de qualquer jeito; por isso, parece mais provável que o enésimo commit seja um trabalho espontâneo de alguém
    Também é uma conquista divertida para o GitHub :)
    Se quiser ler mais sobre esse marco do OSM, há o post oficial do blog: https://blog.openstreetmap.org/2021/02/25/100-million-edits-...
    Minha recapitulação da atividade de changesets na época: https://www.openstreetmap.org/user/LucGommans/diary/395954

    • Há muito tempo, um amigo passou um dia inteiro de trabalho tentando criar o ticket número 1 milhão do nosso help desk
      Não sei como ele acabou conseguindo, mas a equipe até fez uma festinha para comemorar a conquista
      Deve ter sido uns 15 anos atrás; naquela época, parecia que trabalhar em tecnologia era mais divertido

  • Legal! A própria OpenAPI Spec do GitHub também só tem pouco mais de 1 bilhão de repositórios pela frente até estourar int32
    Isso já está acontecendo nos IDs de execução de workflows
    https://github.com/github/rest-api-description/issues/4511

    • Quando cheguei a uma empresa onde trabalhei por um breve período como CTO, uma das tabelas principais já tinha 1,3 bilhão de linhas e usava inteiros de 32 bits como chave primária
      No ritmo de crescimento da época, o valor da chave primária estouraria em poucos meses, então tocamos com bastante urgência um projeto para elevar os IDs para 64 bits a fim de evitar uma catástrofe
    • Algumas semanas atrás, o LuaRocks passou de 65.535 pacotes, o que causou um pequeno problema na comunidade Lua
      Esse número entrou em conflito com a implementação do LuaRocks no LuaJIT [1] [2], e isso fez pipelines de CI/CD e fluxos de trabalho pessoais de alguns usuários falharem, causando transtorno
      Foi resolvido bem rápido, mas foi um caso interessante
      [1] https://github.com/luarocks/luarocks/issues/1797
      [2] https://github.com/openresty/docker-openresty/issues/276

  • Queria ainda estar na Apple
    Acho que a maioria aqui sabe que a Apple usa há muito tempo uma ferramenta interna chamada Radar
    Cada Radar recebe um ID, ou seja, um número de bug
    Um Radar como o bug #1.000.000 era bem especial
    A menos que alguém cometesse um erro e decepcionasse a equipe inteira, normalmente era um Radar falso cheio de piadas internas
    Abrir apenas um deles já bastava, porque um Radar podia referenciar outros Radars; em geral, a diversão começava aí e você caía em um rabbit hole
    Foi uma grande burrice eu não ter capturado ou impresso alguns deles quando tive a chance

    • O sistema de controle de versão em monorepo do Google também atribui a cada alteração um ID monotonicamente crescente desse tipo
      Infelizmente, alguns anos atrás, quando ele se aproximou de um número redondo, pessoas tentando pegar aquele ID rodaram scripts e deixaram o sistema em estado de negação de serviço
      Então agora ele pula IDs perto de grandes números redondos :(
      Provavelmente há aqui uma lição sobre design de schemas
    • Por outro lado, pensando em como a Apple lida com dados confidenciais, eu não gostaria de ser pego levando documentos internos para fora, por mais inofensivos que parecessem

  • Já que estamos falando de IDs de repositórios do GitHub, o primeiro repositório está aqui
    https://api.github.com/repositories/1
    https://github.com/mojombo/grit

  • Provavelmente ficaram verificando repetidamente via script https://api.github.com/repositories/999999999 e criaram um novo repositório no instante em que apareceu
    Como repositórios podem ser editados, também podem ter criado vários com folga e apagado os que não tinham o número certo
    Olhando outros repositórios que o autor criou ontem, “yep” parece ter sido o número mágico, e “shit” deve ter sido o reconhecimento de que errou
    Alguém se lembra do D666666 do Facebook?
    Foi uma conversão de código enorme, e o autor usou uma técnica parecida para conseguir aquele número específico

    • Ou talvez não
      Não sei por que estão presumindo que essa pessoa pegou esse repositório de propósito
    • Como é um repositório vazio, parece que sim

  • Falando sério, é um pouco surpreendente que o GitHub tenha deixado tão fácil calcular a velocidade de criação de novos repositórios
    Esse tipo de informação normalmente não é segredo corporativo?

    • Quando o fosso tem 1 bilhão de unidades de largura, acho que dá para ficar andando por aí de cueca
    • Há algum motivo para o GitHub esconder essa informação?
      Não sei como isso poderia ser usado contra o GitHub
      Entendo que muitas empresas adotem como padrão não divulgar nenhuma informação a menos que sejam obrigadas
    • Usando busca binária, dá para encontrar o ID mais recente muito rapidamente
      No passado, acompanhei o crescimento de vários sites dessa forma
    • Também dá para ver a velocidade de criação de novos usuários
      De certa forma, isso é ainda mais interessante

  • Fico me perguntando se AasishPokhrel criou esse repositório para ser o repositório de número 1 bilhão

    • AasishPokhrel criou ontem 2 repositórios, “shit” e “yep”
      Entre 17 de maio e 10 de junho, não houve atividade
      Não sei se dá para calcular a velocidade de criação de repositórios e criar um no número desejado
    • Isso é bem fácil de manipular
      Basta continuar criando repositórios até sair o de número 1 bilhão e apagar os anteriores
      Com a API do GitHub, é muito simples
      Os únicos problemas são os limites de taxa e outras pessoas criando repositórios ao mesmo tempo, então no fim é uma questão de sorte
    • Parece que ele é um estudante universitário no Nepal estudando desenvolvimento de software, e é realmente emocionante ver que um marco desses pode chegar tão fundo pelo mundo afora
      Espero que ele coloque isso em destaque no currículo e encontre uma boa carreira na área de desenvolvimento
    • É muito suspeito, mas parece possível

  • Parece que aquele repositório mudou de nome e agora redireciona para https://github.com/AasishPokhrel/repository/
    Que chato :-(

    • Voltou ao nome original! :-D

  • Fico curioso para saber quantos repositórios existiriam no total se incluíssemos também servidores locais de Forgejo e GitLab
    Incluindo Subversion, Mercurial, outros amigos do git e até os inimigos
    Será que alguém já criou um mecanismo de busca para essas coisas?
    Seria bom poder pesquisar uma palavra como “a” e estimar o tamanho aproximado
    A grande vantagem do GitHub centralizado sempre me pareceu ser que as pessoas de fato conseguem encontrar meu código
    Depois que a Microsoft comprou o GitHub, pensei em criar uma busca, mas acabei não fazendo porque achei que seria esforço desperdiçado, já que eu não daria conta da parte de marketing
    Recentemente, ao colocar vários projetos no Codeberg, voltei a pensar se valeria a pena tentar, mas talvez alguém já tenha saído na frente

    • Pelo método de enumeração via API mencionado nos comentários irmãos, acho que nem seria preciso estimar
      https://docs.gitlab.com/api/projects/#list-all-projects — por algum motivo estranho, o GitLab parece chamar repositórios de projetos
      https://codeberg.org/api/swagger#/repository/repoGetByID — como está ligado a partir do site Forgejo.org, provavelmente é igual tanto para Forgejo quanto para Codeberg
      E o amigo deles https://gitea.com/api/swagger#/repository/repoGetByID
      O Heptapod é um “fork amigável” do GitLab CE, então a API também funciona da mesma forma: https://heptapod.net/pages/faq#api-hgrc
      Depois disso, acho que seria preciso indexar as instâncias do GitLab por projeto: Gnome, GNU (se um dia abrirem de novo), a situação do Savannah, provavelmente Sourceforge, talvez até sourcehut
      Se eu ganhasse na loteria, gostaria de bancar a operação de instâncias do sourcegraph, da época em que ele tinha licença Apache, no maior número possível de lugares, e doar esse snapshot ao Internet Archive
    • O Software Heritage catalogou 380 milhões de repositórios públicos, dos quais 280 milhões estão no GitHub: https://archive.softwareheritage.org/
      A busca de repositórios ainda é bastante limitada, permitindo apenas coisas como busca de texto completo por URL ou em alguns poucos arquivos de metadados, como package.json

  • https://ohshitgit.com