Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.34.1 no changes
- 2.34.0 11/15/21
- 2.31.1 → 2.33.1 no changes
- 2.31.0 03/15/21
- 2.30.1 → 2.30.2 no changes
- 2.30.0 12/27/20
- 2.29.1 → 2.29.3 no changes
- 2.29.0 10/19/20
- 2.23.1 → 2.28.1 no changes
- 2.23.0 08/16/19
- 2.18.1 → 2.22.5 no changes
- 2.18.0 06/21/18
- 2.16.6 → 2.17.6 no changes
- 2.15.4 12/06/19
- 2.13.7 → 2.14.6 no changes
- 2.12.5 09/22/17
- 2.11.4 09/22/17
- 2.9.5 → 2.10.5 no changes
- 2.8.6 07/30/17
- 2.7.6 07/30/17
- 2.5.6 → 2.6.7 no changes
- 2.4.12 05/05/17
- 2.3.10 09/28/15
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 laquellegit 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 commegit 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>
-
Lorsque <rév> n’est pas spécifié, la commande annote les modifications en arrière à partir de la copie de l’arbre de travail. Ce drapeau permet à la commande de faire croire que la copie de l’arbre de travail contient le contenu du fichier nommé (spécifier
-
pour que la commande lise à 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 configurationblame.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’unfsck.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 configurationblame.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.
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 .