English ▾ Themen ▾ Neueste Version ▾ git-commit-tree zuletzt aktualisiert in 2.49.0

NAME

git-commit-tree - Erstellt ein neues Commit-Objekt

SYNOPSIS

git commit-tree <tree> [(-p <parent>)…​]
git commit-tree [(-p <parent>)…​] [-S[<keyid>]] [(-m <message>)…​]
		  [(-F <file>)…​] <tree>

BESCHREIBUNG

Dies ist normalerweise nicht das, was ein Endbenutzer direkt ausführen möchte. Siehe stattdessen git-commit[1].

Erstellt ein neues Commit-Objekt basierend auf dem bereitgestellten Baum-Objekt und gibt die neue Commit-Objekt-ID auf stdout aus. Die Log-Nachricht wird vom Standard-Input gelesen, es sei denn, die Optionen -m oder -F sind angegeben.

Die Optionen -m und -F können beliebig oft und in beliebiger Reihenfolge angegeben werden. Die Commit-Log-Nachricht wird in der Reihenfolge zusammengestellt, in der die Optionen angegeben werden.

Ein Commit-Objekt kann beliebig viele Eltern haben. Mit genau einem Elternteil ist es ein gewöhnliches Commit. Mehrere Eltern machen das Commit zu einem Merge zwischen mehreren Verläufe. Initiale (Root-)Commits haben keine Eltern.

Während ein Baum einen bestimmten Verzeichniszustand eines Arbeitsverzeichnisses repräsentiert, repräsentiert ein Commit diesen Zustand in der "Zeit" und erklärt, wie man dorthin gelangt.

Normalerweise würde ein Commit einen neuen "HEAD"-Zustand identifizieren, und während es Git egal ist, wo Sie die Notiz über diesen Zustand speichern, speichern wir sie in der Praxis tendenziell einfach in der Datei, auf die .git/HEAD zeigt, damit wir immer sehen können, was der letzte committete Zustand war.

OPTIONEN

<tree>

Ein bestehendes Baum-Objekt.

-p <parent>

Jedes -p gibt die ID eines Eltern-Commit-Objekts an.

-m <message>

Ein Absatz in der Commit-Log-Nachricht. Dies kann mehrfach angegeben werden und jede <message> wird zu einem eigenen Absatz.

-F <file>

Liest die Commit-Log-Nachricht aus der angegebenen Datei. Verwenden Sie -, um aus dem Standard-Input zu lesen. Dies kann mehrfach angegeben werden und der Inhalt jeder Datei wird zu einem eigenen Absatz.

-S[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign

GPG-sign Commits. Das Argument keyid ist optional und standardmäßig die Committer-Identität; wenn es angegeben wird, muss es ohne Leerzeichen an die Option angehängt werden. --no-gpg-sign ist nützlich, um eine zuvor auf der Kommandozeile gegebene Option --gpg-sign zu widerrufen.

Commit-Informationen

Ein Commit kapselt

  • alle Elternobjekt-IDs

  • Autorname, E-Mail und Datum

  • Committersname und E-Mail und die Commit-Zeit.

Ein Commit-Kommentar wird von stdin gelesen. Wenn kein Changelog-Eintrag über "<" Umleitung bereitgestellt wird, wartet git commit-tree einfach darauf, dass einer eingegeben und mit ^D beendet wird.

DATUMSFORMATE

Die Umgebungsvariablen GIT_AUTHOR_DATE und GIT_COMMITTER_DATE unterstützen die folgenden Datumsformate:

Git internes Format

Es ist <unix-timestamp> <time-zone-offset>, wobei <unix-timestamp> die Anzahl der Sekunden seit der UNIX-Epoche ist. <time-zone-offset> ist ein positiver oder negativer Offset von UTC. Zum Beispiel ist CET (das 1 Stunde vor UTC liegt) +0100.

RFC 2822

Das Standard-Datumsformat wie in RFC 2822 beschrieben, zum Beispiel Thu, 07 Apr 2005 22:13:13 +0200.

ISO 8601

Zeit und Datum gemäß dem ISO 8601-Standard, zum Beispiel 2005-04-07T22:13:13. Der Parser akzeptiert auch ein Leerzeichen anstelle des T-Zeichens. Bruchteile von Sekunden werden ignoriert, zum Beispiel wird 2005-04-07T22:13:13.019 als 2005-04-07T22:13:13 behandelt.

Hinweis
 Zusätzlich werden Datumsangaben in den folgenden Formaten akzeptiert: JJJJ.MM.TT, MM/TT/JJJJ und TT.MM.JJJJ.

Diskussion

Git ist bis zu einem gewissen Grad zeichenkodierungsunabhängig.

  • Der Inhalt der Blob-Objekte sind uninterpretierte Bytefolgen. Auf Kern-Ebene erfolgt keine Kodierungsumwandlung.

  • Pfadnamen werden in UTF-8 Normalisierungsform C kodiert. Dies gilt für Baum-Objekte, die Indexdatei, Ref-Namen sowie für Pfadnamen in Kommandozeilenargumenten, Umgebungsvariablen und Konfigurationsdateien (.git/config (siehe git-config[1]), gitignore[5], gitattributes[5] und gitmodules[5]).

    Beachten Sie, dass Git auf Kern-Ebene Pfadnamen einfach als Folgen von Nicht-NUL-Bytes behandelt, es gibt keine Pfadnamen-Kodierungskonvertierungen (außer unter Mac und Windows). Daher funktionieren nicht-ASCII-Pfadnamen meist auch auf Plattformen und Dateisystemen, die Legacy-Erweiterte-ASCII-Kodierungen verwenden. Repositories, die auf solchen Systemen erstellt wurden, funktionieren jedoch nicht ordnungsgemäß auf UTF-8-basierten Systemen (z. B. Linux, Mac, Windows) und umgekehrt. Zusätzlich gehen viele Git-basierte Werkzeuge einfach davon aus, dass Pfadnamen UTF-8 sind und werden andere Kodierungen nicht korrekt anzeigen.

  • Commit-Log-Nachrichten sind typischerweise in UTF-8 kodiert, aber auch andere erweiterte ASCII-Kodierungen werden unterstützt. Dazu gehören ISO-8859-x, CP125x und viele andere, aber *nicht* UTF-16/32, EBCDIC und CJK-Multibyte-Kodierungen (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).

Obwohl wir ermutigen, dass die Commit-Log-Nachrichten in UTF-8 kodiert werden, sind sowohl der Kern als auch Git Porcelain so konzipiert, dass sie Projekten keine UTF-8 aufzwingen. Wenn alle Teilnehmer eines bestimmten Projekts es bequemer finden, Legacy-Kodierungen zu verwenden, verbietet Git dies nicht. Es gibt jedoch ein paar Dinge zu beachten.

  1. git commit und git commit-tree geben eine Warnung aus, wenn die ihnen übergebene Commit-Log-Nachricht keine gültige UTF-8-Zeichenkette zu sein scheint, es sei denn, Sie geben explizit an, dass Ihr Projekt eine Legacy-Kodierung verwendet. Dies geschieht durch Festlegen von i18n.commitEncoding in der Datei .git/config, wie folgt

    [i18n]
	commitEncoding = ISO-8859-1

    Mit der obigen Einstellung erstellte Commit-Objekte speichern den Wert von i18n.commitEncoding in ihrer encoding-Kopfzeile. Dies soll anderen Personen helfen, die sie später betrachten. Das Fehlen dieser Kopfzeile impliziert, dass die Commit-Log-Nachricht in UTF-8 kodiert ist.

  2. git log, git show, git blame und Freunde betrachten den encoding Header eines Commit-Objekts und versuchen, die Log-Nachricht in UTF-8 neu zu kodieren, sofern nicht anders angegeben. Sie können die gewünschte Ausgabe-Kodierung mit i18n.logOutputEncoding in der .git/config-Datei angeben, wie folgt:

    [i18n]
	logOutputEncoding = ISO-8859-1

    Wenn Sie diese Konfigurationsvariable nicht haben, wird stattdessen der Wert von i18n.commitEncoding verwendet.

Beachten Sie, dass wir uns bewusst entschieden haben, die Commit-Log-Nachricht nicht neu zu kodieren, wenn ein Commit durchgeführt wird, um UTF-8 auf der Ebene des Commit-Objekts zu erzwingen, da die Neukodierung nach UTF-8 nicht unbedingt eine reversible Operation ist.

DATEIEN

/etc/mailname

SIEHE AUCH

git-write-tree[1] git-commit[1]

GIT

Teil der git[1] Suite