git-blame - En ligne dans le Cloud

PROGRAMME:

Nom

git-blame - Affiche la dernière révision et l'auteur qui ont modifié chaque ligne d'un fichier

SYNOPSIS

jet blâmer [-c] [-b] [-l] [--racine] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incrémental]
[-L ] [-S ] [-M] [-C] [-C] [-C] [--depuis= ]
[--abbrev= ] [ | --Contenu | --inverser ] [--]

DESCRIPTION

Annote chaque ligne du fichier donné avec les informations de la dernière révision
modifié la ligne. En option, commencez à annoter à partir de la révision donnée.

Lorsqu'il est spécifié une ou plusieurs fois, -L restreint l'annotation aux lignes demandées.

L'origine des lignes est automatiquement suivie à travers les renommages de fichiers entiers (actuellement il
n'est pas une option pour désactiver le renommage). Pour suivre les lignes déplacées d'un fichier à
autre, ou pour suivre des lignes qui ont été copiées et collées à partir d'un autre fichier, etc., reportez-vous à la
Options -C et -M.

Le rapport ne vous dit rien sur les lignes qui ont été supprimées ou remplacées ; tu
besoin d'utiliser un outil tel que jet diff ou l'interface "pioche" brièvement évoquée dans le
paragraphe suivant.

En plus de prendre en charge l'annotation de fichiers, Git prend également en charge la recherche dans l'historique de développement
pour quand un extrait de code s'est produit dans un changement. Cela permet de savoir quand un code
l'extrait a été ajouté à un fichier, déplacé ou copié entre les fichiers, et finalement supprimé ou
remplacé. Cela fonctionne en recherchant une chaîne de texte dans le diff. Un petit exemple de
interface de pioche qui recherche blâme_usage :

$ git log --pretty=oneline -S'blame_usage'
5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output

OPTIONS

-b
Affichez le SHA-1 vide pour les commits de limite. Cela peut également être contrôlé via le
option de configuration blâme.blankboundary.

--racine
Ne traitez pas les commits root comme des limites. Cela peut également être contrôlé via le
option de configuration blâme.showRoot.

--show-stats
Incluez des statistiques supplémentaires à la fin de la sortie de blâme.

-L , , -L :
Annotez uniquement la plage de lignes donnée. Peut être spécifié plusieurs fois. Chevauchement
les plages sont autorisées.

et sont facultatifs. "-L " ou " -L , s'étend de à
fin de fichier. "-L, ” s'étend du début du fichier à .

et peut prendre l'une de ces formes :

· numéro

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

· /expression régulière/

Ce formulaire utilisera la première ligne correspondant à l'expression régulière POSIX donnée. Si est un
regex, il recherchera à partir de la fin de la plage -L précédente, le cas échéant, sinon
depuis le début du fichier. Si est "^/regex/", il recherchera à partir du début de
déposer. Si est une expression régulière, il recherchera à partir de la ligne donnée par .

· +offset ou -offset

Ceci n'est valable que pour et spécifiera un nombre de lignes avant ou après
la ligne donnée par .

Si ": » est donné à la place de et , c'est une expression régulière
qui dénote la plage de la première ligne funcname qui correspond , jusqu'à la
ligne de nom de fonction suivante. " : ” recherche à partir de la fin de la plage -L précédente, si
any, sinon depuis le début du fichier. « ^ : ” recherche à partir du début du fichier.

-l
Afficher le régime long (par défaut : désactivé).

-t
Afficher l'horodatage brut (par défaut : désactivé).

-S
Utiliser les révisions du fichier revs au lieu d'appeler git-rev-liste (1).

--sens inverse
Faites avancer l'histoire au lieu de la reculer. Au lieu de montrer la révision dans laquelle un
ligne est apparue, cela montre la dernière révision dans laquelle une ligne a existé. Cela nécessite
une plage de révision comme START..END où le chemin à blâmer existe dans START.

-p, --porcelaine
Afficher dans un format conçu pour la consommation de la machine.

--ligne-porcelaine
Affiche le format porcelaine, mais affiche les informations de validation pour chaque ligne, pas seulement le
la première fois qu'un commit est référencé. Implique --porcelaine.

--incrémentale
Affichez le résultat de manière incrémentielle dans un format conçu pour la consommation de la machine.

--encodage=
Spécifie l'encodage utilisé pour sortir les noms d'auteur et les résumés de validation. Le régler sur
aucun ne fait blâmer la sortie des données non converties. Pour plus d'informations voir la discussion
à propos de l'encodage dans le journal git(1) page de manuel.

--Contenu
Lorsque n'est pas spécifié, la commande annote les changements à partir de
la copie de l'arbre de travail. Ce drapeau fait que la commande fait comme si la copie de l'arbre de travail
a le contenu du fichier nommé (spécifiez - pour que la commande soit lue à partir du
entrée standard).

--Date
Spécifie le format utilisé pour sortir les dates. Si --date n'est pas fourni, la valeur de
La variable de configuration blâme.date est utilisée. Si la variable de configuration blâme.date n'est pas non plus définie,
le format iso est utilisé. Pour les valeurs prises en charge, consultez la discussion sur l'option --date
at journal git (1).

-M| |
Détectez 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 d'origine a A puis B, et le commit le change en B et
puis A), le traditionnel blâmer l'algorithme 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) jusqu'au commit enfant. Avec cette option, les deux
les groupes de lignes sont imputés au parent en exécutant des passes d'inspection supplémentaires.

est facultatif mais c'est la borne inférieure du nombre de caractères alphanumériques
que Git doit détecter comme déplacement/copie dans un fichier pour qu'il puisse associer ces lignes
avec le commit parent. La valeur par défaut est 20.

-C| |
En plus de -M, détecte les lignes déplacées ou copiées à partir d'autres fichiers qui ont été modifiés dans
le même engagement. Ceci est utile lorsque vous réorganisez votre programme et déplacez le code
à travers les fichiers. Lorsque cette option est donnée deux fois, la commande recherche en plus
copies à partir d'autres fichiers dans le commit qui crée le fichier. Lorsque cette option est donnée
trois fois, la commande recherche en plus des copies d'autres fichiers dans n'importe quel commit.

est facultatif mais c'est la borne inférieure du nombre de caractères alphanumériques
que Git doit détecter comme déplacement/copie entre les fichiers pour qu'il associe ces lignes
avec le commit parent. Et la valeur par défaut est 40. S'il y a plus d'un -C
options données, le l'argument du dernier -C prendra effet.

-h
Afficher le message d'aide.

-c
Utilisez le même mode de sortie que git-annoter(1) (Par défaut : désactivé).

--score-débogage
Inclure les informations de débogage liées au mouvement des lignes entre les fichiers (voir -C)
et les lignes déplacées dans un fichier (voir -M). Le premier nombre indiqué est le score. C'est
le nombre de caractères alphanumériques détectés comme ayant été déplacés entre ou à l'intérieur
des dossiers. Celui-ci doit être supérieur à un certain seuil pour jet blâmer considérer ces lignes de
code à avoir été déplacé.

-f, --show-name
Affiche le nom du fichier dans le commit d'origine. Par défaut, le nom du fichier est affiché s'il y a
toute ligne provenant d'un fichier avec un nom différent, en raison de la détection de renommage.

-n, --show-number
Affiche le numéro de ligne dans le commit d'origine (par défaut : désactivé).

-s
Supprimez le nom de l'auteur et l'horodatage de la sortie.

-e, --show-email
Afficher l'e-mail de l'auteur au lieu du nom de l'auteur (par défaut : désactivé). Cela peut aussi être
contrôlé via l'option de configuration blâme.showEmail.

-w
Ignorer les espaces lorsque vous comparez la version du parent et celle de l'enfant pour trouver où
les lignes sont venues.

--abbrev=
Au lieu d'utiliser les 7+1 chiffres hexadécimaux par défaut comme nom d'objet abrégé,
utilisation +1 chiffres. Notez qu'une colonne est utilisée pour un caret pour marquer la validation de la limite.

LES PORCELAINE Format

Dans ce format, chaque ligne est sortie après un en-tête ; l'en-tête au minimum a le
première ligne qui a :

· SHA-40 de 1 octets du commit auquel la ligne est attribuée ;

· le numéro de ligne de la ligne dans le fichier d'origine ;

· le numéro de ligne de la ligne dans le fichier final ;

· sur une ligne qui démarre un groupe de lignes à partir d'un commit différent du précédent,
le nombre de lignes dans ce groupe. Sur les lignes suivantes, ce champ est absent.

Cette ligne d'en-tête est suivie des informations suivantes au moins une fois pour chaque commit :

· le nom de l'auteur ("author"), l'e-mail ("author-mail"), l'heure ("author-time") et le fuseau horaire
("auteur-tz"); de même pour le commiter.

· le nom de fichier dans le commit auquel la ligne est attribuée.

· la première ligne du message de journal de validation ("résumé").

Le contenu de la ligne réelle est affiché après l'en-tête ci-dessus, préfixé par un TAB. Cette
est de permettre l'ajout ultérieur d'éléments d'en-tête.

Le format porcelaine supprime généralement les informations de commit déjà vues.
Par exemple, deux lignes blâmées pour le même commit seront toutes les deux affichées, mais le
les détails de ce commit ne seront affichés qu'une seule fois. Ceci est plus efficace, mais peut nécessiter
plus d'état soit gardé par le lecteur. L'option --line-porcelain peut être utilisée pour une sortie complète
commit des informations pour chaque ligne, permettant une utilisation plus simple (mais moins efficace) comme :

# compte le nombre de lignes attribuées à chaque auteur
git blâme --line-porcelain file |
sed -n 's/^auteur //p' |
trier | uniq -c | trier -rn

EN PRÉCISANT GAMMES

Contrairement à jet blâmer ainsi que jet annoter dans les anciennes versions de git, l'étendue de l'annotation
peut être limité à la fois aux plages de lignes et aux plages de révision. L'option -L, qui limite
annotation à une plage de lignes, peut être spécifiée plusieurs fois.

Lorsque vous souhaitez trouver l'origine des lignes 40-60 pour le fichier foo, vous pouvez utiliser
l'option -L comme ça (ils veulent dire la même chose - les deux demandent 21 lignes à partir de la ligne
40):

git blâme -L 40,60 foo
git blâme -L 40,+21 foo

Vous pouvez également utiliser une expression régulière pour spécifier la plage de lignes :

git blâme -L '/^sub hello {/,/^}$/' foo

ce qui limite l'annotation au corps du sous-programme hello.

Lorsque vous n'êtes pas intéressé par les modifications antérieures à la version v2.6.18, ou les modifications antérieures à 3
semaines, vous pouvez utiliser des spécificateurs de plage de révision similaires à jet liste des reves:

git blâmer v2.6.18 .. -- foo
git blâme --since=3.weeks -- foo

Lorsque des spécificateurs de plage de révision sont utilisés pour limiter l'annotation, les lignes qui n'ont pas
changé depuis la limite de la plage (soit le commit v2.6.18 ou le commit le plus récent qui
a plus de 3 semaines dans l'exemple ci-dessus) sont blâmés pour ce commit de limite de plage.

Un moyen particulièrement utile est de voir si un fichier ajouté a des lignes créées par copier-coller
à partir de fichiers existants. Parfois, cela indique que le développeur était négligent et a fait
pas refactoriser correctement le code. Vous pouvez d'abord trouver le commit qui a introduit le fichier
avec:

git log --diff-filter=A --pretty=short --foo

puis annotez le changement entre le commit et ses parents, en utilisant commit^! notation:

git blâme -C -C -f $ commit^! -- foo

INCRÉMENTIELLE SORTIE

Lorsqu'elle est appelée avec l'option --incremental, la commande affiche le résultat au fur et à mesure de sa construction. Les
la sortie parlera généralement en premier des lignes touchées par des commits plus récents (c'est-à-dire le
les lignes seront annotées dans le désordre) et est destiné à être utilisé par les téléspectateurs interactifs.

Le format de sortie est similaire au format Porcelaine, mais il ne contient pas le
lignes du fichier en cours d'annotation.

1. Chaque entrée de blâme commence toujours par une ligne de :

<hex sha40 de 1 octets>

Les numéros de ligne comptent à partir de 1.

2. La première fois qu'un commit apparaît dans le flux, il contient diverses autres informations
à ce sujet imprimé avec une étiquette d'un mot au début de chaque ligne décrivant le
informations de commit supplémentaires (auteur, email, committer, dates, résumé, etc.).

3. Contrairement au format Porcelain, les informations de nom de fichier sont toujours données et se terminent
l'entrée:

"nom de fichier"

et donc il est vraiment assez facile à analyser pour un analyseur orienté ligne et mot
(ce qui devrait être assez naturel pour la plupart des langages de script).

Notes
Pour les personnes qui font de l'analyse : pour le rendre plus robuste, ignorez simplement les lignes entre
le premier et le dernier (" " et "filename") où vous ne reconnaissez pas
les mots clés (ou se soucier de celui-ci en particulier) au début du
lignes "informations étendues". De cette façon, s'il y a des informations ajoutées (comme
l'encodage de commit ou le commentaire de commit étendu), un visualiseur de blâme ne s'en souciera pas.

CARTOGRAPHIE AUTEURS

Si le fichier .mailmap existe au niveau supérieur du référentiel, ou à l'emplacement pointé
par les options de configuration mailmap.file ou mailmap.blob, il est utilisé pour mapper l'auteur et
les noms et adresses e-mail des commiters en noms et adresses e-mail réels canoniques.

Dans la forme simple, chaque ligne du fichier se compose du nom réel canonique d'un
auteur, espace et une adresse e-mail utilisée dans le commit (inclus par < ainsi que >) pour cartographier
au nom. Par exemple:

Nom propre[email protected]>

Les formes les plus complexes sont :

<[email protected]>[email protected]>

qui permet à mailmap de remplacer uniquement la partie email d'un commit, et :

Nom propre[email protected]>[email protected]>

qui permet à mailmap de remplacer à la fois le nom et l'email d'un commit correspondant au
l'adresse e-mail de validation spécifiée, et :

Nom propre[email protected]> Nom du commit[email protected]>

qui permet à mailmap de remplacer à la fois le nom et l'email d'un commit correspondant à la fois au
nom de commit et adresse e-mail spécifiés.

Exemple 1 : Votre historique contient des commits de deux auteurs, Jane et Joe, dont les noms apparaissent
dans le référentiel sous plusieurs formes :

Développeur Joe[email protected]>
Joe R. Développeur[email protected]>
Jane Doe[email protected]>
Jane Doe
Jeanne D.

Supposons maintenant que Joe veuille que l'initiale de son deuxième prénom soit utilisée et que Jane préfère son nom de famille
en toutes lettres. Un fichier .mailmap approprié ressemblerait à :

Jane Doe
Joe R. Développeur[email protected]>

Notez qu'il n'y a pas besoin d'une entrée pour , parce que le vrai nom de
cet auteur a déjà raison.

Exemple 2 : votre dépôt contient des commits des auteurs suivants :

pseudo1[email protected]>
pseudo2[email protected]>
pseudo2[email protected]>
Père Noël[email protected]>
clause[email protected]>
CTO[email protected]>

Ensuite, vous voudrez peut-être un fichier .mailmap qui ressemble à :

<[email protected]>[email protected]>
certains mec[email protected]> pseudo1[email protected]>
Autre auteur[email protected]> pseudo2[email protected]>
Autre auteur[email protected]>[email protected]>
père Noël[email protected]>[email protected]>

Utiliser du hachage # pour les commentaires qui sont soit sur leur propre ligne, soit après l'adresse e-mail.

Utilisez git-blame en ligne en utilisant les services onworks.net