English ▾ Themen ▾ Neueste Version ▾ git-annotate zuletzt aktualisiert in 2.52.0

NAME

git-annotate - Datei-Zeilen mit Commit-Informationen annotieren

SYNOPSIS

git annotate [<options>] [<rev-opts>] [<rev>] [--] <file>

BESCHREIBUNG

Annotiert jede Zeile in der gegebenen Datei mit Informationen aus dem Commit, der die Zeile eingeführt hat. Optional kann von einer gegebenen Revision annotiert werden.

Der einzige Unterschied zwischen diesem Befehl und git-blame[1] besteht darin, dass sie leicht unterschiedliche Ausgabeformate verwenden, und dieser Befehl existiert nur zur Rückwärtskompatibilität zur Unterstützung bestehender Skripte und zur Bereitstellung eines vertrauteren Befehlsnamens für Personen, die von anderen SCM-Systemen kommen.

OPTIONEN

-b

Zeige leere SHA-1 für Grenz-Commits. Dies kann auch über die Konfigurationsoption blame.blankBoundary gesteuert werden.

--root

Behandle keine Root-Commits als Grenzen. Dies kann auch über die Konfigurationsoption blame.showRoot gesteuert werden.

--show-stats

Füge zusätzliche Statistiken am Ende der Blame-Ausgabe ein.

-L <start>,<end>
-L :<funcname>

Annotiere nur den Zeilenbereich, der durch <start>,<end> oder den Funktionsnamen-Regex <funcname> gegeben ist. Kann mehrmals angegeben werden. Überlappende Bereiche sind erlaubt.

<start> und <end> sind optional. -L <start> oder -L <start>, reicht von <start> bis zum Ende der Datei. -L ,<end> reicht vom Anfang der Datei bis <end>.

<Start> und <Ende> können eine der folgenden Formen annehmen:

  • <Nummer>

    Wenn <Start> oder <Ende> eine Zahl ist, gibt sie eine absolute Zeilennummer an (Zeilen werden ab 1 gezählt).

  • /<Regulärer Ausdruck>/

    Diese Form verwendet die erste Zeile, die dem gegebenen POSIX-<Regulärer Ausdruck> entspricht. Wenn <Start> ein regulärer Ausdruck ist, wird vom Ende des vorherigen -L-Bereichs, falls vorhanden, ansonsten vom Anfang der Datei gesucht. Wenn <Start> ^/<Regulärer Ausdruck>/ ist, wird vom Anfang der Datei gesucht. Wenn <Ende> ein regulärer Ausdruck ist, wird ab der von <Start> angegebenen Zeile gesucht.

  • +<Offset> oder -<Offset>

    Dies ist nur für <Ende> gültig und gibt eine Anzahl von Zeilen vor oder nach der von <Start> angegebenen Zeile an.

Wenn :<Funktionsname> anstelle von <Start> und <Ende> angegeben ist, ist dies ein regulärer Ausdruck, der den Bereich vom ersten Funktionsnamen-Zeile, der <Funktionsname> entspricht, bis zur nächsten Funktionsnamen-Zeile bezeichnet. :<Funktionsname> sucht vom Ende des vorherigen -L-Bereichs, falls vorhanden, ansonsten vom Anfang der Datei. ^:<Funktionsname> sucht vom Anfang der Datei. Die Funktionsnamen werden auf die gleiche Weise bestimmt wie git diff Hunk-Header ermittelt (siehe Defining a custom hunk-header in gitattributes[5]).

-l

Zeige lange Rev (Standard: aus).

-t

Zeige rohe Zeitstempel (Standard: aus).

-S <revs-file>

Verwende Revisionen aus revs-file anstelle des Aufrufs von git-rev-list[1].

--reverse <rev>..<rev>

Durchlaufe die Historie vorwärts statt rückwärts. Anstatt die Revision anzuzeigen, in der eine Zeile erschien, zeigt dies die letzte Revision an, in der eine Zeile existiert hat. Dies erfordert einen Bereich von Revisionen wie START..END, in dem der zu blame-ende Pfad in START existiert. git blame --reverse START wird der Bequemlichkeit halber als git blame --reverse START..HEAD interpretiert.

--first-parent

Folge nur dem ersten Eltern-Commit, wenn ein Merge-Commit gesehen wird. Diese Option kann verwendet werden, um zu bestimmen, wann eine Zeile in einen bestimmten Integrations-Branch eingeführt wurde, anstatt wann sie insgesamt in der Historie eingeführt wurde.

-p
--porcelain

Gib im Format aus, das für die maschinelle Verarbeitung vorgesehen ist.

--line-porcelain

Gib das Porcelain-Format aus, aber gib die Commit-Informationen für jede Zeile aus, nicht nur für die erste Referenz eines Commits. Impliziert --porcelain.

--incremental

Zeige das Ergebnis inkrementell in einem für die maschinelle Verarbeitung vorgesehenen Format an.

--encoding=<encoding>

Gibt die für die Ausgabe von Autorennamen und Commit-Zusammenfassungen verwendete Kodierung an. Das Einstellen auf none bewirkt, dass die Blame-Ausgabe unkonvertierte Daten liefert. Weitere Informationen finden Sie in der Diskussion zur Kodierung im Handbuch von git-log[1].

--contents <file>

Annotiere unter Verwendung des Inhalts aus der benannten Datei, beginnend mit <rev>, falls angegeben, andernfalls HEAD. Sie können - angeben, um den Befehl die Dateiinhalte aus der Standardeingabe lesen zu lassen.

--date <format>

Gibt das für die Datumsangabe verwendete Format an. Wenn --date nicht angegeben wird, wird der Wert der Konfigurationsvariablen blame.date verwendet. Wenn die Konfigurationsvariable blame.date ebenfalls nicht gesetzt ist, wird das ISO-Format verwendet. Für unterstützte Werte siehe die Diskussion der --date-Option in git-log[1].

--progress
--no-progress

Der Fortschrittsstatus wird standardmäßig auf dem Standardfehlerstrom gemeldet, wenn er an ein Terminal angeschlossen ist. Diese Flagge aktiviert die Fortschrittsmeldung auch dann, wenn kein Terminal angeschlossen ist. --progress kann nicht zusammen mit --porcelain oder --incremental verwendet werden.

-M[<num>]

Erkenne verschobene oder kopierte Zeilen innerhalb einer Datei. Wenn ein Commit einen Block von Zeilen verschiebt oder kopiert (z. B. die ursprüngliche Datei hat A, dann B, und der Commit ändert sie zu B, dann A), bemerkt der traditionelle blame-Algorithmus nur die Hälfte der Bewegung und blame-t typischerweise die nach oben verschobenen Zeilen (d.h. B) auf das Eltern-Commit und weist die nach unten verschobenen Zeilen (d.h. A) dem Kind-Commit zu. Mit dieser Option werden beide Gruppen von Zeilen auf das Eltern-Commit geblamet, indem zusätzliche Inspektionsdurchläufe durchgeführt werden.

<num> ist optional, aber es ist die untere Grenze für die Anzahl alphanumerischer Zeichen, die Git als verschoben/kopiert innerhalb einer Datei erkennen muss, damit diese Zeilen dem Eltern-Commit zugeordnet werden. Der Standardwert ist 20.

-C[<num>]

Erkenne zusätzlich zu -M Zeilen, die aus anderen Dateien verschoben oder kopiert wurden, die im selben Commit geändert wurden. Dies ist nützlich, wenn Sie Ihr Programm neu organisieren und Code über Dateien hinweg verschieben. Wenn diese Option zweimal gegeben wird, sucht der Befehl zusätzlich nach Kopien aus anderen Dateien im Commit, der die Datei erstellt. Wenn diese Option dreimal gegeben wird, sucht der Befehl zusätzlich nach Kopien aus anderen Dateien in jedem Commit.

<num> ist optional, aber es ist die untere Grenze für die Anzahl alphanumerischer Zeichen, die Git als zwischen Dateien verschoben/kopiert erkennen muss, damit diese Zeilen dem Eltern-Commit zugeordnet werden. Und der Standardwert ist 40. Wenn mehr als eine -C-Option angegeben wird, hat das <num>-Argument der letzten -C Wirkung.

--ignore-rev <rev>

Ignoriere Änderungen, die durch die Revision vorgenommen wurden, bei der Zuweisung von Blame, als ob die Änderung nie stattgefunden hätte. Zeilen, die von einem ignorierten Commit geändert oder hinzugefügt wurden, werden dem vorherigen Commit zugewiesen, der diese Zeile oder nahegelegene Zeilen geändert hat. Diese Option kann mehrmals angegeben werden, um mehr als eine Revision zu ignorieren. Wenn die Konfigurationsoption blame.markIgnoredLines gesetzt ist, werden Zeilen, die von einem ignorierten Commit geändert und einem anderen Commit zugewiesen wurden, mit einem ? in der Blame-Ausgabe markiert. Wenn die Konfigurationsoption blame.markUnblamableLines gesetzt ist, werden Zeilen, die von einem ignorierten Commit berührt wurden und denen keine andere Revision zugewiesen werden konnte, mit einem * markiert. In den Porcelain-Modi geben wir ignored und unblamable jeweils auf einer neuen Zeile aus.

--ignore-revs-file <file>

Ignoriere Revisionen, die in file aufgelistet sind, welche im gleichen Format wie eine fsck.skipList sein muss. Diese Option kann wiederholt werden, und diese Dateien werden nach allen Dateien verarbeitet, die mit der Konfigurationsoption blame.ignoreRevsFile angegeben wurden. Ein leerer Dateiname, "", löscht die Liste der Revisionen aus zuvor verarbeiteten Dateien.

--color-lines

Färbe Zeilenannotationen im Standardformat unterschiedlich, wenn sie vom selben Commit wie die vorherige Zeile stammen. Dies erleichtert die Unterscheidung von Codeblöcken, die von verschiedenen Commits eingeführt wurden. Die Farbe ist standardmäßig cyan und kann über die Konfigurationsoption color.blame.repeatedLines angepasst werden.

--color-by-age

Färbe Zeilenannotationen im Standardformat je nach Alter der Zeile. Die Konfigurationsoption color.blame.highlightRecent steuert, welche Farbe für jeden Altersbereich verwendet wird.

-h

Zeige Hilfenachricht.

SIEHE AUCH

git-blame[1]

GIT

Teil der git[1] Suite