Reformatierungs-Commits aus git blame heraushalten: -w und Ignore-Revs-Dateien

Worum es geht

git blame versieht jede Zeile mit dem Commit, der sie zuletzt geändert hat. Ein Formatter-Lauf, eine Änderung der Einrückung oder eine Normalisierung der Zeilenenden „ändert“ jede Zeile, und von da an zeigt blame auf den Aufräum-Commit statt auf die Änderung, die die Logik eingeführt hat. Die Dokumentation bietet dagegen drei Werkzeuge:

• -w ignoriert Whitespace beim Vergleich der Version des Eltern-Commits mit der des Kind-Commits, um zu bestimmen, woher Zeilen stammen.
• --ignore-rev <rev> behandelt einen Commit, als hätte er nie stattgefunden; von ihm betroffene Zeilen werden dem früheren Commit zugeschrieben, der sie geändert hat. --ignore-revs-file <file> liest solche Commits aus einer Datei, und blame.ignoreRevsFile in der Konfiguration wendet eine Datei automatisch an. Mit blame.markIgnoredLines werden die so neu zugeschriebenen Zeilen mit ? markiert; mit blame.markUnblamableLines werden Zeilen, die keinem anderen Commit zugeschrieben werden können, mit * markiert.
• -M erkennt innerhalb einer Datei verschobene oder kopierte Zeilen, und -C erkennt zusätzlich Zeilen, die aus anderen, im selben Commit geänderten Dateien verschoben oder kopiert wurden, sodass ein Refactoring, das Code verlagert, die ursprüngliche Autorschaft erhält.

Die GitHub-Dokumentation besagt, dass eine Datei namens .git-blame-ignore-revs im Wurzelverzeichnis des Repositorys automatisch auf dessen Blame-Ansicht angewendet wird.

Warum es wichtig ist

Über blame finden Reviewer, Bereitschaftsdienste und Agenten die Begründung hinter einer Zeile: die Commit-Nachricht, den Pull Request, das Ticket. Eine Historie, in der jede Zeile auf „apply black“ oder „prettier 3.0“ zeigt, verliert diese Spur genau in dem Moment, in dem sie gebraucht wird.

So wird es angewendet

• Grosse mechanische Änderungen in eigenen Commits halten, die nichts anderes enthalten, damit sie sich als Ganzes ignorieren lassen.
• Den vollständigen Commit-Hash jedes solchen Commits mit einer erläuternden Kommentarzeile in .git-blame-ignore-revs eintragen und die Datei committen.
• In jedem Klon git config blame.ignoreRevsFile .git-blame-ignore-revs setzen (per Setup-Skript oder dokumentiertem Einzeiler); ohne das wendet die Kommandozeile die Datei nicht an.
• Bei Untersuchungen standardmässig git blame -w -M -C verwenden und -L <start>,<end>, um den Bereich einzuschränken.
• Editoren und Code-Hosts lesen dieselbe Datei; vor dem Verlassen darauf prüfen, welche das tatsächlich tun.

Stolpersteine

Wird ein Commit ignoriert, der auch echte Änderungen enthielt, verbirgt das diese Änderungen vor blame. Hashes müssen unabgekürzt sein (die Konfigurationsdokumentation verlangt einen unabgekürzten Objektnamen pro Zeile), und nach einer Umschreibung der Historie passen die gelisteten IDs zu nichts mehr, sodass die Datei neu erzeugt werden muss. git log -S und git bisect sind davon nicht betroffen und finden den Commit bei Bedarf weiterhin.