Git
Français ▾ Topics ▾ Latest version ▾ git-commit-tree last updated in 2.34.1

NOM

git-commit - Crée un nouvel objet commit

SYNOPSIS

git commit-tree <arbre> [(-p <parent>)…​]
git commit-tree [(-p <parent>)…​] [-S[<id-clé>]] [(-m <message>)…​]
		  [(-F <fichier>)…​] <arbre>

DESCRIPTION

Ce n’est généralement pas ce qu’un utilisateur final veut exécuter directement. Voir git-commit[1] à la place.

Crée un nouvel objet commit basé sur l’objet arbre fourni et émet l’identifiant du nouvel objet commit sur stdout. Le message de journal est lu depuis l’entrée standard, à moins que les options -m ou -F soient données.

Les options -m et -F peuvent être données plus d’une fois, dans n’importe quel ordre. Le message du journal de livraison sera composé dans l’ordre dans lequel les options sont données.

Un objet commit peut avoir un nombre quelconque de parents. Avec exactement un parent, c’est un commit ordinaire. Avoir plus d’un parent fait du commit une fusion entre plusieurs lignes d’historique. Les commits initiaux (racine) n’ont pas de parents.

Alors qu’un arbre représente un état particulier d’un répertoire de travail, un commit représente cet état dans le "temps", et explique comment y arriver.

Normalement, un commit devrait identifier un nouvel état "HEAD", et bien que Git ne se soucie pas de l’endroit où vous enregistrez la note sur cet état, en pratique nous avons tendance à simplement écrire le résultat dans le fichier qui est pointé par .git/HEAD, de sorte que nous pouvons toujours voir quel était le dernier état validé.

OPTIONS

<arbre>

Un objet d’arbre existant.

-p <parent>

Chaque -p indique l’id d’un objet commit parent.

-m <message>

Un paragraphe dans le message du journal de validation. Ceci peut être donné plus d’une fois et chaque <message> devient son propre paragraphe.

-F <fichier>

Lire le message de validation depuis le fichier indiqué. Utilisez - pour lire le message depuis l’entrée standard. Ceci peut être indiqué plusieurs fois et le contenu de chaque fichier devient un paragraphe différent.

-S[<idclé>]
--gpg-sign[=<idclé>]
--no-gpg-sign

Signer les commits avec GPG. L’argument idclé est optionnel avec par défaut l’identité du validateur ; si spécifiée, elle doit être collée à l’option sans aucun espace. --no-gpg-sign est utile pour annuler l’effet de la variable de configuration commit.gpgSign ainsi que tout --gpg-sign précédent.

Information de validation

Un commit encapsule :

  • tous les identifiants des objets parents

  • nom de l’auteur, courriel et date

  • le nom et l’adresse électronique du validateur et la date du commit.

Un commentaire de validation est lu à partir de stdin. Si une entrée de changelog n’est pas fournie via la redirection « < », git commit-tree attendra simplement qu’une entrée soit entrée et terminée par ^D.

FORMATS DE DATE

Les variables d’environnement GIT_AUTHOR_DATE et GIT_COMMITTER_DATE supportent les formats de date suivants :

Format interne de Git

Il est de la forme <horodatage unix> <décalage de fuseau horaire>, où <horodatage unix> est un nombre de secondes depuis l’époque UNIX. <décalage de fuseau horaire> est un décalage positif ou négative par rapport à UTC. Par exemple, CET (qui est en avance d’une heure sur UTC) est +0100.

RFC 2822

Le standard de format des courriel tel que décrit par la RFC 2822, par exemple Thu, 07 Apr 2005 22:13:13 +0200.

ISO 8601

Les heures et les dates sont spécifiées par le standard ISO 8601, par exemple 2005-04-07T22:13:13. L’analyseur accepte aussi un espace au lieu du caractère T. Les parties fractionnelles d’une seconde seront ignorées, par exemple, 2005-04-07T22:13:13.019 sera considéré comme étant 2005-04-07T22:13:13.

Note
 De plus, la partie date est acceptée dans les formats suivants : AAAA.MM.JJ, MM/JJ/AAAA et JJ.MM.AAAA.

Discussion

Git est dans une certaine mesure agnostique concernant l’encodage des caractères.

  • Le contenu des objets blob est une séquence d’octets non interprétés. Il n’y a pas de conversion d’encodage au niveau de base.

  • Les noms de chemins sont encodés en forme C de normalisation UTF-8. Ceci s’applique aux objets arbre, au fichier d’index, au noms de références ainsi qu’aux noms de chemin en argument de ligne de commande, aux variables d’environnement et aux fichiers de configuration (.git/config (voir git-config[1]), gitignore[5], gitattributes[5] and gitmodules[5]).

    Remarquez que Git traite les noms de chemins comme des séquences d’octets non-nuls au niveau de base, il n’y a pas de conversion d’encodage des noms de fichiers (sauf sur Mac et Windows). De ce fait, l’utilisation de noms de chemins non-ASCII fonctionnera pratiquement, même sur les plateformes et systèmes de fichier utilisant d’anciens encodages d’ASCII étendu.

  • Les messages du journal des validations sont typiquement encodés en UTF-8, mais les autres encodages d’ASCII étendu sont aussi pris en charge. Ceci inclut ISO-8859-x, CP125x et de nombreux autres, mais pas UTF-16/32, EBCDIC ni les encodages multi-octets CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).

Bien que l’usage de UTF-8 dans les messages de validation soit encouragé, le cœur de Git et la porcelaine sont conçus pour ne pas forcer l’usage d’UTF-8 dans les projets. Si tous les participants d’un projet donné trouvent plus simple d’utiliser des encodages anciens, Git ne l’interdit pas. Cependant, il y a quelques détails à garder en tête.

  1. git commit et git commit-tree affichent un avertissement si le message de validation fourni ne semble pas être une chaîne de caractères UTF-8 valide, à moins que vous n’indiquiez explicitement que votre projet utilise un encodage ancien. La manière de l’indiquer est d’avoir i18n.commitEncoding dans .git/config, comme ceci :

    [i18n]
	commitEncoding = ISO-8859-1

    Les objets commit créés avec le réglage ci-dessus enregistrent la valeur de i18n.commitEncoding dans leur entête d’encodage encoding. Ceci permet d’aider les personnes qui les liront plus tard. L’absence de cet entête implique que les message de validation est encodé en UTF-8.

  2. Sauf indication contraire, git log, git show, git blame et consort lisent l’entête encoding d’un objet commit et essaient de ré-encoder le message de validation en UTF-8. Vous pouvez spécifier l’encodage de sortie que vous souhaitez avec i18n.logOutputEncoding dans le fichier .git/config, comme ceci :

    [i18n]
	logOutputEncoding = ISO-8859-1

    Si vous n’avez pas changé cette variable de configuration, c’est la valeur de i18n.commitEncoding qui est utilisée.

Remarquez qu’il a été délibérément choisi de ne pas ré-encoder le message de validation quand le commit est créé pour forcer l’UTF-8 au niveau de l’objet commit parce que ré-encoder en UTF-8 n’est pas nécessairement une opération réversible.

FICHIERS

/etc/mailname

VOIR AUSSI

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

GIT

Fait partie de la suite git[1]

TRADUCTION

Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .

scroll-to-top