Was It Never Collected, or Rewritten Away? A Commit-Provenance Dataset Separating Ingestion Gaps from Upstream History Edits across the World of Code

Resumen Técnico: Un conjunto de datos de procedencia de commits que separa las brechas de ingesta de las ediciones de historial ascendente

Planteamiento del problema
Los espejos globales de control de versiones de código abierto, como World of Code (WoC), son inherentemente incompletos. Cuando un estudio observa un commit "ausente" (uno anunciado por el proyecto ascendente pero ausente en el espejo), la causa es ambigua. La ausencia puede deberse a una brecha de recolección (el espejo nunca ingirió el commit) o a una edición de historial ascendente (el proyecto realizó un force-push, rebase o squash, borrando el commit de la historia actual del repositorio). Tratar esto como un único saco de "commits faltantes" conduce a dos errores analíticos: sobrestima la verdadera brecha de recolección y oculta silenciosamente los commits reescritos que, al ser recreados con nuevos SHAs en otros lugares, inflan los conteos de contribuciones. Los conjuntos de datos existentes carecen de un mecanismo para distinguir entre estos dos fenómenos a escala.

Metodología
El artículo introduce una metodología para resolver esta ambigüedad mediante la triangulación de dos vistas independientes del mismo grafo de commits:

1. El testigo histórico (GHArchive): El flujo de PushEvents de GHArchive sirve como un registro de solo adición (append-only) de lo que GitHub anunció en el momento de un push. Registra los SHAs de los commits before y head para cada actualización de referencia. Crucialmente, no existe un flag de "fuerza" (force) en el esquema a través de ninguna era; por lo tanto, los force-pushes deben reconstruirse estructuralmente.
2. La base de datos acumulada (World of Code V2604): Este objeto de base de datos crece mediante capturas periódicas y nunca elimina objetos una vez recolectados. Representa la unión de todo lo que el corpus ha recopilado.

Reconstrucción de Force-Push (Exp. H1)
Dado que no existe un flag de fuerza explícito, los autores reconstruyen los eventos de force-pushed recorriendo la cadena de push para cada referencia. Un push normal extiende la referencia (fast-forward), lo que significa que el before anterior coincide con el head previo. Un force-push rompe esta cadena: el nuevo before no coincide con el head anterior. Estas rupturas identifican cabezas (heads) "huérfanas", sirviendo como testigos de ediciones de historial ascendente.

Clasificación de Procedencia (Exp. H2)
Al unir cada SHA de commit anunciado de GHArchive contra la membresía de WoC, los autores asignan una etiqueta de tres vías a cada commit:

• Presente: El commit existe en WoC (recolectado antes de cualquier reescritura).
• Reescrito: El commit está ausente de WoC y fue huérfano por un force-push detectado (una edición de historial ascendente).
• Nunca-ingestado: El commit está ausente de WoC pero no fue huérfano por un force-push (un candidato a brecha de recolección).

Resultados Clave
El análisis de 1,118,116,350 commits anunciados a través del conjunto de datos arroja la siguiente distribución:

• 53.35% están Presentes en WoC.
• 6.47% están Reescritos (huérfanos de force-push).
• 40.18% Nunca fueron ingestados.

A nivel de proyecto (78,125,788 repositorios), el force-pushing se observa en el 25.47% de los repositorios, y los commits reescritos aparecen en el 12.85%. Sin embargo, el force-pushing típicamente reescribe solo una parte corta del extremo (tip) en lugar de un historial profundo, borrando una pequeña porción del volumen total de commits.

Significancia y Reivindicaciones
El artículo sostiene que la métrica de "commits faltantes" reportada tradicionalmente por los espejos es engañosa. Específicamente:

1. Reporte Honesto de Completitud: La cifra del 40.18% de "nunca-ingestados" es un límite superior de la verdadera brecha de recolección. Los autores identifican cinco razones por las cuales esta cifra sobrecuenta la brecha real (por ejemplo, el tiempo de la marca de agua (watermark), puntos ciegos pre-2015 donde no se pueden detectar force-pushes, y retrasos en la cadencia de recuperación). Aproximadamente uno de cada quince commits faltantes es en realidad una reescritura que el proyecto borró, no un fallo del espejo.
2. Corrección de Productividad: La edición de historial impone un subconteo del 10.82% en las medidas de productividad basadas en commits. Un conteo ingenuo de la historia visible actual pierde el 6.47% de los commits que fueron reescritos. Los autores lanzan un factor de corrección por proyecto para restaurar esta producción perdida.
3. Detección de Duplicados: Los commits reescritos se identifican como "duplicados de mismo parche" (same-patch duplicates). Cuando un commit es rebasado o condensado (squashed) y reemitido con un nuevo SHA, es el mismo parche. El conjunto de datos permite a los analistas tratar estos como duplicados en lugar de contribuciones distintas.

Limitaciones y Advertencias
Los autores señalan explícitamente que el conjunto de datos es conservador. El grupo de "nunca-ingestados" absorbe:

• Commits enviados después de la marca de agua de V2604.
• Reescrituras ocurridas en la era 2011–2014 donde el campo before estaba ausente.
• Commits presentes en los datos de objetos crudos pero ausentes de la tabla resuelta utilizada para la unión.
• Pérdida de historial debido a la eliminación o privatización de repositorios (lo que no deja rastro estructural en la cadena de push).

Artefactos
El artículo lanza un paquete de replicación autónomo vinculado a WoC V2604, que incluye:

• Un testigo de force-push (forcepush.gz).
• Un mapa de procedencia por commit (prov.b{0..127}.gz).
• Un resumen por proyecto (P2compaction.gz).
• Un factor de corrección de productividad por proyecto (P2prodCorr.gz).

Estos artefactos permiten que cualquier estudio a escala de WoC separe las brechas de ingesta de las ediciones ascendentes, corrija los sesgos de productividad y reporte la completitud del espejo de manera honesta.