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.41.1 → 2.47.0 no changes
- 2.41.0 06/01/23
- 2.39.1 → 2.40.3 no changes
- 2.39.0 12/12/22
- 2.34.1 → 2.38.5 no changes
- 2.34.0 11/15/21
- 2.31.1 → 2.33.8 no changes
- 2.31.0 03/15/21
- 2.30.1 → 2.30.9 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 no changes
- 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
- 2.1.4 → 2.2.3 no changes
- 2.0.5 12/17/14
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>
-
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 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 .