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

När revisionsintervallspecifikationer används för att begränsa annoteringen, kommer rader som inte har ändrats sedan intervallgränsen (antingen committen v2.6.18 eller den senaste commiten som är äldre än 3 veckor i exemplet ovan) att skyllas på den intervallgräns-committen.

Ett särskilt användbart sätt är att se om en tillagd fil har rader som skapats genom kopiering och inklistring från befintliga filer. Ibland indikerar detta att utvecklaren var slarvig och inte refaktoriserade koden ordentligt. Du kan först hitta den commit som introducerade filen med:

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

och sedan annotera ändringen mellan commiten och dess föräldrar med notationen commit^!:

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

INKREMENTELL UTDATA När kommandot anropas med alternativet --incremental matas resultatet ut allteftersom det byggs upp. Utdata kommer i allmänhet att handla om rader som berörs av nyare commits först (dvs. raderna kommer att annoteras i oordning) och är avsett att användas av interaktiva visare.

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

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

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

   Radnummer räknas från 1.

2. Första gången en commit dyker upp i strömmen skrivs olika annan
   information om den ut med en enords-tagg i början av varje rad som
   beskriver den extra commit-informationen (författare, e-post,
   committer, datum, sammanfattning etc.).

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

       "filename" <mellanslags-citerat-filnamn-här>

   och därmed är det verkligen ganska enkelt att parsa för en rad- och
   ordorienterad parser (vilket borde vara ganska naturligt för de
   flesta skriptspråk).

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

KARTLÄGGA FÖRFATTARE Se gitmailmap(5). KONFIGURATION Allt under denna rad i detta avsnitt är selektivt inkluderat från dokumentationen för git-config(1). Innehållet är detsamma som det som finns där:

blame.blankBoundary::

   Visa tomt commit-objektnamn för gränskommitteringar i
   git-blame(1). Detta alternativ är falskt som standard.

blame.coloring::

   Detta bestämmer färgschemat som ska tillämpas på blame-utdata. Det
   kan vara repeatedLines, highlightRecent eller none som är
   standard.

blame.date::

   Anger det format som används för att mata ut datum i
   git-blame(1). Om det inte anges används iso-formatet. För vilka
   värden som stöds, se diskussionen om alternativet --date i
   git-log(1).

blame.showEmail::

   Visa författarens e-postadress istället för författarnamnet i
   git-blame(1). Detta alternativ är falskt som standard.

blame.showRoot::

   Behandla inte rotkommitteringar som gränser i git-blame(1).
   Detta alternativ är falskt som standard.

blame.ignoreRevsFile::

   Ignorera revisioner som listas i filen, ett icke-förkortat
   objektnamn per rad, i git-blame(1). Blanksteg och kommentarer
   som börjar med # ignoreras. Detta alternativ kan upprepas flera
   gånger. Tomma filnamn kommer att återställa listan över ignorerade
   revisioner. Detta alternativ kommer att hanteras före
   kommandoradsalternativet --ignore-revs-file.

blame.markUnblamableLines::

   Markera rader som ändrades av en ignorerad revision som vi inte
   kunde tillskriva en annan commit med en * i utdata från
   git-blame(1).

blame.markIgnoredLines::

   Markera rader som ändrades av en ignorerad revision som vi
   tillskrev en annan commit med ett ? i utdata från
   git-blame(1).

SE ÄVEN git-annotate(1) GIT Del av git(1)-sviten KOLOFON Den här sidan är en del av projektet git (Git distribuerat versionshanteringssystem). Information om projektet finns på <⟨http://git-scm.com/⟩>. Om du har en felrapport för den här manualsidan, se <⟨http://git-scm.com/community⟩>. Den här sidan hämtades från projektets uppströms Git-arkiv <⟨https://github.com/git/git.git⟩> den 2025-02-02. (Vid den tidpunkten var datumet för den senast hittade commiten i arkivet 2025-01-31.) Om du upptäcker några renderingsproblem i den här HTML-versionen av sidan, eller om du tror att det finns en bättre eller mer aktuell källa för sidan, eller om du har korrigeringar eller förbättringar av informationen i den här KOLOFONEN (som *inte* är en del av den ursprungliga manualsidan), skicka ett e-postmeddelande till man-pages@man7.org

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