git-rev-list(1)

NAMN

git-rev-list - listar commit-objekt i omvänd kronologisk ordning

SYNOPSIS

git rev-list [<alternativ>] <commit>... [--] [<sökväg>...]

BESKRIVNING

git rev-list listar commitar som kan nås genom att följa parent-länkarna från de angivna commitarna, men utesluter commitar som kan nås från commitar som anges med ett ^ framför. Som standard skrivs resultatet ut i omvänd kronologisk ordning.

Man kan se detta som en mängdoperation. Commits som kan nås från någon av de commitar som anges på kommandoraden bildar en mängd. Därefter dras de commitar som kan nås från någon av de commitar som anges med ^ framför bort från mängden. De återstående commitarna är det som skrivs ut. Flera alternativ och sökvägsparametrar kan användas för att begränsa resultatet ytterligare.

Följande kommando:

$ git rev-list foo bar ^baz

betyder: lista alla commitar som kan nås från foo eller bar, men inte från baz.

Den särskilda notationen:

<commit1>..<commit2>

kan användas som kortform för:

^<commit1> <commit2>

Exempelvis är följande två kommandon likvärdiga:

$ git rev-list origin..HEAD
$ git rev-list HEAD ^origin

En annan särskild notation är:

<commit1>...<commit2>

Den är användbar vid merge-situationer. Resultatet blir den symmetriska differensen mellan de två operandernas commit-mängder. Följande två kommandon är likvärdiga:

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

rev-list är ett grundläggande Git-kommando eftersom det kan bygga upp och traversera commit-historikens härkomstgrafer. Därför har kommandot många olika alternativ och används internt av så skilda kommandon som git-bisect(1) och git-repack(1).

ALTERNATIV

Begränsning av commitar

Förutom att ange ett commit-intervall med de särskilda notationer som beskrivs ovan kan ytterligare begränsningar användas.

Flera begränsningsalternativ snävar normalt in resultatet ytterligare. Exempelvis begränsar --since=<datum1> resultatet till commitar nyare än <datum1>, och om man dessutom använder --grep=<mönster> begränsas resultatet ytterligare till commitar vars loggmeddelande innehåller en rad som matchar <mönster>, om inget annat anges.

Observera att dessa begränsningar används före alternativ för sortering och formatering, till exempel --reverse.

-<antal>, -n <antal>, --max-count=<antal>

Begränsa utskriften till <antal> commitar.

--skip=<antal>

Hoppa över <antal> commitar innan utskriften börjar.

--since=<datum>, --after=<datum>

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

--since-as-filter=<datum>

Visa alla commitar som är nyare än <datum>. Till skillnad från --since besöks alla commitar i intervallet, i stället för att vandringen stoppas när den första äldre commiten hittas.

--until=<datum>, --before=<datum>

Visa commitar som är äldre än <datum>.

--max-age=<tidsstämpel>, --min-age=<tidsstämpel>

Begränsa de commitar som skrivs ut till ett angivet tidsintervall.

--author=<mönster>, --committer=<mönster>

Begränsa resultatet till commitar vars author- eller committer-rader matchar det reguljära uttrycket <mönster>. Om flera --author=<mönster> anges väljs commitar där författaren matchar något av mönstren. Samma princip gäller för flera --committer=<mönster>.

--grep-reflog=<mönster>

Begränsa resultatet till commitar med reflog-poster som matchar det reguljära uttrycket <mönster>. Om flera --grep-reflog anges väljs commitar vars reflog-meddelande matchar något av mönstren. Det är ett fel att använda detta alternativ utan --walk-reflogs.

--grep=<mönster>

Begränsa resultatet till commitar vars loggmeddelande matchar det reguljära uttrycket <mönster>. Om flera --grep=<mönster> anges väljs commitar vars meddelande matchar något av mönstren, men se även --all-match.

--all-match

Begränsa resultatet till commitar som matchar alla angivna --grep-mönster, i stället för minst ett.

--invert-grep

Begränsa resultatet till commitar vars loggmeddelande inte matchar mönstret som angavs med --grep=<mönster>.

-i, --regexp-ignore-case

Matcha de begränsande reguljära uttrycken utan hänsyn till versaler och gemener.

--basic-regexp

Tolka begränsningsmönstren som grundläggande reguljära uttryck. Detta är standard.

-E, --extended-regexp

Tolka begränsningsmönstren som utökade reguljära uttryck i stället för grundläggande reguljära uttryck.

-F, --fixed-strings

Tolka begränsningsmönstren som fasta strängar, inte som reguljära uttryck.

-P, --perl-regexp

Tolka begränsningsmönstren som Perl-kompatibla reguljära uttryck. Stöd för denna typ av uttryck är ett valfritt byggtidsberoende. Om Git inte kompilerades med stöd för dem avslutas kommandot med fel när alternativet används.

--remove-empty

Stoppa när en angiven sökväg försvinner från trädet.

--merges

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

--no-merges

Skriv inte ut commitar med fler än en parent. Detta är exakt samma sak som --max-parents=1.

--min-parents=<antal>, --max-parents=<antal>, --no-min-parents, --no-max-parents

Visa endast commitar som har minst respektive högst så många parent-commitar. Särskilt gäller att --max-parents=1 är samma sak som --no-merges, och --min-parents=2 är samma sak som --merges. --max-parents=0 ger alla rotcommitar, och --min-parents=3 ger alla octopus-mergar.

--no-min-parents och --no-max-parents återställer dessa gränser till ingen gräns. Likvärdiga former är --min-parents=0 och --max-parents=-1. Negativa tal betyder ingen övre gräns.

--first-parent

När commitar letas fram för inkludering följs endast första parent när en merge-commit påträffas. Detta kan ge en bättre översikt över utvecklingen av en viss topic branch, eftersom merge-commitar in i en sådan gren ofta bara handlar om att uppdatera mot upstream. Med detta alternativ kan man ignorera de enskilda commitar som drogs in i historiken genom en sådan merge.

--exclude-first-parent-only

När commitar letas fram för exkludering med ^ följs endast första parent när en merge-commit påträffas. Detta kan användas för att hitta ändringsmängden i en topic branch från punkten där den avvek från en remote branch, även om godtyckliga merge-commitar förekommer som legitima ändringar i topic-branchen.

--not

Vänder betydelsen av prefixet ^ — eller avsaknaden av det — för alla efterföljande revisionsangivelser fram till nästa --not. När alternativet används på kommandoraden före --stdin påverkas inte de revisioner som skickas via standard in. Omvänt påverkar --not som skickas via standard in inte de revisioner som angavs på kommandoraden.

--all

Låtsas som om alla refs i refs/, tillsammans med HEAD, angavs på kommandoraden som <commit>.

--branches[=<mönster>]

Låtsas som om alla refs i refs/heads angavs på kommandoraden som <commit>. Om <mönster> anges begränsas grenarna till de som matchar det givna shell-globmönstret. Om <mönster> saknar ?, * eller [ läggs /* implicit till i slutet.

--tags[=<mönster>]

Låtsas som om alla refs i refs/tags angavs på kommandoraden som <commit>. Om <mönster> anges begränsas taggarna till de som matchar det givna shell-globmönstret. Om mönstret saknar ?, * eller [ läggs /* implicit till i slutet.

--remotes[=<mönster>]

Låtsas som om alla refs i refs/remotes angavs på kommandoraden som <commit>. Om <mönster> anges begränsas remote-tracking-grenar till de som matchar det givna shell-globmönstret. Om mönstret saknar ?, * eller [ läggs /* implicit till i slutet.

--glob=<glob-mönster>

Låtsas som om alla refs som matchar shell-globmönstret <glob-mönster> angavs på kommandoraden som <commit>. Inledande refs/ läggs automatiskt till om det saknas. Om mönstret saknar ?, * eller [ läggs /* implicit till i slutet.

--exclude=<glob-mönster>

Ta inte med refs som matchar <glob-mönster> när nästa --all, --branches, --tags, --remotes eller --glob annars skulle ha tagit hänsyn till dem. Upprepningar av alternativet ackumulerar exkluderingsmönster fram till nästa sådant pseudo-ref-alternativ. Andra alternativ eller argument rensar inte de ackumulerade mönstren.

Mönster som anges bör inte börja med refs/heads, refs/tags eller refs/remotes när de används med --branches, --tags respektive --remotes. De måste däremot börja med refs/ när de används med --glob eller --all. Om ett avslutande /* är avsett måste det anges uttryckligen.

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

Ta inte med refs som skulle döljas av git-fetch, git-receive-pack eller git-upload-pack genom inställningarna fetch.hideRefs, receive.hideRefs eller uploadpack.hideRefs tillsammans med transfer.hideRefs. Se git-config(1). Alternativet påverkar nästa pseudo-ref-alternativ --all eller --glob och rensas därefter.

--reflog

Låtsas som om alla objekt som nämns i refloggar angavs på kommandoraden som <commit>.

--alternate-refs

Låtsas som om alla objekt som nämns som ref-spetsar i alternativa arkiv angavs på kommandoraden. Ett alternativt arkiv är ett arkiv vars objektkatalog anges i objects/info/alternates. Mängden inkluderade objekt kan ändras av exempelvis core.alternateRefsCommand. Se git-config(1).

--single-worktree

Som standard undersöks alla working trees när flera finns, för alternativ som --all, --reflog och --indexed-objects. Se git-worktree(1). Detta alternativ gör att endast aktuell working tree undersöks.

--ignore-missing

Om ett ogiltigt objektnamn påträffas i indata låtsas Git som om det inte hade angivits.

--stdin

Läs argument från standard in utöver argument från kommandoraden. Detta accepterar commitar och pseudoalternativ som --all och --glob=. När en ---avskiljare påträffas behandlas efterföljande indata som sökvägar som begränsar resultatet. Flaggor som --not som läses via standard in gäller endast argument som skickas på samma sätt och påverkar inte efterföljande kommandoradsargument.

--quiet

Skriv inget till standard ut. Denna form används främst för att låta anroparen kontrollera exitstatus för att avgöra om ett objektintervall är helt sammanhängande eller inte. Det är snabbare än att omdirigera standard ut till /dev/null, eftersom utdata inte behöver formateras.

--disk-usage, --disk-usage=human

Undertryck normal utdata och skriv i stället ut summan av byte som används för lagring på disk av de valda commitarna eller objekten. Detta motsvarar att skicka resultatet till:

git cat-file --batch-check='%(objectsize:disk)'

men körs mycket snabbare, särskilt med --use-bitmap-index. Se avsnittet CAVEATS i git-cat-file(1) för begränsningar kring vad “lagring på disk” betyder. Med det valfria värdet human visas storleken i ett människoläsbart format.

--cherry-mark

Som --cherry-pick, men markera likvärdiga commitar med = i stället för att utelämna dem, och icke-likvärdiga med +.

--cherry-pick

Utelämna commitar som introducerar samma ändring som en annan commit på den “andra sidan” när commit-mängden begränsas med symmetrisk differens.

Om man exempelvis har två grenar, A och B, är ett vanligt sätt att lista commitar som bara finns på ena sidan att använda --left-right. Det visar dock också commitar som cherry-pickats från den andra grenen. Med detta alternativ utesluts sådana commit-par.

--left-only, --right-only

Lista endast commitar på respektive sida av en symmetrisk differens, alltså endast de som skulle markeras med < respektive > av --left-right.

Exempelvis utelämnar --cherry-pick --right-only A...B de commitar från B som finns i A eller är patch-likvärdiga med en commit i A. Med andra ord listas +-commitarna från git cherry A B. Mer exakt ger --cherry-pick --right-only --no-merges exakt samma lista.

--cherry

En synonym för --right-only --cherry-mark --no-merges. Den är användbar för att begränsa resultatet till commitar på vår sida och markera de som redan har tillämpats på den andra sidan av en förgrenad historik, till exempel med:

git log --cherry upstream...mybranch

Det liknar:

git cherry upstream mybranch

-g, --walk-reflogs

I stället för att vandra i commit-härkomstens kedja vandras reflog-poster från den senaste till äldre poster. När detta alternativ används kan man inte ange commitar som ska exkluderas, det vill säga notationer som ^<commit>, <commit1>..<commit2> och <commit1>...<commit2> kan inte användas.

Med andra pretty-format än oneline och reference läggs två extra rader med information från refloggen till i utdata. Reflog-väljaren kan visas som ref@{<N>} eller som ref@{<tidsstämpel>}, beroende på reglerna nedan.

1. Om startpunkten anges som ref@{<N>} visas indexformatet.
2. Om startpunkten anges som ref@{now} visas tidsstämpelformatet.
3. Om inget av detta användes men --date angavs visas tidsstämpeln i det format som begärdes av --date.
4. Annars visas indexformatet.

Med --pretty=oneline placeras denna information som prefix på samma rad som commit-meddelandet. Alternativet kan inte kombineras med --reverse. Se även git-reflog(1). Med --pretty=reference visas inte denna information alls.

--merge

Visa commitar som rör konfliktsökvägar i intervallet HEAD...<annan>, där <annan> är den första existerande pseudorefen i MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD eller REBASE_HEAD. Fungerar endast när indexet har omatchade merge-poster. Alternativet kan användas för att visa relevanta commitar när konflikter från en trevägsmerge löses.

--boundary

Skriv ut exkluderade gränscommitar. Gränscommitar får prefixet -.

--use-bitmap-index

Försök snabba upp traverseringen med pack-bitmap-indexet, om ett sådant finns. Observera att när traversering sker med --objects skrivs inte sökvägar för träd och blobbar ut.

--progress=<rubrik>

Visa förloppsrapporter på standard fel när objekt behandlas. Texten <rubrik> skrivs ut med varje förloppsuppdatering.

-z

I stället för att avgränsa objekt med radbrytning avgränsas varje utskrivet objekt och tillhörande metadata med NUL-byte. Utdata skrivs i formen:

<OID> NUL [<token>=<värde> NUL]...

Ytterligare objektmetadata, som objektsökvägar eller gränsobjekt, skrivs i formen <token>=<värde>. Tokenvärden skrivs som de är, utan kodning eller avkortning. En OID-post innehåller aldrig tecknet = och markerar därför början på en ny objektpost. Exempel:

<OID> NUL
<OID> NUL path=<sökväg> NUL
<OID> NUL boundary=yes NUL
<OID> NUL missing=yes NUL [<token>=<värde> NUL]...

Detta läge är endast kompatibelt med utdataalternativen --objects, --boundary och --missing.

Historikförenkling

Ibland är man bara intresserad av delar av historiken, till exempel commitar som ändrar en viss <sökväg>. Historikförenkling har två delar: dels vilka commitar som väljs ut, dels hur historiken förenklas. Det finns flera strategier.

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

<sökvägar>

Commits som ändrar de angivna sökvägarna väljs.

--simplify-by-decoration

Commits som pekas ut av någon gren eller tagg väljs.

Observera att extra commitar 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 historik som förklarar trädets slutliga tillstånd. “Enklast” betyder att vissa sidogrenar beskärs om slutresultatet är detsamma, exempelvis vid merge av grenar med samma innehåll.

--show-pulls

Ta med alla commitar från standardläget, men även merge-commitar som inte är TREESAME mot första parent men är TREESAME mot en senare parent. Detta är användbart för att visa de merge-commitar som först introducerade en ändring till en gren.

--full-history

Samma som standardläge, men utan att beskära viss historik.

--dense

Endast de valda commitarna visas, plus sådana som behövs för en meningsfull historik.

--sparse

Alla commitar i den förenklade historiken visas.

--simplify-merges

Ytterligare alternativ till --full-history som tar bort onödiga merge-commitar från resultatet när det inte finns några valda commitar som bidrar till mergen.

--ancestry-path[=<commit>]

När ett intervall av commitar ska visas, till exempel <commit1>..<commit2> eller <commit2> ^<commit1>, och en commit <commit> finns i intervallet, visas endast commitar i intervallet som är förfäder till <commit>, ättlingar till <commit> eller <commit> själv. Om ingen commit anges används <commit1>, alltså den exkluderade delen av intervallet. Alternativet kan anges flera gånger; då inkluderas en commit om den är någon av de angivna commitarna eller är förfader eller ättling till någon av dem.

En mer detaljerad förklaring följer.

Anta att du angav foo som sökväg. Vi kallar commitar som ändrar foo för !TREESAME och övriga för TREESAME. I en diff filtrerad för foo ser de olika respektive lika ut.

Följande exempelhistorik används för att visa skillnaden mellan olika förenklingsinställningar. Vi antar att man filtrerar på filen foo i denna commitgraf:

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

Den horisontella raden A---Q betraktas som första parent för varje merge. Commits är följande:

• I är den initiala commiten där foo finns med innehållet asdf och filen quux finns med innehållet quux. Initiala commitar jämförs mot ett tomt träd, så I är !TREESAME.
• I A innehåller foo bara foo.
• B innehåller samma ändring som A. Dess merge M är trivial och därmed TREESAME mot alla parents.
• C ändrar inte foo, men dess merge N ändrar den till foobar, så den är inte TREESAME mot någon parent.
• D sätter foo till baz. Dess merge O kombinerar strängarna från N och D till foobarbaz, och är därför inte TREESAME mot någon parent.
• E ändrar quux till xyzzy, och dess merge P kombinerar strängarna till quux xyzzy. P är TREESAME mot O, men inte mot E.
• X är en oberoende rotcommit som lade till filen side, och Y ändrade den. Y är TREESAME mot X. Dess merge Q lade till side till P. Q är TREESAME mot P, men inte mot Y.

rev-list går bakåt genom historiken och inkluderar eller exkluderar commitar beroende på om --full-history och/eller parent-omskrivning via --parents eller --children används.

Standardläge

Commits inkluderas om de inte är TREESAME mot någon parent. Om commiten är en merge och är TREESAME mot en parent, följs endast den parenten. Om det finns flera TREESAME-parents följs bara en av dem. Annars följs alla parents.

Resultatet blir:

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

Regeln att bara följa en TREESAME-parent, om sådan finns, tog bort B helt från övervägande. C besöktes via N, men är TREESAME. Rotcommitar jämförs mot ett tomt träd, så I är !TREESAME.

--full-history utan parent-omskrivning

Detta skiljer sig från standardläget på en punkt: alla parents till en merge följs alltid, även om mergen är TREESAME mot någon av dem. Även om mer än en sida av mergen har commitar som inkluderas betyder det inte att själva mergen inkluderas. I exemplet blir resultatet:

I  A  B  N  D  O  P  Q

M exkluderades eftersom den är TREESAME mot båda parents. E, C och B vandrades alla, men bara B var !TREESAME.

--full-history med parent-omskrivning

Vanliga commitar inkluderas bara om de är !TREESAME, om inte detta ändras med exempelvis --sparse. Merges inkluderas alltid. Deras parent-listor skrivs däremot om: längs varje parent beskärs commitar som inte själva ingår. Resultatet blir:

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

Jämför med --full-history utan omskrivning. E beskars eftersom den är TREESAME, men parent-listan för P skrevs om till att innehålla E:s parent I. Samma sak hände för C och N, samt X, Y och Q.

--dense

Commits som vandras inkluderas om de inte är TREESAME mot någon parent.

--sparse

Alla commitar som vandras inkluderas. Observera att utan --full-history förenklas fortfarande merge-commitar: om en parent är TREESAME följs bara den, så de andra sidorna av mergen vandras aldrig.

--simplify-merges

Först byggs en historikgraf på samma sätt som --full-history med parent-omskrivning. Sedan förenklas varje commit C till sin ersättning C' i den slutliga historiken:

• Sätt C' till C.
• Ersätt varje parent P till C' med dess förenkling P'. Under processen tas parents bort om de är förfäder till andra parents, eller är rotcommitar som är TREESAME mot ett tomt träd. Dubbletter tas bort, men Git ser till att aldrig ta bort alla parents som commiten är TREESAME mot.
• Om C' efter omskrivningen är en rotcommit eller merge-commit, en boundary-commit eller !TREESAME, behålls den. Annars ersätts den med sin enda parent.

Exemplet blir:

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

De viktiga skillnaderna mot --full-history med parent-omskrivning är bland annat att N:s parent-lista fick I borttagen eftersom den är förfader till den andra parenten M, att P togs bort eftersom den blev en TREESAME-commit med en enda parent, och att Q på motsvarande sätt förenklades bort.

--ancestry-path[=<commit>]

Begränsa de visade commitarna till de som är förfader till <commit>, ättling till <commit>, eller <commit> själv.

Exempel:

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

Ett vanligt D..M beräknar commitar som är förfäder till M men utesluter de som är förfäder till D. I exemplet blir det alla commitar utom A och B samt D själv.

Om man vill hitta vilka commitar i M som är förorenade av en bugg introducerad i D vill man kanske bara visa delen av D..M som faktiskt är ättlingar till D. Det gör --ancestry-path:

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

Med --ancestry-path=H D..M blir resultatet:

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

Med --ancestry-path=K D..M blir resultatet:

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

--show-pulls

För att förstå --show-pulls används ett nytt exempel:

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

Anta att I skapade file.txt, som ändrades av A, B och X på olika sätt. Commits C, Z och Y ändrar inte file.txt. Mergen M löste konflikten genom att inkludera ändringar från både A och B och är därför inte TREESAME mot någon av dem. Mergen R skapades däremot genom att ignorera innehållet i file.txt vid M och endast ta innehållet från X. Därför är R TREESAME mot X, men inte mot M. Mergen N tar naturligt innehållet från R, så N är TREESAME mot R, men inte mot C. Mergarna O och P är TREESAME mot sina första parents, men inte mot sina andra parents Z respektive Y.

I standardläge har N och R båda en TREESAME-parent, så dessa kanter följs och övriga ignoreras. Resultatet blir:

        I---X

Med --full-history vandrar Git varje kant. Då hittas A, B och M, men även merge-commitarna O och P. Med parent-omskrivning blir grafen:

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

Mergarna O och P tillför här extra brus eftersom de inte faktiskt bidrog med en ändring till file.txt. De mergade bara topic branches som baserades på en äldre version av filen.

Med --simplify-merges försvinner O och P. Även N förenklas bort, vilket ger:

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

Detta visar de viktiga enkel-parent-ändringarna A, B och X, samt mergen M och den mindre lyckade mergen R. Nackdelen är att --simplify-merges måste vandra hela commit-historiken innan ett enda resultat kan returneras, vilket kan vara dyrt i stora arkiv.

--show-pulls visar, utöver standardhistoriken, varje merge-commit som inte är TREESAME mot sin första parent men är TREESAME mot en senare parent. En sådan merge behandlas som om den “drog in” ändringen från en annan gren. I exemplet ger --show-pulls resultatet:

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

Med --show-pulls tillsammans med --simplify-merges ingår all nödvändig information:

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

--simplify-by-decoration gör att man kan se den stora topologiska bilden genom att utelämna commitar som inte refereras av taggar. Commits markeras som !TREESAME om de refereras av taggar eller ändrar innehållet i sökvägarna som anges på kommandoraden. Alla andra commitar markeras som TREESAME och kan förenklas bort.

Hjälpmedel för bisect

--bisect

Begränsa utdata till det commit-objekt som ligger ungefär halvvägs mellan inkluderade och exkluderade commitar. Den dåliga bisect-referensen refs/bisect/bad läggs till bland de inkluderade commitarna om den finns, och de goda bisect-referenserna refs/bisect/good-* läggs till bland de exkluderade om de finns.

Om det inte finns några refs i refs/bisect/ och:

$ git rev-list --bisect foo ^bar ^baz

skriver ut midpoint, kommer följande två kommandon ge ungefär lika långa resultat:

$ git rev-list foo ^midpoint
$ git rev-list midpoint ^bar ^baz

Att hitta ändringen som introducerade en regression reduceras därmed till en binär sökning.

--bisect-vars

Beräknar samma sak som --bisect, men använder inte refs i refs/bisect/ och skriver ut text som är färdig att evalueras av skalet. Raderna sätter variabler som bisect_rev, bisect_nr, bisect_good, bisect_bad och bisect_all.

--bisect-all

Skriver ut alla commit-objekt mellan inkluderade och exkluderade commitar, sorterade efter avstånd till de inkluderade och exkluderade commitarna. De längst bort visas först. Detta är användbart när man vill välja en bra commit att testa men vill undvika vissa commitar, till exempel för att de inte kompilerar.

Alternativet kan användas tillsammans med --bisect-vars. Då skrivs samma variabeltext som med --bisect-vars ut efter den sorterade commit-listan.

Sortering av commitar

Som standard visas commitar i omvänd kronologisk ordning.

--date-order

Visa inga parents innan alla deras children har visats, men visa i övrigt commitar i commit-tidsstämpelordning.

--author-date-order

Visa inga parents innan alla deras children har visats, men visa i övrigt commitar i författartidsstämpelordning.

--topo-order

Visa inga parents innan alla deras children har visats, och undvik att blanda commitar från flera historielinjer.

Exempel:

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

Där siffrorna anger commit-tidsstämpelordning, visar git rev-list med --date-order commitarna som:

8 7 6 5 4 3 2 1

Med --topo-order kan resultatet bli:

8 6 5 3 7 4 2 1

eller:

8 7 4 2 6 5 3 1

Vissa äldre commitar visas före nyare för att undvika att två parallella utvecklingsspår blandas ihop.

--reverse

Skriv ut de valda commitarna i omvänd ordning. Kan inte kombineras med --walk-reflogs.

Objekttraversering

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

--objects

Skriv ut objekt-ID för alla objekt som refereras av de listade commitarna. Exempelvis betyder --objects foo ^bar: “skicka mig alla objekt-ID som jag behöver hämta om jag har commit-objektet bar men inte foo.” Se även --object-names.

--in-commit-order

Skriv ut tree- och blob-ID i commit-ordning. Tree- och blob-ID skrivs ut efter att de först refererats av en commit.

--objects-edge

Liknar --objects, men skriver också ut ID för exkluderade commitar med prefixet -. Detta används av git-pack-objects(1) för att bygga ett “thin pack”.

--objects-edge-aggressive

Liknar --objects-edge, men försöker hårdare hitta exkluderade commitar, vilket kostar mer tid. Detta används för att bygga thin packs för shallow repositories.

--indexed-objects

Låtsas som om alla träd och blobbar som används av indexet angavs på kommandoraden. Vanligen vill man även använda --objects.

--unpacked

Endast användbart med --objects. Skriv ut objekt-ID som inte finns i packfiler.

--object-names

Endast användbart med --objects. Skriv ut namnen på de objekt-ID som hittas. Detta är standard. Objektnamnet är tvetydigt och främst avsett som ledtråd vid packning av objekt. Det görs ingen skillnad mellan namn på taggar, träd och blobbar; sökvägar kan ändras för att ta bort radbrytningar; och om ett objekt skulle visas flera gånger med olika namn visas bara ett namn.

--no-object-names

Endast användbart med --objects. Skriv inte ut namnen på objekt-ID som hittas. Detta inverterar --object-names och gör utdata enklare att tolka av kommandon som git-cat-file(1).

--filter=<filterspec>

Endast användbart med något av --objects*. Utelämnar objekt, vanligen blobbar, från listan över utskrivna objekt.

Formen --filter=blob:none utelämnar alla blobbar.

Formen --filter=blob:limit=<n>[kmg] utelämnar blobbar med storlek minst <n> byte eller enheter. <n> kan vara noll. Suffixen k, m och g anger KiB, MiB respektive GiB.

Formen --filter=object:type=(tag|commit|tree|blob) utelämnar alla objekt som inte är av den begärda typen. Observera att explicit angivna objekt ignorerar filter och alltid skrivs ut om inte --filter-provided-objects också anges.

Formen --filter=sparse:oid=<blob-ish> använder en sparse-checkout-specifikation i den angivna blobben eller blob-uttrycket för att utelämna blobbar som inte skulle behövas för en sparse checkout av de begärda referenserna.

Formen --filter=tree:<djup> utelämnar alla blobbar och träd vars djup från rotträdet är större än eller lika med <djup>. Djupet är minsta djup om ett objekt finns på flera djup i de traverserade commitarna.

• <djup>=0 inkluderar inga träd eller blobbar om de inte anges explicit.
• <djup>=1 inkluderar endast träd och blobbar som refereras direkt av en nåbar commit eller ett explicit angivet objekt.
• <djup>=2 fungerar som 1 men inkluderar träd och blobbar ytterligare en nivå bort.

Formen --filter=sparse:path=<sökväg>, som läste från en godtycklig filsystemssökväg, har tagits bort av säkerhetsskäl.

Flera --filter=-flaggor kan anges för att kombinera filter. Endast objekt som accepteras av alla filter inkluderas.

Formen --filter=combine:<filter1>+<filter2>+...<filterN> kan också användas, men är svårare än att upprepa --filter och behövs sällan. Filter separeras med + och individuella filter är %-kodade, ungefär som URL-kodning. Utöver + och % är flera specialtecken reserverade och måste kodas.

--no-filter

Stäng av tidigare --filter=-argument.

--filter-provided-objects

Filtrera även listan över explicit angivna objekt. Annars skrivs sådana objekt alltid ut även om de inte matchar filtren. Endast användbart med --filter=.

--filter-print-omitted

Endast användbart med --filter=. Skriv ut en lista över objekt som utelämnats av filtret. Objekt-ID får prefixet ~.

--missing=<åtgärd>

Ett felsökningsalternativ för framtida arbete med partial clone. Det anger hur saknade objekt hanteras.

--missing=error gör att rev-list stoppar med fel om ett saknat objekt påträffas. Detta är standard.

--missing=allow-any tillåter objekttraverseringen att fortsätta om ett saknat objekt påträffas. Saknade objekt utelämnas tyst från resultatet.

--missing=allow-promisor liknar allow-any, men tillåter endast förväntade promisor-saknade objekt. Oväntat saknade objekt ger fel.

--missing=print liknar allow-any, men skriver också ut en lista över saknade objekt. Objekt-ID får prefixet ?.

--missing=print-info liknar print, men skriver även ut extra information om det saknade objektet, härledd från det innehållande objektet. Formen är:

?<oid> [<token>=<värde>]...

Tokenpar kan exempelvis vara:

• path=<sökväg> — visar sökvägen för det saknade objektet, härledd från ett innehållande objekt. Sökvägar med blanksteg eller specialtecken skrivs vid behov med C-liknande citattecken.
• type=<typ> — visar den saknade objektets typ, härledd från ett innehållande objekt.

Om vissa spetsar som skickas till traverseringen saknas betraktas de också som saknade och ignoreras. Om Git inte kan få deras objekt-ID uppstår dock ett fel.

--exclude-promisor-objects

Endast för internt bruk. Förfiltrera objekttraversering vid promisor-gränsen. Detta används med partial clone och är starkare än --missing=allow-promisor, eftersom det begränsar själva traverseringen i stället för att bara tysta fel om saknade objekt.

--no-walk[=(sorted|unsorted)]

Visa endast de angivna commitarna, men vandra inte deras förfäder. Detta har ingen effekt om ett intervall anges. Med argumentet unsorted visas commitarna i den ordning de angavs på kommandoraden. Annars, med sorted eller utan argument, visas de i omvänd kronologisk ordning efter commit-tid. Kan inte kombineras med --graph.

--do-walk

Åsidosätter ett tidigare --no-walk.

Commit-formatering

Med dessa alternativ beter sig git-rev-list(1) ungefär som de mer specialiserade commit-loggverktygen git-log(1), git-show(1) och git-whatchanged(1).

--pretty[=<format>], --format=<format>

Skriv commit-loggar i ett visst format. <format> kan vara oneline, short, medium, full, fuller, reference, email, raw, format:<sträng> eller tformat:<sträng>. Om formatet inte är något av dessa men innehåller %<platshållare> fungerar det som om --pretty=tformat:<format> hade angivits.

Se avsnittet “PRETTY FORMATS” för mer information. Om =<format> utelämnas används medium. Standardformat kan anges i arkivets konfiguration. Se git-config(1).

--abbrev-commit

Visa en unik förkortad prefixform av commit-objektnamnet i stället för hela det 40-byte långa hexadecimala namnet. --abbrev=<n> kan användas för att ange minsta längd på prefixet.

--no-abbrev-commit

Visa hela det 40-byte långa hexadecimala commit-objektnamnet. Detta upphäver --abbrev-commit, oavsett om det angavs explicit eller följde av alternativ som --oneline. Det åsidosätter även variabeln log.abbrevCommit.

--oneline

Kortform för:

--pretty=oneline --abbrev-commit

--encoding=<kodning>

Commit-objekt lagrar vilken teckenkodning som används för loggmeddelandet i sin encoding-header. Detta alternativ anger att commit-loggmeddelandet ska kodas om till användarens önskade kodning. För icke-plumbing-kommandon är standard UTF-8.

Om ett objekt säger sig vara kodat i X och Git skriver ut i X skrivs objektet ut ordagrant. Ogiltiga sekvenser i originalet kan därför kopieras till utdata. Om iconv(3) misslyckas med konverteringen skrivs också originalobjektet ut ordagrant.

--expand-tabs=<n>, --expand-tabs, --no-expand-tabs

Expandera tabbar i loggmeddelandet före utskrift. Varje tab ersätts av tillräckligt många blanksteg för att nå nästa displaykolumn som är en multipel av <n>. --expand-tabs är kortform för --expand-tabs=8. --no-expand-tabs är kortform för --expand-tabs=0 och stänger av tabbutökning.

Som standard expanderas tabbar i pretty-format som indenterar loggmeddelandet med fyra blanksteg, alltså medium, full och fuller.

--show-signature

Kontrollera giltigheten för ett signerat commit-objekt genom att skicka signaturen till gpg --verify och visa resultatet.

--relative-date

Synonym för --date=relative.

--date=<format>

Påverkar endast datum som visas i människoläsbart format, till exempel med --pretty. Konfigurationsvariabeln log.date anger ett standardvärde för loggkommandots --date-alternativ. Som standard visas datum i den ursprungliga tidszonen, antingen committerens eller författarens.

--date=relative visar datum relativt aktuell tid, exempelvis “2 hours ago”.

--date=local visar datum i användarens lokala tidszon.

--date=iso eller --date=iso8601 visar datum i ISO 8601-liknande format. Skillnaderna mot strikt ISO 8601 är bland annat att blanksteg används i stället för T mellan datum och tid, och att tidszonen skrivs utan kolon.

--date=iso-strict eller --date=iso8601-strict visar datum i strikt ISO 8601-format.

--date=rfc eller --date=rfc2822 visar datum i RFC 2822-format, vanligt i e-postmeddelanden.

--date=short visar endast datumet i formatet YYYY-MM-DD.

--date=raw visar datum som sekunder sedan epoken följt av tidszonsförskjutningen.

--date=human visar tidszonen om den inte matchar aktuell tidszon, och skriver inte ut hela datumet om det redan är tydligt. Exempelvis kan året utelämnas för datum under aktuellt år.

--date=unix visar datum som Unix-epoktidsstämpel.

--date=format:<format> matar formatet till systemets strftime.

--date=format-local:<format> fungerar som format:, men använder den lokala tidszonen.

--header

Skriv ut commitens råa header före den formaterade utskriften.

--no-commit-header

Undertryck headerraden som innehåller commit och objekt-ID.

--commit-header

Återaktivera headerraden som innehåller commit och objekt-ID efter ett tidigare --no-commit-header.

--parents

Skriv även ut parent-commitar. Aktiverar även parent-omskrivning i förenklad historik.

--children

Skriv även ut child-commitar. Aktiverar även parent-omskrivning i förenklad historik.

--timestamp

Skriv ut rå commit-tidsstämpel före varje commit.

--left-right

Markera vilken sida av en symmetrisk differens en commit kan nås från. Commits från vänster sida får prefixet <, och commitar från höger sida får >. Om --boundary används får boundary-commitar prefixet -.

--graph

Rita en textbaserad graf över commit-historiken till vänster om utdata. Detta kan göra att extra rader skrivs ut för att grafhistoriken ska ritas korrekt. Kan inte kombineras med --no-walk.

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

När --graph inte används visas alla historikgrenar normalt hoptryckta, vilket kan göra det svårt att se att två på varandra följande commitar inte hör till en linjär gren. Detta alternativ infogar en barriär mellan sådana commitar. Om <barriär> anges används den strängen i stället för standardsträngen.

--count

Skriv ut ett tal som anger hur många commitar som skulle ha listats, och undertryck övrig utdata. När det används tillsammans med --left-right skrivs antalet för vänster och höger sida separat. Tillsammans med --cherry-mark utelämnas patch-likvärdiga commitar från dessa antal och antalet likvärdiga commitar skrivs ut som ett tredje tal.

PRETTY FORMATS

Om commiten är en merge-commit, och om pretty-formatet inte är oneline, email eller raw, infogas en extra rad före raden Author:. Den raden börjar med Merge: och följs av hashvärdena för föräldra-commitarna, separerade med blanksteg. Observera att de commitar som listas inte nödvändigtvis är den direkta listan över parent-commitar om historiken har begränsats, till exempel om du bara visar ändringar som rör en viss katalog eller fil.

Det finns flera inbyggda format, och du kan definiera egna format genom att sätta konfigurationsalternativet pretty.<namn> till antingen ett annat formatnamn eller till en format:-sträng enligt beskrivningen nedan. Se även git-config(1).

Här är detaljerna för de inbyggda formaten:

oneline

<hash> <title-line>

Detta format är avsett att vara så kompakt som möjligt.

short

commit <hash>
Author: <author>

<title-line>

medium

commit <hash>
Author: <author>
Date:   <author-date>

<title-line>

<full-commit-message>

full

commit <hash>
Author: <author>
Commit: <committer>

<title-line>

<full-commit-message>

fuller

commit <hash>
Author:     <author>
AuthorDate: <author-date>
Commit:     <committer>
CommitDate: <committer-date>

<title-line>

<full-commit-message>

reference

<abbrev-hash> (<title-line>, <short-author-date>)

Detta format används för att hänvisa till en annan commit i ett commit-meddelande och motsvarar:

--pretty='format:%C(auto)%h (%s, %ad)'

Som standard formateras datumet med --date=short, om inget annat --date-alternativ uttryckligen anges. Precis som andra format:-strängar med platshållare påverkas utdata inte av andra alternativ som --decorate och --walk-reflogs.

email

From <hash> <date>
From: <author>
Date: <author-date>
Subject: [PATCH] <title-line>

<full-commit-message>

mboxrd

Som email, men rader i commit-meddelandet som börjar med From — eventuellt föregånget av ett eller flera > — citeras med > så att de inte misstolkas som början på en ny commit.

raw

Formatet raw visar hela commiten exakt som den är lagrad i commit-objektet. Hashvärden visas i full längd oavsett om --abbrev eller --no-abbrev används, och parent-information visar de verkliga parent-commitarna utan hänsyn till grafts eller historikförenkling. Observera att formatet påverkar hur commitar visas, men inte hur diffen visas, till exempel med git log --raw. Använd --no-abbrev för att få fullständiga objektnamn i raw-difformat.

format:<format-sträng>

Formatet format:<format-sträng> låter dig ange exakt vilken information som ska visas. Det fungerar ungefär som printf-format, med den viktiga skillnaden att radbrytning skrivs som %n i stället för \n.

Exempel:

format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"

kan visa något i stil med:

The author of fe6e0ee was Junio C Hamano, 23 hours ago
The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<

Följande platshållare är tillgängliga.

Platshållare som utvidgas till ett enskilt bokstavstecken

%n

Radbrytning.

%%

Ett rått procenttecken.

%x00

%x följt av två hexadecimala siffror ersätts med en byte med värdet från de hexadecimala siffrorna. I resten av dokumentet kallas detta för en bokstavlig formateringskod.

Platshållare som påverkar formateringen av efterföljande platshållare

%Cred

Byt färg till rött.

%Cgreen

Byt färg till grönt.

%Cblue

Byt färg till blått.

%Creset

Återställ färgen.

%C(<spec>)

Färgspecifikation enligt beskrivningen av värden i avsnittet “CONFIGURATION FILE” i git-config(1). Som standard visas färger endast när färgutdata är aktiverad för loggutdata. %C(always,<spec>) visar färger även när färg annars inte är aktiverad. Ofta är --color=always ett bättre sätt att aktivera färg i hela utdata. %C(auto) aktiverar automatisk färgning för efterföljande platshållare tills färgen ändras igen.

%m

Vänster-, höger- eller gränsmarkering: <, > eller -.

%w([<w>[,<i1>[,<i2>]]])

Slå på radbrytning, på samma sätt som flaggan -w i git-shortlog(1).

%<(<n>[,(trunc|ltrunc|mtrunc)])

Låt nästa platshållare ta minst <n> kolumnbredder. Om det behövs fylls den ut med blanksteg till höger. Om utdata är längre än <n> kolumner kan den kortas av med ellipsen ..:

ltrunc  ..ft
mtrunc  mi..le
trunc   rig..

Förkortning fungerar korrekt endast när <n> är minst 2. Breda tecken, exempelvis emoji, kan ta två kolumner och kombinerande tecken kan hamna fel vid utfyllnadsgränser.

%<|(<m>)

Låt nästa platshållare ta minst så många kolumner som behövs för att nå displaykolumn <m>. Om <m> är negativ räknas positionen från terminalfönstrets högra kant.

%>(<n>), %>|(<m>)

Liknar %< och %<|, men fyller ut med blanksteg till vänster.

%>>(<n>), %>>|(<m>)

Liknar %> och %>|, men om nästa platshållare tar mer utrymme än angivet och det finns blanksteg till vänster om den, används dessa blanksteg.

%><(<n>), %><|(<m>)

Liknar %< och %<|, men fyller ut på båda sidor så att texten centreras.

Platshållare som utvidgas till information från commiten

%H

Commit-hash.

%h

Förkortad commit-hash.

%T

Tree-hash.

%t

Förkortad tree-hash.

%P

Parent-hashar.

%p

Förkortade parent-hashar.

%an, %aN

Författarens namn, respektive författarens namn med hänsyn till .mailmap. Se git-shortlog(1) eller git-blame(1).

%ae, %aE

Författarens e-postadress, respektive e-postadress med hänsyn till .mailmap.

%al, %aL

Den lokala delen av författarens e-postadress, alltså delen före @, respektive samma uppgift med hänsyn till .mailmap.

%ad, %aD, %ar, %at, %ai, %aI, %as, %ah

Författardatum i olika format: enligt --date=<format>, RFC 2822, relativt, Unix-tidsstämpel, ISO 8601-liknande, strikt ISO 8601, kort format YYYY-MM-DD och mänskligt anpassat format.

%cn, %cN

Committer-namn, respektive committer-namn med hänsyn till .mailmap.

%ce, %cE

Committer-e-postadress, respektive committer-e-postadress med hänsyn till .mailmap.

%cl, %cL

Den lokala delen av committer-e-postadressen, respektive samma uppgift med hänsyn till .mailmap.

%cd, %cD, %cr, %ct, %ci, %cI, %cs, %ch

Committer-datum i olika format: enligt --date=<format>, RFC 2822, relativt, Unix-tidsstämpel, ISO 8601-liknande, strikt ISO 8601, kort format YYYY-MM-DD och mänskligt anpassat format.

%d

Ref-namn, på samma sätt som --decorate i git-log(1).

%D

Ref-namn utan omslutningen " (" och ")".

%(decorate[:<alternativ>,...])

Ref-namn med anpassade dekorationer. Alternativ kan styra prefix, suffix, separator, pointer och tag. Standardvärden är bland annat " (", ")", , ', " → " och "tag: ". Om värden innehåller kommatecken eller avslutande parentes måste bokstavliga formateringskoder som %x2C och %x29 användas.

Exempel:

%(decorate:prefix=,suffix=,tag=,separator= )

%(describe[:<alternativ>,...])

Ett mänskligt läsbart namn, ungefär som git-describe(1). För commitar som inte kan beskrivas blir resultatet en tom sträng. Alternativ kan bland annat vara tags, abbrev=<antal>, match=<mönster> och exclude=<mönster>.

%S

Ref-namn som angavs på kommandoraden och som gjorde att commiten nåddes, ungefär som git log --source. Fungerar endast med git log.

%e

Kodning.

%s

Ämnesrad.

%f

Sanerad ämnesrad, lämplig som filnamn.

%b

Brödtext.

%B

Rå brödtext, alltså ämnesrad och brödtext utan uppdelning.

%GG

Rå verifieringsmeddelande från GPG för en signerad commit.

%G?

Visar status för signaturen:

G  god och giltig signatur
B  dålig signatur
U  god signatur med okänd giltighet
X  god signatur som har gått ut
Y  god signatur skapad med en utgången nyckel
R  god signatur skapad med en återkallad nyckel
E  signaturen kan inte kontrolleras, exempelvis på grund av saknad nyckel
N  ingen signatur

%GS

Namnet på den som signerade en signerad commit.

%GK

Nyckeln som användes för att signera en signerad commit.

%GF

Fingeravtrycket för nyckeln som användes för att signera en signerad commit.

%GP

Fingeravtrycket för den primära nyckel vars undernyckel användes för att signera en signerad commit.

%GT

Tillitsnivån för nyckeln som användes för att signera en signerad commit.

%gD

Reflog-väljare, till exempel:

refs/stash@{1}
refs/stash@{2 minutes ago}

%gd

Förkortad reflog-väljare. Samma som %gD, men ref-namndelen förkortas för att bli mer läsbar.

%gn, %gN

Namn för reflog-identitet, respektive samma namn med hänsyn till .mailmap.

%ge, %gE

E-postadress för reflog-identitet, respektive samma e-postadress med hänsyn till .mailmap.

%gs

Reflog-ämne.

%(trailers[:<alternativ>,...])

Visar trailers från brödtexten så som de tolkas av git-interpret-trailers(1). Alternativ kan bland annat vara:

key=<nyckel>

Visa endast trailers med angiven nyckel. Matchningen är skiftlägesokänslig och avslutande kolon är valfritt. Detta aktiverar automatiskt only.

only[=<bool>]

Välj om rader som inte är trailers i trailer-blocket ska tas med.

separator=<avskiljare>

Anger avskiljaren mellan trailer-rader. Standard är radmatning. Använd %x2C om ett kommatecken ska ingå i avskiljaren.

unfold[=<bool>]

Motsvarar att --unfold gavs till interpret-trailers.

keyonly[=<bool>]

Visa endast trailerns nyckel.

valueonly[=<bool>]

Visa endast trailerns värde.

key_value_separator=<avskiljare>

Anger avskiljaren mellan nyckel och värde för varje trailer. Standard är ": ".

Anmärkningar om platshållare

Vissa platshållare beror på andra alternativ till revisionsgenomgångsmotorn. Exempelvis ger reflog-platshållarna %g* en tom sträng om Git inte går igenom reflog-poster.

Platshållarna %d och %D använder kort dekorationsformat om --decorate inte redan angavs.

Booleska alternativ accepterar ett valfritt värde. Alla värden som accepteras av --type=bool i git-config(1), till exempel yes och off, accepteras. Ett booleskt alternativ utan värde motsvarar =true.

Om du lägger till + efter % i en platshållare infogas en radmatning direkt före expansionen, men endast om platshållaren expanderas till en icke-tom sträng.

Om du lägger till - efter % i en platshållare tas alla sammanhängande radmatningar direkt före expansionen bort, men endast om platshållaren expanderas till en tom sträng.

Om du lägger till ett blanksteg efter % i en platshållare infogas ett blanksteg direkt före expansionen, men endast om platshållaren expanderas till en icke-tom sträng.

tformat:

Formatet tformat: fungerar exakt som format:, förutom att det använder terminator-semantik i stället för separator-semantik. Varje commit får alltså ett avslutande tecken, vanligen en radbrytning, i stället för att separatorn bara placeras mellan poster.

Detta innebär att den sista posten i ett enradigt format avslutas korrekt med radbrytning, precis som formatet oneline.

Exempel med format::

$ git log -2 --pretty=format:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973 -- NO NEWLINE

Med tformat::

$ git log -2 --pretty=tformat:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973

Dessutom tolkas en okänd sträng som innehåller % som om tformat: stod framför den. Följande två kommandon är därför likvärdiga:

$ git log -2 --pretty=tformat:%h 4da45bef
$ git log -2 --pretty=%h 4da45bef

EXEMPEL

Skriv ut listan över commitar som kan nås från den aktuella grenen.

git rev-list HEAD

Skriv ut listan över commitar på denna gren, men inte i upstream-grenen.

git rev-list @{upstream}..HEAD

Formatera commitar med författare och commit-meddelande. Se även porcelain-kommandot git-log(1).

git rev-list --format=medium HEAD

Formatera commitar tillsammans med deras diffar. Se även porcelain-kommandot git-log(1), som kan göra detta i en enda process.

git rev-list HEAD |
git diff-tree --stdin --format=medium -p

Skriv ut listan över commitar på den aktuella grenen som rörde någon fil i katalogen Documentation.

git rev-list HEAD -- Documentation/

Skriv ut listan över commitar som du har skapat under det senaste året, på valfri gren, tagg eller annan ref.

git rev-list --author=you@example.com --since=1.year.ago --all

Skriv ut listan över objekt som kan nås från den aktuella grenen, alltså alla commitar och de blobbar och träd som de innehåller.

git rev-list --objects HEAD

Jämför diskstorleken för alla nåbara objekt, objekt som kan nås från refloggar och den totala packade storleken. Detta kan visa om git repack -ad kan minska arkivets storlek genom att ta bort onåbara objekt, och om det kan hjälpa att rensa refloggar.

# nåbara objekt
git rev-list --disk-usage --objects --all
# plus refloggar
git rev-list --disk-usage --objects --all --reflog
# total använd diskstorlek
du -c .git/objects/pack/*.pack .git/objects/??/*
# alternativ till du: summera fälten "size" och "size-pack"
git count-objects -v

Rapportera diskstorleken för varje gren, utan objekt som används av den aktuella grenen. Detta kan hitta avvikande grenar som bidrar till att arkivet blivit onödigt stort, exempelvis om någon råkat checka in stora byggartefakter.

git for-each-ref --format='%(refname)' |
while read branch
do
        size=$(git rev-list --disk-usage --objects HEAD..$branch)
        echo "$size $branch"
done |
sort -n

Jämför storleken på disk för grenar i en grupp refs, men uteslut en annan grupp. Om du blandar objekt från flera remotes i ett enda arkiv kan detta visa vilka remotes som bidrar till arkivets storlek, med storleken för origin som baslinje.

git rev-list --disk-usage --objects --remotes=$suspect --not --remotes=origin

GIT

Del av git(1)-sviten.

COLOPHON

Denna manualsida är en del av projektet git, det distribuerade versionshanteringssystemet Git. Information om projektet finns på Git-projektets webbplats. För felrapporter om Git hänvisas till Git-projektets gemenskaps- och supportresurser.

Den HTML-version som användes som källa anger att sidan hämtades från projektets upstream Git-repository den 2026-01-16. Vid det tillfället var den senaste commit som hittades i repositoryt daterad 2026-01-15. Sidans HTML-rendering skapades av Michael Kerrisk för man7.org.

Sidslut

Orginalhemsidan på Engelska https://man7.org/linux/man-pages/man1/git-rev-list.1.html Det här är en maskinöversättning av Linux man sidor till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på https://www.linux.se/kontaka-linux-se/

Tack till Datorhjälp hemma som har sponsrat Linux.se med webbhotell.