← Neueste Arbeiten
💻 computer science

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

Dieses Paper führt einen Commit-Provenienz-Datensatz ein, der zwischen fehlenden Commits unterscheidet, die durch Upstream-Historien-Rewrites (Force-Pushes) verursacht wurden, und solchen, die aus echten Ingestionslücken in globalen Code-Spiegeln resultieren, wobei aufgezeigt wird, dass etwa 6,5 % der fehlenden Commits umgeschrieben statt verloren gegangen sind, und Korrekturfaktoren bereitstellt, um die Genauigkeit der Beitragszählung und der Vollständigkeitsberichterstattung von Spiegeln zu verbessern.

Ursprüngliche Autoren: Audris Mockus

Veröffentlicht 2026-07-07
📖 5 Min. Lesezeit🧠 Tiefgang

Ursprüngliche Autoren: Audris Mockus

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen, ein perfektes, vollständiges Fotoalbum von jedem einzelnen Moment in einem riesigen, globalen Kunstprojekt zu führen, in dem Tausende von Menschen ständig über die Arbeit der anderen malen, ausradieren und neu übermalen.

Dieses Papier handelt von einem neuen Werkzeug, das uns hilft zu verstehen, warum einige Fotos in unserem Album fehlen.

Das Problem: Das „Vermisste Foto“-Rätsel

Seit Jahren versuchen Forscher, jedes einzelne Commit (ein „Foto“ von Code-Änderungen) von GitHub in einer riesigen Datenbank namens World of Code (WoC) zu sammeln. Aber sie bemerkten ein Problem: Das Album ist unvollständig. Es fehlen Millionen von „Fotos“, die eigentlich vorhanden sein sollten.

Früher nahmen Forscher einfach an, dass diese Fotos für immer verloren seien, weil das Erfassungssystem versagt hatte. Sie dachten: „Oh, wir haben 40 % der Fotos verpasst; unsere Sammlung ist fehlerhaft.“

Doch dieses Papier argumentiert: Moment mal. Vielleicht sind die Fotos nicht verloren gegangen; vielleicht wurden sie mit Absicht gelöscht.

Die zwei Verdächtigen

Die Autorin, Audris Mockus, identifiziert zwei sehr unterschiedliche Gründe, warum ein Foto fehlen könnte:

  1. Die Erfassungslücke (Der „Verpasste Schuss“): Die Kamera (das Erfassungssystem) hat geblinzelt, oder die Dateübertragung ist fehlgeschlagen, und das Foto wurde nie gespeichert. Dies ist ein echter Fehler.
  2. Das Umschreiben der Historie (Der „Gelöschte Entwurf“): Der Künstler (der Projektbesitzer) fand eine bestimmte Version des Gemäldes nicht gut. Er nutzte einen „Force-Push“ (einen digitalen Radiergummi), um diese Version aus der Historie zu löschen und durch eine neue zu ersetzen. Das Foto existierte nie in der finalen Version, weil der Künstler es gelöscht hat.

Die alte Art des Zählens warf diese beiden Fälle in einen Topf. Es sagte: „Uns fehlen 46 % der Fotos!“ Das ließ die Sammlung viel schlechter aussehen, als sie tatsächlich war.

Die Detektivarbeit: Zwei verschiedene Blickwinkel

Um dieses Rätsel zu lösen, verwendete die Autorin zwei verschiedene „Kameras“, um dasselbe Ereignis zu betrachten:

  • Kamera A (GHArchive): Dies ist wie eine Überwachungskamera, die alles aufzeichnet, was in dem Moment beworben wurde, als es geschah. Es ist ihr egal, ob ein Foto später gelöscht wird; sie zeichnet einfach auf: „Um 14:00 Uhr wurde jemand ein Foto namens ‚Commit X‘ gepusht.“
  • Kamera B (World of Code): Dies ist das aktuelle Fotoalbum. Es enthält alles, was bisher gesammelt wurde, behält aber gelöschte Fotos nicht bei.

Durch den Vergleich des Protokolls der Überwachungskamera (was beworben wurde) mit dem aktuellen Album (was aufbewahrt wird), konnte die Autorin jedes fehlende Foto in drei ordentliche Stapel sortieren:

  1. Vorhanden: Das Foto ist im Album. (53 % der Zeit)
  2. Umgeschrieben: Das Foto wurde beworben, aber der Künstler hat es später gelöscht. Die Überwachungskamera hat es gesehen, aber das Album hat es nicht, weil es gelöscht wurde. (6,5 % der Zeit)
  3. Nie erfasst: Das Foto wurde beworben, der Künstler hat es nicht gelöscht, aber das Album hat es trotzdem nicht. Dies ist die wahre Erfassungslücke. (40 % der Zeit)

Die große Überraschung

Die Ergebnisse waren schockierend. Früher dachte man, die „Fehlrate“ läge bei fast 47 %.

  • Die Realität: Nur 40 % sind wirklich verloren (Erfassungslücken).
  • Die Wendung: Etwa 6,5 % der „fehlenden“ Fotos wurden tatsächlich von den Künstlern selbst gelöscht.

Das bedeutet: Von jeweils 15 fehlenden Fotos war eines kein Fehler des Sammlers, sondern eine bewusste Änderung durch das Projekt.

Warum das wichtig ist (in einfachen Worten)

1. Ehrliche Berichterstattung
Wenn Sie Software erforschen, müssen Sie nicht mehr sagen: „Unsere Daten sind zu 47 % unvollständig.“ Sie können sagen: „Unsere Daten sind zu 40 % unvollständig, und die anderen 7 % wurden von den Erstellern gelöscht.“ Dies macht Ihre Studie viel genauer.

2. Arbeit korrekt zählen
Stellen Sie sich vor, ein Arbeiter schreibt 100 Zeilen Code, löscht sie dann und schreibt sie als 100 neue Zeilen neu.

  • Alte Zählung: Sie sehen nur die 100 neuen Zeilen. Sie denken, er hat 100 Zeilen Arbeit geleistet.
  • Neue Zählung: Dieses Werkzeug sieht, dass er 100 schrieb, sie löschte und 100 weitere schrieb. Es erkennt, dass die „gelöschten“ 100 Zeilen echte Arbeit waren, die nur verborgen wurde.
  • Das Ergebnis: Das Papier zeigt, dass man, wenn man nur das zählt, was derzeit sichtbar ist, die Gesamtproduktivität um etwa 10,8 % unterschätzt. Das ist so, als würde man denken, eine Fabrik hätte 90 Autos hergestellt, obwohl sie tatsächlich 100 hergestellt hat, weil 10 aussortiert und neu gebaut wurden.

3. Doppelzählung vermeiden
Wenn ein Entwickler einen Commit umschreibt (den alten Commit löscht und einen neuen mit einer neuen ID erstellt), ist dies derselbe „Patch“ an Code. Ohne dieses Werkzeug könnte ein Computer die alte Version und die neue Version als zwei separate Beiträge zählen. Dieses Werkzeug markiert sie als Duplikate, damit man nicht verwirrt wird.

Das Fazit

Dieses Papier liefert uns eine Lupe für Detektive. Es trennt die „kaputte Kamera“ (Erfassungslücken) vom „gelöschten Entwurf“ (Umschreiben der Historie).

Es sagt uns, dass die World of Code eigentlich besser darin ist, Daten zu sammeln, als wir dachten (weil ein Teil der „fehlenden“ Daten gar nicht mehr vorgesehen war), aber es sagt uns auch, dass wir die Arbeit von Entwicklern unterschätzen, weil wir die Arbeit, die sie gelöscht haben, nicht sehen können.

Die Autorin hat alle Daten und Werkzeuge veröffentlicht, damit jeder diese „Detektiv-Linse“ nutzen kann, um ein klareres, ehrlicheres Bild der Welt des Codes zu erhalten.

Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?

Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.

Digest testen →