git-blame(1)

NAMN

git-blame - Visa vilken revision och författare som senast ändrade varje rad i en fil

SYNOPSIS

git blame [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]

                 [-L <intervall>] [-S <revs-fil>] [-M] [-C] [-C] [-C] [--since=<datum>]
                 [--ignore-rev <rev>] [--ignore-revs-file <fil>]
                 [--color-lines] [--color-by-age] [--progress] [--abbrev=<n>]
                 [ --contents <fil> ] [<rev> | --reverse <rev>..<rev>] [--] <fil>

BESKRIVNING

Annoterar varje rad i den givna filen med information från den revision som senast ändrade raden. Valfritt kan annoteringen starta från den givna revisionen.

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

Ursprunget till rader följs automatiskt över filomdöpningar (för närvarande finns inget alternativ för att stänga av följningen av omdöpningar). 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 inget om rader som har raderats eller ersatts; du behöver använda ett verktyg som git diff eller det "pickaxe"-gränssnitt som kort nämns i följande stycke.

Förutom att stödja filannotering stöder Git även sökning i utvecklingshistoriken efter när ett kodavsnitt förekom 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 diffen. Ett litet exempel på pickaxe-gränssnittet som söker efter blame_usage:

$ git log --pretty=oneline -S'blame_usage'
5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Gör utdata

ALTERNATIV

• -b

Visa tomt SHA-1 för gränskommitteringar. Detta kan också kontrolleras via konfigurationsalternativet blame.blankBoundary.

• --root

Behandla inte rotkommitteringar som gränser. Detta kan också kontrolleras via konfigurationsalternativet blame.showRoot.

• --show-stats

Inkludera ytterligare statistik i slutet av blame-utdata.

• -L <start>,<end>, -L :<funcname>

Annotera endast det radintervall som anges av <start>,<end>, eller av det reguljära uttrycket för funktionsnamn <funcname>. Kan anges flera gånger. Överlappande intervall är tillåtna.

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

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

* nummer

Om <start> eller <end> är ett nummer anger det ett absolut radnummer (rader räknas från 1).

* /regex/

Denna form kommer att använda den första raden som matchar det givna POSIX-regexet. Om <start> är ett regex kommer det att söka från slutet av det föregående -L-intervallet, om något, annars från början av filen. Om <start> är ^/regex/ kommer det att söka från början av filen. Om <end> är ett regex kommer det att söka med start på raden som anges av <start>.

* +offset eller -offset

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

Om ::<funcname> anges istället för <start> och <end> är det ett reguljärt uttryck som betecknar intervallet från den första funcname-raden som matchar <funcname> till nästa funcname-rad. ::<funcname> söker från slutet av det föregående -L-intervallet, om något, annars från början av filen. ^::<funcname> söker från början av filen. Funktionsnamnen bestäms på samma sätt som git diff räknar ut patch-hunk-huvuden (se Defining a custom hunk-header i gitattributes(5)).

• -l

Visa lång rev (Standard: av).

• -t

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

• -S <revs-fil>

Använd revisioner från revs-fil istället för att anropa git-rev-list(1).

• --reverse <rev>..<rev>

Gå historiken framåt istället för bakåt. Istället för att visa den revision där en rad dök upp, visar detta den sista revision där en rad har funnits. Detta kräver ett revisionsintervall som START..END där sökvägen att skylla finns i START. git blame --reverse START tolkas som git blame --reverse START..HEAD för enkelhetens skull.

• --first-parent

Följ endast den första föräldra-commiten när en merge-commit påträffas. Detta alternativ 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 som helhet.

• -p, --porcelain

Visa i ett format utformat för maskinkonsumtion.

• --line-porcelain

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

• --incremental

Visa resultatet inkrementellt i ett format utformat för maskinkonsumtion.

• --encoding=<kodning>

Anger den kodning som används för att mata ut författarnamn och commit-sammanfattningar. Om du ställer in den på none kommer blame-utdata att vara okonverterad data. För mer information, se diskussionen om kodning på manualsidan för git-log(1).

• --contents <fil>

Annotera med innehållet från den namngivna filen, med start från <rev> om den anges, och HEAD annars. Du kan ange - för att kommandot ska läsa filinnehållet från standardinmatningen.

• --date <format>

Anger det format 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 vilka värden som stöds, se diskussionen om alternativet --date i git-log(1).

• --[no-]progress

Status för framsteg rapporteras som standard på standardfelströmmen när den är kopplad till en terminal. Denna flagga aktiverar framstegsrapportering även om den inte är kopplad till en terminal. Kan inte användas --progress tillsammans med --porcelain eller --incremental.

• -M[<num>]

Upptäck flyttade eller kopierade rader inom en fil. När en commit flyttar eller kopierar ett block med rader (t.ex. originalfilen har A och sedan B, och commiten ändrar det till B och sedan A), märker den traditionella blame-algoritmen bara hälften av flyttningen och skyller vanligtvis på raderna som flyttades upp (dvs. B) på föräldern och tilldelar skuld till raderna som flyttades ner (dvs. A) till barn-commiten. Med detta alternativ 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 flyttade/kopierade inom en fil för att associera dessa rader med föräldra-commiten. Standardvärdet är 20.

• -C[<num>]

Förutom -M upptäcker du rader som flyttats eller kopierats från andra filer som ändrades i samma commit. Detta är användbart när du omorganiserar ditt program och flyttar kod runt mellan filer. När detta alternativ anges två gånger söker kommandot dessutom efter kopior från andra filer i den commit som skapar filen. När detta alternativ anges tre gånger söker kommandot dessutom efter kopior från andra filer i alla commits.

<num> är valfritt men det är den nedre gränsen för antalet alfanumeriska tecken som Git måste upptäcka som flyttade/kopierade mellan filer för att associera dessa rader med föräldra-commiten. Och standardvärdet är 40. Om det finns mer än ett -C alternativ anges, kommer argumentet <num> för det sista -C att gälla.

• --ignore-rev <rev>

Ignorera ändringar som gjorts av revisionen när skuld tilldelas, som om ändringen aldrig skedde. Rader som ändrades eller lades till av en ignorerad commit kommer att skyllas på den föregående commit som ändrade den raden eller närliggande rader. Detta alternativ kan anges flera gånger för att ignorera mer än en revision. Om konfigurationsalternativet blame.markIgnoredLines är inställt kommer rader som ändrades av en ignorerad commit och tillskrevs en annan commit att markeras med ett ? i blame-utdata. Om konfigurationsalternativet blame.markUnblamableLines är inställt kommer de rader som berördes av en ignorerad commit som vi inte kunde tillskriva en annan revision att markeras med en *.

• --ignore-revs-file <fil>

Ignorera revisioner som listas i fil, som måste ha samma format som en fsck.skipList. Detta alternativ kan upprepas, och dessa filer kommer att behandlas efter eventuella filer som anges med konfigurationsalternativet blame.ignoreRevsFile. Ett tomt filnamn, "", kommer att rensa listan över revs från tidigare behandlade filer.

• --color-lines

Färglägg radannoteringar i standardformatet olika om de kommer från samma commit som föregående rad. Detta gör det lättare att skilja kodblock som introducerats av olika commits. Färgen är som standard cyan och kan justeras med konfigurationsalternativet color.blame.repeatedLines.

• --color-by-age

Färglägg radannoteringar beroende på radens å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 flyttning 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 anse att dessa kodrader har flyttats.

• -f, --show-name

Visa filnamnet i den ursprungliga commiten. Som standard visas filnamnet om det finns någon rad som kom från en fil med ett annat namn, på grund av omdöpningsdetektering.

• -n, --show-number

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

• -s

Undertryck författarnamn och tidsstämpel från utdata.

• -e, --show-email

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

• -w

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

• --abbrev=<n>

Istället för att använda standard 7+1 hexadecimala siffror som förkortat objektnamn, använd <m>+1 siffror, där <m> är minst <n> men säkerställer att commit-objektnamnen är unika. Observera att 1 kolumn används för en cirkumflex för att markera gränskommiten.

STANDARDUTDATA

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

• förkortat objektnamn för den commit som raden kom ifrån;
• författaridentitet (som standard författarnamn och datum, om inte -s eller -e anges); och
• radnummer

före radinnehållet.

PORSLINSFORMATET

I detta format matas varje rad ut efter ett huvud; huvudet har som minimum den första raden som innehåller:

• 40-byte SHA-1 för den commit 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 commit än den föregående, antalet rader i denna grupp. På efterföljande rader saknas detta fält.

Denna huvudrad följs av följande information minst en gång för varje commit:

• författarnamn ("author"), e-post ("author-mail"), tid ("author-time") och tidszon ("author-tz"); liknande för committer.
• filnamnet i den commit som raden tillskrivs.
• den första raden i commit-loggmeddelandet ("summary").

Innehållet i den faktiska raden matas ut efter ovanstående huvud, prefixat med en TAB. Detta för att möjliggöra att fler huvudelement läggs till senare.

Porslinsformatet undertrycker i allmänhet commit-information som redan har setts. Till exempel kommer två rader som skylls på samma commit båda att visas, men detaljerna för den commiten kommer bara att visas en gång. Detta är effektivare, men kan kräva att läsaren håller mer tillstånd. Alternativet --line-porcelain kan användas för att mata ut fullständig commit-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 fil |
sed -n 's/^author //p' |
sort | uniq -c | sort -rn

SPECIFICERA INTERVALL

Till skillnad från git blame och git annotate i äldre versioner av git kan omfattningen av annoteringen 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 i filen foo, kan du använda alternativet -L på följande sätt (de betyder samma sak – båda frågar efter 21 rader med start 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

vilket begränsar annoteringen till kroppen av subrutinen hello.

När du inte är intresserad av ändringar äldre än version v2.6.18, eller ändringar äldre än 3 veckor, kan du använda revisionsintervallspecifikationer som liknar git rev-list:

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