Git 🌙
Français â–Ÿ Topics â–Ÿ Latest version â–Ÿ git-commit-tree last updated in 2.45.0

NOM

git-commit-tree - 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 tout --gpg-sign prĂ©cĂ©dent sur la ligne de commande.

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 de date 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