Celebración por la creación del repositorio número mil millones en GitHub

 (github.com/AasishPokhrel)
2 puntos por GN⁺ 2025-06-12 | 1 comentarios | Compartir por WhatsApp
  • El usuario de GitHub jonmagic celebró en el Issue #1 la creación del repositorio número mil millones de GitHub e informó que el repositorio shit tiene ese ID
  • Como evidencia, la respuesta de curl -s presentada incluye id 1000000000, node_id R_kgDOOO5rKAA, name shit y full_name AasishPokhrel/shit
  • El hilo de comentarios siguió principalmente con felicitaciones y bromas usando el nombre del repositorio y el emoji 💩, y la publicación inicial recibió miles de reacciones 👍, 😄 y 🎉
  • jonmagic dejó enlaces a la documentación de GitHub, indicando que el propietario del repositorio podía usar el bloqueo de la conversación o cancelar la suscripción si lo necesitaba
  • El 28 de junio de 2025, el propietario del repositorio restringió la conversación a collaborators y la bloqueó; ese mismo día se eliminó un comentario

shit, señalado como el repositorio número mil millones

  • El título del issue es Congratulations on creating the one billionth repository on GitHub! y el contenido felicita la creación del repositorio número mil millones en GitHub
  • jonmagic felicitó al creador del repositorio y presentó como evidencia parte del resultado de la siguiente llamada a la API
  • El mensaje de felicitación incluye una broma con el nombre del repositorio, del tipo “espero que tengas la oportunidad de crear una 💩 increíble”

Reacciones en los comentarios y flujo de bromas

  • Los primeros comentarios consistieron en su mayoría en felicitaciones y juegos de palabras
    • “Estoy ansioso por ver qué 💩 increíble vas a crear”
    • “No puedo esperar a que esta 💩 despegue”
    • “Voy a hacer fork de esto”
    • “Dejo un comentario antes de que bloqueen este issue”
  • MangoCubes comentó que le tranquilizó ver que jonmagic era empleado de GitHub
  • jordigh parodió el formato típico de un comentario en un issue, preguntando algo como “¿hay una fecha estimada de corrección o alguna solución alternativa?”
  • Después siguieron apareciendo comentarios cortos como 💩, sssssssshit y “peak shit”

Aviso ante la avalancha de notificaciones

Escala de participación y reacciones

  • En el cuerpo del issue original se muestran miles de reacciones
    • 👍 4524
    • 😄 2116
    • 🎉 2638
    • ❤️ 945
    • 🚀 1201
    • 👀 611
  • En medio de la lista de comentarios aparece el mensaje de que quedan 1136 elementos más, por lo que solo se muestra una parte de los comentarios
  • En los metadatos se muestran algunos participantes y +1092

Bloqueo y estado posterior

  • El 28 de junio de 2025, el propietario del repositorio bloqueó la conversación y la restringió a collaborators
  • Ese mismo día se eliminó un comentario de luckydonald
  • Al pie del issue se muestra un aviso de que hay que registrarse o iniciar sesión para participar en la conversación de GitHub

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-06-12
Opiniones de Hacker News

  • Me recordó al conjunto de cambios número 100 millones de OpenStreetMap.
    Algunas personas, incluyéndome, lo intentamos de forma casual, pero al final no se lo llevó alguien que lo estaba buscando, sino alguien que estaba mapeando África con mucho empeño.
    Viéndolo en retrospectiva, fue un desenlace mucho más entrañable, y esa persona ya había sido nominada antes a un premio de OSM.
    En OpenStreetMap todo son datos reales de producción, así que es difícil crear datos basura así nomás; por eso parece más probable que el enésimo commit sea el trabajo espontáneo de alguien.
    También es un logro divertido para GitHub :)
    Si quieres leer más sobre este hito de OSM, aquí está la publicación oficial del blog: https://blog.openstreetmap.org/2021/02/25/100-million-edits-...
    Mi resumen de la actividad de conjuntos de cambios en ese momento: https://www.openstreetmap.org/user/LucGommans/diary/395954

    • Hace tiempo, un amigo se pasó un día laboral entero intentando crear el ticket número un millón de nuestro helpdesk.
      No sé cómo lo logró al final, pero el equipo hasta hizo una pequeña fiesta para conmemorar ese logro.
      Probablemente fue hace unos 15 años; siento que en ese entonces trabajar en tecnología era más divertido.

  • ¡Genial! Al propio OpenAPI Spec de GitHub ya solo le faltan poco más de 1,000 millones de repositorios para que se desborde un int32.
    En los ID de ejecuciones de workflows eso ya está pasando.
    https://github.com/github/rest-api-description/issues/4511

    • Cuando llegué a una empresa donde trabajé brevemente como CTO, una tabla central ya tenía 1,300 millones de filas y usaba enteros de 32 bits como clave primaria.
      Al ritmo de crecimiento de entonces, en unos meses el valor de la clave primaria se iba a desbordar, así que tuvimos que impulsar con bastante urgencia un proyecto para pasar los ID a 64 bits y evitar una catástrofe.
    • Hace unas semanas, LuaRocks superó los 65,535 paquetes y eso causó algunos problemas en la comunidad de Lua.
      Ese número chocó con la implementación de LuaRocks en LuaJIT [1] [2], y algunos usuarios sufrieron fallas en sus pipelines de CI/CD y flujos de trabajo personales.
      Se resolvió bastante rápido, pero fue interesante.
      [1] https://github.com/luarocks/luarocks/issues/1797
      [2] https://github.com/openresty/docker-openresty/issues/276

  • Ojalá todavía estuviera en Apple.
    Creo que la mayoría aquí sabe que Apple usa desde hace mucho una herramienta interna llamada Radar.
    Cada Radar tiene un ID, es decir, un número de bug.
    Un Radar como el bug #1,000,000 era algo bastante especial.
    A menos que alguien metiera la pata y decepcionara a todo el equipo, normalmente era un Radar falso lleno de chistes internos.
    Con abrir uno ya bastaba, porque un Radar podía referenciar a otros Radar, así que por lo general uno terminaba cayendo en un rabbit hole y disfrutándolo.
    Fue una verdadera tontería no haber capturado o impreso algunos cuando tuve la oportunidad.

    • El sistema de control de versiones del monorepo de Google también asigna un ID monótonamente creciente a cada cambio.
      Lamentablemente, hace unos años, cuando se acercaba a cierto número redondo, la gente que intentaba quedarse con ese ID empezó a correr scripts y el sistema quedó en estado de denegación de servicio.
      Por eso ahora se saltan los ID cercanos a números redondos grandes :(
      Probablemente aquí haya alguna lección sobre diseño de esquemas.
    • Por otro lado, pensando en cómo Apple maneja los datos confidenciales, no creo que uno quisiera que lo atraparan sacando documentos internos, por más inofensivos que parecieran.

  • Ya que hablamos de los ID de repositorios de GitHub, el primer repositorio está aquí:
    https://api.github.com/repositories/1
    https://github.com/mojombo/grit

  • Probablemente estuvo revisando repetidamente con un script https://api.github.com/repositories/999999999 y creó un repositorio nuevo en cuanto apareció.
    Como los repositorios se pueden modificar, quizá creó varios con margen y luego borró los que no tenían el número correcto.
    Viendo otros repositorios que el autor creó ayer, parece que “yep” era el número mágico y “shit” era admitir que se había quedado corto.
    ¿Alguien recuerda el D666666 de Facebook?
    Fue una conversión de código enorme, y el autor usó una técnica parecida para obtener un número específico.

    • O quizá no.
      No sé por qué se asume que esta persona intentó quedarse con ese repositorio a propósito.
    • Como es un repositorio vacío, parece que sí.

  • Hablando en serio, me sorprende un poco que GitHub haya hecho tan fácil calcular la velocidad a la que se crean nuevos repositorios
    ¿Este tipo de información no suele ser un secreto corporativo?

    • Supongo que cuando tu foso mide 1.000 millones de ancho, acabas paseándote un poco en ropa interior
    • ¿Hay alguna razón por la que GitHub debería ocultar esta información?
      No veo cómo se podría usar esto en contra de GitHub
      Entiendo que muchas empresas tengan como valor predeterminado no revelar nada a menos que se las obligue
    • Con búsqueda binaria también se puede encontrar rapidísimo el ID más reciente
      Antes rastreaba así el crecimiento de varios sitios web
    • También se puede ver la velocidad de creación de nuevos usuarios
      En cierto modo, eso es más interesante

  • Me pregunto si AasishPokhrel creó este repositorio para que fuera el repositorio número 1.000 millones

    • AasishPokhrel creó ayer 2 repositorios, “shit” y “yep”
      No tuvo actividad entre el 17 de mayo y el 10 de junio
      No sé si se puede calcular la velocidad de creación de repositorios y crear uno justo para que coincida con el número deseado
    • Esto se puede manipular con bastante facilidad
      Basta con seguir creando repositorios hasta que salga el número 1.000 millones y luego borrar los anteriores
      Con la API de GitHub es muy sencillo
      El único problema son los límites de velocidad y otras personas creando repositorios al mismo tiempo, así que al final es cuestión de suerte
    • Parece que es un estudiante universitario de Nepal que estudia desarrollo de software, y de verdad conmueve que un hito así pueda llegar tan lejos en el mundo
      Ojalá lo ponga bien destacado en su CV y encuentre una buena carrera en desarrollo
    • Muy sospechoso, pero parece posible

  • Parece que le cambiaron el nombre a ese repositorio y ahora redirige a https://github.com/AasishPokhrel/repository/
    Qué mal :-(

    • ¡Volvió a su nombre original! :-D

  • Me pregunto cuántos repositorios habrá en total si sumamos también los servidores locales de Forgejo y GitLab
    Incluyendo Subversion, Mercurial, otros amigos de git y hasta sus enemigos
    ¿Alguien habrá creado ya un buscador para todo esto?
    Estaría bueno poder buscar una palabra como “a” para estimar más o menos la escala
    La gran ventaja de un GitHub centralizado siempre me pareció que la gente realmente puede encontrar mi código
    Después de que Microsoft compró GitHub, pensé en crear un buscador, pero al final no lo hice porque no iba a poder con la parte de marketing y sería trabajo en vano
    Últimamente he subido varios proyectos a Codeberg y volví a pensar si valdría la pena intentarlo, aunque quizá alguien ya se me adelantó

    • Por los métodos de enumeración vía API mencionados en los comentarios hermanos, parece que no hace falta estimar
      https://docs.gitlab.com/api/projects/#list-all-projects — por alguna razón extraña, GitLab parece llamarlos proyectos, no repositorios
      https://codeberg.org/api/swagger#/repository/repoGetByID — como está enlazado desde el sitio de Forgejo.org, probablemente sea igual para Forgejo y Codeberg
      Y su amigo https://gitea.com/api/swagger#/repository/repoGetByID
      Heptapod es un “fork amigable” de GitLab CE, así que la API funciona igual: https://heptapod.net/pages/faq#api-hgrc
      Luego habría que indexar las instancias de GitLab por proyecto: Gnome, GNU (si algún día lo vuelven a abrir), cómo está lo de Savannah, probablemente Sourceforge, y quizá incluso sourcehut
      Si me ganara la lotería, me gustaría financiar la operación de instancias de sourcegraph, de cuando tenía licencia Apache, en tantos lugares como fuera posible, y donar esa instantánea a Internet Archive
    • Software Heritage catalogó 380 millones de repositorios públicos, de los cuales 280 millones están en GitHub: https://archive.softwareheritage.org/
      La búsqueda de repositorios todavía es bastante limitada: básicamente búsqueda de texto completo por URL o en unos pocos archivos de metadatos como package.json

  • https://ohshitgit.com