[ Web Proxy ]
URL:
Viewing: https://git-scm.com/docs/git-commit-tree/fr [Back]  [Original]
Git - git-commit-tree Documentation
Git [Git]
Type / to search entire site:
dark-mode.svg [dark-mode.svg]
Franais Topics Latest version git-commit-tree last updated in 2.55.0

NOM

git-commit-tree - Cre 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 gnralement pas ce qu’un utilisateur final veut excuter directement. Voir git-commit[1] la place.

Cre 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’entre standard, moins que les options -m ou -F soient donnes.

Les options -m et -F peuvent tre donnes 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 donnes.

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 reprsente un tat particulier d’un rpertoire de travail, un commit reprsente 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 rsultat 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’entre standard. Ceci peut tre indiqu plusieurs fois et le contenu de chaque fichier devient un paragraphe diffrent.

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

Signer les commits avec GPG. L’argument idcl est optionnel avec par dfaut l’identit du validateur; si spcifie, elle doit tre colle l’option sans aucun espace. --no-gpg-sign est utile pour annuler l’effet de tout --gpg-sign prcdent sur la ligne de commande.

Information de commit

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 commit est lu partir de stdin. Si une entre de changelog nest pas fournie via la redirection <, git commit-tree attendra simplement quune entre soit entre et termine 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> <dcalage-de-fuseau-horaire>, o <horodatage-unix> est un nombre de secondes depuis l’poque UNIX. <dcalage-de-fuseau-horaire> est un dcalage positif ou ngative 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 dcrit par la RFC 2822, par exemple Thu, 07 Apr 2005 22:13:13 +0200.

ISO 8601

Les heures et les dates sont spcifies par le standard ISO 8601, par exemple 2005-04-07T22:13:13. L’analyseur accepte aussi un espace au lieu du caractre T. Les parties fractionnelles d’une seconde seront ignores, par exemple, 2005-04-07T22:13:13.019 sera considr comme tant 2005-04-07T22:13:13.

Note
 De plus, la partie date est accepte 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 caractres.

  • Le contenu des objets blob est une squence d’octets non interprts. Il n’y a pas de conversion d’encodage au niveau de base.

  • Les noms de chemins sont encods en forme C de normalisation UTF-8. Ceci s’applique aux objets arbre, au fichier d’index, au noms de rfrences 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 squences 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, mme sur les plateformes et systmes de fichier utilisant d’anciens encodages d’ASCII tendu.

  • Les messages du journal des validations sont typiquement encods 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 cur de Git et la porcelaine sont conus 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 dtails garder en tte.

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

    [i18n]
	commitEncoding = ISO-8859-1

    Les objets commit crs avec le rglage ci-dessus enregistrent la valeur de i18n.commitEncoding dans leur entte d’encodage encoding. Ceci permet d’aider les personnes qui les liront plus tard. L’absence de cet entte 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’entte encoding d’un objet commit et essaient de r-encoder le message de validation en UTF-8. Vous pouvez spcifier 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 utilise.

Remarquez qu’il a t dlibrment 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 ncessairement une opration rversible.

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-Nol 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 .

About this site
Patches, suggestions, and comments are welcome.
Git is a member of Software Freedom Conservancy
Web Proxy Viewer  |  New URL  |  Original Page