git-blame(1): Skillnad mellan sidversioner

Från Wiki.linux.se
Hoppa till navigering Hoppa till sök
(Skapade sidan med 'När revisionsintervallspecifikationer används för att begränsa annoteringen, kommer rader som inte har ändrats sedan intervallgränsen (antingen commiten v2.6.18 eller den senaste commiten som är äldre än 3 veckor i exemplet ovan) att skyllas på den intervallgräns-commiten. 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...')
(Ingen skillnad)

Versionen från 9 april 2025 kl. 05.20

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

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