Git
Français ▾ Topics ▾ Latest version ▾ git-annotate last updated in 2.43.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