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

Resumo Técnico: Um Conjunto de Dados de Proveniência de Commits Separando Lacunas de Ingestão de Edições de Histórico Upstream

Declaração do Problema
Espelhos globais de controle de versão de código aberto, como o World of Code (WoC), são inerentemente incompletos. Quando um estudo observa um commit "ausente" (um commit anunciado pelo projeto upstream, mas ausente no espelho), a causa é ambígua. A ausência pode decorrer de uma lacuna de coleta (o espelho nunca ingeriu o commit) ou de uma edição de histórico upstream (o projeto realizou um force-push, rebase ou squash, apagando o commit do histórico atual do repositório). Tratar isso como um único balde de "commits ausentes" leva a dois erros analíticos: superestima a verdadeira lacuna de coleta e oculta silenciosamente commits reescritos que, quando recriados com novos SHAs em outro lugar, inflam as contagens de contribuição. Conjuntos de dados existentes carecem de um mecanismo para distinguir esses dois fenômenos em escala.

Metodologia
O artigo introduz uma metodologia para resolver essa ambiguidade através da triangulação de duas visões independentes do mesmo grafo de commits:

1. A Testemunha Histórica (GHArchive): O fluxo de PushEvent do GHArchive serve como um log de anexação (append-only) do que o GitHub anunciou no momento de um push. Ele registra os SHAs de commit before e head para cada atualização de referência. Crucialmente, não existe uma flag de "força" (force) registrada no esquema em nenhuma era; portanto, os force-pushes devem ser reconstruídos estruturalmente.
2. O Banco de Dados Acumulado (World of Code V2604): Este banco de dados de objetos cresce via buscas periódicas e nunca deleta objetos uma vez coletados. Ele representa a união de tudo o que o corpus já reuniu.

Reconstrução de Force-Push (Exp. H1)
Como não existe uma flag de força explícita, os autores reconstroem eventos de force-push percorrendo a cadeia de push para cada referência. Um push normal estende a referência (fast-forward), o que significa que o before anterior coincide com o head anterior. Um force-push quebra essa cadeia: o novo before não coincide com o head anterior. Essas quebras identificam cabeças (heads) anteriores "órfãs", servindo como testemunhas de edições de histórico upstream.

Classificação de Proveniência (Exp. H2)
Ao cruzar cada SHA de commit anunciado pelo GHArchive contra a participação no WoC, os autores atribuem um rótulo de três vias a cada commit:

• Presente (Present): O commit existe no WoC (coletado antes de qualquer reescrita).
• Reescrito (Rewritten): O commit está ausente do Wo WoC e foi órfão de um force-push detectado (uma edição de histórico upstream).
• Nunca-ingerido (Never-ingested): O commit está ausente do WoC, mas não foi órfão de um force-push (um candidato a lacuna de coleta).

Resultados Principais
A análise de 1.118.116.350 commits anunciados através do conjunto de dados resulta na seguinte distribuição:

• 53,35% estão Presentes no WoC.
• 6,47% foram Reescritos (órfãos de force-push).
• 40,18% Nunca foram ingeridos.

Ao nível do projeto (78.125.788 repositórios), o force-pushing é observado em 25,47% dos repositórios, e commits reescritos aparecem em 12,85%. No entanto, o force-pushing tipicamente reescreve apenas uma pequena extremidade (tip), em vez de um histórico profundo, apagando uma pequena fatia do volume total de commits.

Significância e Alegações
O artigo afirma que a métrica de "commit ausente" tradicionalmente reportada pelos espelhos é enganosa. Especificamente:

1. Relato Honesto de Completude: O número de 40,18% de "nunca-ingeridos" é um limite superior para a verdadeira lacuna de coleta. Os autores identificam cinco razões pelas quais este número superestima a lacça real (ex: tempo de watermark, pontos cegos pré-2015 onde force-pushes não podem ser detectados e atrasos na cadência de recuperação). Aproximadamente um em cada quinze commits ausentes é, na verdade, uma reescrita que o projeto apagou, não uma falha do espelho.
2. Correção de Produtividade: A edição de histórico impõe uma subcontagem de 10,82% nas medidas de produtividade baseadas em commits. Uma contagem ingênua do histórico visível atual perde os 6,47% de commits que foram reescritos. Os autores liberam um fator de correção por projeto para restaurar esta produção perdida.
3. Detecção de Duplicatas: Commits reescritos são identificados como "duplicatas de mesmo patch" (same-patch duplicates). Quando um commit é rebaseado ou sofre squash e é reemitido com um novo SHA, ele é o mesmo patch. O conjunto de dados permite que analistas tratem isso como duplicatas em vez de contribuições distintas.

Limitações e Ressalvas
Os autores explicitamente observam que o conjunto de dados é conservador. O balde "nunca-ingerido" absorve:

• Commits enviados após o watermark do V2604.
• Reescritas ocorrendo na era 2011–2014 onde o campo before estava ausente.
• Commits presentes nos dados brutos de objetos, mas ausentes da tabela resolvida usada para o cruzamento (join).
• Perda de histórico devido à exclusão ou privatização de repositórios (o que não deixa rastro estrutural na cadeia de push).

Artefatos
O artigo libera um pacote de replicação autossuficiente vinculado ao WoC V2604, incluindo:

• Uma testemunha de force-push (forcepush.gz).
• Um mapa de proveniência por commit (prov.b{0..127}.gz).
• Um agrupamento (rollup) por projeto (P2compaction.gz).
• Um fator de correção de produtividade por projeto (P2prodCorr.gz).

Estes artefatos permitem que qualquer estudo em escala WoC separe lacunas de ingestão de edições upstream, corrija vieses de produtividade e reporte a completude do espelho honestamente.