git-commit-tree - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

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

ZUSAMMENFASSUNG

git Commit-Baum [(-P )...]
git Commit-Baum [(-P )...] [-S[ ]] [(-m )...]
[(-F )...]

BESCHREIBUNG

Dies ist normalerweise nicht das, was ein Endbenutzer direkt ausführen möchte. Sehen Git-Commit(1) statt.

Erstellt ein neues Commit-Objekt basierend auf dem bereitgestellten Baumobjekt und gibt das neue Commit aus
Objekt-ID auf stdout. Die Log-Meldung wird von der Standardeingabe gelesen, es sei denn -m oder -F
Optionen gegeben sind.

Ein Commit-Objekt kann eine beliebige Anzahl von Eltern haben. Mit genau einem Elternteil ist es ein gewöhnliches
verpflichten. Wenn mehr als ein Elternteil vorhanden ist, wird der Commit zu einer Zusammenführung mehrerer Zeilen von
Geschichte. Anfängliche (root) Commits haben keine übergeordneten Elemente.

Während ein Baum einen bestimmten Verzeichnisstatus eines Arbeitsverzeichnisses darstellt, ist ein Commit
stellt diesen Zustand in "Zeit" dar und erklärt, wie man dorthin gelangt.

Normalerweise würde ein Commit einen neuen "HEAD"-Zustand identifizieren, und während Git sich nicht darum kümmert, wo du bist
Speichern Sie die Notiz zu diesem Zustand, in der Praxis neigen wir dazu, das Ergebnis einfach in die Datei zu schreiben
darauf zeigt .git/HEAD, damit wir immer sehen können, was der letzte festgeschriebene Zustand ist
war.

OPTIONAL

Ein vorhandenes Baumobjekt

-P
. -p gibt die ID eines übergeordneten Commit-Objekts an.

-m
Ein Absatz in der Commit-Log-Meldung. Dies kann mehr als einmal und jede gegeben werden
wird ein eigener Absatz.

-F
Lesen Sie die Commit-Protokollnachricht aus der angegebenen Datei. Verwenden Sie - um aus der Norm zu lesen
Eingang.

-S[ ], --gpg-Zeichen[= ]
GPG-Zeichen-Commits. Das Argument keyid ist optional und wird standardmäßig auf den Committer gesetzt
Identität; falls angegeben, muss es ohne Leerzeichen an die Option angehängt werden.

--kein-gpg-zeichen
Countermand-commit.gpgSign-Konfigurationsvariable, die so eingestellt ist, dass sie jedes einzelne erzwingt
verpflichten sich zu unterschreiben.

VERPFLICHTEN INFORMATIONEN

Ein Commit kapselt:

· alle übergeordneten Objekt-IDs

· Autorname, E-Mail und Datum

· Name und E-Mail-Adresse des Committers und die Commit-Zeit.

Während Elternobjekt-IDs in der Befehlszeile bereitgestellt werden, werden Autor- und Committer-Informationen bereitgestellt
wird aus den folgenden Umgebungsvariablen entnommen, falls gesetzt:

GIT_AUTHOR_NAME
GIT_AUTHOR_EMAIL
GIT_AUTHOR_DATE
GIT_COMMITTER_NAME
GIT_COMMITTER_EMAIL
GIT_COMMITTER_DATE

(nb "<", ">" und "\n"s werden entfernt)

Falls (einige) dieser Umgebungsvariablen nicht gesetzt sind, werden die Informationen aus
die Konfigurationselemente user.name und user.email oder, falls nicht vorhanden, die Umgebung
Variable EMAIL, oder, falls nicht gesetzt, Systembenutzername und Hostname für
ausgehende Post (entnommen aus /etc/mailname und auf den vollständig qualifizierten Hostnamen zurückgreifen
wenn diese Datei nicht existiert).

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

DATUM FORMATEN

Die Umgebungsvariablen GIT_AUTHOR_DATE, GIT_COMMITTER_DATE unterstützen das folgende Datum
Formate:

Git-internes Format
es ist , wo ist die Zahl der
Sekunden seit der UNIX-Epoche. ist ein positiver oder negativer Offset
von UTC. Zum Beispiel ist MEZ (das ist 2 Stunden vor UTC) +0200.

RFC 2822
Das Standard-E-Mail-Format wie in RFC 2822 beschrieben, zum Beispiel Do, 07 Apr 2005
22:13:13 +0200.

ISO 8601
Uhrzeit und Datum gemäß ISO 8601-Standard, zum Beispiel 2005-04-07T22:13:13. Die
Parser akzeptiert auch ein Leerzeichen anstelle des T-Zeichens.

Note
Außerdem wird der Datumsteil 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 nicht interpretierte Bytefolgen. Es gibt kein
Kodierung der Übersetzung auf der Kernebene.

· Pfadnamen sind in UTF-8-Normalisierungsform C kodiert. Dies gilt für Baumobjekte,
die Indexdatei, Referenznamen sowie Pfadnamen in Befehlszeilenargumenten,
Umgebungsvariablen und Konfigurationsdateien (.git/config (siehe git-config(1)), ignorieren(5)
gittributes(5) und gitmodule(5)).

Beachten Sie, dass Git auf der Kernebene Pfadnamen einfach als Sequenzen von Nicht-NUL behandelt
Bytes gibt es keine Konvertierungen der Pfadnamencodierung (außer auf Mac und Windows).
Daher funktioniert die Verwendung von Nicht-ASCII-Pfadnamen meistens sogar auf Plattformen und Dateien
Systeme, die ältere erweiterte ASCII-Codierungen verwenden. Repositorys, die am . erstellt wurden
solche Systeme funktionieren auf UTF-8-basierten Systemen (zB Linux, Mac, Windows) nicht richtig
und umgekehrt. Darüber hinaus gehen viele Git-basierte Tools einfach davon aus, dass Pfadnamen
UTF-8 und zeigt andere Codierungen nicht richtig an.

· Commit-Protokollnachrichten werden normalerweise in UTF-8 kodiert, aber auch andere erweiterte ASCII-Kodierungen
werden ebenfalls unterstützt. Dazu gehören ISO-8859-x, CP125x und viele andere, aber nicht
UTF-16/32, EBCDIC und CJK Multi-Byte-Kodierungen (GBK, Shift-JIS, Big5, EUC-x, CP9xx
etc.).

Obwohl wir empfehlen, dass die Commit-Log-Meldungen in UTF-8 kodiert sind, sind sowohl der Kern als auch der
Git Porcelain wurde entwickelt, um UTF-8 für Projekte nicht zu erzwingen. Wenn alle Teilnehmer von a
bestimmte Projekte finden es bequemer, Legacy-Kodierungen zu verwenden, Git verbietet es nicht
es. Es gibt jedoch ein paar Dinge zu beachten.

1. git verpflichten und git Commit-Baum gibt eine Warnung aus, wenn die ihm übergebene Commit-Log-Meldung
sieht nicht wie eine gültige UTF-8-Zeichenfolge aus, es sei denn, Sie sagen ausdrücklich, dass Ihr Projekt a . verwendet
Legacy-Codierung. Der Weg, dies zu sagen, ist i18n.commitencoding in .git/config
Datei, wie folgt:

[i18n]
Commitencoding = ISO-8859-1

Commit-Objekte, die mit der obigen Einstellung erstellt wurden, zeichnen den Wert von i18n.commitencoding auf
in seinem Codierungsheader. Dies ist, um anderen Leuten zu helfen, die sie später ansehen. Mangel an
Dieser Header impliziert, dass die Commit-Log-Meldung in UTF-8 kodiert ist.

2. git Log, git erklären, git Schuld und Freunde schauen sich den Codierungsheader eines Commits an
-Objekt und versuchen Sie, die Protokollnachricht in UTF-8 umzucodieren, sofern nicht anders angegeben. Du
kann die gewünschte Ausgabecodierung mit i18n.logoutputencoding in .git/config festlegen
Datei, wie folgt:

[i18n]
Protokollausgabecodierung = ISO-8859-1

Wenn Sie diese Konfigurationsvariable nicht haben, ist der Wert von i18n.commitencoding
stattdessen verwendet.

Beachten Sie, dass wir uns bewusst dafür entschieden haben, die Commit-Log-Meldung nicht neu zu codieren, wenn ein Commit
gemacht, um UTF-8 auf der Ebene des Commit-Objekts zu erzwingen, da eine Umcodierung in UTF-8 nicht möglich ist
zwangsläufig ein reversibler Vorgang.

Verwenden Sie git-commit-tree online mit den onworks.net-Diensten