git-blame - Online in de cloud

PROGRAMMA:

NAAM

git-blame - Toon welke revisie en auteur het laatst elke regel van een bestand heeft gewijzigd

KORTE INHOUD

git schuld [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incrementeel]
[-L ] [-S ] [-M] [-C] [-C] [-C] [--sinds= ]
[--afgekort= ] [ | --inhoud | --achteruit ] [--]

PRODUCTBESCHRIJVING

Annoteert elke regel in het gegeven bestand met informatie van de laatste revisie
de lijn aangepast. Begin optioneel met annoteren vanaf de gegeven revisie.

Indien een of meerdere keren opgegeven, beperkt -L de annotatie tot de gevraagde regels.

De oorsprong van regels wordt automatisch gevolgd bij het hernoemen van hele bestanden (momenteel is er
is geen optie om het hernoemen volgen uit te schakelen). Om regels te volgen die zijn verplaatst van het ene bestand naar
een andere, of om regels te volgen die zijn gekopieerd en geplakt uit een ander bestand, enz., zie de
-C en -M opties.

Het rapport vertelt u niets over regels die zijn verwijderd of vervangen; Jij
moet een tool gebruiken zoals git diff of de "houweel"-interface die kort wordt genoemd in de
volgende paragraaf.

Naast het ondersteunen van bestandsannotatie, ondersteunt Git ook het doorzoeken van de ontwikkelingsgeschiedenis
voor wanneer een codefragment voorkwam in een wijziging. Dit maakt het mogelijk om te volgen wanneer een code
snippet is toegevoegd aan een bestand, verplaatst of gekopieerd tussen bestanden en uiteindelijk verwijderd of
vervangen. Het werkt door te zoeken naar een tekststring in de diff. Een klein voorbeeld van de
houweel-interface die zoekt naar blablabla:

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

OPTIES

-b
Toon lege SHA-1 voor grenstoewijzingen. Dit kan ook worden geregeld via de
schuld.blankboundary configuratieoptie.

--wortel
Behandel root commits niet als grenzen. Dit kan ook worden geregeld via de
schuld.showRoot configuratieoptie.

--show-statistieken
Voeg aanvullende statistieken toe aan het einde van de schuldoutput.

-L , , -L:
Annoteer alleen het gegeven lijnbereik. Mag meerdere keren worden opgegeven. Overlappend
bereiken zijn toegestaan.

En zijn optioneel. “-L ” of “-L ”, strekt zich uit van naar
einde van het bestand. "-L, ” loopt van het begin van het bestand tot .

En kan een van deze vormen aannemen:

· nummer

Als of een getal is, specificeert het een absoluut regelnummer (aantal regels
vanaf 1).

· /regex/

Dit formulier gebruikt de eerste regel die overeenkomt met de opgegeven POSIX-regex. Als is een
regex, zal het zoeken vanaf het einde van het vorige -L bereik, indien aanwezig, anders
vanaf het begin van het bestand. Als is "^/regex/", het zal zoeken vanaf het begin van
bestand. Als is een regex, het zal zoeken vanaf de regel gegeven door .

· +offset of -offset

Deze is alleen geldig voor en specificeert een aantal regels ervoor of erna
de lijn gegeven door .

Als ": ” wordt gegeven in plaats van En , het is een reguliere expressie
dat geeft het bereik aan vanaf de eerste regel funcname die overeenkomt , op naar de
volgende functienaamregel. “: ” zoekt vanaf het einde van het vorige -L bereik, als
elke, anders vanaf het begin van het bestand. "^: ” zoekt vanaf het begin van het bestand.

-l
Toon lange rev (Standaard: uit).

-t
Onbewerkte tijdstempel weergeven (standaard: uit).

-S
Gebruik revisies uit het revs-bestand in plaats van aanroepen git-rev-lijst(1).

--omgekeerde
Loop de geschiedenis vooruit in plaats van achteruit. In plaats van de revisie te tonen waarin a
regel verschenen, dit toont de laatste revisie waarin een regel heeft bestaan. Dit vereist
een bereik van revisie zoals START..END waar het pad naar schuld bestaat in START.

-p, --porselein
Weergeven in een formaat dat is ontworpen voor machineverbruik.

--line-porselein
Toon het porseleinformaat, maar voer commit-informatie uit voor elke regel, niet alleen de
eerste keer dat er naar een commit wordt verwezen. Impliceert --porselein.

--toenemend
Toon het resultaat stapsgewijs in een formaat dat is ontworpen voor machineverbruik.

--codering=
Specificeert de codering die wordt gebruikt om auteursnamen en samenvattingen van vastleggingen uit te voeren. Instellen op
geen enkele zorgt ervoor dat de schuld niet-geconverteerde gegevens uitvoert. Voor meer informatie zie de discussie
over codering in de git-log(1) handleiding pagina.

--inhoud
Wanneer niet is opgegeven, annoteert de opdracht de wijzigingen in achterwaartse richting vanaf
de werkende boomkopie. Deze vlag laat het commando doen alsof het de werkboom kopieert
heeft de inhoud van het genoemde bestand (specificeer - om de opdracht te laten lezen uit het
standaard invoer).

--datum
Specificeert de notatie die wordt gebruikt om datums uit te voeren. Als --date niet wordt opgegeven, wordt de waarde van de
schuld.date configuratievariabele wordt gebruikt. Als de configuratievariabele blablabla ook niet is ingesteld,
het iso-formaat wordt gebruikt. Zie voor ondersteunde waarden de bespreking van de optie --date
at git-log(1).

-M| |
Detecteer verplaatste of gekopieerde regels binnen een bestand. Wanneer een commit een blok van verplaatst of kopieert
regels (bijv. het originele bestand heeft A en dan B, en de commit verandert het in B en
dan A), de traditionele schuld algoritme merkt slechts de helft van de beweging op en
geeft doorgaans de schuld aan de lijn die naar boven is verplaatst (bijv. B) aan de ouder en wijst de schuld toe
naar de regels die naar beneden zijn verplaatst (dwz A) naar de onderliggende commit. Met deze optie, beide
groepen lijnen worden de schuld van de ouder gegeven door extra keuringen uit te voeren.

is optioneel, maar het is de ondergrens van het aantal alfanumerieke tekens
die Git moet detecteren als verplaatsen/kopiëren binnen een bestand om die regels te associëren
met de ouderbetrokkenheid. De standaardwaarde is 20.

-C| |
Detecteer naast -M regels die zijn verplaatst of gekopieerd uit andere bestanden die zijn gewijzigd in
dezelfde toezegging. Dit is handig wanneer u uw programma reorganiseert en code verplaatst
over bestanden. Als deze optie twee keer wordt gegeven, zoekt het commando ook naar
kopieën van andere bestanden in de commit die het bestand aanmaakt. Wanneer deze optie wordt gegeven
drie keer zoekt het commando bovendien naar kopieën van andere bestanden in elke commit.

is optioneel, maar het is de ondergrens van het aantal alfanumerieke tekens
die Git moet detecteren als verplaatsen/kopiëren tussen bestanden om die regels te associëren
met de ouderbetrokkenheid. En de standaardwaarde is 40. Als er meer dan één -C
gegeven opties, de argument van de laatste -C wordt van kracht.

-h
Help-bericht weergeven.

-c
Gebruik dezelfde uitvoermodus als git-annoteren(1) (Standaard: uit).

--score-debuggen
Voeg foutopsporingsinformatie toe met betrekking tot de verplaatsing van regels tussen bestanden (zie -C)
en lijnen verplaatst binnen een bestand (zie -M). Het eerste vermelde getal is de score. Dit is
het aantal alfanumerieke tekens dat is gedetecteerd als verplaatst tussen of binnen
bestanden. Deze moet boven een bepaalde drempel liggen git schuld om die lijnen van te overwegen
code is verplaatst.

-f, --show-naam
Toon de bestandsnaam in de originele commit. Standaard wordt de bestandsnaam weergegeven als die er is
elke regel die afkomstig is van een bestand met een andere naam vanwege hernoemdetectie.

-n, --show-nummer
Toon het regelnummer in de originele commit (Standaard: uit).

-s
Onderdruk de auteursnaam en het tijdstempel van de uitvoer.

-e, --toon-e-mail
Toon het e-mailadres van de auteur in plaats van de naam van de auteur (Standaard: uit). Dit kan ook
gecontroleerd via de schuld.showEmail configuratieoptie.

-w
Negeer witruimte bij het vergelijken van de versie van de ouder en die van het kind om te zien waar
de lijnen kwamen uit.

--afgekort=
In plaats van de standaard 7+1 hexadecimale cijfers als afgekorte objectnaam te gebruiken,
gebruik +1 cijfers. Merk op dat 1 kolom wordt gebruikt voor een dakje om de boundary commit te markeren.

HET PORSELEIN FORMAT

In dit formaat wordt elke regel uitgevoerd na een koptekst; de header heeft minimaal de
eerste regel die heeft:

· 40-byte SHA-1 van de commit waaraan de regel is toegeschreven;

· het regelnummer van de regel in het originele bestand;

· het regelnummer van de regel in het uiteindelijke bestand;

· op een regel die een groep regels start vanaf een andere commit dan de vorige,
het aantal regels in deze groep. Op volgende regels ontbreekt dit veld.

Deze kopregel wordt voor elke commit minstens één keer gevolgd door de volgende informatie:

· de auteursnaam ("author"), e-mail ("author-mail"), tijd ("author-time") en tijdzone
("auteur-tz"); hetzelfde voor committer.

· de bestandsnaam in de commit waaraan de regel is toegeschreven.

· de eerste regel van het commit-logbericht ("summary").

De inhoud van de eigenlijke regel wordt uitgevoerd na de bovenstaande koptekst, voorafgegaan door een TAB. Dit
is om later meer header-elementen toe te voegen.

Het porseleinen formaat onderdrukt over het algemeen commit-informatie die al is gezien.
Twee regels die de schuld krijgen van dezelfde commit worden bijvoorbeeld beide getoond, maar de
details voor die commit worden slechts één keer getoond. Dit is efficiënter, maar kan nodig zijn
meer staat worden gehouden door de lezer. De optie --line-porcelain kan worden gebruikt om volledig uit te voeren
commit-informatie voor elke regel, waardoor eenvoudiger (maar minder efficiënt) gebruik mogelijk is, zoals:

# tel het aantal regels dat aan elke auteur is toegeschreven
git schuld --line-porseleinen bestand |
sed -n 's/^auteur //p' |
sorteren | uniek -c | sorteer -rn

SPECIFICEREN: BEREIKEN

Anders git schuld en git geannoteerde in oudere versies van git, de omvang van de annotatie
kan worden beperkt tot zowel lijnbereiken als revisiebereiken. De optie -L, die beperkt
annotatie aan een bereik van regels, kan meerdere keren worden opgegeven.

Als u geïnteresseerd bent in het vinden van de oorsprong voor regels 40-60 voor bestand foo, kunt u dit gebruiken
de -L optie zoals zo (ze bedoelen hetzelfde - beide vragen om 21 regels beginnend bij regel
40):

git schuld -L 40,60 foo
git schuld -L 40,+21 foo

U kunt ook een reguliere expressie gebruiken om het regelbereik te specificeren:

git schuld -L '/^sub hallo {/,/^}$/' foo

wat de annotatie beperkt tot de hoofdtekst van de hallo-subroutine.

Wanneer u geen interesse heeft in wijzigingen ouder dan versie v2.6.18, of wijzigingen ouder dan 3
weken kunt u revisiebereikspecificaties gebruiken die vergelijkbaar zijn met git rev-lijst:

git schuld v2.6.18.. -- foo
git schuld --sinds=3.weken -- foo

Wanneer revisiebereikspecificaties worden gebruikt om de annotatie te beperken, zijn regels die dat niet hebben
gewijzigd sinds de bereikgrens (de commit v2.6.18 of de meest recente commit that
is meer dan 3 weken oud in het bovenstaande voorbeeld) krijgen de schuld voor die range boundary commit.

Een bijzonder handige manier is om te zien of een toegevoegd bestand regels bevat die zijn gemaakt door kopiëren en plakken
uit bestaande bestanden. Soms geeft dit aan dat de ontwikkelaar slordig was en dat ook deed
de code niet correct refactoren. Je kunt eerst de commit vinden die het bestand heeft geïntroduceerd
met:

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

en annoteer vervolgens de wijziging tussen de commit en zijn ouders, met behulp van commit^! notatie:

git schuld -C -C -f $commit^! -- foe

TOENEMEND OUTPUT

Wanneer aangeroepen met --incremental optie, geeft de opdracht het resultaat weer zoals het is gebouwd. De
uitvoer zal over het algemeen eerst spreken over regels die zijn aangeraakt door recentere commits (dwz de
regels worden buiten de juiste volgorde geannoteerd) en is bedoeld voor gebruik door interactieve kijkers.

Het uitvoerformaat is vergelijkbaar met het porseleinformaat, maar bevat niet het werkelijke
regels uit het bestand dat wordt geannoteerd.

1. Elke vermelding van de schuld begint altijd met een regel van:

<40-byte hex sha1>

Regelnummers tellen vanaf 1.

2. De eerste keer dat een commit in de stream verschijnt, heeft het verschillende andere informatie
erover afgedrukt met een tag van één woord aan het begin van elke regel die de
extra commit-informatie (auteur, e-mail, committer, data, samenvatting, etc.).

3. In tegenstelling tot het porseleinformaat wordt de bestandsnaaminformatie altijd gegeven en beëindigd
de ingang:

"bestandsnaam"

en dus is het echt vrij eenvoudig te ontleden voor een regel- en woordgeoriënteerde ontleder
(wat vrij natuurlijk zou moeten zijn voor de meeste scripttalen).

Note
Voor mensen die aan parsen doen: om het robuuster te maken, negeert u alle regels ertussen
de eerste en laatste (" " en "bestandsnaam" regels) waar u het niet herkent
de tagwoorden (of geef om die specifieke) aan het begin van de
regels "uitgebreide informatie". Op die manier, als er ooit toegevoegde informatie (zoals
de commit-codering of het uitgebreide commit-commentaar), zal een schuldkijker er niet om geven.

MAPPING AUTEURS

Als het bestand .mailmap bestaat op het hoogste niveau van de repository, of op de aangegeven locatie
door de configuratie-opties mailmap.file of mailmap.blob, wordt het gebruikt om auteur en
namen en e-mailadressen van committers naar canonieke echte namen en e-mailadressen.

In de eenvoudige vorm bestaat elke regel in het bestand uit de canonieke echte naam van een
auteur, witruimte en een e-mailadres gebruikt in de commit (ingesloten door < en >) in kaart brengen
naar de naam. Bijvoorbeeld:

Goede naam[e-mail beveiligd]>

De meer complexe vormen zijn:

<[e-mail beveiligd]>[e-mail beveiligd]>

waardoor mailmap alleen het e-mailgedeelte van een commit kan vervangen, en:

Goede naam[e-mail beveiligd]>[e-mail beveiligd]>

waarmee mailmap zowel de naam als de e-mail kan vervangen van een commit die overeenkomt met de
opgegeven commit e-mailadres, en:

Goede naam[e-mail beveiligd]> Naam vastleggen[e-mail beveiligd]>

waarmee mailmap zowel de naam als de e-mail kan vervangen van een commit die overeenkomt met de
gespecificeerde commit naam en e-mailadres.

Voorbeeld 1: Je geschiedenis bevat commits van twee auteurs, Jane en Joe, van wie de namen verschijnen
in de repository onder verschillende vormen:

Joe Ontwikkelaar[e-mail beveiligd]>
Joe R. Ontwikkelaar[e-mail beveiligd]>
Jane Doe[e-mail beveiligd]>
Jane Doe
Jane D.

Stel nu dat Joe zijn middelste naam als initiaal wil gebruiken, en Jane de voorkeur geeft aan haar achternaam
volledig uitgeschreven. Een correct .mailmap-bestand zou er als volgt uitzien:

Jane Doe
Joe R. Ontwikkelaar[e-mail beveiligd]>

Merk op hoe er geen vermelding nodig is voor , omdat de echte naam van
die auteur heeft al gelijk.

Voorbeeld 2: Uw repository bevat commits van de volgende auteurs:

bijnaam1[e-mail beveiligd]>
bijnaam2[e-mail beveiligd]>
bijnaam2[e-mail beveiligd]>
de kerstman[e-mail beveiligd]>
clausule[e-mail beveiligd]>
CTO[e-mail beveiligd]>

Dan wilt u misschien een .mailmap-bestand dat eruitziet als:

<[e-mail beveiligd]>[e-mail beveiligd]>
Een of andere kerel[e-mail beveiligd]> nick1[e-mail beveiligd]>
Andere auteur[e-mail beveiligd]> nick2[e-mail beveiligd]>
Andere auteur[e-mail beveiligd]>[e-mail beveiligd]>
Kerstman[e-mail beveiligd]>[e-mail beveiligd]>

Gebruik hasj # voor opmerkingen die op hun eigen regel staan, of na het e-mailadres.

Gebruik git-blame online met behulp van onworks.net-services