Git 🌙
Français â–Ÿ Topics â–Ÿ Latest version â–Ÿ git-annotate last updated in 2.41.0

NOM

git-annotate - Annote les lignes d’un fichier avec les informations de commit

SYNOPSIS

git annotate [<options>] [<opts-rév>] [<rév>] [--] <fichier>

DESCRIPTION

Annote chaque ligne dans le fichier donnĂ© avec les informations du commit qui a introduit la ligne. Annote optionnellement Ă  partir d’une rĂ©vision donnĂ©e.

La seule diffĂ©rence entre cette commande et git-blame[1] est qu’elles utilisent des formats de sortie lĂ©gĂšrement diffĂ©rents, et cette commande n’existe que pour la rĂ©trocompatibilitĂ© afin de prendre en charge les scripts existants, et de fournir un nom de commande plus familier aux personnes venant d’autres systĂšmes SCM.

OPTIONS

-b

Afficher un SHA-1 vierge pour les validations de limite. Cela peut Ă©galement ĂȘtre contrĂŽlĂ© par l’option de configuration blame.blankBoundary.

--root

Ne pas considĂ©rer les commits de base comme des limites. Ceci peut Ă©galement ĂȘtre contrĂŽlĂ© via l’option de configuration blame.showRoot.

--show-stats

Inclure des statistiques supplémentaires à la fin de la sortie de blame.

-L <début>,<fin>
-L: <nomfonc>

N’annoter que la plage de lignes donnĂ©e par <dĂ©but>,<fin> ou par la regex du nom de la fonction <nom-de-fonction>. Peut ĂȘtre spĂ©cifiĂ© plusieurs fois. Les intervalles qui se chevauchent sont autorisĂ©s.

<dĂ©but> et <fin> sont facultatifs. -L <dĂ©but> ou -L <dĂ©but>,, s’étend de <dĂ©but> jusqu’Ă  la fin du fichier. -L,<fin> s’étend du dĂ©but du fichier jusqu’Ă  <fin>.

<dĂ©but> et <fin> peuvent prendre l’une de ces formes :

  • nombre

    Si <début> ou <fin> est un nombre, il spécifie un numéro de ligne absolu (les lignes comptent à partir de 1).

  • /regex/

    Cette forme utilisera la premiÚre ligne correspondant à la regex POSIX donnée. Si <début> est une regex, la recherche se fera à partir de la fin de la plage -L précédente, le cas échéant, sinon à partir du début du fichier. Si <début> est ^/regex/, la recherche se fera à partir du début du fichier. Si <fin> est une regex, la recherche débutera à partir de la ligne donnée par <début>.

  • + offset ou -offset

    Ceci n’est valable que pour <fin> et spĂ©cifiera un nombre de lignes avant ou aprĂšs la ligne donnĂ©e par <dĂ©but>.

Si :<nom-de-fonction> est donnĂ© Ă  la place de <dĂ©but> et de <fin>, il s’agit d’une expression rĂ©guliĂšre qui indique la plage depuis premiĂšre ligne qui correspond Ă  <nom-de-fonction>, jusqu’Ă  la ligne de nom-de-fonction suivante. La recherche de :<nom-de-fonction> se fait Ă  partir de la fin de la plage -L prĂ©cĂ©dente, s’il y en a une, sinon Ă  partir du dĂ©but du fichier. La recherche de ^:<nom-de-fonction> commence au dĂ©but du fichier. Les noms de fonction sont dĂ©terminĂ©s de la mĂȘme maniĂšre que celle par laquelle git diff fonctionne sur les en-tĂȘtes de section de rustine (voir DĂ©finir un en-tĂȘte personnalisĂ© dans gitattributes[5]).

-l

Afficher la révision long (par défaut : désactivé).

-t

Afficher les horodatages bruts (Défaut : désactivé).

-S <fichier-des-révs>

Utiliser les rĂ©visions depuis le fichier-des-rĂ©visions au lieu d’appeler git-rev-list[1].

--reverse <rév>..<rév>

Parcourir l’historique en avant au lieu d’en arriĂšre. Au lieu de montrer la rĂ©vision dans laquelle une ligne est apparue, ceci montre la derniĂšre rĂ©vision dans laquelle une ligne a existĂ©. Cela nĂ©cessite une gamme de rĂ©visions comme DÉBUT..FIN oĂč le chemin de blĂąme existe dans DÉBUT. Pour plus de commoditĂ©, git blame --reverse DÉBUT est pris comme git blame --reverse DÉBUT..HEAD.

--first-parent

Ne suivre que le premier commit parent lors de la rencontre d’un commit de fusion. Cette option peut ĂȘtre utilisĂ©e pour dĂ©terminer le moment oĂč une ligne a Ă©tĂ© introduite dans une branche d’intĂ©gration particuliĂšre, plutĂŽt que le moment oĂč elle a Ă©tĂ© introduite dans l’historique global.

-p
--porcelain

Afficher dans un format propice Ă  la consommation par machine.

--line-porcelain

Afficher le format porcelaine, mais sortir les informations de commit pour chaque ligne, et pas seulement la premiĂšre fois qu’un commit est rĂ©fĂ©rencĂ©. Implique --porcelaine.

--incremental

Afficher le résultat progressivement dans un format conçu pour la consommation par une machine.

--encoding=<codage>

SpĂ©cifier l’encodage utilisĂ© pour produire les des noms d’auteurs et les rĂ©sumĂ©s des commits. Le dĂ©finir sur none rend la sortie de blĂąme des donnĂ©es non converties. Pour plus d’informations, voir la discussion sur l’encodage dans la page manuelle git-log[1].

--contents <fichier>

Annoter en utilisant le contenu du fichier nommĂ©, en commençant par <rĂ©v> si elle est spĂ©cifiĂ©e, et HEAD sinon. Vous pouvez spĂ©cifier - pour que la commande lise le contenu du fichier Ă  partir de l’entrĂ©e standard.

--date <format>

SpĂ©cifie le format utilisĂ© pour les dates sur la sortie. Si --date n’est pas fourni, la valeur de la variable de configuration blame.date est utilisĂ©e. Si la variable de configuration blame.date n’est pas non plus dĂ©finie, le format iso est utilisĂ©. Pour les valeurs prises en charge, voir la discussion de l’option --date Ă  git-log[1].

--[no-]progress

L’Ă©tat d’avancement est indiquĂ© par dĂ©faut sur le flux d’erreurs standard lorsqu’il est connectĂ© Ă  un terminal. Ce drapeau permet de signaler l’Ă©tat d’avancement mĂȘme s’il n’est pas attachĂ© Ă  un terminal. On ne peut pas utiliser --progress avec --porcelain ou --incremental.

-M[<num>]

DĂ©tecter les lignes dĂ©placĂ©es ou copiĂ©es dans un fichier. Lorsqu’un commit dĂ©place ou copie un bloc de lignes (par exemple, le fichier original a A puis B, et le commit le change en B puis A), l’algorithme traditionnel de blame ne remarque que la moitiĂ© du mouvement et blĂąme gĂ©nĂ©ralement les lignes qui ont Ă©tĂ© dĂ©placĂ©es vers le haut (c’est-Ă -dire B) au parent et attribue le blĂąme aux lignes qui ont Ă©tĂ© dĂ©placĂ©es vers le bas (c’est-Ă -dire A) au commit enfant. Avec cette option, les deux groupes de lignes sont blĂąmĂ©s sur le parent en effectuant des passes d’inspection supplĂ©mentaires.

<num>est facultatif, mais c’est la limite infĂ©rieure sur le nombre de caractĂšres alphanumĂ©riques que Git doit dĂ©tecter comme dĂ©placĂ©es/copiĂ©es dans un fichier pour qu’il associe ces lignes avec le commit parent. La valeur par dĂ©faut est 20.

-C[<num>]

En plus de -M, dĂ©tecter les lignes dĂ©placĂ©es ou copiĂ©es Ă  partir d’autres fichiers qui ont Ă©tĂ© modifiĂ©s dans le mĂȘme commit. Ceci est utile lorsque vous rĂ©organisez votre programme et que vous dĂ©placez du code d’un fichier Ă  l’autre. Lorsque cette option est donnĂ©e deux fois, la commande recherche en plus les copies depuis d’autres fichiers dans le commit qui crĂ©e le fichier. Lorsque cette option est donnĂ©e trois fois, la commande recherche Ă©galement des copies d’autres fichiers dans n’importe quel commit.

<num> est optionnel mais c’est la limite infĂ©rieure du nombre de caractĂšres alphanumĂ©riques que Git doit dĂ©tecter comme Ă©tant des dĂ©placements/copies entre fichiers pour qu’il puisse associer ces lignes au commit parent. Et la valeur par dĂ©faut est 40. S’il y a plus d’une option -C donnĂ©e, l’argument <num> du dernier -C prendra effet.

--ignore-rev <rév>

Ignorer les modifications apportĂ©es par la rĂ©vision lors de l’attribution de la responsabilitĂ©, comme si la modification ne s’Ă©tait jamais produite. Les lignes qui ont Ă©tĂ© modifiĂ©es ou ajoutĂ©es par un commit ignorĂ© seront blĂąmĂ©es sur le commit prĂ©cĂ©dent qui a modifiĂ© cette ligne ou les lignes voisines. Cette option peut ĂȘtre spĂ©cifiĂ©e plusieurs fois pour ignorer plus d’une rĂ©vision. Si l’option de configuration blame.markIgnoredLines est activĂ©e, alors les lignes qui ont Ă©tĂ© modifiĂ©es par un commit ignorĂ© et attribuĂ©es Ă  un autre commit seront marquĂ©es avec un ? dans la sortie de blame. Si l’option de configuration blame.markUnblamableLines est dĂ©finie, alors les lignes touchĂ©es par un commit ignorĂ© que nous n’avons pas pu attribuer Ă  une autre rĂ©vision sont marquĂ©es d’un *.

--ignore-revs-file <fichier>

Ignorer les rĂ©visions listĂ©es dans le fichier, qui doit ĂȘtre au mĂȘme format qu’un fsck.skipList. Cette option peut ĂȘtre rĂ©pĂ©tĂ©e, et ces fichiers seront traitĂ©s aprĂšs tous les fichiers spĂ©cifiĂ©s avec l’option de configuration blame.ignoreRevsFile. Un nom de fichier vide, "", effacera la liste des rĂ©visions des fichiers prĂ©cĂ©demment traitĂ©s.

--color-lines

Colorier diffĂ©remment les annotations de ligne dans le format par dĂ©faut si elles proviennent du mĂȘme commit que la ligne prĂ©cĂ©dente. Cela permet de distinguer plus facilement les blocs de code introduits par des commits diffĂ©rents. La couleur par dĂ©faut est le cyan et peut ĂȘtre ajustĂ©e en utilisant l’option de configuration color.blame.repeatedLines.

--color-by-age

Colorer les annotations de ligne en fonction de l’Ăąge de la ligne dans le format par dĂ©faut. L’option de configuration color.blame.highlightRecent contrĂŽle quelle couleur est utilisĂ©e pour chaque tranche d’Ăąge.

-h

Afficher le message d’aide.

VOIR AUSSI

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