Git

git-log last updated in 2.53.0

NAMN

git-log - Visa inchecknings-loggar

SYNOPSIS

git log [<flaggor>] [<versionsintervall>] [[--] <sökväg>…]

BESKRIVNING

Visar inchecknings-loggarna.

Lista incheckningar som kan nås genom att följa parent-länkarna från de angivna incheckningarna, men exkludera incheckningar som kan nås från de som anges med ett {caret} framför sig. Utdata ges som standard i omvänd kronologisk ordning.

Du kan tänka på detta som en mängdoperation. Incheckningar som kan nås från någon av de incheckningar som anges på kommandoraden bildar en mängd, och sedan subtraheras incheckningar som kan nås från någon av dem som anges med ^ framför från den mängden. De återstående incheckningarna är det som visas i kommandots utdata. Olika andra alternativ och sökvägsparametrar kan användas för att ytterligare begränsa resultatet.

Således, följande kommando:

$ git log foo bar ^baz

betyder "lista alla incheckningar som är nåbara från foo eller bar, men inte från baz".

En särskild notation "<inchecking1>..<inchecking2>" kan användas som en förkortning för "^<inchecking1> <inchecking2>". Till exempel, kan något av följande användas omväxlande:

$ git log origin..HEAD
$ git log HEAD ^origin

En annan speciell notation är "<inchecking1>...<inchecking2>" vilket är användbart för sammanslagningar. Den resulterande uppsättningen commits är den symmetriska skillnaden mellan de två operanderna. Följande två kommandon är ekvivalenta:

$ git log A B --not $(git merge-base --all A B)
$ git log A...B

Kommandot använder alternativ som är tillämpliga för kommandot git-rev-list[1] för att kontrollera vad som visas och hur, och alternativ som är tillämpliga för kommandot git-diff[1] för att kontrollera hur de ändringar som varje commit introducerar visas.

ALTERNATIV

--follow

Fortsätt lista historiken för en fil utöver namnbyten (fungerar bara för en enskild fil).

--no-decorate

--decorate[=(short|full|auto|no)]

Skriv ut referensnamnen för alla incheckningar som visas. Möjliga värden är:

`short`;; prefixen för referensnamn `refs/heads/`, `refs/tags/` och
	`refs/remotes/` skrivs inte ut.
`full`;; hela referensnamnet (inklusive prefix) skrivs ut.
`auto`:: om utdata går till en terminal visas referensnamnen
	som om `short` hade angetts, annars visas inga
	referensnamn.

Alternativet --decorate är en förkortning för --decorate=short. Standardvärdet är log.decorate om det är konfigurerat, annars auto.

--decorate-refs=<mönster>

--decorate-refs-exclude=<mönster>

För varje kandidatreferens, använd den inte för dekoration om den matchar någon av <mönster>-parametrarna som anges till --decorate-refs-exclude eller om den inte matchar någon av <mönster>-parametrarna som anges till --decorate-refs. Konfigurationsalternativet log.excludeDecoration tillåter att referenser exkluderas från dekorationerna, men ett explicit --decorate-refs-mönster kommer att åsidosätta en matchning i log.excludeDecoration.

Om inget av dessa alternativ eller konfigurationsinställningar anges, används referenser som dekoration om de matchar HEAD, refs/heads/, refs/remotes/, refs/stash/ eller refs/tags/.

--clear-decorations

När det här alternativet anges, rensar det alla tidigare --decorate-refs- eller --decorate-refs-exclude-alternativ och minskar standardfiltret för dekoration så att det inkluderar alla referenser. Detta alternativ antas om konfigurationsvärdet log.initialDecorationSet är satt till all.

--source

Skriv ut referensnamnet som anges på kommandoraden genom vilket varje incheckning nåddes.

--mailmap

--no-mailmap

--use-mailmap

--no-use-mailmap

Använd mailmap-filen för att mappa författar- och committer-namn och e-postadresser till kanoniska riktiga namn och e-postadresser. Se git-shortlog[1].

--full-diff

Utan denna flagga, visar git log -p <sökväg>... incheckningar som berör de angivna sökvägarna, och diffs kring samma angivna sökvägar. Med detta, visas hela diffen för incheckningar som berör de angivna sökvägarna; detta betyder att "<sökväg>..." endast begränsar incheckningar, och begränsar inte diff för dessa incheckningar.

Observera att detta påverkar alla diff-baserade utdatatyper, t.ex. de som produceras av --stat, etc.

--log-size

Inkludera en rad log size <nummer> i utdata för varje incheckning, där <nummer> är längden på inchecknings-meddelande i byte. Avsedd att snabba upp verktyg som läser loggmeddelanden från git log-utdata genom att låta dem allokera utrymme i förväg.

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

-L:<funktionsnamn>:<fil>

Spåra utvecklingen av radintervallet som ges av <start>,<slut>, eller av funktionsnamnet regex <funktionsnamn>, inom <fil>. Du får inte ange några sökvägsmönster-begränsare. Detta är för närvarande begränsat till en walk som börjar från en enda revision, d.v.s. du får bara ange noll eller ett positivt revisionsargument, och <start> och <slut> (eller <funktionsnamn>) måste finnas i startrevisionen. Du kan ange detta alternativ mer än en gång. Innebär --patch. Patch-utdata kan undertryckas med --no-patch, men andra diff-format (nämligen --raw, --numstat, --shortstat, --dirstat, --summary, --name-only, --name-status, --check) är för närvarande inte implementerade.

<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-styckes-huvuden (se Definiera en anpassad styckes-huvuden i gitattributes[5]).

<revisionsintervall>: Visa endast incheckningar inom det angivna revisionsintervallet. När ingen <revisionsintervall> anges, används som standard HEAD (dvs. hela historiken som leder till den aktuella incheckningen). origin..HEAD anger alla incheckningar som är åtkomliga från den aktuella incheckningen (dvs. HEAD), men inte från origin. För en komplett lista över sätt att stava <revisionsintervall>, se avsnittet Ange intervall i gitrevisions[7].
[--] <sökväg>...: Visa endast incheckningar som är tillräckliga för att förklara hur filerna som matchar de angivna sökvägarna uppstod. Se Historikförenkling nedan för detaljer och andra förenklingslägen.

Sökvägar kan behöva prefixas med -- för att separera dem från alternativ eller revisionsintervallet, när förvirring uppstår.

Inchecknings Begränsning

Förutom att ange ett intervall av incheckningar som ska listas med hjälp av de speciella notationer som förklaras i beskrivningen, kan ytterligare inchecknings-begränsningar tillämpas.

Att använda fler alternativ begränsar generellt sett utdata ytterligare (t.ex. --since=<datum1> begränsar till incheckningar nyare än <datum1>, och att använda det med --grep=<mönster> begränsar ytterligare till incheckningar vars loggmeddelande har en rad som matchar <mönster>), om inget annat anges.

Observera att dessa tillämpas före inchecknings-ordnings och formateringsalternativ, såsom --reverse.

-<nummer>

-n <nummer>

--max-count=<nummer>

Begränsa utdata till <nummer> incheckningar.

--skip=<nummer>

Hoppa över <nummer> incheckningar innan du börjar visa inchecknings-utdata.

--since=<datum>

--after=<datum>

Visa incheckningar som är nyare än <datum>.

--since-as-filter=<datum>

Visa alla incheckningar som är nyare än <datum>. Detta besöker alla incheckningar i intervallet, istället för att stanna vid den första incheckningen som är äldre än <datum>.

--until=<datum>

--before=<datum>

Visa incheckningar äldre än <datum>.

--author=<mönster>

--committer=<mönster>

Begränsa utdata för incheckningar till de med författar/incheckare-huvud-rader som matchar det reguljära uttrycket <mönster>. Med mer än ett --author=<mönster> väljs incheckningar vars författare matchar någon av <mönster> (på samma sätt för flera --committer=<mönster>).

--grep-reflog=<mönster>

Begränsa utdata för incheckningar till de med reflog-poster som matchar det reguljära uttrycket <mönster>. Med mer än ett --grep-reflog väljs incheckningar vars reflog-meddelande matchar något av de givna mönstren. Det är ett fel att använda det här alternativet om inte --walk-reflogs används.

--grep=<mönster>

Begränsa utdata för incheckningar till de med ett loggmeddelande som matchar det reguljära uttrycket <mönster>. Med mer än ett --grep=<mönster> väljs incheckningar vars meddelande matchar någon av <mönster> (men se --all-match).

När --notes är i kraft, matchas meddelandet från anteckningar som om det vore en del av loggmeddelandet.

--all-match

Begränsa utdata till de incheckningar som matchar alla givna --grep, istället för de som matchar minst en.

--invert-grep

Begränsa utdata till de incheckningar med ett loggmeddelande som inte matchar <mönster> som anges med --grep=<mönster>.

-i

--regexp-ignore-case

Matcha de reguljära uttrycks begränsande mönstren utan hänsyn till gemener och versaler.

--basic-regexp

Betrakta de begränsande mönstren som grundläggande reguljära uttryck; detta är standardinställningen.

-E

--extended-regexp

Betrakta att de begränsande mönstren som utökade reguljära uttryck istället för de standard grundläggande reguljära uttrycken.

-F

--fixed-strings

Betrakta de begränsande mönstren som fasta strängar (tolka inte mönster som ett reguljärt uttryck).

-P

--perl-regexp

Betrakta de begränsande mönstren som Perl-kompatibla reguljära uttryck.

Stöd för den här typen av reguljära uttryck är ett valfritt kompilerings-tids beroende. Om Git inte kompilerades med stöd för dem kommer det att dö om det här alternativet anges.

--remove-empty

Stanna när en given sökväg försvinner från trädet.

--merges

Skriv endast ut sammanslagnings-incheckningar. Detta är exakt samma sak som --min-parents=2.

--no-merges

Skriv inte ut incheckningar med mer än en förälder. Detta är exakt samma sak som --max-parents=1.

--min-parents=<nummer>

--max-parents=<nummer>

--no-min-parents

--no-max-parents

Visar endast incheckningar som har minst (eller högst) lika många föräldra-incheckningar. Speciellt är --max-parents=1 samma sak som --no-merges, --min-parents=2 samma sak som --merges. --max-parents=0 ger alla rot-incheckningar och --min-parents=3 alla bläckfisk-sammanslagningar.

--no-min-parents och --no-max-parents återställer dessa gränser (till ingen gräns) igen. Motsvarande former är --min-parents=0 (någon incheckning har 0 eller fler föräldrar) och --max-parents=-1 (negativa tal anger ingen övre gräns).

--first-parent

När du letar efter incheckningar att inkludera, följ endast den första förälder-incheckningen när du ser en sammanslagnings-incheckning. Det här alternativet kan ge en bättre översikt när du tittar på utvecklingen av en viss ämnesgren, eftersom sammanslagningar till en ämnesgren tenderar att bara handla om att anpassning till uppdateringar uppströms då och då, och det här alternativet låter dig ignorera de individuella incheckningar som införts i din historik genom en sådan sammanslagning.

Det här alternativet ändrar även standard diff-formatet för sammanslagnings-incheckningar till first-parent, se --diff-merges=first-parent för mer information.

--exclude-first-parent-only

När du hittar incheckningar att exkludera (med en ^), följ endast den första förälder-incheckningen när du ser en sammanslagnings-incheckning. Detta kan användas för att hitta uppsättningen ändringar i en ämnesgren från den punkt där den avvek från den fjärranslutna grenen, givet att godtyckliga sammanslagingar kan vara giltiga ämnesgrenändringar.

--not

Vänder betydelsen av prefixet ^ (eller avsaknaden av det) för alla efterföljande revisionsspecifikationer, upp till nästa --not. När det används på kommandoraden före --stdin, kommer revisionerna som skickas via stdin inte att påverkas av det. Omvänt, när det skickas via standardindata, kommer revisionerna som skickas på kommandoraden inte att påverkas av det.

--all

Låtsas som om alla referenser i refs/, tillsammans med HEAD, listas på kommandoraden som <incheckning>.

--branches[=<mönster>]

Låtsas som om alla referenser i refs/heads listas på kommandoraden som <incheckning>. Om <mönster> anges, begränsa grenar till de som matchar given shell-glob. Om <mönster> saknar ?, * eller [, antyds /* i slutet.

--tags[=<mönster>]

Låtsas som om alla referenser i refs/tags listas på kommandoraden som <incheckning>. Om <mönster> anges, begränsa taggarna till de som matchar den givna shell-globen. Om mönstret saknar ?, * eller [, antyds /* i slutet.

--remotes[=<mönster>]

Låtsas som om alla referenser i refs/remotes listas på kommandoraden som <incheckning>. Om <mönster> anges, begränsas fjärrspårningsgrenar till de som matchar given shell-glob. Om mönstret saknar ?, * eller [, antyds /* i slutet.

--glob=<glob-mönster>

Låtsas som om alla referenser som matchar skalglob <glob-mönster> listas på kommandoraden som <incheckning>. Inledande refs/ läggs automatiskt till om det saknas. Om mönstret saknar ?, * eller [, antyds /* i slutet.

--exclude=<glob-mönster>

Inkludera inte referenser som matchar <glob-mönster> som nästa --all, --branches, --tags, --remotes eller --glob annars skulle beakta. Upprepningar av detta alternativ ackumulerar exluderings-mönster upp till nästa --all, --branches, --tags, --remotes eller --glob-alternativ (andra alternativ eller argument rensar inte ackumulerade mönster).

Mönstren som anges ska inte börja med refs/heads, refs/tags eller refs/remotes när de tillämpas på --branches, --tags respektive --remotes, och de måste börja med refs/ när de tillämpas på --glob eller --all. Om ett efterföljande /* är avsett måste det anges explicit.

--exclude-hidden=(fetch|receive|uploadpack)

Inkludera inte referenser som skulle döljas av git-fetch, git-receive-pack eller git-upload-pack genom att konsultera lämplig fetch.hideRefs, receive.hideRefs eller uploadpack.hideRefs konfiguration tillsammans med transfer.hideRefs (se git-config[1]). Detta alternativ påverkar nästa pseudo-ref-alternativ --all eller --glob och rensas efter att de har bearbetats.

--reflog

Låtsas som om alla objekt som nämns av reflogs listas på kommandoraden som <incheckning>.

--alternate-refs

Låtsas som om alla objekt som nämns som referens-toppar för alternativa förvar listades på kommandoraden. Ett alternativt förvar är vilket förvar som helst vars objektkatalog är specificerad i objects/info/alternates. Uppsättningen av inkluderade objekt kan modifieras av core.alternateRefsCommand, etc. Se git-config[1].

--single-worktree

Som standard, granskas alla arbetskataloger med följande alternativ när det finns fler än ett (se git-worktree[1]): --all, --reflog och --indexed-objects. Detta alternativ tvingar dem att endast granska det aktuella arbetskatalogen.

--ignore-missing

När du ser ett ogiltigt objektnamn i indatafältet, låtsas som om det felaktiga indatafältet inte angavs.

--bisect

Låtsas som om den felaktiga halverings-referensen refs/bisect/bad listades och som om den följdes av --not och den bra halverings-referensen refs/bisect/good-* på kommandoraden.

--stdin

Förutom att hämta argument från kommandoraden, läs dem även från standardinmatning. Detta accepterar incheckningar och pseudo-alternativ som --all och --glob=. När en ---avgränsare setts, behandlas följande inmatning som sökvägar och används för att begränsa resultatet. Flaggor som --not som läses via standardinmatning respekteras endast för argument som skickas på samma sätt och kommer inte att påverka några efterföljande kommandoradsargument.

--cherry-mark

Liksom --cherry-pick (se nedan) men markera motsvarande incheckningar med = istället för att utelämna dem, och ojämlika med +.

--cherry-pick

Utelämna alla incheckningar som introducerar samma förändring som en annan incheckning på den "andra sidan" när uppsättningen incheckningar är begränsad med symmetrisk skillnad.

Om du till exempel, har två grenar, A och B, är ett vanligt sätt att lista alla incheckningar på endast ena sidan av dem med --left-right (se exemplet nedan i beskrivningen av alternativet --left-right). Det visar dock de incheckningar som valdes ut från den andra grenen (till exempel kan “3rd on b” vara utvalt från gren A). Med det här alternativet exkluderas sådana par av incheckningar från utdata.

--left-only

--right-only

Lista endast incheckningar på respektive sida av en symmetrisk skillnad, d.v.s. endast de som skulle markeras < respektive > med --left-right.

Till exempel, --cherry-pick --right-only A...B utelämnar de incheckningar från B som finns i A eller är patch-ekvivalenta med en incheckning i A. Med andra ord listar detta + incheckningar från git cherry A B. Mer exakt ger --cherry-pick --right-only --no-merges den exakta listan.

--cherry

En synonym för --right-only --cherry-mark --no-merges; användbar för att begränsa utdata till incheckningar på vår sida och markera de som har tillämpats på den andra sidan av en förgrenad historik med git log --cherry upstream...mybranch, liknande git cherry upstream mybranch.

-g

--walk-reflogs

Istället för att gå igenom inchecknings-förfäderstkedjan, gå över reflog-poster från den senaste till de äldre. När det här alternativet används kan du inte ange incheckningar att exkludera (det vill säga, notationerna ^<incheckning>, <incheckning1>..<incheckning2> och <incheckning1>...<incheckning2> kan inte användas).

Med formatet --pretty annat än oneline och reference (av uppenbara skäl) orsakar detta att utdata har två extra rader med information hämtad från refloggen. Refloggs-beteckningen i utdata kan visas som ref@{<N:te>} (där <N:te> är det omvänd-kronologiska indexet i refloggen) eller som ref@{<tidsstämpel>} (med <tidsstämpel> för den posten), beroende på några regler:

Om startpunkten anges som ref@{<N:te>}, visa indexformatet.
Om startpunkten angavs som ref@{now}, visa tidsstämpelformatet.
Om ingetdera användes, men --date angavs på kommandoraden, visa tidsstämpeln i det format som begärs av --date.
Annars, visa indexformatet.

Under --pretty=oneline, prefixeras inchecknings-meddelandet med denna information på samma rad. Detta alternativ kan inte kombineras med --reverse. Se även git-reflog[1].

Under --pretty=reference kommer denna information inte att visas alls.

--merge

Visa incheckningar som berör konflikterande sökvägar i intervallet HEAD...<andra>, där <andra> är den första befintliga pseudoreferensen i MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD eller REBASE_HEAD. Fungerar bara när indexet har osammanfogade poster. Det här alternativet kan användas för att visa relevanta incheckningar när konflikter från en trevägssammanfogning löses.

--boundary

Utdata exkluderar gräns-incheckningar. Gräns-incheckningar har prefixet -.

Historisk förenkling

Ibland är man bara intresserad av delar av historiken, till exempel incheckningar som ändrar en viss <sökväg>. Men det finns två delar av Historik förenkling, en del handlar om att välja incheckningar och den andra är hur man gör det, eftersom det finns olika strategier för att förenkla historiken.

Följande alternativ väljer vilka incheckningar som ska visas:

<sökvägar>: Incheckningar som ändrar de angivna <sökvägarna> är markerade.
--simplify-by-decoration: Incheckningar som refereras av någon gren eller tagg väljs.

Observera att extra incheckningar kan visas för att ge en meningsfull historik.

Följande alternativ påverkar hur förenklingen utförs:

Standardläge: Förenklar historiken till den enklaste historiken som förklarar trädets slutliga tillstånd. Enklast eftersom den beskär vissa sidogrenar om slutresultatet är detsamma (dvs. sammanfogar grenar med samma innehåll)
--show-pulls: Inkludera alla incheckningar från standardläget, men även alla sammanslagnings-incheckningar som inte är TRÄDSAMA till den första föräldern men är TRÄDSAMA till en senare förälder. Det här läget är användbart för att visa de sammanslagnings-incheckningar som "först introducerade" en ändring i en gren.
--full-history: Samma som standardläget, men rensar inte bort en del historik.
--dense: Endast de valda incheckningar visas, plus några för att ha en meningsfull historik.
--sparse: Alla incheckningar i den förenklade historiken visas.
--simplify-merges: Ytterligare ett alternativ till --full-history för att ta bort onödiga sammanslagningar från den resulterande historiken, eftersom det inte finns några valda incheckningar som bidrar till denna sammanslagning.
--ancestry-path[=<incheckning>]: När ett intervall av incheckningar ges att visa (t.ex. <incheckning1>..<incheckning2> eller <incheckning2> ^<incheckning1>), och en incheckning_<incheckning>_ inom det intervallet, visas endast incheckningar i det intervallet som är förfäder till <incheckning>, underordnade till <incheckning>, eller <incheckning> självt. Om ingen incheckning anges, använd <incheckning1> (den exkluderade delen av intervallet) som <incheckning>. Kan skickas flera gånger; i så fall inkluderas en incheckning om det är någon av de angivna incheckningarna eller om det är en förfader eller ättling till en av dem.

En mer detaljerad förklaring följer.

Anta att du angav foo som <sökvägar>. Vi ska anropa incheckningar som modifierar foo !TRÄDSAMA, och resten TRÄDSAMA. (I en diff filtrerad för foo ser de olika respektive lika ut.)

I det följande kommer vi alltid att hänvisa till samma exempelhistorik för att illustrera skillnaderna mellan förenklingsinställningarna. Vi antar att du filtrerar efter en fil foo i denna commit-graf:

	  .-A---M---N---O---P---Q
	 /     /   /   /   /   /
	I     B   C   D   E   Y
	 \   /   /   /   /   /
	  `-------------'   X

Den horisontella historiklinjen A---Q tas som den första föräldern till varje sammanslagning. Incheckningarna är:

I är den initiala incheckningen, där foo finns med innehållet asdf, och en fil quux finns med innehållet quux. Initiala incheckningar jämförs med ett tomt träd, så I är !TRÄDSAMA.
I A innehåller foo bara foo.
B innehåller samma ändring som A. Dess sammanslagning M är trivial och därför TRÄDSAMA för alla föräldrar.
C ändrar inte foo, men dess sammanslagning N ändrar det till foobar, så det är inte TRÄDSAMA med någon förälder.
D sätter foo till baz. Dess sammanslagning O kombinerar strängarna från N och D till foobarbaz; d.v.s. den är inte TRÄDSAMA med någon förälder.
E ändrar quux till xyzzy, och dess sammanslagning P kombinerar strängarna till quux xyzzy. P är TRÄDSAMA till O, men inte till E.
X är en oberoende rot-incheckning som lade till en ny fil side, och Y modifierade den. Y är TRÄDSAMA till X. Dess sammanslagning Q lade till side till P, och Q är TRÄDSAMA till P, men inte till Y.

rev-list går bakåt genom historiken, inklusive eller exkluderar incheckningar baserat på om --full-history och/eller omskrivning av överordnade kommandon (via --parents eller --children) används. Följande inställningar är tillgängliga.

Standardläge

Incheckningar inkluderas om de inte är TRÄDSAMA till någon förälder (även om detta kan ändras, se --sparse nedan). Om incheckningen var en sammanslagning, och den var TRÄDSAMA till en förälder, följ endast den föräldern. (Även om det finns flera TRÄDSAMA-föräldrar, följ endast en av dem.) Annars, följ alla föräldrar.

Detta resulterar i:

	  .-A---N---O
	 /     /   /
	I---------D

Observera hur regeln att endast följer TRÄDSAMA-föräldern, om en sådan finns tillgänglig, tog bort B helt från beaktande. C beaktades via N, men är TRÄDSAMA. Rot-incheckningar jämförs med ett tomt träd, så I är !TRÄDSAMA.

Förälder/barn-relationer är bara synliga med --parents, men det påverkar inte de incheckningar som är valda i standardläget, så vi har visat förälder-linjerna.

--full-history utan förälder omskrivning

Det här läget skiljer sig från standardläget på en punkt: följ alltid alla föräldrar till en sammanslagning, även om den är TRÄDSAMA till en av dem. Även om mer än en sida av sammanslagningen har inkluderade incheckningar, betyder det inte att själva sammanslagningen är det! I exemplet får vi

	I  A  B  N  D  O  P  Q

M exkluderades eftersom det är TRÄDSAMA för båda föräldrarna. E, C och B fick alla gå, men endast B var !TRÄDSAMA, så de andra visas inte.

Observera att utan omskrivning av föräldern är det inte riktigt möjligt att prata om förälder/barn-relationerna mellan incheckningar, så vi visar dem frånkopplade.

--full-history med föräldraomskrivning

Vanliga incheckningar inkluderas endast om de är !TRÄDSAMA (även om detta kan ändras, se --sparse nedan).

Sammanslagningar inkluderas alltid. Emellertid skrivs deras föräldralista om: längs varje förälder, beskär bort incheckningar som inte själva inkluderas. Detta resulterar i

	  .-A---M---N---O---P---Q
	 /     /   /   /   /
	I     B   /   D   /
	 \   /   /   /   /
	  `-------------'

Jämför med --full-history utan att skriva om ovan. Observera att E beskars bort eftersom det är TRÄDSAMA, men föräldralistan till P skrevs om för att innehålla E`s föräldra `I. Detsamma hände för C och N, och X, Y och Q.

Utöver ovanstående inställningar, kan du ändra om TRÄDSAMA påverkar inkludering:

--dense

Incheckningar som genomgås inkluderas om de inte är TREESAME med någon förälder.

--sparse

Alla incheckningar som gnomgås inkluderas.

Observera att utan --full-history förenklar detta fortfarande sammanslagningar: om en av föräldrarna är TRÄDSAMA följer vi bara den, så de andra sidorna av sammanslagningen genomgås aldrig.

--simplify-merges

Först, bygg en historikgraf på samma sätt som --full-history med föräldraomskrivning gör (se ovan).

Förenkla sedan varje incheckning C till dess ersättnings-C' i den slutliga historiken enligt följande regler:

Sätt C till C.
Ersätt varje förälder P till C' med dess förenklingsmässiga P'. I processen, ta bort föräldrar som är förfäder till andra föräldrar eller som är rot-incheckningar TRÄDSAMA till ett tomt träd, och ta bort dubbletter, men var noga med att aldrig ta bort alla föräldrar som vi är TRÄDSAMA till.
Om efter denna föräldern omskrivning, C' är en root- eller sammanslagnings-incheckning (har noll eller >1 förälder), en gräns-incheckning eller !TRÄDSAMA, så finns den kvar. Annars ersätts den med sin enda förälder.

Effekten av detta visas bäst genom att jämföra med --full-history med föräldraomskrivning. Exemplet blir:

	  .-A---M---N---O
	 /     /       /
	I     B       D
	 \   /       /
	  `---------'

Notera de största skillnaderna i N, P och Q jämfört med --full-history:

N`s föräldralista hade `I borttagen, eftersom den är en förfader till den andra föräldern M. Ändå fanns N kvar eftersom den är !TRÄDSAMA.
På liknande sätt togs I bort från P`s föräldralista. `P togs sedan bort helt, eftersom den hade en förälder och är TRÄDSAMA.
Q`s föräldralista förenklade `Y till X. X togs sedan bort eftersom det var en TRÄDSAMA-rot. Q togs sedan bort helt eftersom den hade en förälder och är TRÄDSAMA.

Det finns ytterligare ett förenklingsläge tillgängligt:

--ancestry-path[=<incheckning>]

Begränsa de visade incheckningar till de som är en förfader till <incheckning>, eller som är en ättling till <incheckning>, eller som är <incheckning> självt.

Som ett exempel på användningsfall, betrakta följande inchecknings-historik:

	    D---E-------F
	   /     \       \
	  B---C---G---H---I---J
	 /                     \
	A-------K---------------L--M

En vanlig D..M beräknar mängden incheckningar som är förfäder till M, men exkluderar de som är förfäder till D. Detta är användbart för att se vad som hände med historiken som ledde till M sedan D, i den meningen att "vad har M som inte existerade i D". Resultatet i det här exemplet skulle vara alla incheckningar, förutom A och B (och D självt, förstås).

När vi vill ta reda på vilka incheckningar i M som är kontaminerade med buggen som introducerades av D och behöver åtgärdas, kanske vi bara vill visa den delmängd av D..M som faktiskt är ättlingar till D, dvs. exklusive C och K. Det är precis vad alternativet --ancestry-path gör. Tillämpat på D..M-intervallet resulterar det i:

		E-------F
		 \       \
		  G---H---I---J
			       \
				L--M

Vi kan också använda --ancestry-path=D istället för --ancestry-path vilket betyder samma sak när det tillämpas på D..M-intervallet men är bara mer explicit.

Om vi istället är intresserade av ett givet ämne inom detta intervall, och alla incheckningar som påverkas av det ämnet, kanske vi bara vill se den delmängd av D..M som innehåller det ämnet i sin förfäders-sökväg. Så att använda --ancestry-path=H D..M till exempel skulle resultera i:

		E
		 \
	      C---G---H---I---J
			       \
				L--M

Medan --ancestry-path=K D..M skulle resultera i

		K---------------L--M

Innan vi diskuterar ett annat alternativ, --show-pulls, behöver vi skapa en ny exempel historik.

Ett vanligt problem som användare stöter på när de tittar på förenklad historik är att en incheckning som de vet har ändrat en fil på något sätt inte visas i filens förenklade historik. Låt oss demonstrera ett nytt exempel och visa hur alternativ som --full-history och --simplify-merges fungerar i så fall:

	  .-A---M-----C--N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`-Z'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `---Y--'

I det här exemplet, anta att I skapade file.txt som modifierades av A, B och X på olika sätt. De ensamstående föräldra-incheckningen C, Z och Y ändrar inte file.txt. Sammanslagnings-incheckningen M skapades genom att lösa sammanslagnings-konflikten för att inkludera både ändringar från A och B och är därför inte TRÄDSAMA till någon av dem. Sammanslagningens-incheckningen R skapades dock genom att ignorera innehållet i file.txt vid M och endast ta innehållet i file.txt vid X. Därför är R TREESAME till X men inte M. Slutligen är den naturliga sammanslagnings-lösningen för att skapa N att ta innehållet i file.txt vid R, så N är TRÄDSAMA till R men inte C. Sammanslagnings-incheckningen O och P är TRÄDSAMA till sina första föräldrar, men inte till sina andra föräldrar, Z respektive Y.

När standardläget används har både N och R en TRÄDSAMA-förälder, så dessa kanter genomgångna och de andra ignoreras. Den resulterande historikgrafen är:

	I---X

När man använder --full-history går Git runt på varje kant. Detta kommer att upptäcka incheckningar A och B och merge M, men kommer också att avslöja merge commits O och P. Med omskrivning av föräldern, blir den resulterande grafen:

	  .-A---M--------N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`--'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `------'

Här bidrar sammanslagnings-incheckningar O och P med extra brus, eftersom de faktiskt inte bidrog med någon ändring i file.txt. De slog bara samman ett ämne som baserades på en äldre version av file.txt. Detta är ett vanligt problem i förvar som använder ett arbetsflöde där många bidragsgivare arbetar parallellt och slog samman sina ämnesgrenar längs en enda stam: många orelaterade slog samman visas i --full-history-resultaten.

När man använder alternativet --simplify-merges försvinner incheckningar O och P från resultaten. Detta beror på att de omskrivna andra föräldrarna till O och P är nåbara från sina första föräldrar. Dessa kanter tas bort och då ser incheckningarna ut som ensamstående-förälder-incheckningar som är TRÄDSAMA som sin förälder. Detta händer även med incheckning N, vilket resulterar i en historikvy enligt följande:

	  .-A---M--.
	 /     /    \
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

I den här vyn, ser vi alla viktiga ensamstående-förälder förändringar från A, B och X. Vi ser också den noggrant lösta sammanslagningen M och den inte så noggrant lösta sammanslagningen R. Detta är vanligtvis tillräckligt med information för att avgöra varför incheckningar A och B "försvann" från historiken i standardvyn. Det finns dock några problem med den här metoden.

Det första problemet är prestanda. Till skillnad från tidigare alternativ kräver --simplify-merges att man går igenom hela inchecknings-historiken innan ett enda resultat returneras. Detta kan göra alternativet svårt att använda för mycket stora fövar.

Det andra problemet gäller granskning. När många bidragsgivare arbetar på samma förvar är det viktigt vilka sammanslagnings-incheckningar som introducerade en ändring i en viktig gren. Den problematiska sammanslagnings-incheckningen R ovan är sannolikt inte den sammanslagnings-incheckning som användes för att slå samman den med en viktig gren. Istället användes sammanslagnings-incheckningen N för att slå samman R och X med den viktiga grenen. Denna incheckning kan innehålla information om varför ändringen X åsidosatte ändringarna från A och B i sitt inchecknings-meddelande.

--show-pulls

Förutom de incheckningar som visas i standardhistoriken, visa varje sammanslagnings-incheckning som inte är TRÄDSAMA till sin första förälder men är TRÄDSAMA till en senare förälder.

När en sammanslagnings-incheckning inkluderas av --show-pulls, behandlas sammanslagnings-incheckningen som om den "hämtat" ändringen från en annan gren. När --show-pulls används i detta exempel (och inga andra alternativ) är den resulterande grafen:

	I---X---R---N

Här inkluderas sammanslagnings-incheckningar R och N eftersom de drog-in (pulled) incheckningar X respektive R till basgrenen. Dessa sammanslås är anledningen till att incheckningar A och B inte visas i standardhistoriken.

När --show-pulls paras ihop med --simplify-merges innehåller grafen all nödvändig information:

	  .-A---M--.   N
	 /     /    \ /
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

Observera att eftersom M kan nås från R, har gränsen från N till M förenklats bort. N visas dock fortfarande i historiken som en viktig incheckning eftersom den "drog in" (pulled) ändringen R i huvudgrenen.

Alternativet --simplify-by-decoration låter dig bara se den övergripande bilden av historikens topologi, genom att utelämna incheckningar som inte refereras till av taggar. Incheckningar markeras som !TRÄDSAMA (med andra ord, behålls efter historikförenklingsreglerna som beskrivs ovan) om (1) de refereras till av taggar, eller (2) de ändrar innehållet i sökvägarna som anges på kommandoraden. Alla andra incheckningar markeras som TRÄDSAMA (med förbehåll för att förenklas bort).

Inchecknings-ordning

Som standard, visas incheckningar i omvänd kronologisk ordning.

--date-order

Visa inga föräldrar innan alla dess barn visas, men annars visa incheckningar i inchecknings-tidsstämpelordningen.

--author-date-order

Visa inga föräldrar innan alla dess barn visas, men annars visa incheckningar i författar-tidsstämpel-ordning.

--topo-order

Visa inga föräldrar innan alla dess barn visas, och undvik att visa incheckningar på flera historikrader blandade.

Till exempel, i en inchecknings-historik som denna:

    ---1----2----4----7
	\	       \
	 3----5----6----8---

där siffrorna anger ordningen på tidsstämplarna för incheckningar, visar git rev-list och vänner med --date-order incheckningar i tidsstämpelordningen: 8 7 6 5 4 3 2 1.

Med --topo-order skulle de visa 8 6 5 3 7 4 2 1 (eller 8 7 4 2 6 5 3 1); vissa äldre incheckningar visas före nyare för att undvika att visa incheckningar från två parallella utvecklingsspår blandade.

--reverse

Skriv ut de incheckningar som valts att visas (se avsnittet Inchecknings-begränsningar ovan) i omvänd ordning. Kan inte kombineras med --walk-reflogs.

Objekt-traversering

Dessa alternativ är främst avsedda för packning av Git-förvar.

--no-walk[=(sorted|unsorted)]: Visa endast de givna incheckningar, men gå inte igenom deras förfäder. Detta har ingen effekt om ett intervall anges. Om argumentet unsorted anges visas incheckningar i den ordning de angavs på kommandoraden. Annars (om sorted eller inget argument angavs) visas incheckningar i omvänd kronologisk ordning efter inchecknings-tid. Kan inte kombineras med --graph.
--do-walk: Åsidosätter en tidigare --no-walk.

Inchecknings-formatering

--pretty[=<format>]

--format=<format>

Skriv ut innehållet i inchecknings-loggarna i ett givet format med en pretty-print, där <format> kan vara ett av följande: oneline, short, medium, full, fuller, reference, email, raw, format:<string> och tformat:<string>. När <format> inte är något av ovanstående, och innehåller %<placeholder>, fungerar det som om --pretty=tformat:<format> vore angivet.

Se avsnittet "VACKERT FORMAT" för ytterligare information om varje format. När =<format>-delen utelämnas används medium som standard.

Note	Du kan ange standardformatet för pretty i kodförråds-konfigurationen (se git-config[1]).

--abbrev-commit

Istället för att visa det fullständiga 40-byte hexadecimala inchecknings-objektnamnet, visa ett prefix som namnger objektet unikt. Alternativet --abbrev=<n> (som också modifierar diff-utdata, om det visas) kan användas för att ange prefixets minsta längd.

Detta borde göra --pretty=oneline mycket mer läsbar för personer som använder terminaler med 80 kolumner.

--no-abbrev-commit

Visa det fullständiga 40-byte hexadecimala inchecknings-objektnamnet. Detta negerar --abbrev-commit, antingen explicit eller underförstått av andra alternativ som --oneline. Det åsidosätter också variabeln log.abbrevCommit.

--oneline

Detta är en förkortning för --pretty=oneline --abbrev-commit som används tillsammans.

--encoding=<kodning>

Incheckning-objekt registrerar teckenkodningen som används för loggmeddelandet i deras kodnings-huvud; det här alternativet kan användas för att ange att kommandot ska koda om inchecknings-loggmeddelandet i den kodning som användaren föredrar. För icke-rörmokeri-kommandon är standardvärdet UTF-8. Observera att om ett objekt påstår sig vara kodat i X och vi matar ut i X, kommer vi att mata ut objektet ordagrant; det betyder att ogiltiga sekvenser i den ursprungliga commiten kan kopieras till utdata. På samma sätt, om iconv(3) misslyckas med att konvertera incheckningen, kommer vi att mata ut det ursprungliga objektet ordagrant i tysthet.

--expand-tabs=<n>

--expand-tabs

--no-expand-tabs

Utför en tabbexpandering (ersätt varje tabb med tillräckligt med mellanslag för att fylla till nästa visningskolumn som är en multipel av <n>) i loggmeddelandet innan det visas i utdata. --expand-tabs är en förkortning för --expand-tabs=8, och --no-expand-tabs är en förkortning för --expand-tabs=0, vilket inaktiverar tabbexpandering.

Som standard expanderas flikarna i snygga format som indenterar loggmeddelandet med 4 mellanslag (dvs. medium, som är standard, full och fuller).

--notes[=<ref>]

Visa anteckningarna (se git-notes[1]) som kommenterar incheckningen när inchecknings-loggmeddelandet visas. Detta är standardinställningen för kommandona git log, git show och git whatchanged när det inte finns något --pretty, --format eller --oneline-alternativ angivet på kommandoraden.

Som standard, är de anteckningar som visas från anteckningsreferenserna som listas i variablerna core.notesRef och notes.displayRef (eller motsvarande miljööverskridanden). Se git-config[1] för mer information.

Med ett valfritt argument <ref>, använd ref för att hitta de anteckningar som ska visas. Ref kan ange hela referensnamnet när det börjar med refs/notes/; när det börjar med notes/, prefixeras refs/ och annars refs/notes/ för att bilda referensens fullständiga namn.

Flera --notes-alternativ kan kombineras för att styra vilka anteckningar som visas. Exempel: "--notes=foo" visar endast anteckningar från refs/notes/foo; "--notes=foo --notes" visar både anteckningar från "refs/notes/foo" och från standardanteckningsreferenserna.

--no-notes

Visa inte anteckningar. Detta upphäver ovanstående alternativ --notes, genom att återställa listan över anteckningsreferenser från vilka anteckningar visas. Alternativ analyseras i den ordning som anges på kommandoraden, så t.ex. "--notes --notes=foo --no-notes --notes=bar" kommer bara att visa anteckningar från refs/notes/bar.

--show-notes-by-default

Visa standardanteckningarna om inte alternativ för att visa specifika anteckningar anges.

--show-notes[=<ref>]

--standard-notes

--no-standard-notes

Dessa alternativ är föråldrade. Använd alternativen --notes/--no-notes ovan istället.

--show-signature

Kontrollera giltigheten hos ett signerat inchecknings-objekt genom att skicka signaturen till gpg --verify och visa utdata.

--relative-date

Synonym för --date=relative.

--date=<format>

Only takes effect for dates shown in human-readable format, such as when using --pretty. log.date config variable sets a default value for the log command’s --date option. By default, dates are shown in the original time zone (either committer’s or author’s). If -local is appended to the format (e.g., iso-local), the user’s local time zone is used instead.

--date=relative visar datum i förhållande till aktuell tid, t.ex. “2 hours ago”. Alternativet -local har ingen effekt för --date=relative.

--date=local är ett alias för --date=default-local.

--date=iso (eller --date=iso8601) visar tidsstämplar i ett ISO 8601-liknande format. Skillnaderna mot det strikta ISO 8601-formatet är:

ett mellanslag istället för datum-/tidsavgränsaren T
ett mellanrum mellan tid och tidszon
inget kolon mellan timmar och minuter i tidszonen

--date=iso-strict (eller --date=iso8601-strict) visar tidsstämplar i strikt ISO 8601-format.

--date=rfc (eller --date=rfc2822) visar tidsstämplar i RFC 2822-format, som ofta finns i e-postmeddelanden.

--date=short visar bara datumet, men inte tiden, i formatet YYYY-MM-DD.

--date=raw visar datumet som sekunder sedan epoken (1970-01-01 00:00:00 UTC), följt av ett mellanslag, och sedan tidszonen som en förskjutning från UTC (ett + eller - med fyra siffror; de två första är timmar och de två andra är minuter). Dvs. som om tidsstämpeln formaterades med strftime("%s %z")). Observera att alternativet -local inte påverkar värdet sekunder-sedan-epoken (som alltid mäts i UTC), men ändrar det tillhörande tidszonvärdet.

--date=human visar tidszonen om tidszonen inte matchar den aktuella tidszonen, och skriver inte ut hela datumet om det matchar (dvs. hoppa över utskriften av år för datum som är "i år", men hoppar även över hela själva datumet om det är under de senaste dagarna och vi bara kan ange vilken veckodag det var). För äldre datum utelämnas också timme och minut.

--date=unix visar datumet som en Unix-epoktidsstämpel (sekunder sedan 1970). Precis som med --raw är detta alltid i UTC och därför har -local ingen effekt.

--date=format:<format> matar <format> till ditt system strftime, förutom %s, %z och %Z, som hanteras internt. Använd --date=format:%c för att visa datumet i ditt systemspråks föredragna format. Se manualen för strftime(3) för en komplett lista över formatplatshållare. När du använder -local är den korrekta syntaxen --date=format-local:<format>.

--date=default är standardformatet och baseras på ctime(3)-utdata. Det visar en enda rad med tre bokstäver för veckodag, tre bokstäver för månad, dag i månaden, timme-minut-sekunder i formatet "HH:MM:SS", följt av ett fyrsiffrigt årtal plus tidszoninformation, såvida inte den lokala tidszonen används, t.ex. Thu Jan 1 00:00:00 1970 +0000.

--parents

Skriv även ut föräldrarna till incheckningen (i formen "incheckning förälder…"). Möjliggör även omskrivning av föräldrar, se Historik-förenkling ovan.

--children

Skriv även ut barn till incheckning (i formen "incheckning barn…"). Möjliggör även omskrivning av överordnade filer, se Historikförenkling ovan.

--left-right

Markera vilken sida av en symmetrisk skillnad en incheckning är nåbar från. Incheckningar från vänster sida har prefixet < och de från höger med >. Om de kombineras med --boundary har dessa incheckningar prefixet -.

Till exempel, om du har denna topologi:

	     y---b---b  gren B
	    / \ /
	   /   .
	  /   / \
	 o---x---a---a  gren A

du skulle få en utdata som denna:

	$ git rev-list --left-right --boundary --pretty=oneline A...B

	>bbbbbbb... 3:a på b
	>bbbbbbb... 2:a på b
	<aaaaaaa... 3:a på a
	<aaaaaaa... 2:a på a
	-yyyyyyy... 1:a på b
	-xxxxxxx...1:a på a

--graph

Rita en textbaserad grafisk representation av inchecknings-historiken till vänster om utdata. Detta kan orsaka att extra rader skrivs ut mellan incheckningar, för att grafhistoriken ska kunna ritas korrekt. Kan inte kombineras med --no-walk.

Detta möjliggör förälder -omskrivning , se Historik-förenkling ovan.

Detta innebär att alternativet --topo-order är standard, men alternativet --date-order kan också anges.

--show-linear-break[=<barriär>]

När --graph inte används, plattas alla historikgrenar ut, vilket kan göra det svårt att se att de två på varandra följande incheckningar inte tillhör en linjär gren. Det här alternativet placerar en barriär mellan dem i så fall. Om <barrier> anges, är det strängen som visas istället för standardsträngen.

VACKRA FORMAT

Om incheckningen är en sammanslagning, och om vackra-formatet inte är oneline, email eller raw, infogas en extra rad före raden Author:. Denna rad börjar med "Merge:" och hasherna för föräldraincheckningar skrivs ut, separerade med mellanslag. Observera att de listade incheckningar inte nödvändigtvis är listan över de direkta föräldraincheckningarna om du har begränsat din historikvy: till exempel om du bara är intresserad av ändringar relaterade till en viss katalog eller fil.

Det finns flera inbyggda format, och du kan definiera ytterligare format genom att sätta ett pretty.<namn>-konfigurationsalternativ till antingen ett annat formatnamn eller en format:-sträng, enligt beskrivningen nedan (se git-config[1]). Här är detaljerna för de inbyggda formaten:

oneline
```
<hash> <titelrad>
```
Detta är utformat för att vara så kompakt som möjligt.

short

commit <hash>
Author: <författare>

<titelrad>

medium

commit <hash>
Author: <författare>
Date:   <författar-datum>

<titelrad>

<fullt-inchecknings-meddelande>

full

commit <hash>
Author: <författare>
Commit: <incheckare>

<titelrad>

<fullt-inchecknings-meddelande>

fuller

commit <hash>
Author:     <författare>
AuthorDate: <författar-datum>
Commit:     <incheckare>
CommitDate: <incheckare-datum>

<titelrad>

<fullt-inchecknings-meddelande>

reference
```
<förkortad-hash> (<titelrad>, <kort-författar-datum>)
```
Detta format används för att referera till en annan incheckning i ett inchecknings-meddelande och är detsamma som --pretty='format:%C(auto)%h (%s, %ad). Som standard formateras datumet med --date=short om inte ett annat --date-alternativ uttryckligen anges. Precis som med alla format: med formatplatshållare påverkas inte dess utdata av andra alternativ som --decorate och --walk-reflogs.

email

From <hash> <datum>
From: <författare>
Date: <författare-datum>
Subject: [PATCH] <titelrad>

<fullt-inchecknings-meddelande>

mboxrd

Som email, men rader i inchecknings-meddelandet som börjar med "From " (föregångna av noll eller fler ">") citeras med ">" så att de inte förväxlas med att starta en ny incheckning.
raw

raw-formatet visar hela incheckningen exakt så som den lagras i inchecknings-objektet. Det är värt att notera att hasherna visas i sin helhet, oavsett om --abbrev eller --no-abbrev används, och informationen i parents visar de verkliga föräldra-incheckningen, utan att ta hänsyn till grafts eller historikförenkling. Observera att detta format påverkar hur incheckningar visas, men inte hur diffen visas, t.ex. med git log --raw. För att få fullständiga objektnamn i ett rått diff-format, använd --no-abbrev.
format:<formatsträng>

Formatet format:<format-sträng> låter dig ange vilken information du vill visa. Det fungerar lite som printf-formatet, med det anmärkningsvärda undantaget att du får en nyrad med %n istället för \n.

T.ex., format:"Författaren till %h var %an, %ar%nTiteln var >>%s<<%n" skulle visa något liknande:
```
The author of fe6e0ee was Junio C Hamano, 23 hours ago
The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
```
Platshållarna är:
- Platshållare som expanderar till ett enda bokstavstecken:
  
  %n
  
  newline
  
  %%
  
  en rå %
  
  %x00
  
  %x följt av två hexadecimala siffror ersätts med en byte med de hexadecimala siffrornas värde (vi kommer att kalla detta "bokstavlig formateringskod" i resten av detta dokument).
- Platshållare som påverkar formateringen av senare platshållare:
  
  %Cred
  
  byt färg till röd
  
  %Cgreen
  
  byt färg till grönt
  
  %Cblue
  
  byt färg till blå
  
  %Creset
  
  återställ färg
  
  %C(<spec>)
  
  färgspecifikation, som beskrivs under Värden i avsnittet "KONFIGURATIONSFIL" i git-config[1]. Som standard, visas färger endast när de är aktiverade för loggutdata (av color.diff, color.ui eller --color, och med respekt för auto-inställningarna för den förra om vi går till en terminal). %C(auto,<spec>) accepteras som en historisk synonym för standardvärdet (t.ex. %C(auto,red)). Att ange %C(always,<spec>) kommer att visa färgerna även när färg inte är aktiverad på annat sätt (men överväg att bara använda --color=always för att aktivera färg för hela utdata, inklusive detta format och allt annat som git kan färga). Enbart auto (dvs. %C(auto)) kommer att aktivera automatisk färgning på nästa platshållare tills färgen byts igen.
  
  %m
  
  vänster (<), höger (>) eller gränsmärke (-)
  
  %w([<w>[,<i1>[,<i2>]]])
  
  växla radbrytning, som alternativet -w i git-shortlog[1].
  
  %<(<n>[,(trunc|ltrunc|mtrunc)])
  
  make the next placeholder take at least N column widths, padding spaces on the right if necessary. Optionally truncate (with ellipsis ..) at the left (ltrunc) ..ft, the middle (mtrunc) mi..le, or the end (trunc) rig.., if the output is longer than <n> columns. Note 1: that truncating only works correctly with <n> >= 2. Note 2: spaces around the <n> and <m> (see below) values are optional. Note 3: Emojis and other wide characters will take two display columns, which may over-run column boundaries. Note 4: decomposed character combining marks may be misplaced at padding boundaries.
  
  %<|(<m> )
  
  låt nästa platshållare ta minst fram till <m>:e visningskolumnen, fyll ut mellanslag till höger om det behövs. Använd negativa <m>-värden för kolumnpositioner mätt från terminalfönstrets högra kant.
  
  %>(<n>)
  
  %>|(<m>)
  
  liknar %<(<n>), %<|(<m>) respektive, men fyller ut mellanslag till vänster
  
  %>>(<n>)
  
  %>>|(<m>)
  
  liknande %>(<n>), %>|(<m>) respektive, förutom att om nästa platshållare tar fler mellanslag än angivet och det finns mellanslag till vänster om den, använd dessa mellanslag
  
  %><(<n>)
  
  %><|(<m>)
  
  liknar %<(<n>), %<|(<m>) respektive, men utfyllnad på båda sidor (dvs. texten centreras)
- Platshållare som expanderar till information som extraheras från incheckningen:
  %H
  
  incheckning hash
  
  %h
  
  förkortad inchecknings-hash
  
  %T
  
  trädhash
  
  %t
  
  förkortad trädhash
  
  %P
  
  förälder-hashkoder
  
  %p
  
  förkortade föräldra-hashkoder
  
  %an
  
  författarnamn
  
  %aN
  
  författarnamn (angående .mailmap, se git-shortlog[1] eller git-blame[1])
  
  %ae
  
  författarens e-postadress
  
  %aE
  
  författarens e-postadress (angående .mailmap, se git-shortlog[1] eller git-blame[1])
  
  %al
  
  författarens e-postadress lokal-del (delen före @-tecknet)
  
  %aL
  
  författarens lokala del (se %al) avseende .mailmap, se git-shortlog[1] eller git-blame[1])
  
  %ad
  
  författardatum (formatet respekterar --date= alternativet)
  
  %aD
  
  författardatum, RFC2822-stil
  
  %ar
  
  författardatum, relativ
  
  %at
  
  författardatum, UNIX-tidsstämpel
  
  %ai
  
  författardatum, ISO 8601-liknande format
  
  %aI
  
  författardatum, strikt ISO 8601-format
  
  %as
  
  författardatum, kortformat (ÅÅÅÅ-MM-DD)
  
  %ah
  
  författardatum, mänsklig stil (som alternativet --date=human i git-rev-list[1])
  
  %cn
  
  incheckare-namn
  
  %cN
  
  namn på incheckare (för .mailmap, se git-shortlog[1] eller git-blame[1])
  
  %ce
  
  e-postadress för incheckare
  
  %cE
  
  e-postadress för incheckare (respekterar .mailmap, se git-shortlog[1] eller git-blame[1])
  
  %cl
  
  e-postadress för incheckare lokal-del (delen före @-tecknet)
  
  %cL
  
  incheckare lokal-del (se %cl) respekterar .mailmap, se git-shortlog[1] eller git-blame[1])
  
  %cd
  
  incheckare-datum (formatet respekterar --date= alternativet)
  
  %cD
  
  incheckare-datum, RFC2822-stil
  
  %cr
  
  incheckare-datum, relativ
  
  %ct
  
  incheckare-datum, UNIX-tidsstämpel
  
  %ci
  
  incheckare-datum, ISO 8601-liknande format
  
  %cI
  
  incheckare-datum, strikt ISO 8601-format
  
  %cs
  
  incheckare-datum, kortformat (ÅÅÅÅ-MM-DD)
  
  %ch
  
  incheckare-datum, mänsklig stil (som alternativet --date=human i git-rev-list[1])
  
  %d
  
  referensnamn, som --decorate alternativet i git-log[1]
  
  %D
  
  referensnamn utan " (", ")" omslag.
  
  %(decorate[:<option>,...])
  
  referensnamn med anpassade dekorationer. Strängen decorate kan följas av ett kolon och noll eller fler kommaseparerade alternativ. Alternativvärden kan innehålla bokstavliga formateringskoder. Dessa måste användas för kommatecken (%x2C) och avslutande parenteser (%x29) på grund av deras roll i alternativsyntaxen.
  
  prefix=<värde>: Visas före listan med referensnamn. Standardvärdet är " (".
  
  suffix=<värde>: Visas efter listan med referensnamn. Standardvärdet är ")".
  
  separator=<värde>: Visas mellan referensnamn. Standardvärdet är ", ".
  
  pointer=<värde>: Visas mellan HEAD och grenen den pekar på, om någon. Standardinställningen är " → ".
  
  tag=<värde>: Visas före taggnamn. Standardinställningen är "tag: ".
Till exempel, för att skapa dekorationer utan radbrytning eller taggannoteringar, och med mellanslag som avgränsare:

%(decorate:prefix=,suffix=,tag=,separator= )
%(describe[:<option>,...])
human-readable name, like git-describe[1]; empty string for undescribable commits. The describe string may be followed by a colon and zero or more comma-separated options. Descriptions can be inconsistent when tags are added or removed at the same time.
tags[=<bool-value>]: Istället för att bara överväga kommenterade taggar, överväg även lättviktiga taggar.

abbrev=<nummer>: Istället för att använda standardantalet hexadecimala siffror (som varierar beroende på antalet objekt i förvaret med standardvärdet 7) för det förkortade objektnamnet, använd <nummer> siffror, eller så många siffror som behövs för att bilda ett unikt objektnamn.

match=<mönster>: Beakta endast taggar som matchar den givna glob(7) <mönster>, exklusive prefixet refs/tags/.

exclude=<mönster>: Beakta inte taggar som matchar det angivna glob(7) <mönster>, exklusive prefixet refs/tags/.
%S

referensnamnet som anges på kommandoraden genom vilket incheckningen nåddes (som git log --source), fungerar bara med git log

%e

kodning

%s

ämne

%f

sanerad ämnesrad, lämplig för ett filnamn

%b

kropp

%B

rå kropp (oförpackat motiv och kropp)

%N

inchecknings-anteckningar

%GG

rått verifieringsmeddelande från GPG för en signerad incheckning

%G?

visa "G" för en bra (giltig) signatur, "B" för en felaktig signatur, "U" för en bra signatur med okänd giltighetstid, "X" för en bra signatur som har gått ut, "Y" för en bra signatur gjord av en utgången nyckel, "R" för en bra signatur gjord av en återkallad nyckel, "E" om signaturen inte kan kontrolleras (t.ex. saknad nyckel) och "N" för ingen signatur

%GS

visa namnet på signeraren för en signerad incheckning

%GK

visa nyckeln som används för att signera en signerad incheckning

%GF

visa fingeravtrycket på nyckeln som används för att signera en signerad incheckning

%GP

visa fingeravtrycket för den primärnyckel vars undernyckel användes för att signera en signerad incheckning

%GT

visa förtroendenivån för nyckeln som används för att signera en signerad incheckning

%gD

reflog-väljare, t.ex. refs/stash@{1} eller refs/stash@{2 minutes ago}; formatet följer reglerna som beskrivs för alternativet -g. Delen före @ är refnamnet som det anges på kommandoraden (så git log -g refs/heads/master skulle ge refs/heads/master@{0}).

%gd

förkortad reflog-väljare; samma som %gD, men refname-delen är förkortad för mänsklig läsbarhet (så refs/heads/master blir bara master).

%gn

reflog-identitets namn

%gN

namn på reflog-identitet (för .mailmap, se git-shortlog[1] eller git-blame[1])

%ge

reflog-identitet e-postadress

%gE

reflog-identitet e-postadress (respekterar .mailmap, se git-shortlog[1] eller git-blame[1])

%gs

reflog ämne

%(trailers[:<alternativ>,...])
visa släprad för brödtexten så som de tolkas av git-interpret-trailers[1]. Strängen trailers kan följas av ett kolon och noll eller fler kommaseparerade alternativ. Om något alternativ anges flera gånger vinner den sista förekomsten.
key=<key>: visar endast släprad med angiven <key>. Matchning sker utan att skiftläges-känsligt och avslutande kolon är valfritt. Om alternativet anges flera gånger visas släprader som matchar någon av nycklarna. Detta alternativ aktiverar automatiskt alternativet only så att icke-släprader i släp-blocket döljs. Om det inte önskas kan det inaktiveras med only=false. T.ex. visar %(trailers:key=Reviewed-by) trailerrader med nyckeln Reviewed-by.

only[=<bool>]: välj om icke-släprader från trailerblocket ska inkluderas.

separator=<sep>: anger avgränsaren som infogas mellan släprader. Standardinställningen är ett radmatningstecken. Strängen <sep> kan innehålla de bokstavliga formateringskoder som beskrivs ovan. För att använda kommatecken som avgränsare måste man använda %x2C eftersom det annars skulle tolkas som nästa alternativ. T.ex. visar %(trailers:key=Ticket,separator=%x2C) alla släprader vars nyckel är "Ticket" avgränsade med ett kommatecken och ett mellanslag.

unfold[=<bool>]: gör att det beter sig som om tolka-släpraders --unfold-alternativ var angivet. T.ex., %(trailers:only,unfold=true) vecklar ut och visar alla släprader.

keyonly[=<bool>]: visar endast den viktigaste delen av släpraden.

valueonly[=<bool>]: visar endast värdedelen av släprad.

key_value_separator=<sep>: anger avgränsaren som infogas mellan nyckeln och värdet för varje trailer. Standardvärdet är ": ". Annars delar den samma semantik som separator=<sep> ovan.

Note

Vissa platshållare kan vara beroende av andra alternativ som ges till revisionsgenomgångsmotorn. Till exempel kommer reflog-alternativen %g* att infoga en tom sträng om vi inte går igenom reflog-poster (t.ex. med git log -g). Platshållarna %d och %D kommer att använda det "korta" dekorationsformatet om --decorate inte redan angavs på kommandoraden.

De booleska alternativen accepterar ett valfritt värde [=<bool-value>]. Värdena som tas av --type=bool git-config[1], som yes och off, accepteras alla. Att ge ett booleskt alternativ utan =<värde> är liktydigt med att ge det med =true.

Om du lägger till ett + (plustecken) efter % för en platshållare infogas en radmatning omedelbart före expansionen om och endast om platshållaren expanderar till en sträng som inte är tom.

Om du lägger till ett - (minustecken) efter % för en platshållare, raderas alla radmatningar omedelbart före expansionen om och endast om platshållaren expanderar till en tom sträng.

Om du lägger till ett (mellanslag) efter % av en platshållare, infogas ett mellanslag omedelbart före expansionen om och endast om platshållaren expanderar till en sträng som inte är tom.

tformat:

Formatet tformat: fungerar precis som format:, förutom att det tillhandahåller "terminator"-semantik istället för "separator"-semantik. Med andra ord, varje commit har meddelandets terminatorteckne (vanligtvis en nyrad) tillagt, snarare än en avgränsare placerad mellan poster. Detta innebär att den sista posten i ett enradigt format avslutas korrekt med en ny rad, precis som formatet "enradigt" gör. Till exempel:
```
$ git log -2 --pretty=format:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973 -- NO NEWLINE

$ git log -2 --pretty=tformat:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973
```
Dessutom, tolkas alla okända strängar som innehåller % som om de har tformat: framför sig. Till exempel är dessa två likvärdiga:
```
$ git log -2 --pretty=tformat:%h 4da45bef
$ git log -2 --pretty=%h 4da45bef
```

DIFF-FORMATERING

Som standard, genererar git log ingen diff-utdata. Alternativen nedan kan användas för att visa ändringarna som gjorts av varje incheckning.

Observera att om inte någon av varianterna av --diff-merges (inklusive korta -m, -c, --cc och --dd) uttryckligen anges, kommer sammanslagnings-incheckningar inte att visa en diff, även om ett diff-format som --patch är valt, och de kommer inte heller att matcha sökalternativ som -S. Undantaget är när --first-parent används, i vilket fall first-parent är standardformatet för merge-commits.

-p

-u

--patch

Generera patch (se Generera patchtext med -p).

-s

--no-patch

Undertryck all utdata från diff-maskineriet. Användbart för kommandon som git show som visar patchen som standard för att undertrycka deras utdata, eller för att avbryta effekten av alternativ som --patch, --stat tidigare på kommandoraden i ett alias.

-m

Visa differenser för sammanslagings-incheckningar i standardformatet. Detta liknar --diff-merges=on, förutom att -m inte kommer att producera någon utdata om inte -p också anges.

-c

Producera kombinerad diff-utdata för sammanslagings-incheckningar. Genväg för --diff-merges=combined -p.

--cc

Producera tät kombinerad diff-utdata för sammanslagnings-incheckningar. Genväg för --diff-merges=dense-combined -p.

--dd

Skapa diff med avseende på första föräldern för både sammanslå- och reguljära incheckningar. Genväg för --diff-merges=first-parent -p.

--remerge-diff

Producera remerge-diff utdata för sammanslagnings-incheckningar. Genväg för --diff-merges=remerge -p.

--no-diff-merges

Synonym för --diff-merges=off.

--diff-merges=<format>

Ange diff-formatet som ska användas för sammanslagnings-incheckningar. Standardinställningen är `off` om inte --first-parent används, i vilket fall first-parent är standardinställningen.

Följande format stöds:

off
none: Inaktivera utdata för diffs för sammanslagnings-incheckningar. Användbart för att åsidosätta implicita värden.
on
m: Gör diff-utdata för sammanslagnings-incheckningar så att de visas i standardformatet. Standardformatet kan ändras med hjälp av konfigurationsvariabeln log.diffMerges, vars standardvärde är separate.
first-parent
1: Visa fullständig skillnad med avseende på första föräldern. Detta är samma format som --patch producerar för icke-sammanslagna incheckningar.
separate: Visa fullständig differens med avseende på varje förälder. Separat loggpost och differens genereras för varje förälder.
combined
c: Visa skillnader från varje förälder till sammanslagningsresultatet samtidigt istället för att visa parvisa skillnader mellan en förälder och resultatet en i taget. Dessutom listas endast filer som har ändrats från alla föräldrar.
dense-combined
cc: Komprimera ytterligare utdata som produceras av --diff-merges=combined genom att utelämna ointressanta stycken vars innehåll i föräldrarna bara har två varianter och sammanslagningsresultatet väljer en av dem utan modifiering.
remerge
r: Återsammanfoga två-föräldra sammanslagnings-incheckningar för att skapa ett temporärt trädobjekt – potentiellt innehållande filer med konfliktmarkörer och liknande. En skillnad visas sedan mellan det temporära trädet och den faktiska sammanslagnings-incheckningen.

Utdata som genereras när detta alternativ används kan komma att ändras, och detsamma gäller dess interaktion med andra alternativ (såvida det inte uttryckligen dokumenterats).

--combined-all-paths

Gör att kombinerade diffs (används försammanslagnings-incheckningar) listar namnet på filen från alla föräldrar. Det har således bara effekt när --diff-merges=[dense-]combined används, och är sannolikt bara användbart om filnamnsändringar upptäcks (dvs. när antingen namnbyte eller kopieringsdetektering har begärts).

-U<n>

--unified=<n>

Generera skillnader med <n> kontextrader istället för de vanliga tre. implicerar --patch.

--output=<fil>

Utdata till en specifik fil istället för stdout.

--output-indicator-new=<tecken>

--output-indicator-old=<tecken>

--output-indicator-context=<tecken>

Ange tecknet som används för att indikera nya, gamla eller kontextuella rader i den genererade patchen. Normalt är de +, - respektive ' '.

--raw

För varje incheckning, visa en sammanfattning av ändringarna med hjälp av raw diff -formatet. Se avsnittet "RÅTTUTGÅNGSFORMAT" i git-diff[1]. Detta skiljer sig från att visa själva loggen i råformat, vilket du kan uppnå med --format=raw.

--patch-with-raw

Synonym till -p --raw.

-t

Visa trädobjekten i diff-utdata.

--indent-heuristic

Aktivera heuristiken som flyttar olika styckesgränser för att göra patchar lättare att läsa. Detta är standardinställningen.

--no-indent-heuristic

Inaktivera indenteringsheuristiken.

--minimal

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

--patience

Generera en diff med algoritmen "patience diff".

--histogram

Generera en diff med algoritmen "histogram diff".

--anchored=<text>

Generera en diff med algoritmen "anchored diff".

Det här alternativet kan anges mer än en gång.

Om en rad finns i både käll- och destinationsraden, bara finns en gång och börjar med <text>, försöker den här algoritmen förhindra att den visas som en borttagning eller tillägg i utdata. Den använder algoritmen "patience diff" internt.

--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.

--stat[=<bredd>[,<namn-bredd>[,<antal>]]

Generera en diffstat. Som standard används så mycket utrymme som behövs för filnamnsdelen och resten för grafdelen. Maximal bredd är som standard terminalbredd, eller 80 kolumner om den inte är ansluten till en terminal, och kan åsidosättas av <bredd>. Bredden på filnamnsdelen kan begränsas genom att ge en annan bredd <namnbredd> efter ett kommatecken eller genom att ställa in diff.statNameWidth=<namnbredd>. Bredden på grafdelen kan begränsas genom att använda --stat-graph-width=<grafbredd> eller genom att ställa in diff.statGraphWidth=<grafbredd>. Att använda --stat eller --stat-graph-width påverkar alla kommandon som genererar en statistisk graf, medan att ställa in diff.statNameWidth eller diff.statGraphWidth inte påverkar git format-patch. Genom att ange en tredje parameter <count> kan du begränsa utdata till de första <count> raderna, följt av ... om det finns fler.

Dessa parametrar kan också ställas in individuellt med --stat-width=<bredd>, --stat-name-width=<namn-bredd> och --stat-count=<antal>.

--compact-summary

Skriv ut en komprimerad sammanfattning av utökad huvud-information, såsom skapande eller borttagning av filer ("ny" eller "borta", valfritt +l om det är en symbolisk länk) och lägesändringar (+x eller -x för att lägga till respektive ta bort en körbar bit) i diffstat. Informationen placeras mellan filnamnsdelen och grafdelen. Innebär --stat.

--numstat

Liknar --stat, men visar antalet tillagda och borttagna rader i decimalnotation och sökväg utan förkortning, för att göra det mer maskinvänligt. För binära filer matas två - ut istället för att säga 0 0.

--shortstat

Skriv endast ut den sista raden i formatet --stat som innehåller det totala antalet ändrade filer, samt antalet tillagda och borttagna rader.

-X [<param>,...]

--dirstat[=<param>,...]

Visar fördelningen av den relativa mängden ändringar för varje underkatalog. Beteendet för --dirstat kan anpassas genom att skicka en kommaseparerad lista med parametrar. Standardvärdena styrs av konfigurationsvariabeln diff.dirstat (se git-config[1]). Följande parametrar är tillgängliga:

changes: Beräkna dirstat-talen genom att räkna raderna som har tagits bort från källan eller lagts till i destinationen. Detta ignorerar mängden rena kodförflyttningar inom en fil. Med andra ord räknas inte omarrangemang av rader i en fil lika mycket som andra ändringar. Detta är standardbeteendet när ingen parameter anges.
lines: Beräkna dirstat-talen genom att göra den vanliga radbaserade diff-analysen och summera antalet borttagna/tillagda rader. (För binära filer, räkna istället 64-byte-block, eftersom binära filer inte har något naturligt koncept för rader). Detta är ett dyrare --dirstat-beteende än changes-beteendet, men det räknar omordnade rader i en fil lika mycket som andra ändringar. Den resulterande utdata överensstämmer med vad du får från de andra --*stat-alternativen.
files: Beräkna dirstat-talen genom att räkna antalet ändrade filer. Varje ändrad fil räknas lika i dirstat-analysen. Detta är det beräkningsmässigt billigaste beteendet för --dirstat, eftersom det inte behöver titta på filinnehållet alls.
cumulative: Count changes in a child directory for the parent directory as well. Note that when using cumulative, the sum of the percentages reported may exceed 100%. The default (non-cumulative) behavior can be specified with the noncumulative parameter.
<gränsvärde>: En heltalsparameter anger en gränsvärde i procent (3 % som standard). Kataloger som bidrar med mindre än denna procentandel av ändringarna visas inte i utdata.

Exempel: Följande räknar ändrade filer, ignorerar kataloger med mindre än 10 % av den totala mängden ändrade filer och ackumulerar antal underkataloger i överordnade kataloger: --dirstat=files,10,cumulative.

--cumulative

Synonym för --dirstat=cumulative.

--dirstat-by-file[=<param>,...]

Synonym för --dirstat=files,<param>,....

--summary

Skriv ut en komprimerad sammanfattning av utökad huvud-information, såsom skapanden, namnbyten och läges-ändringar.

--patch-with-stat

Synonym till -p --stat.

-z

Separera incheckningar med NUL istället för newlines.

Also, when --raw or --numstat has been given, do not munge pathnames and use NULs as output field terminators.

Utan detta alternativ, citeras sökvägar med "ovanliga" tecken enligt beskrivningen för konfigurationsvariabeln core.quotePath (se git-config[1]).

--name-only

Visa endast namnet på varje ändrad fil i trädet efter avbildningen. Filnamnen är ofta kodade i UTF-8. För mer information, se diskussionen om kodning på manualsidan för git-log[1].

--name-status

Visa endast namn och status för varje ändrad fil. Se beskrivningen av alternativet --diff-filter för information om vad statusbokstäverna betyder. Precis som --name-only är filnamnen ofta kodade i UTF-8.

--submodule[=<format>]

Ange hur skillnader i undermoduler visas. När --submodule=short anges används formatet short. Detta format visar bara namnen på incheckningar i början och slutet av intervallet. När --submodule eller --submodule=log anges används formatet log. Detta format listar incheckningar i intervallet, precis som git-submodule[1] summary gör. När --submodule=diff anges används formatet diff. Detta format visar en inline-diff av ändringarna i undermodulinnehållet mellan inchecknings-intervallet. Standardinställningen är diff.submodule eller formatet short om konfigurationsalternativet inte är inställt.

--color[=<när>]

Visa färglagd skillnad. --color (dvs. utan =<när>) är samma sak som --color=always. <när> kan vara en av always, aldrig eller auto.

--no-color

Stäng av färgad diff. Det är samma sak som --color=never.

--color-moved[=<läge>]

Flyttade kodrader färgas annorlunda. Standardvärdet för <läge> är no om alternativet inte anges och zebra om alternativet utan läge anges. Läget måste vara ett av:

no: Flyttade linjer markeras inte.
default: Är en synonym för "zebra". Detta kan komma att ändras till ett mer förnuftigt läge i framtiden.
plain: Alla rader som läggs till på en plats och togs bort på en annan plats kommer att färgas med color.diff.newMoved. På liknande sätt kommer color.diff.oldMoved att användas för borttagna rader som läggs till någon annanstans i diff-filen. Det här läget plockar upp alla flyttade rader, men det är inte särskilt användbart i en granskning för att avgöra om ett kodblock flyttades utan permutation.
blocks: Block med flyttad text på minst 20 alfanumeriska tecken upptäcks snabbt. De upptäckta blocken målas med antingen färgen color.diff.(old|new)Moved. Intilliggande block kan inte skiljas åt.
zebra: Block med flyttad text detekteras som i blocks-läge. Blocken målas med antingen färgen color.diff.(old|new)Moved eller color.diff.(old|new)MovedAlternative. Växlingen mellan de två färgerna indikerar att ett nytt block har detekterats.
dimmed-zebra: Liknar zebra, men ytterligare nedtoning av ointressanta delar av flyttad kod utförs. Gränslinjerna för två intilliggande block anses intressanta, resten är ointressant. dimmed_zebra är en föråldrad synonym.

--no-color-moved

Stäng av rörelsedetektering. Detta kan användas för att åsidosätta konfigurationsinställningar. Det är samma sak som --color-moved=no.

--color-moved-ws=<läge>,...

Detta konfigurerar hur blanksteg ignoreras när rörelsedetektering utförs för --color-moved. Dessa lägen kan anges som en kommaseparerad lista:

no: Ignorera inte blanksteg när du utför rörelsedetektering.
ignore-space-at-eol: Ignorera ändringar i blanktecken vid radslut.
ignore-space-change: Ignorera ändringar i mängden blanktecken. Detta ignorerar blanktecken i radslutet och betraktar alla andra sekvenser av ett eller flera mellanslagstecken som likvärdiga.
ignore-all-space: Ignorera blanktecken när du jämför rader. Detta ignorerar skillnader även om en rad har blanktecken medan den andra raden inte har något.
allow-indentation-change: Ignorera först eventuella blanksteg i flyttdetekteringen, gruppera sedan de flyttade kodblocken endast i ett block om ändringen i blanksteg är densamma per rad. Detta är inkompatibelt med de andra lägena.

--no-color-moved-ws

Ignorera inte blanksteg när du utför rörelsedetektering. Detta kan användas för att åsidosätta konfigurationsinställningar. Det är samma sak som --color-moved-ws=no.

--word-diff[=<läge>]

Som standard avgränsas ord med blanksteg; se --word-diff-regex nedan. <läge> har som standard plain och måste vara en av:

color: Markera ändrade ord med endast färger. Innebär --color.
plain: Visar ord som [-borttagen-] och {tillagd}. Gör inga försök att ta escape avgränsare om de förekommer i indata, så utdata kan vara tvetydig.
porcelain: Använd ett speciellt radbaserat format avsett för skriptanvändning. Tillagda/borttagna/oändrade körningar skrivs ut i det vanliga enhetliga diff-formatet, med början med ett +/-/` -tecknet i början av raden och sträcker sig till slutet av raden. Nya rader i inmatningen representeras av en tilde `~ på en egen rad.
none: Inaktivera orddiff igen.

Observera att trots namnet på det första läget, används färg för att markera de ändrade delarna i alla lägen om det är aktiverat.

--word-diff-regex=<regex>

Använd <regex> för att avgöra vad ett ord är, istället för att betrakta sträckor av icke-blanksteg som ett ord. Innebär även --word-diff om det inte redan var aktiverat.

Varje icke-överlappande matchning av <regex> betraktas som ett ord. Allt mellan dessa matchningar betraktas som blanktecken och ignoreras(!) i syfte att hitta skillnader. Du kanske vill lägga till |[^[:space:]] i ditt reguljära uttryck för att se till att det matchar alla tecken som inte är blanktecken. En matchning som innehåller en nyrad avkortas tyst(!) vid nyradslinjen.

Till exempel kommer --word-diff-regex=. att behandla varje tecken som ett ord och, på motsvarande sätt, visa skillnader tecken för tecken.

Regex-funktionen kan också ställas in via en diff-drivrutin eller ett konfigurationsalternativ, se gitattributes[5] eller git-config[1]. Om du anger den explicit åsidosätts alla diff-drivrutiner eller konfigurationsinställningar. Diff-drivrutiner åsidosätter konfigurationsinställningar.

--color-words[=<regex>]

Motsvarande --word-diff=color plus (om ett regex angavs) --word-diff-regex=<regex>.

--no-renames

Stäng av namnbytesdetektering, även när konfigurationsfilen anger standardinställningen för det.

--rename-empty

--no-rename-empty

Huruvida tomma blobbar ska användas som namnbyteskälla.

--check

Varna om ändringar introducerar konfliktmarkörer eller blankteckenfel. Vad som anses vara blankteckenfel styrs av konfigurationen av core.whitespace. Som standard betraktas efterföljande blanktecken (inklusive rader som enbart består av blanktecken) och ett mellanslagstecken som omedelbart följs av ett tabbtecken inuti radens första indrag som blankteckenfel. Avslutas med status som inte är noll om problem upptäcks. Inte kompatibel med --exit-code.

--ws-error-highlight=<slag>

Markera blankteckenfel i raderna context, old eller new i diff-filen. Flera värden separeras med kommatecken, none återställer tidigare värden, default återställer listan till new och all är en förkortning för old,new,context. När detta alternativ inte anges och konfigurationsvariabeln diff.wsErrorHighlight inte är angiven, markeras endast blankteckenfel i raderna new. Blankteckenfelen är färgade med color.diff.whitespace.

--full-index

Istället för de första tecknen, visa de fullständiga namnen på blob-objekten före och efter avbildningen på "index"-raden när du genererar utdata för patch-format.

--binary

Förutom --full-index, mata ut en binär diff som kan tillämpas med git-apply. implicerar --patch.

--abbrev[=<n>]

Istället för att visa det fullständiga 40-byte hexadecimala objektnamnet i utdata i diff-raw-format och diff-tree-huvud-rader, visa det kortaste prefixet som är minst <n> hexdigits långt och som unikt refererar till objektet. I diff-patch-utdataformat har --full-index högre prioritet, d.v.s. om --full-index anges kommer fullständiga blobnamn att visas oavsett --abbrev. Antal siffror som inte är standard kan anges med --abbrev=<n>.

-B[<n>][/<m>]

--break-rewrites[=[<n>][/<m>]]

Dela upp fullständiga omskrivningsändringar i par av radera och skapa. Detta tjänar två syften:

Det påverkar hur en förändring som innebär en total omskrivning av en fil, inte som en serie borttagningar och infogningar blandade med ett fåtal rader som råkar matcha textuellt som kontexten, utan som en enda borttagning av allt gammalt följt av en enda infogning av allt nytt, och siffran <m> styr denna aspekt av -B-alternativet (standard är 60%). -B/70% anger att mindre än 30% av originalet ska finnas kvar i resultatet för att Git ska betrakta det som en total omskrivning (dvs. annars kommer den resulterande patchen att vara en serie borttagningar och infogningar blandade med kontextrader).

När den används med -M betraktas även en helt omskriven fil som källa till ett namnbyte (vanligtvis betraktar -M bara en fil som försvunnit som källa till ett namnbyte), och siffran <n> styr denna aspekt av alternativet -B (standard är 50%). -B20% anger att en ändring med tillägg och borttagning jämfört med 20% eller mer av filens storlek är berättigad att plockas upp som en möjlig källa till ett namnbyte till en annan fil.

-M[<n>]

--find-renames[=<n>]

Om du genererar diffs, upptäck och rapportera namnbyten för varje . incheckning För att följa filer över namnbyten medan du går igenom historiken, se --follow. Om <n> anges, är det ett tröskelvärde för likhetsindexet (dvs. mängden tillägg/borttagningar jämfört med filens storlek). Till exempel betyder -M90% att Git ska betrakta ett borttagnings-/tilläggspar som ett namnbyte om mer än 90 % av filen inte har ändrats. Utan ett %-tecken ska talet läsas som ett bråktral, med ett decimaltecken före. Dvs. -M5 blir 0,5 och är således detsamma som -M50%. På liknande sätt är -M05 detsamma som -M5%. För att begränsa detekteringen till exakta namnbyten, använd -M100%. Standardlikhetsindexet är 50 %.

-C[<n>]

--find-copies[=<n>]

Identifiera kopior såväl som byt namn. Se även --find-copies-harder. Om <n> anges har det samma betydelse som för -M<n>.

--find-copies-harder

Av prestandaskäl hittar -C-alternativet som standard bara kopior om originalfilen för kopian ändrades i samma ändringsuppsättning. Denna flagga gör att kommandot inspekterar omodifierade filer som kandidater för kopians källa. Detta är en mycket dyr operation för stora projekt, så använd den med försiktighet. Att ge mer än ett -C-alternativ har samma effekt.

-D

--irreversible-delete

Utelämna preimage för borttagningar, d.v.s. skriv bara ut huvudet men inte skillnaden mellan preimage och /dev/null. Den resulterande patchen är inte avsedd att tillämpas med patch eller git apply; detta är enbart för personer som bara vill koncentrera sig på att granska texten efter ändringen. Dessutom saknar utdata uppenbarligen tillräckligt med information för att tillämpa en sådan patch i omvänd ordning, även manuellt, därav namnet på alternativet.

När det används tillsammans med -B, utelämna även förbilden i borttagningsdelen av ett borttagnings-/skaparpar.

-l<num>

Alternativen -M och -C involverar några preliminära steg som kan upptäcka delmängder av namnbyten/kopior billigt, följt av en uttömmande reservdel som jämför alla återstående oparade destinationer med alla relevanta källor. (För namnbyten är endast återstående oparade källor relevanta; för kopior är alla originalkällor relevanta.) För N källor och destinationer är denna uttömmande kontroll O(N^2). Detta alternativ förhindrar att den uttömmande delen av namnbytes-/kopieringsdetektering körs om antalet inblandade käll-/destinationsfiler överstiger det angivna antalet. Standardvärdet är diff.renameLimit. Observera att värdet 0 behandlas som obegränsat.

--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]

Markera endast filer som är Tillagda (A), Kopierade (C), Borttagna (D), Modifierade (M), Omdöpta (R), har sin typ (dvs. vanlig fil, symlänk, undermodul, …) ändrad (T), är Osammanslagna (U), är Okända (X) eller har fått sin parning Bruten (B). Vilken kombination som helst av filtertecknen (inklusive inga) kan användas. När * (Allt-eller-inget) läggs till i kombinationen markeras alla sökvägar om det finns någon fil som matchar andra kriterier i jämförelsen; om det inte finns någon fil som matchar andra kriterier markeras ingenting.

Även, dessa versaler kan ändras till gemener för att exkludera. T.ex. exkluderar --diff-filter=ad tillagda och borttagna sökvägar.

Observera att inte alla diffs kan innehålla alla typer. Till exempel kan kopierade och omdöpta poster inte visas om detektering för dessa typer är inaktiverat.

-S<sträng>

Leta efter skillnader som ändrar antalet förekomster av den angivna <sträng> (dvs. tillägg/borttagning) i en fil. Avsedd för skriptutvecklarens bruk.

Det är användbart när du letar efter ett exakt kodblock (som en struktur) och vill veta blockets historia sedan det först kom till: använd funktionen iterativt för att mata in det intressanta blocket i föravbildningen tillbaka till -S och fortsätt tills du får den allra första versionen av blocket.

Binära filer genomsöks också.

-G<regex>

Leta efter skillnader vars patchtext innehåller tillagda/borttagna rader som matchar <regex>.

För att illustrera skillnaden mellan -S<regex> --pickaxe-regex och -G<regex>, betrakta en incheckning med följande diff i samma fil:

+    return frotz(nitfol, two->ptr, 1, 0);
...
-    hit = frotz(nitfol, mf2.ptr, 1, 0);

Medan git log -G"frotz\(nitfol" visar denna incheckning, gör git log -S"frotz\(nitfol" --pickaxe-regex inte det (eftersom antalet förekomster av den strängen inte ändrades).

Om inte --text anges kommer patchar av binära filer utan ett textconv-filter att ignoreras.

Se posten pickaxe i gitdiffcore[7] för mer information.

--find-object=<objekt-id>

Leta efter skillnader som ändrar antalet förekomster av det angivna objektet. I likhet med -S är det bara argumentet som skiljer sig genom att det inte söker efter en specifik sträng utan efter ett specifikt objekt-id.

Objektet kan vara en blob eller en undermodul-incheckning. Det innebär att -t-alternativet i git-log också kan hitta träd.

--pickaxe-all

När -S eller -G hittar en ändring, visa alla ändringar i den ändringsmängden, inte bara de filer som innehåller ändringen i <sträng>.

--pickaxe-regex

Behandla <sträng> som ges till -S som ett utökat POSIX-reguljärt uttryck som matchar.

-O<ordingsfil>

Styr ordningen i vilka filer visas i utdata. Detta åsidosätter konfigurationsvariabeln diff.orderFile (se git-config[1]). För att avbryta diff.orderFile, använd -O/dev/null.

Utmatningsordningen bestäms av ordningen på glob-mönstren i <ordingsfil>. Alla filer med sökvägar som matchar det första mönstret matas ut först, alla filer med sökvägar som matchar det andra mönstret (men inte det första) matas ut härnäst, och så vidare. Alla filer med sökvägar som inte matchar något mönster matas ut sist, som om det fanns ett implicit match-all-mönster i slutet av filen. Om flera sökvägar har samma rangordning (de matchar samma mönster men inga tidigare mönster), är deras utmatningsordning i förhållande till varandra den normala ordningen.

<ordingsfil> tolkas enligt följande:

Tomma rader ignoreras, så de kan användas som avgränsare för läsbarhet.
Rader som börjar med en hash ("#") ignoreras, så de kan användas för kommentarer. Lägg till ett bakåtsnedstreck ("\") i början av mönstret om det börjar med en hash.
Varje annan rad innehåller ett enda mönster.

Mönster har samma syntax och semantik som mönster som används för fnmatch(3) utan FNM_PATHNAME-flaggan, förutom att ett sökvägsnamn också matchar ett mönster om borttagning av ett antal av de slutliga sökvägsnamnskomponenterna matchar mönstret. Till exempel matchar mönstret "foo*bar" "fooasdfbar" och "foo/bar/baz/asdf" men inte "foobarx".

--skip-to=<fil>

--rotate-to=<fil>

Släng filerna före den namngivna <fil> från utdata (dvs. hoppa till), eller flytta dem till slutet av utdata (dvs. rotera till). Dessa alternativ uppfanns främst för användning av git difftool-kommandot, och kanske inte är särskilt användbara annars.

-R

Växla två indata; det vill säga visa skillnader mellan index eller fil på disk och trädinnehåll.

--relative[=<sökväg>]

--no-relative

När den körs från en underkatalog till projektet kan den få instruktioner att exkludera ändringar utanför katalogen och visa sökvägar relativa till den med detta alternativ. När du inte befinner dig i en underkatalog (t.ex. i ett bart arkiv) kan du namnge vilken underkatalog som utdata ska vara relativ till genom att ange <sökväg> som argument. --no-relative kan användas för att ångra både konfigurationsalternativet diff.relative och föregående --relative.

-a

--text

Hantera alla filer som text.

--ignore-cr-at-eol

Ignorera vagnretur i slutet av raden vid en jämförelse.

--ignore-space-at-eol

Ignorera ändringar i blanktecken vid radslut.

-b

--ignore-space-change

Ignorera ändringar i mängden blanktecken. Detta ignorerar blanktecken i radslutet och betraktar alla andra sekvenser av ett eller flera mellanslagstecken som likvärdiga.

-w

--ignore-all-space

Ignorera blanktecken när du jämför rader. Detta ignorerar skillnader även om en rad har blanktecken medan den andra raden inte har något.

--ignore-blank-lines

Ignorera ändringar i rader som är helt blanka.

-I<regex>

--ignore-matching-lines=<regex>

Ignorera ändringar vars alla rader matchar <regex>. Det här alternativet kan anges mer än en gång.

--inter-hunk-context=<nummer>

Visar sammanhanget mellan olika stycken, upp till det angivna <antal> rader, och sammanfogar därmed stycken som ligger nära varandra. Standardvärdet är diff.interHunkContext eller 0 om konfigurationsalternativet inte är inställt.

-W

--function-context

Visa hela funktionen som kontextrader för varje ändring. Funktionsnamnen bestäms på samma sätt som git diff räknar ut patch-hunk-huvuden (se "Definiera en anpassad styckes-huvud" i gitattributes[5]).

--ext-diff

Tillåt att en extern diff-hjälp körs. Om du ställer in en extern diff-drivrutin med gitattributes[5], måste du använda den här alternativet med git-log[1] och vänner.

--no-ext-diff

Tillåt inte externa diff-drivrutiner.

--textconv

--no-textconv

Tillåt (eller förbjud) att externa textkonverteringsfilter körs vid jämförelse av binära filer. Se gitattributes[5] för mer information. Eftersom textconv-filter vanligtvis är en envägskonvertering är den resulterande diff-funktionen lämplig för mänsklig konsumtion, men kan inte tillämpas. Av denna anledning är textconv-filter som standard endast aktiverade för git-diff[1] och git-log[1], men inte för git-format-patch[1] eller diff rörmokeri-kommandon.

--ignore-submodules[=(none|untracked|dirty|all)]

Ignorera ändringar i undermoduler i diff-genereringen. all är standardinställningen. Om none används betraktas undermodulen som modifierad när den antingen innehåller ospårade eller modifierade filer, eller om dess HEAD skiljer sig från incheckningen som registrerats i superprojektet, och kan användas för att åsidosätta alla inställningar i ignore-alternativet i git-config[1] eller gitmodules[5]. När untracked används anses undermoduler inte vara smutsiga när de bara innehåller ospårat innehåll (men de skannas fortfarande efter modifierat innehåll). Om dirty används ignoreras alla ändringar i arbetsträdet för undermoduler, endast ändringar i de incheckningar som lagras i superprojektet visas (detta var beteendet fram till 1.7.0). Om all används döljs alla ändringar i undermoduler.

--src-prefix=<prefix>

Visa givet käll_<prefix>_ istället för ”a/”.

--dst-prefix=<prefix>

Visa den angivna mål <prefix> istället för "b/".

--no-prefix

Visa inte käll- eller målprefix.

--default-prefix

Använd standard käll- och destinationsprefixen ("a/" och "b/"). Detta åsidosätter konfigurationsvariabler som diff.noprefix, diff.srcPrefix, diff.dstPrefix och diff.mnemonicPrefix (se git-config[1]).

--line-prefix=<prefix>

Lägg till ett ytterligare <prefix> före varje utdatarad.

--ita-invisible-in-index

Som standard visas poster som läggs till av git add -N som en befintlig tom fil i git diff och en ny fil i git diff --cached. Det här alternativet gör att posten visas som en ny fil i git diff och obefintlig i git diff --cached. Det här alternativet kan ångras med --ita-visible-in-index. Båda alternativen är experimentella och kan komma att tas bort i framtiden.

--max-depth=<djup>

För varje sökvägsmönster som anges på kommandoraden, gå ner högst <djup>-nivåer i kataloger. Värdet -1 betyder ingen gräns. Kan inte kombineras med jokertecken i sökvägsmönster. Givet ett träd som innehåller foo/bar/baz visar följande lista de träffar som genereras av varje uppsättning alternativ:

--max-depth=0 -- foo: foo
--max-depth=1 -- foo: foo/bar
--max-depth=1 -- foo/bar: foo/bar/baz
--max-depth=1 -- foo foo/bar: foo/bar/baz
--max-depth=2 -- foo: foo/bar/baz

Om ingen sökvägsmönster anges mäts djupet som om alla poster på toppnivå vore specificerade. Observera att detta skiljer sig från att mäta från roten, eftersom --max-depth=0 fortfarande skulle returnera foo. Detta låter dig fortfarande begränsa djupet samtidigt som du frågar efter en delmängd av posterna på toppnivå.

Observera att det här alternativet endast stöds för skillnader mellan trädobjekt, inte mot indexet eller arbetskatalog.

För en mer detaljerad förklaring av dessa vanliga alternativ, se även gitdiffcore[7].

Generera patchtext med -p

Att köra git-diff[1], git-log[1], git-show[1], git-diff-index[1], git-diff-tree[1] eller git-diff-files[1] med alternativet -p producerar patchtext. Du kan anpassa skapandet av patchtext via miljövariablerna GIT_EXTERNAL_DIFF och GIT_DIFF_OPTS (se git[1]), och attributet diff (se gitattributes[5]).

Det som -p-alternativet producerar skiljer sig något från det traditionella diff-formatet:

Det föregås av ett "git diff"-huvudet som ser ut så här:
```
diff --git a/fil1 b/fil2
```
Filnamnen a/ och b/ är desamma om det inte rör sig om att byta namn/kopiera. Speciellt, även vid skapande eller borttagning, används /dev/null inte istället för filnamnen a/ eller b/.

När ett namnbyte/kopiering är inblandat visar fil1 och fil2 namnet på källfilen för namnbytet/kopieringen respektive namnet på filen som namnbytet/kopieringen producerar.
Den följs av en eller flera utökade huvud-rader:
```
old mode <sökväg>
new mode <behörigheter>
deleted file mode <behörigheter>
new file mode <läge>
copy from <sökväg>
copy to <sökväg>
rename from <sökväg>
rename to <sökväg>
similarity index <nummer>
dissimilarity index <nummer>
index <hash>..<hash> <behörigheter>
```
Fil-rättigheter <behörigheter> skrivs ut som 6-siffriga oktala tal inklusive filtyp och filbehörighetsbitar.

Sökvägar i utökade huvuden inkluderar inte prefixen a/ och b/.

Likhetsindexet är andelen oförändrade rader och olikhetsindexet är andelen ändrade rader. Det är ett avrundat heltal följt av ett procenttecken. Likhetsindexvärdet 100 % är således reserverat för två lika filer, medan 100 % olikhet innebär att ingen rad från den gamla filen kom med i den nya.

Indexraden innehåller namnen på blob-objekten före och efter ändringen. <behörigheter> inkluderas om fil-rättigheterna inte ändras; annars anger separata rader det gamla och det nya läget.
Sökvägar med "ovanliga" tecken anges i citat enligt beskrivningen för konfigurationsvariabeln core.quotePath (se git-config[1]).
Alla fil1-filer i utdata refererar till filer före incheckning, och alla fil2-filer refererar till filer efter incheckning. Det är felaktigt att tillämpa varje ändring på varje fil sekventiellt. Till exempel kommer den här patchen att byta a och b:
```
diff --git a/a b/b
rename from a
rename to b
diff --git a/b b/a
rename from b
rename to a
```
Hunk-rubriker nämner namnet på den funktion som stycket gäller för. Se "Definiera en anpassat styckes-huvud" i gitattributes[5] för detaljer om hur man anpassar detta till specifika språk.

Kombinerat diff-format

Alla diff-genererande kommandon kan använda -c eller --cc alternativet för att skapa en kombinerad diff när en merge visas. Detta är standardformatet när merges visas med git-diff[1] eller git-show[1]. Observera också att du kan ge lämplig --diff-merges alternativ till vilket som helst av dessa kommandon för att tvinga generering av diffs i ett specifikt format.

Ett "kombinerat diff"-format ser ut så här:

diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
	return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
  }

- static void describe(char *arg)
 -static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
  {
 +	unsigned char sha1[20];
 +	struct commit *cmit;
	struct commit_list *list;
	static int initialized = 0;
	struct commit_name *n;

 +	if (get_sha1(arg, sha1) < 0)
 +		usage(describe_usage);
 +	cmit = lookup_commit_reference(sha1);
 +	if (!cmit)
 +		usage(describe_usage);
 +
	if (!initialized) {
		initialized = 1;
		for_each_ref(get_name);

Den föregås av ett "git diff"-huvudet, som ser ut så här (när alternativet -c används):
```
diff --combined fil
```
eller så här (när --cc-alternativet används):
```
diff --cc fil
```
Den följs av ett eller flera utökade huvud-rader (detta exempel visar en sammanslagning med två föräldrar):
```
index <hash>,<hash>..<hash>
mode <behörighter>,<behörighter>..<behörighter>
new file mode <behörighter>
deleted file mode <behörighter>,<behörighter>
```
Raden mode <behörighter>,<behörighter>..<behörighter> visas bara om minst en av <behörighter> skiljer sig från resten. Utökade huvuden med information om detekterad innehållsförflyttning (namnbyten och kopieringsdetektering) är utformade för att fungera med diff-värdet för två <trädlikt> och används inte av kombinerat diff-format.
Den följs av en tvåradig från-fil/till-fil huvud:
```
--- a/fil
+++ b/fil
```
I likhet med det tvåradiga huvud för det traditionella unified diff-formatet används /dev/null för att signalera skapade eller raderade filer.

Om alternativet --combined-all-paths däremot anges, får du istället för en tvåradig från-fil/till-fil-rubrik en N+1-radig from-file/to-file huvud, där N är antalet föräldrar i sammanslagings-incheckning:
```
--- a/fil
--- a/fil
--- a/fil
+++ b/fil
```
Detta utökade format kan vara användbart om namnbytes- eller kopieringsdetektering är aktivt, så att du kan se filens ursprungliga namn i olika överordnade filer.
Chunk-huvud-formatet är modifierat för att förhindra att folk av misstag matar in det i patch -p1. Kombinerat diff-format skapades för granskning av sammanslagings inchecknings-ändringar och var inte avsett att tillämpas. Ändringen liknar ändringen i det utökade index-huvudet:
```
@@@ <från-fil-omfång> <från-fil-omfång> <till-fil-omfånge> @@@
```
Det finns (antal föräldrar + 1) @-tecken i chunk-huvudet för kombinerat diff-format.

Till skillnad från det traditionella "unified" diff-formatet, som visar två filer A och B med en enda kolumn som har prefixet - (minus — visas i A men tas bort i B), + (plus — saknas i A men läggs till i B) eller " " (mellanslag — oförändrat), jämför detta format två eller flera filer fil1, fil2,… med en fil X, och visar hur X skiljer sig från var och en av filN. En kolumn för var och en av filN läggs till på utdataraden för att ange hur X:s rad skiljer sig från den.

Ett --tecknet i kolumn N betyder att raden visas i fileN men inte i resultatet. Ett +-tecknet i kolumn N betyder att raden visas i resultatet, och fileN har inte den raden (med andra ord, raden lades till, ur den överordnade filens synvinkel).

I exemplet ovan ändrades funktionssignaturen från båda filerna (därav två borttagningar av - från både fil1 och fil2, plus ++ för att betyda att en rad som lades till inte visas i vare sig fil1 eller fil2). Dessutom är åtta andra rader desamma från fil1 men visas inte i fil2 (därav prefixet +).

När det visas med git diff-tree -c jämför den föräldrarna till en sammanslagnings-incheckning med sammanslagnings-resultatet (dvs. file1..fileN är föräldrarna). När det visas med git diff-files -c jämför den de två olösta sammanslagnings-föräldrarna med den fungerande arbetskatalog filen (dvs. file1 är steg 2, även kallad "vår version", file2 är steg 3, även kallad "deras version").

EXEMPEL

git log --no-merges: Visa hela incheckning-historiken, men hoppa över alla sammanslagningar
git log v2.6.12.. include/scsi drivers/scsi: Visa alla incheckningar sedan version v2.6.12 som ändrat någon fil i underkatalogerna include/scsi eller drivers/scsi
git log --since="2 weeks ago" -- gitk: Visa alla commits sedan version v2.6.12 som ändrat någon fil i underkatalogerna include/scsi eller drivers/scsi
git log --name-status release..test: Visa de incheckning som finns i grenen "test" men ännu inte i grenen "release", tillsammans med listan över sökvägar som varje commit ändrar.
git log --follow builtin/rev-list.c: Visar de incheckningar som ändrade builtin/rev-list.c, inklusive de commits som gjordes innan filen fick sitt nuvarande namn.
git log --branches --not --remotes=origin: Visar alla incheckningar som finns i någon av de lokala grenarna men inte i någon av de fjärrspårande grenarna för origin (det du har som origin inte har).
git log master --not --remotes=*/master: Visar alla incheckningar som finns i den lokala mastern men inte i några master-grenar för fjärrkodförrådet.
git log -p -m --first-parent: Visar historiken inklusive ändringsskillnader, men bara från "huvudgrenens" perspektiv, hoppar över incheckningar som kommer från sammanslagna grenar och visar fullständiga skillnader för ändringar som introducerats av sammanslagningarna. Detta är bara meningsfullt när man följer en strikt policy att sammanfoga alla ämnesgrenar när man stannar kvar på en enda integrationsgren.
git log -L /int main/',/^}/:main.c: Visar hur funktionen main() i filen main.c utvecklades över tid.
git log -3: Begränsar antalet incheckningar som ska visas till 3.

DISKUSSION

Git är till viss del teckenkodningsagnostisk.

Innehållet i blob-objekten är otolkade sekvenser av byte. Det finns ingen kodningsöversättning på kärnnivå.
Sökvägsnamn är kodade i UTF-8-normaliseringsform C. Detta gäller trädobjekt, indexfilen, referensnamn, såväl som sökvägsnamn i kommandoradsargument, miljövariabler och konfigurationsfiler (.git/config (se git-config[1]), gitignore[5], gitattributes[5] och gitmodules[5]).

Observera att Git på kärnnivå behandlar sökvägsnamn helt enkelt som sekvenser av icke-NUL-byte, det finns inga konverteringar av sökvägskodning (förutom på Mac och Windows). Därför fungerar användning av sökvägsnamn som inte är ASCII-namn oftast även på plattformar och filsystem som använder äldre utökade ASCII-kodningar. Förvar som skapas på sådana system kommer dock inte att fungera korrekt på UTF-8-baserade system (t.ex. Linux, Mac, Windows) och vice versa. Dessutom antar många Git-baserade verktyg helt enkelt att sökvägsnamn är UTF-8 och kommer inte att kunna visa andra kodningar korrekt.
Meddelanden i commitloggar kodas vanligtvis i UTF-8, men andra utökade ASCII-kodningar stöds också. Detta inkluderar ISO-8859-x, CP125x och många andra, men inte UTF-16/32, EBCDIC och CJK multibyte-kodningar (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).

Även om vi uppmuntrar att incheckningsloggmeddelanden kodas i UTF-8, är både kärnan och användarkommandona (porcelain) i Git utformade för att inte tvinga fram UTF-8 i projekt. Om alla deltagare i ett visst projekt tycker att det är bekvämare att använda äldre kodningar, förbjuder inte Git det. Det finns dock några saker att tänka på.

git commit och git commit-tree utfärdar en varning om incheckningsloggmeddelandet som ges till det inte ser ut som en giltig UTF-8-sträng, såvida du inte uttryckligen anger att ditt projekt använder en äldre kodning. Sättet att säga detta är att ha i18n.commitEncoding i .git/config-filen, så här:
```
[i18n]
	commitEncoding = ISO-8859-1
```
Incheckningsobjekt som skapats med ovanstående inställning registrerar värdet för i18n.commitEncoding i sin encoding-header. Detta är för att hjälpa andra som tittar på dem senare. Avsaknaden av denna header innebär att incheckningsloggmeddelandet är kodat i UTF-8.
git log, git show, git blame och vänner tittar på encoding-headern för ett incheckningsobjekt och försöker koda om loggmeddelandet till UTF-8 om inget annat anges. Du kan ange önskad utdatakodning med i18n.logOutputEncoding i .git/config-filen, så här:
```
[i18n]
	logOutputEncoding = ISO-8859-1
```
Om du inte har den här konfigurationsvariabeln används värdet för i18n.commitEncoding i stället.

Observera att vi medvetet valde att inte koda om incheckningsloggmeddelandet när en incheckning görs för att tvinga fram UTF-8 på incheckningsobjektnivå, eftersom omkodning till UTF-8 inte nödvändigtvis är en reversibel operation.

KONFIGURATION

Se git-config[1] för kärnvariabler och git-diff[1] för inställningar relaterade till diff-generering.

format.pretty: Standardinställning för alternativet --format. (Se Vackra format ovan.) Standardinställningen är medium.
i18n.logOutputEncoding: Kodning att använda vid visning av loggar. (Se Diskussion ovan.) Standardvärdet är i18n.commitEncoding om det är inställt, och UTF-8 annars.

Allt ovanför den här raden i det här avsnittet finns inte med i dokumentationen för git-config[1]. Innehållet som följer är detsamma som det som finns där:

log.abbrevCommit

Om sant, gör git-log[1], git-show[1], och git-whatchanged[1] anta --abbrev-commit. Du kan åsidosätta detta alternativ med --no-abbrev-commit.

log.date

Ställ in standardläget för datum och tid för log-kommandot. Att ställa in ett värde för log.date liknar att använda git logs --date-alternativ. Se git-log[1] för mer information.

Om formatet är inställt på "auto:foo" och bläddrare används, kommer formatet "foo" att användas för datumformatet. Annars kommer "standard" att användas.

log.decorate

Print out the ref names of any commits that are shown by the log command. Possible values are:

short: referensnamnsprefixen refs/heads/, refs/tags/ och refs/remotes/ skrivs inte ut.
full: det fullständiga referensnamnet (inklusive prefix) skrivs ut.
auto: om utdata går till en terminal, visas referensnamnen som om short hade angetts, annars visas inga referensnamn.

Detta är samma sak som alternativet --decorate i git log.

log.initialDecorationSet

Som standard, visar git log bara dekorationer för vissa kända referensnamnrymder. Om alla anges visas alla referenser som dekorationer.

log.excludeDecoration

Exkludera de angivna mönstren från loggdekorationerna. Detta liknar kommandoradsalternativet --decorate-refs-exclude, men konfigurations-alternativet kan åsidosättas av --decorate-refs.

log.diffMerges

Ställ in diff-formatet som ska användas när --diff-merges=on är specificerat, se --diff-merges i git-log[1] för detaljer. Standardinställningen är separate.

log.follow

Om true kommer git log att agera som om --follow-alternativet användes när en enda <sökväg> anges. Detta har samma begränsningar som --follow, d.v.s. det kan inte användas för att följa flera filer och fungerar inte bra på icke-linjär historik.

log.graphColors

En lista med färger, separerade med kommatecken, som kan användas för att rita historiklinjer i git log --graph.

log.showRoot

Om sant, visas den initiala incheckningen som en stor skapandehändelse. Detta motsvarar en diff mot ett tomt träd. Verktyg som git-log[1] eller git-whatchanged[1], som normalt döljer rot-incheckningen, kommer nu att visa den. Sant som standard.

log.showSignature

Om sant, gör att git-log[1], git-show[1] och git-whatchanged[1] antar --show-signature.

log.mailmap

Om sant, gör att git-log[1], git-show[1] och git-whatchanged[1] antar --use-mailmap, annars antar man --no-use-mailmap. Sant som standard.

notes.mergeStrategy: Vilken sammanslagningsstrategi som ska väljas som standard vid lösande av anteckningskonflikter. Måste vara en av manual, ours, theirs, union eller cat_sort_uniq. Standardinställningen är manual. Se avsnittet "ANTECKNINGAR SAMMANSLAGNINGSSTRATEGIER" i git-notes[1] för mer information om varje strategi.

Den här inställningen kan åsidosättas genom att skicka --strategy-alternativet till git-notes[1].
notes.<name>.mergeStrategy: Vilken sammanslagningsstrategi man ska välja när man sammanfogar anteckningar med refs/notes/<namn>. Detta åsidosätter den mer generella notes.mergeStrategy. Se avsnittet "ANTECKNINGAR SAMMANSLAGNINGSSTRATEGIER" i git-notes[1] för mer information om tillgängliga strategier.
notes.displayRef: Vilken referens (eller referenser, om en glob eller angetts mer än en gång), utöver standardvärdet som anges av core.notesRef eller GIT_NOTES_REF, som anteckningar ska läsas från när inchecknings-meddelanden visas med kommandofamiljen git log.

Den här inställningen kan åsidosättas med miljövariabeln GIT_NOTES_DISPLAY_REF, som måste vara en kolonseparerad lista med referenser eller globs.

En varning kommer att utfärdas för referenser som inte finns, men en glob som inte matchar några referenser ignoreras tyst.

Den här inställningen kan inaktiveras med alternativet --no-notes till kommandofamiljen git-log[1], eller med alternativet --notes=<ref> som accepteras av dessa kommandon.

Det effektiva värdet för core.notesRef (eventuellt åsidosatt av GIT_NOTES_REF) läggs också implicit till i listan över referenser som ska visas.
notes.rewrite.<kommando>: När man skriver om incheckningar med <kommando> (för närvarande amend eller rebase), och variabeln är false, kommer git inte att kopiera anteckningar från originalet till den omskrivna incheckningen. Standardvärdet är true. Se även notes.rewriteRef nedan.

Den här inställningen kan åsidosättas med miljövariabeln GIT_NOTES_REWRITE_REF, som måste vara en kolonseparerad lista med referenser eller globs.
notes.rewriteMode: När anteckningar kopieras under en omskrivning (se alternativet notes.rewrite.<kommando>), avgör detta vad som ska göras om mål-incheckningen redan har en anteckning. Måste vara en av overwrite, concatenate, cat_sort_uniq eller ignore. Standardvärdet är concatenate.

Den här inställningen kan åsidosättas med miljövariabeln GIT_NOTES_REWRITE_MODE.
notes.rewriteRef: När anteckningar kopieras under en omskrivning, anger detta den (fullständigt kvalificerade) referens vars anteckningar ska kopieras. Kan vara en glob, i vilket fall anteckningar i alla matchande referenser kommer att kopieras. Du kan också ange denna konfiguration flera gånger.

Har inget standardvärde; du måste konfigurera den här variabeln för att aktivera omskrivning av anteckningar. Ställ in den på refs/notes/commits för att aktivera omskrivning för standard incheckning anteckningarna.

Kan åsidosättas med miljövariabeln GIT_NOTES_REWRITE_REF. Se notes.rewrite.<kommando> ovan för en ytterligare beskrivning av dess format.

En del av git[1]-sviten

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands