Svenska ▾ Topics ▾ Latest version ▾ git-blame last updated in 2.53.0

NAMN

git-blame - Visa vilken version och författare som sist modifierade varje rad i en fil

SYNOPSIS

git blame [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
	    [-L <intervall>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<datum>]
	    [--ignore-rev <rev>] [--ignore-revs-file <fil>]
	    [--color-lines] [--color-by-age] [--progress] [--abbrev=<n>]
	    [ --contents <file> ] [<rev> | --reverse <rev>..<rev>] [--] <fil>

BESKRIVNING

Annoterar varje rad i den givna filen med information från den revision som senast ändrade raden. Börja annotera från den givna revisionen om du vill.

När -L anges en eller flera gånger begränsar det annoteringen till de begärda raderna.

Radernas ursprung följs automatiskt vid namnbyten av hela filer (för närvarande finns det inget alternativ att stänga av namnbytesfunktionen). För att följa rader som flyttats från en fil till en annan, eller för att följa rader som kopierats och klistrats in från en annan fil, etc., se alternativen -C och -M.

Rapporten berättar ingenting om rader som har tagits bort eller ersatts; du behöver använda ett verktyg som git diff eller gränssnittet "pickaxe" som kortfattat nämns i följande stycke.

Förutom att stödja fil-annoteringar stöder Git även sökning i utvecklingshistoriken för att se när ett kodavsnitt inträffade i en ändring. Detta gör det möjligt att spåra när ett kodavsnitt lades till i en fil, flyttades eller kopierades mellan filer, och slutligen raderades eller ersattes. Det fungerar genom att söka efter en textsträng i diff-filen. Ett litet exempel på pickaxe-gränssnittet som söker efter blame_usage:

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

ALTERNATIV

-b

Visa tom SHA-1 för gräns-incheckningar. Detta kan också styras via konfigurationsalternativet blame.blankBoundary.

--root

Behandla inte root-incheckningar som gränser. Detta kan också styras via konfigurationsalternativet blame.showRoot.

--show-stats

Include additional statistics at the end of blame output.

-L <start>,<slut>
-L :<funktionsnamn>

Kommentera endast radintervallet som anges av <start>,<slut> eller av funktionsnamnets regex <funktionsnamn>. Kan anges flera gånger. Överlappande intervall är tillåtna.

<start> och <slut> är valfria. -L <start> eller -L <start>, sträcker sig från <start> till slutet av filen. -L ,<slut> sträcker sig från början av filen till <slut>.

<start> och <slut> kan anta en av dessa former:

  • <nummer>

    Om <start> eller <slut> är ett tal, anger det ett absolut radnummer (raderna räknas från 1).

  • /<regex>/

    Det här formen använder den första raden som matchar det givna POSIX-värdet <regex>. Om <start> är ett regex, söker den från slutet av föregående -L-intervall, om något, annars från början av filen. Om <start> är ^/<regex>/, söker den från början av filen. Om <slut> är ett regex, börjar sökandet på raden som anges av <start>.

  • +<offset> or -<offset>

    Detta gäller endast för <slut> och anger ett antal rader före eller efter raden som anges av <start>.

Om :<funktionsnamn> anges istället för <start> och <slut>, är det ett reguljärt uttryck som anger intervallet från den första funktionsnamn-raden som matchar <funktionsnamn>, upp till nästa funcname-rad. :<funktionsnamn> söker från slutet av föregående -L-intervall, om något, annars från början av filen. ^:<funktionsnamn> söker från början av filen. Funktionsnamnen bestäms på samma sätt som git diff beräknar patch-hunk-headers (se Definiera en anpassad hunk-header i gitattributes[5]).

-l

Visa lång rev (Standard: av).

-t

Visa rå tidsstämpel (Standard: av).

-S <revs-file>

Använd revisioner från revs-filen istället för att anropa git-rev-list[1].

--reverse <rev>..<rev>

Gå framåt istället för bakåt i historiken. Istället för att visa den version där en rad förekom, visar detta den senaste versionen där en rad har funnits. Detta kräver ett versionsintervall som START..SLUT där sökvägen att skylla finns i START. git blame --reverse START tas som git blame --reverse START..HEAD för enkelhetens skull.

--first-parent

Följ endast den första överordnade incheckning när en merge commit visas. Det här alternativet kan användas för att avgöra när en rad introducerades i en viss integrationsgren, snarare än när den introducerades i historiken överlag.

-p
--porcelain

Visa i ett format utformat för maskinkonsumtion.

--line-porcelain

Visa porslinsformatet, men mata ut incheckning-information för varje rad, inte bara första gången en incheckning refereras. Innebär --porcelain.

--incremental

Visa resultatet stegvis i ett format som är utformat för maskin-konsumtion.

--encoding=<kodning>

Anger kodningen som används för att mata ut författarnamn och inchecknings-sammanfattningar. Om den ställs in på none matas blame-data ut som okonverterad. För mer information, se diskussionen om kodning på manualsidan för git-log[1].

--contents <fil>

Kommentera med innehållet från den namngivna filen, med början från <rev> om det anges, och HEAD annars. Du kan ange - för att få kommandot att läsas från standard in för filinnehållet.

--date <format>

Anger formatet som används för att mata ut datum. Om --date inte anges används värdet för konfigurationsvariabeln blame.date. Om konfigurationsvariabeln blame.date inte heller är inställd används iso-formatet. För värden som stöds, se diskussionen om alternativet --date på git-log[1].

--progress
--no-progress

Förloppsstatus rapporteras som standard i standardfelströmmen när den är ansluten till en terminal. Denna flagga aktiverar förloppsrapportering även om den inte är ansluten till en terminal. Det går inte att använda --progress tillsammans med --porcelain eller --incremental.

-M[<num>]

Identifiera flyttade eller kopierade rader i en fil. När en incheckning flyttar eller kopierar ett radblock (t.ex. originalfilen har A och sedan B, och incheckning ändrar det till B och sedan A), märker den traditionella "skuld"-algoritmen bara hälften av rörelsen och skyller vanligtvis de rader som flyttades upp (dvs. B) på föräldern och tilldelar skulden till de rader som flyttades ner (dvs. A) till barn-inchecking. Med det här alternativet skylls båda grupperna av rader på föräldern genom att köra extra inspektionsomgångar.

<num> är valfritt men det är den nedre gränsen för antalet alfanumeriska tecken som Git måste upptäcka som flytt/kopiering inom en fil för att dessa rader ska associeras med den överordnade incheckning. Standardvärdet är 20.

-C[<num>]

Utöver -M, upptäcker rader som flyttats eller kopierats från andra filer som har ändrats i samma incheckning. Detta är användbart när du omorganiserar ditt program och flyttar kod mellan filer. När det här alternativet anges två gånger letar kommandot dessutom efter kopior från andra filer i den incheckning som skapar filen. När det här alternativet anges tre gånger letar kommandot dessutom efter kopior från andra filer i valfri incheckning.

<num> är valfritt men det är den nedre gränsen för antalet alfanumeriska tecken som Git måste upptäcka vid flyttning/kopiering mellan filer för att dessa rader ska associeras med den överordnade incheckningen. Och standardvärdet är 40. Om det finns fler än ett -C-alternativ angivet, kommer <num>-argumentet för det sista -C att gälla.

--ignore-rev <rev>

Ignorera ändringar gjorda av revisionen när du tilldelar skuld, som om ändringen aldrig inträffade. Rader som ändrades eller lades till av en ignorerad incheckning kommer att skyllas på den föregående incheckning som ändrade den raden eller närliggande rader. Det här alternativet kan anges flera gånger för att ignorera mer än en revision. Om konfigurationsalternativet blame.markIgnoredLines är aktiverat, kommer rader som ändrades av en ignorerad incheckning och tillskrivits en annan incheckning att markeras med ett ? i skuldutdata. Om konfigurationsalternativet blame.markUnblamableLines är aktiverat, markeras de rader som berörts av en ignorerad incheckning som vi inte kunde tillskriva en annan revision med ett *. I porslinslägena skriver vi ignored respektive unblamable på en nyrad.

--ignore-revs-file <fil>

Ignorera revisioner som listas i fil, vilka måste ha samma format som en fsck.skipList. Detta alternativ kan upprepas, och dessa filer kommer att bearbetas efter alla filer som angetts med konfigurationsalternativet blame.ignoreRevsFile. Ett tomt filnamn, "", rensar listan över revideringar från tidigare bearbetade filer.

--color-lines

Färglägg radannoteringar i standardformatet annorlunda om de kommer från samma incheckning som föregående rad. Detta gör det enklare att skilja kodblock som introduceras av olika incheckningar. Standardfärgen är cyan och kan justeras med konfigurationsalternativet color.blame.repeatedLines.

--color-by-age

Färglägg linjeannoteringar beroende på linjens ålder i standardformatet. Konfigurationsalternativet color.blame.highlightRecent styr vilken färg som används för varje åldersintervall.

-h

Visa hjälpmeddelande.

-c

Använd samma utdataläge som git-annotate[1] (Standard: av).

--score-debug

Inkludera felsökningsinformation relaterad till förflyttning av rader mellan filer (se -C) och rader som flyttats inom en fil (se -M). Det första numret som listas är poängen. Detta är antalet alfanumeriska tecken som upptäckts ha flyttats mellan eller inom filer. Detta måste vara över ett visst tröskelvärde för att git blame ska betrakta dessa kodrader som flyttade.

-f
--show-name

Visa filnamnet i den ursprungliga incheckningen. Som standard visas filnamnet om det finns någon rad som kommer från en fil med ett annat namn, på grund av namnbytesdetektering.

-n
--show-number

Visa radnumret i den ursprungliga incheckningen (Standard: av).

-s

Undertryck författarnamnet och tidsstämpeln från utdata.

-e
--show-email

Visa författarens e-postadress istället för författarnamnet (Standard: av). Detta kan också styras via konfigurationsalternativet blame.showEmail.

-w

Ignorera blanktecken vid jämförelse av förälderns version och barnets för att hitta var raderna kommer ifrån.

--diff-algorithm=(patience|minimal|histogram|myers)

Välj en diff-algoritm. Varianterna är följande:

default
myers

Den grundläggande giriga diff-algoritmen. För närvarande är detta standard.

minimal

Lägg extra tid på att se till att minsta möjliga skillnad produceras.

patience

Använd algoritmen "patience diff" när du genererar patchar.

histogram

Denna algoritm utökar tålamodsalgoritmen till att "stödja vanliga element med låg förekomst".

Om du till exempel, konfigurerade variabeln diff.algorithm till ett värde som inte är standard och vill använda standardvärdet, måste du använda alternativet --diff-algorithm=default.

--abbrev=<n>

Istället för att använda standardvärdet 7+1 hexadecimala siffror som förkortat objektnamn, använd <m>+1 siffror, där <m> är minst <n> men säkerställer att inchecknings-objektnamnen är unika. Observera att 1 kolumn används för ett cirkumflet för att markera gränsen för incheckning.

STANDARDFORMATET

När varken --porcelain eller --incremental är angivna, kommer git blame att mata ut annoteringar för varje rad med:

  • förkortat objektnamn för den incheckningen som raden kom ifrån;

  • författar indent (som standard författarnamn och datum, såvida inte -s eller -e anges); och

  • radnummer

före radinnehållet.

PORSLINSFORMATET

I det här formatet, matas varje rad ut efter en rubrik; rubriken har som minimum den första raden som har:

  • 40-byte SHA-1 för den incheckning som raden tillskrivs;

  • radnumret för raden i originalfilen;

  • radnumret för raden i den slutliga filen;

  • På en rad som startar en grupp rader från en annan incheckning än den föregående, antalet rader i denna grupp. På efterföljande rader saknas detta fält.

Denna rubrikrad följs av följande information minst en gång för varje incheckning:

  • författarnamn ("author"), e-postadress ("author-mail"), tid ("author-time") och tidszon ("author-tz"); på samma sätt för incheckare.

  • filnamnet i incheckningen som raden tillskrivs.

  • den första raden i inchecknings-loggmeddelandet ("sammanfattning").

Innehållet på den faktiska raden matas ut efter ovanstående rubrik, prefixerat av en TAB. Detta är för att möjliggöra att fler rubrikelement kan läggas till senare.

Porslinsformatet undertrycker generellt inchecknings-information som redan har visats. Till exempel kommer två rader som är kopplade till samma incheckning att visas, men detaljerna för den incheckningen visas bara en gång. Information som är specifik för enskilda rader kommer inte att grupperas tillsammans, som revs som markeras som "ignorerade" eller "icke-klanderliga". Detta är mer effektivt, men kan kräva att läsaren behåller mer status. Alternativet --line-porcelain kan användas för att mata ut fullständig inchecknings-information för varje rad, vilket möjliggör enklare (men mindre effektiv) användning som:

# räkna antalet rader som tillskrivs varje författare
git blame --line-porcelain file |
sed -n 's/^author //p' |
sort | uniq -c | sort -rn

ANGE INTERVALL

Till skillnad från git blame och git annotate i äldre versioner av git, kan annoteringens omfattning begränsas till både radintervall och revisionsintervall. Alternativet -L, som begränsar annoteringen till ett radintervall, kan anges flera gånger.

När du är intresserad av att hitta ursprunget för raderna 40-60 för filen foo kan du använda alternativet -L så här (de betyder samma sak — båda frågar efter 21 rader som börjar på rad 40):

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

Du kan också använda ett reguljärt uttryck för att ange radintervallet:

git blame -L '/^sub hello {/,/^}$/' foo

which limits the annotation to the body of the hello subroutine.

När du inte är intresserad av ändringar äldre än version v2.6.18, eller ändringar äldre än 3 veckor, kan du använda specifikationer för revisionsintervall liknande git rev-list:

git blame v2.6.18.. -- foo
git blame --since=3.weeks -- foo

När revisions-intervall specifikationer används för att begränsa annoteringen, skylls rader som inte har ändrats sedan intervallgränsen (antingen commit v2.6.18 eller den senaste incheckningen som är mer än 3 veckor gammal i exemplet ovan) för den intervall-gräns incheckning.

Ett särskilt användbart sätt är att se om en tillagd fil har rader som skapats genom kopiering och klistra in från befintliga filer. Ibland indikerar detta att utvecklaren slarvat och inte omstrukturerade koden korrekt. Du kan först hitta den incheckningen som introducerade filen med:

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

och sedan anteckna ändringen mellan incheckningeb och dess föräldrar med hjälp av notationen commit^!:

git blame -C -C -f $commit^! -- foo

INKREMENTELL UTMATNING

När kommandot anropas med alternativet --incremental, matar det ut resultatet allt eftersom det byggs. Utdata kommer generellt att tala om rader som berörts av nyare incheckningar först (dvs. raderna kommer att annoteras i fel ordning) och är avsett att användas av interaktiva tittare.

Utdataformatet liknar porslinsformatet, men det innehåller inte de faktiska raderna från filen som annoteras.

  1. Varje skuld-post börjar alltid med en rad av:

    <40-byte-hex-sha1> <källrad> <resultatrad> <antal-rader>

    Radnummer räknas från 1.

  2. Första gången en incheckning dyker upp i strömmen skrivs det ut diverse annan information om den med en enordstagg i början av varje rad som beskriver den extra inchecknings-informationen (författare, e-postadress, committer, datum, sammanfattning etc.).

  3. Till skillnad från porslinsformatet anges filnamnsinformationen alltid och avslutar posten:

    "filnamn" <filnamn-med-blanksteg-i-citat-ska-gå-här>

    och därmed är det egentligen ganska enkelt att tolka för någon rad- och ordorienterad parser (vilket borde vara ganska naturligt för de flesta skriptspråk).

    Note
    		 För personer som utför parsning: för att göra det mer robust, ignorera bara alla rader mellan den första och sista ("<sha1>" och "filename" rader) där du inte känner igen taggorden (eller bryr dig om just det ordet) i början av raderna "utökad information". På så sätt, om det någonsin läggs till information (som inchecknings-kodningen eller kommentarer om extended commit), kommer en blame-läsare inte att bry sig.

KARTLÄGG FÖRFATTARE

Se gitmailmap[5].

KONFIGURATION

Allt under den här raden i det här avsnittet är selektivt inkluderat från dokumentationen git-config[1]. Innehållet är detsamma som det som finns där:

Warning

Missing sv/config/blame.adoc

See original version for this content.

SE ÄVEN

git-annotate[1]

GIT

En del av git[1]-sviten