git-rev-list(1): Skillnad mellan sidversioner
Admin (diskussion | bidrag) (Skapade sidan med '== NAMN == '''git-rev-list''' — listar commit-objekt i omvänd kronologisk ordning == SYNOPSIS == <pre> git rev-list [<flaggor>] <commit>... [--] [<sökväg>...] </pre> == BESKRIVNING == '''git rev-list''' listar commits som kan nås genom att följa '''parent'''-länkarna från de angivna commit-objekten, men utesluter commits som kan nås från de objekt som anges med ett '''^''' framför sig. Utdata ges som standard i omvänd kronologisk ordning. Man kan tänk...') |
Admin (diskussion | bidrag) Ingen redigeringssammanfattning |
||
| Rad 611: | Rad 611: | ||
Flaggan kan anges flera gånger. Om så sker inkluderas en commit om den är någon av de angivna commitsen, eller om den är förfader eller ättling till någon av dem. | Flaggan kan anges flera gånger. Om så sker inkluderas en commit om den är någon av de angivna commitsen, eller om den är förfader eller ättling till någon av dem. | ||
'''--simplify-by-decoration''' | |||
Flaggan '''--simplify-by-decoration''' gör det möjligt att bara se den stora bilden av historikens topologi genom att utelämna commits som inte refereras av taggar. | |||
Commits markeras som '''!TREESAME''' — med andra ord behålls de efter reglerna för historieförenkling ovan — om: | |||
1. de refereras av taggar, eller | |||
2. de ändrar innehållet i de sökvägar som anges på kommandoraden. | |||
Alla andra commits markeras som '''TREESAME''' och kan därmed förenklas bort. | |||
=== Hjälp för bisect === | |||
'''--bisect''' | |||
Begränsa utdata till ett enda commit-objekt som ligger ungefär halvvägs mellan inkluderade och exkluderade commits. | |||
Observera att den dåliga bisect-referensen: | |||
<pre> | |||
refs/bisect/bad | |||
</pre> | |||
läggs till bland de inkluderade commitsen, om den finns. De goda bisect-referenserna: | |||
<pre> | |||
refs/bisect/good-* | |||
</pre> | |||
läggs till bland de exkluderade commitsen, om de finns. | |||
Om det inte finns några referenser i: | |||
<pre> | |||
refs/bisect/ | |||
</pre> | |||
och följande kommando: | |||
<pre> | |||
$ git rev-list --bisect foo ^bar ^baz | |||
</pre> | |||
skriver ut <i>midpoint</i>, kommer följande två kommandon att ge utdata av ungefär samma längd: | |||
<pre> | |||
$ git rev-list foo ^midpoint | |||
$ git rev-list midpoint ^bar ^baz | |||
</pre> | |||
Att hitta den ändring som introducerar en regression reduceras därmed till en binär sökning: generera och testa upprepade gånger nya "mittpunkter" tills commit-kedjan har längden ett. | |||
'''--bisect-vars''' | |||
Beräknar samma sak som '''--bisect''', men använder inte referenser i: | |||
<pre> | |||
refs/bisect/ | |||
</pre> | |||
Dessutom skrivs text ut som är redo att köras med shellens '''eval'''. | |||
Raderna tilldelar: | |||
'''bisect_rev''' | |||
Namnet på mittpunktsrevisionen. | |||
'''bisect_nr''' | |||
Förväntat antal commits som återstår att testa efter att '''bisect_rev''' har testats. | |||
'''bisect_good''' | |||
Förväntat antal commits som återstår att testa om '''bisect_rev''' visar sig vara god. | |||
'''bisect_bad''' | |||
Förväntat antal commits som återstår att testa om '''bisect_rev''' visar sig vara dålig. | |||
'''bisect_all''' | |||
Antalet commits som för närvarande ingår i bisect-sökningen. | |||
'''--bisect-all''' | |||
Skriver ut alla commit-objekt mellan inkluderade och exkluderade commits, sorterade efter deras avstånd till de inkluderade och exkluderade commitsen. | |||
Referenser i: | |||
<pre> | |||
refs/bisect/ | |||
</pre> | |||
används inte. | |||
Den commit som ligger längst bort visas först. Det är denna enda commit som visas när '''--bisect''' används. | |||
Detta är användbart eftersom det gör det enkelt att välja en bra commit att testa när man av någon anledning vill undvika att testa vissa commits, till exempel om de inte kan kompileras. | |||
Flaggan kan användas tillsammans med '''--bisect-vars'''. I så fall skrivs samma text ut som med '''--bisect-vars''' efter alla sorterade commit-objekt. | |||
=== Commit-sortering === | |||
Som standard visas commits i omvänd kronologisk ordning. | |||
'''--date-order''' | |||
Visa ingen parent före att alla dess children har visats, men visa i övrigt commits i ordning efter commit-tidsstämpel. | |||
'''--author-date-order''' | |||
Visa ingen parent före att alla dess children har visats, men visa i övrigt commits i ordning efter author-tidsstämpel. | |||
'''--topo-order''' | |||
Visa ingen parent före att alla dess children har visats, och undvik att blanda commits från flera parallella historiklinjer. | |||
Exempel på commit-historik: | |||
<pre> | |||
---1----2----4----7 | |||
\ \ | |||
3----5----6----8--- | |||
</pre> | |||
där siffrorna anger commit-tidsstämplarnas ordning. | |||
Med '''git rev-list''' och liknande kommandon med '''--date-order''' visas commits i tidsstämpelordning: | |||
<pre> | |||
8 7 6 5 4 3 2 1 | |||
</pre> | |||
Med '''--topo-order''' kan de i stället visas som: | |||
<pre> | |||
8 6 5 3 7 4 2 1 | |||
</pre> | |||
eller: | |||
<pre> | |||
8 7 4 2 6 5 3 1 | |||
</pre> | |||
Det innebär att vissa äldre commits kan visas före nyare commits för att undvika att parallella utvecklingsspår blandas ihop. | |||
'''--reverse''' | |||
Skriv ut de valda commitsen i omvänd ordning. | |||
Kan inte kombineras med '''--walk-reflogs'''. | |||
=== Objekttraversering === | |||
Dessa flaggor är främst avsedda för packning av Git-arkiv. | |||
'''--objects''' | |||
Skriv ut objekt-ID:n för alla objekt som refereras av de listade commitsen. | |||
Exempel: | |||
<pre> | |||
--objects foo ^bar | |||
</pre> | |||
betyder ungefär: "ge mig alla objekt-ID:n som jag behöver ladda ner om jag har commit-objektet '''bar''' men inte '''foo'''". | |||
Se även '''--object-names''' nedan. | |||
'''--in-commit-order''' | |||
Skriv ut träd- och blob-ID:n i commit-ordning. Träd- och blob-ID:n skrivs ut efter att de först refererats av en commit. | |||
'''--objects-edge''' | |||
Liknar '''--objects''', men skriver även ut ID:n för exkluderade commits med ett '''-''' framför. | |||
Detta används av [[git-pack-objects(1)]] för att bygga ett "tunt" pack, där objekt lagras i deltaform baserat på objekt som finns i dessa exkluderade commits. Det minskar nätverkstrafiken. | |||
'''--objects-edge-aggressive''' | |||
Liknar '''--objects-edge''', men försöker hårdare att hitta exkluderade commits, till priset av längre körningstid. | |||
Detta används i stället för '''--objects-edge''' för att bygga tunna pack för grunda arkiv. | |||
'''--indexed-objects''' | |||
Låtsas som om alla träd och blobbar som används av indexet angivits på kommandoraden. | |||
Observera att man troligen även vill använda '''--objects'''. | |||
'''--unpacked''' | |||
Endast användbar tillsammans med '''--objects'''. Skriv ut objekt-ID:n som inte finns i packfiler. | |||
'''--object-names''' | |||
Endast användbar tillsammans med '''--objects'''. Skriv ut namnen på de objekt-ID:n som hittas. Detta är standardbeteendet. | |||
Observera att "namnet" på varje objekt är tvetydigt och främst är avsett som en ledtråd vid packning av objekt. | |||
I synnerhet gäller: | |||
* ingen skillnad görs mellan namn på taggar, träd och blobbar, | |||
* sökvägsnamn kan ändras för att ta bort radbrytningar, | |||
* om ett objekt förekommer flera gånger med olika namn visas endast ett namn. | |||
'''--no-object-names''' | |||
Endast användbar tillsammans med '''--objects'''. Skriv inte ut namnen på objekt-ID:n som hittas. | |||
Detta inverterar '''--object-names''' och gör utdata enklare att tolka för kommandon som [[git-cat-file(1)]]. | |||
'''--filter='''<i><filter-spec></i> | |||
Endast användbar tillsammans med någon av '''--objects'''-flaggorna. Utelämnar objekt, vanligen blobbar, från listan över utskrivna objekt. | |||
<i><filter-spec></i> kan ha följande former: | |||
'''--filter=blob:none''' | |||
Utelämnar alla blobbar. | |||
'''--filter=blob:limit='''<i><n></i>['''kmg'''] | |||
Utelämnar blobbar med storlek minst <i><n></i> byte eller enheter. <i><n></i> kan vara noll. | |||
Suffixen '''k''', '''m''' och '''g''' kan användas för KiB, MiB eller GiB. | |||
Exempel: | |||
<pre> | |||
blob:limit=1k | |||
</pre> | |||
är samma som: | |||
<pre> | |||
blob:limit=1024 | |||
</pre> | |||
'''--filter=object:type='''('''tag'''|'''commit'''|'''tree'''|'''blob''') | |||
Utelämnar alla objekt som inte är av den begärda typen. | |||
Observera att uttryckligen angivna objekt ignorerar filter och alltid skrivs ut, om inte '''--filter-provided-objects''' också anges. | |||
'''--filter=sparse:oid='''<i><blob-ish></i> | |||
Använder en sparse-checkout-specifikation som finns i blobben, eller blob-uttrycket, <i><blob-ish></i> för att utelämna blobbar som inte skulle krävas för en sparse checkout på de begärda referenserna. | |||
'''--filter=tree:'''<i><djup></i> | |||
Utelämnar alla blobbar och träd vars djup från rotträdet är större än eller lika med <i><djup></i>. | |||
Om ett objekt finns på flera djup används minsta djup. | |||
<pre> | |||
<djup>=0 | |||
</pre> | |||
inkluderar inga träd eller blobbar, om de inte uttryckligen anges på kommandoraden eller via standard in när '''--stdin''' används. | |||
<pre> | |||
<djup>=1 | |||
</pre> | |||
inkluderar endast trädet och blobbarna som refereras direkt av en commit som kan nås från <i><commit></i>, eller från ett uttryckligen angivet objekt. | |||
<pre> | |||
<djup>=2 | |||
</pre> | |||
är som <i><djup>=1</i>, men inkluderar även träd och blobbar ytterligare en nivå bort från en uttryckligen angiven commit eller ett uttryckligen angivet träd. | |||
Observera att formen: | |||
<pre> | |||
--filter=sparse:path=<sökväg> | |||
</pre> | |||
som ville läsa från en godtycklig sökväg i filsystemet har tagits bort av säkerhetsskäl. | |||
Flera '''--filter='''-flaggor kan anges för att kombinera filter. Endast objekt som accepteras av varje filter inkluderas. | |||
Formen: | |||
<pre> | |||
--filter=combine:<filter1>+<filter2>+...+<filterN> | |||
</pre> | |||
kan också användas för att kombinera flera filter, men detta är svårare än att bara upprepa '''--filter''' och är normalt inte nödvändigt. | |||
Filter fogas samman med '''+''' och enskilda filter procentkodas, det vill säga URL-kodas. | |||
Förutom '''+''' och '''%''' är följande tecken reserverade och måste också kodas: | |||
<pre> | |||
~ ! @ # $ ^ & * ( ) [ ] { } ; " , < > ? ' ` | |||
</pre> | |||
samt alla tecken med ASCII-kod mindre än eller lika med: | |||
<pre> | |||
0x20 | |||
</pre> | |||
vilket inkluderar mellanslag och radbrytning. | |||
Andra godtyckliga tecken kan också kodas. | |||
Exempelvis är följande likvärdiga: | |||
<pre> | |||
combine:tree:3+blob:none | |||
combine:tree%3A3+blob%3Anone | |||
</pre> | |||
'''--no-filter''' | |||
Stäng av tidigare angiven '''--filter='''-flagga. | |||
'''--filter-provided-objects''' | |||
Filtrera listan över uttryckligen angivna objekt. Dessa skrivs annars alltid ut även om de inte matchar något filter. | |||
Endast användbar tillsammans med '''--filter='''. | |||
'''--filter-print-omitted''' | |||
Endast användbar tillsammans med '''--filter='''. Skriver ut en lista över objekten som utelämnades av filtret. Objekt-ID:n får prefixet '''~'''. | |||
'''--missing='''<i><åtgärd-för-saknat></i> | |||
En felsökningsflagga som hjälper framtida utveckling av "partial clone". Den anger hur saknade objekt ska hanteras. | |||
'''--missing=error''' | |||
Stoppa '''rev-list''' med fel om ett saknat objekt påträffas. Detta är standard. | |||
'''--missing=allow-any''' | |||
Tillåt objekttraversering att fortsätta om ett saknat objekt påträffas. Saknade objekt utelämnas tyst från resultatet. | |||
'''--missing=allow-promisor''' | |||
Som '''allow-any''', men tillåt endast traversering att fortsätta för förväntade promisor-saknade objekt. Oväntade saknade objekt ger fel. | |||
'''--missing=print''' | |||
Som '''allow-any''', men skriver också ut en lista över saknade objekt. Objekt-ID:n får prefixet '''?'''. | |||
'''--missing=print-info''' | |||
Som '''print''', men skriver även ut ytterligare information om det saknade objektet, härledd från det objekt som innehåller det. | |||
Informationen skrivs på samma rad som det saknade objektets ID i formen: | |||
<pre> | |||
?<oid> [<token>=<värde>]... | |||
</pre> | |||
Par av typen <i><token></i>=''''''<i><värde></i> separeras med mellanslag. | |||
Värdet kodas på ett sätt som beror på token-typen, men mellanslag och radbrytningar i värdet förväntas alltid representeras så att resultatet inte innehåller någon av dessa problematiska byte. | |||
Möjliga token-värden är bland annat: | |||
'''path='''<i><sökväg></i> | |||
Visar sökvägen för det saknade objektet, härledd från ett innehållande objekt. En sökväg som innehåller mellanslag eller specialtecken omges med dubbla citattecken i C-stil vid behov. | |||
'''type='''<i><typ></i> | |||
Visar typen för det saknade objektet, härledd från ett innehållande objekt. | |||
Om vissa tips som skickas till traverseringen saknas, betraktas de också som saknade och traverseringen ignorerar dem. Om deras objekt-ID inte kan hämtas uppstår dock ett fel. | |||
'''--exclude-promisor-objects''' | |||
Endast för internt bruk. | |||
Förfiltrerar objekttraversering vid promisor-gränsen. Detta används med partial clone. | |||
Detta ä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 commitsen, men traversera inte deras förfäder. | |||
Detta har ingen effekt om ett intervall anges. | |||
Om argumentet '''unsorted''' anges visas commits i den ordning de gavs på kommandoraden. | |||
Annars, om '''sorted''' anges eller inget argument ges, visas commits i omvänd kronologisk ordning efter commit-tid. | |||
Kan inte kombineras med '''--graph'''. | |||
'''--do-walk''' | |||
Åsidosätter tidigare '''--no-walk'''. | |||
Versionen från 24 maj 2026 kl. 04.18
NAMN
git-rev-list — listar commit-objekt i omvänd kronologisk ordning
SYNOPSIS
git rev-list [<flaggor>] <commit>... [--] [<sökväg>...]
BESKRIVNING
git rev-list listar commits som kan nås genom att följa parent-länkarna från de angivna commit-objekten, men utesluter commits som kan nås från de objekt som anges med ett ^ framför sig. Utdata ges som standard i omvänd kronologisk ordning.
Man kan tänka på detta som en mängdoperation. Commits som kan nås från någon av de commits som anges på kommandoraden bildar en mängd. Därefter dras de commits bort som kan nås från någon av de commits som anges med ^ framför sig. De återstående commitsen är de som skrivs ut.
Olika andra flaggor och sökvägsparametrar kan användas för att begränsa resultatet ytterligare.
Exempel:
$ git rev-list foo bar ^baz
betyder: lista alla commits som kan nås från foo eller bar, men inte från baz.
En särskild notation:
<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 sammanslagningar. Den resulterande mängden commits är den symmetriska differensen mellan de två operanderna.
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 ger möjlighet att bygga och traversera commit-grafer. Därför har det många olika flaggor som gör att det kan användas av så olika kommandon som git bisect och git repack.
FLAGGOR
Begränsning av commits
Förutom att ange ett intervall av commits som ska listas med de särskilda notationerna ovan, kan ytterligare begränsningar användas.
Fler flaggor begränsar i allmänhet utdata ytterligare. Exempel: --since=<datum1> begränsar till commits nyare än <datum1>, och om den används tillsammans med --grep=<mönster> begränsas resultatet ytterligare till commits vars loggmeddelande innehåller en rad som matchar <mönster>, om inget annat anges.
Dessa begränsningar tillämpas före sorterings- och formateringsflaggor, som till exempel --reverse.
-<antal>, -n <antal>, --max-count=<antal>
Begränsa utdata till <antal> commits.
--skip=<antal>
Hoppa över <antal> commits innan utdata börjar visas.
--since=<datum>, --after=<datum>
Visa commits som är nyare än <datum>.
--since-as-filter=<datum>
Visa alla commits som är nyare än <datum>. Detta besöker alla commits i intervallet, i stället för att stanna vid den första commit som är äldre än <datum>.
--until=<datum>, --before=<datum>
Visa commits som är äldre än <datum>.
--max-age=<tidsstämpel>, --min-age=<tidsstämpel>
Begränsa utdata till ett angivet tidsintervall.
--author=<mönster>, --committer=<mönster>
Begränsa commit-utdata till commits vars author- eller committer-rader matchar det reguljära uttrycket <mönster>.
Om flera --author=<mönster> anges väljs commits där författaren matchar något av mönstren. Detsamma gäller flera --committer=<mönster>.
--grep-reflog=<mönster>
Begränsa commit-utdata till commits med reflog-poster som matchar det reguljära uttrycket <mönster>.
Om flera --grep-reflog anges väljs commits vars reflog-meddelande matchar något av mönstren.
Det är ett fel att använda denna flagga om inte --walk-reflogs används.
--grep=<mönster>
Begränsa commit-utdata till commits vars loggmeddelande matchar det reguljära uttrycket <mönster>.
Om flera --grep=<mönster> anges väljs commits vars meddelande matchar något av mönstren, se dock --all-match.
--all-match
Begränsa commit-utdata till commits som matchar alla angivna --grep-mönster, i stället för commits som matchar minst ett.
--invert-grep
Begränsa commit-utdata till commits vars loggmeddelande inte matchar mönstret som angivits med --grep=<mönster>.
-i, --regexp-ignore-case
Matcha reguljära uttryck utan hänsyn till versaler och gemener.
--basic-regexp
Tolkar begränsningsmönstren som grundläggande reguljära uttryck. Detta är standard.
-E, --extended-regexp
Tolkar begränsningsmönstren som utökade reguljära uttryck i stället för grundläggande reguljära uttryck.
-F, --fixed-strings
Tolkar begränsningsmönstren som fasta strängar. Mönstret tolkas alltså inte som ett reguljärt uttryck.
-P, --perl-regexp
Tolkar begränsningsmönstren som Perl-kompatibla reguljära uttryck.
Stöd för dessa reguljära uttryck är ett valfritt kompileringsberoende. Om Git inte kompilerats med stöd för dem kommer kommandot att avslutas med fel när denna flagga används.
--remove-empty
Stanna när en angiven sökväg försvinner från trädet.
--merges
Skriv endast ut merge-commits. Detta är exakt samma som:
--min-parents=2
--no-merges
Skriv inte ut commits med mer än en parent. Detta är exakt samma som:
--max-parents=1
--min-parents=<antal>, --max-parents=<antal>, --no-min-parents, --no-max-parents
Visa endast commits som har minst, eller högst, det angivna antalet parent-commits.
Särskilda fall:
--max-parents=1
är samma som --no-merges.
--min-parents=2
är samma som --merges.
--max-parents=0
ger alla rot-commits.
--min-parents=3
ger alla octopus-merges.
--no-min-parents och --no-max-parents återställer dessa begränsningar. Likvärdiga former är:
--min-parents=0 --max-parents=-1
Negativa tal betyder ingen övre gräns.
--first-parent
När commits som ska inkluderas hittas, följ endast den första parent-commiten när en merge-commit påträffas.
Detta kan ge en bättre överblick när man visar utvecklingen av en viss topic branch, eftersom sammanslagningar in i en topic branch ofta bara handlar om att anpassa sig till uppdaterad upstream. Flaggan gör att man kan ignorera de enskilda commits som fördes in i historiken av en sådan merge.
--exclude-first-parent-only
När commits ska uteslutas med ^, följ endast den första parent-commiten när en merge-commit påträffas.
Detta kan användas för att hitta mängden ändringar i en topic branch från den punkt där den skilde sig från fjärrgrenen, även när godtyckliga merges är giltiga ändringar i topic branchen.
--not
Vänder betydelsen av prefixet ^, eller frånvaron av det, för alla efterföljande revisionsangivelser fram till nästa --not.
När flaggan används på kommandoraden före --stdin påverkas inte revisioner som skickas via standard in. Omvänt gäller att när --not skickas via standard in påverkas inte revisioner som angivits på kommandoraden.
--all
Låtsas som om alla referenser i:
refs/
tillsammans med HEAD angivits på kommandoraden som <commit>.
--branches[=<mönster>]
Låtsas som om alla referenser i:
refs/heads
angivits på kommandoraden som <commit>.
Om <mönster> anges begränsas grenarna till de som matchar ett shell-glob. Om mönstret saknar ?, * eller [ läggs /* implicit till i slutet.
--tags[=<mönster>]
Låtsas som om alla referenser i:
refs/tags
angivits på kommandoraden som <commit>.
Om <mönster> anges begränsas taggarna till de som matchar ett shell-glob. Om mönstret saknar ?, * eller [ läggs /* implicit till i slutet.
--remotes[=<mönster>]
Låtsas som om alla referenser i:
refs/remotes
angivits på kommandoraden som <commit>.
Om <mönster> anges begränsas fjärrspårande grenar till de som matchar ett shell-glob. Om mönstret saknar ?, * eller [ läggs /* implicit till i slutet.
--glob=<glob-mönster>
Låtsas som om alla referenser som matchar shell-globen <glob-mönster> angivits på kommandoraden som <commit>.
Prefixet refs/ läggs automatiskt till om det saknas. Om mönstret saknar ?, * eller [ läggs /* implicit till i slutet.
--exclude=<glob-mönster>
Inkludera inte referenser som matchar <glob-mönster> och som nästa --all, --branches, --tags, --remotes eller --glob annars skulle ha tagit med.
Upprepningar av denna flagga ackumulerar exkluderingsmönster fram till nästa --all, --branches, --tags, --remotes eller --glob. Andra flaggor eller argument rensar inte de ackumulerade mönstren.
Mönster ska inte börja med:
refs/heads refs/tags 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 referenser som skulle döljas av git-fetch, git-receive-pack eller git-upload-pack genom att läsa respektive konfiguration:
fetch.hideRefs receive.hideRefs uploadpack.hideRefs transfer.hideRefs
Se git-config(1). Denna flagga påverkar nästa pseudo-ref-flagga --all eller --glob och rensas efter att den behandlats.
--reflog
Låtsas som om alla objekt som nämns av reflogs angivits på kommandoraden som <commit>.
--alternate-refs
Låtsas som om alla objekt som nämns som ref-spetsar i alternativa arkiv angivits på kommandoraden.
Ett alternativt arkiv är ett arkiv vars objektkatalog anges i:
objects/info/alternates
Mängden inkluderade objekt kan ändras med bland annat core.alternateRefsCommand. Se git-config(1).
--single-worktree
Som standard undersöks alla arbetsträd av följande flaggor när det finns fler än ett arbetsträd, se git-worktree(1):
--all --reflog --indexed-objects
Denna flagga tvingar dem att endast undersöka det aktuella arbetsträdet.
--ignore-missing
När ett ogiltigt objektnamn påträffas i indata, låtsas som om den felaktiga indatan inte angavs.
--stdin
Utöver argument från kommandoraden läses argument även från standard in. Detta accepterar commits och pseudo-flaggor som --all och --glob=.
När separatorn -- påträffas behandlas efterföljande indata som sökvägar och används för att begränsa resultatet.
Flaggor som --not som läses via standard in respekteras endast för argument som skickats på samma sätt och påverkar inte efterföljande kommandoradsargument.
--quiet
Skriv ingenting till standardutmatning. Denna form är främst avsedd för att låta anroparen testa avslutningsstatusen för att se om ett objektintervall är fullständigt sammanhängande eller inte.
Detta är snabbare än att omdirigera standardutmatning till:
/dev/null
eftersom utdata inte behöver formateras.
--disk-usage, --disk-usage=human
Undertryck normal utdata. Skriv i stället ut summan av antalet byte som används för lagring på disk av de valda commitsen eller objekten.
Detta motsvarar att skicka utdata till:
git cat-file --batch-check='%(objectsize:disk)'
men kör 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 lagringsstorleken i ett läsbart format, till exempel:
12.24 KiB 3.50 MiB
--cherry-mark
Som --cherry-pick, se nedan, men markera likvärdiga commits med = i stället för att utelämna dem, och icke-likvärdiga commits med +.
--cherry-pick
Utelämna commits som introducerar samma ändring som en annan commit på "andra sidan" när commit-mängden begränsas med symmetrisk differens.
Om du till exempel har två grenar, A och B, är ett vanligt sätt att lista alla commits som bara finns på en sida att använda --left-right. Men då visas commits som cherry-pickats från den andra grenen. Med denna flagga utesluts sådana par av commits från utdata.
--left-only, --right-only
Lista endast commits på respektive sida av en symmetrisk differens, det vill säga endast de som skulle markeras med < respektive > av --left-right.
Exempel:
--cherry-pick --right-only A...B
utelämnar de commits från B som finns i A eller är patch-likvärdiga med en commit i A.
Med andra ord listar detta +-commits från:
git cherry A B
Mer exakt ger:
--cherry-pick --right-only --no-merges
den exakta listan.
--cherry
Synonym för:
--right-only --cherry-mark --no-merges
Användbar för att begränsa utdata till commits på vår sida och markera de som redan har tillämpats på andra sidan av en förgrenad historik:
git log --cherry upstream...mybranch
Det liknar:
git cherry upstream mybranch
-g, --walk-reflogs
I stället för att gå genom commit-ancestry, gå genom reflog-poster från den senaste till äldre poster.
När denna flagga används kan commits som ska exkluderas inte anges. Det betyder att notationer som:
^<commit> <commit1>..<commit2> <commit1>...<commit2>
inte kan användas.
Med --pretty i annat format än oneline och reference får utdata två extra rader med information från refloggen.
Reflog-angivelsen i utdata kan visas som:
ref@{<Nth>}
där <Nth> är det omvända kronologiska indexet i refloggen, eller som:
ref@{<tidsstämpel>}
beroende på reglerna nedan:
1. Om startpunkten anges som ref@{<Nth>} visas indexformatet.
2. Om startpunkten anges som ref@{now} visas tidsstämpelformat.
3. Om inget av ovanstående används men --date angavs på kommandoraden, visas tidsstämpeln i det format som begärdes med --date.
4. Annars visas indexformatet.
Med --pretty=oneline läggs denna information före commit-meddelandet på samma rad.
Flaggan kan inte kombineras med --reverse.
Se även git-reflog(1).
Med --pretty=reference visas inte denna information alls.
--merge
Visa commits som rör konfliktfyllda sökvägar i intervallet:
HEAD...<other>
där <other> är den första befintliga pseudoreferensen i:
MERGE_HEAD CHERRY_PICK_HEAD REVERT_HEAD REBASE_HEAD
Fungerar endast när indexet har omatchade poster. Flaggan kan användas för att visa relevanta commits vid lösning av konflikter från en trevägsmerge.
--boundary
Skriv ut exkluderade gränscommits. Gränscommits får prefixet -.
--use-bitmap-index
Försök snabba upp traverseringen med pack bitmap-index, om ett sådant finns.
Observera att när traversering görs med --objects kommer träd och blobbar inte att få sina tillhörande sökvägar utskrivna.
--progress=<rubrik>
Visa förloppsrapporter på standardfel medan objekt behandlas. Texten <rubrik> skrivs ut vid varje förloppsuppdatering.
-z
I stället för att utdata avgränsas med radbrytning avgränsas varje objekt och tillhörande metadata med NUL-byte.
Utdata skrivs i följande form:
<OID> NUL [<token>=<värde> NUL]...
Ytterligare objektmetadata, till exempel objektsökvägar eller gränsobjekt, skrivs med formen:
<token>=<värde>
Tokenvärden skrivs som de är, utan kodning eller trunkering. En OID-post innehåller aldrig tecknet = och används därför för att markera 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 utdataflaggorna:
--objects --boundary --missing
Historieförenkling
Ibland är man bara intresserad av delar av historiken, till exempel de commits som ändrar en viss <sökväg>. Historieförenkling består av två delar: dels vilka commits som väljs, dels hur historiken förenklas. Det finns flera strategier för detta.
Följande flaggor väljer vilka commits som ska visas:
<sökvägar>
Commits som ändrar de angivna sökvägarna väljs.
--simplify-by-decoration
Commits som refereras av någon gren eller tagg väljs.
Observera att extra commits kan visas för att ge en meningsfull historik.
Följande flaggor påverkar hur förenklingen utförs:
Standardläge
Förenklar historiken till den enklaste historiken som förklarar trädets slutliga tillstånd. Den är "enklast" eftersom vissa sidogrenar beskärs om slutresultatet är detsamma, till exempel när grenar med samma innehåll slås samman.
--show-pulls
Ta med alla commits från standardläget, men även merge-commits som inte är TREESAME med första parent men är TREESAME med en senare parent. Detta läge är användbart för att visa de merge-commits som "först introducerade" en ändring till en gren.
--full-history
Samma som standardläget, men beskär inte viss historik.
--dense
Endast de valda commitsen visas, plus vissa extra commits som behövs för att ge en meningsfull historik.
--sparse
Alla commits i den förenklade historiken visas.
--simplify-merges
Ytterligare flagga till --full-history för att ta bort vissa onödiga merges från den resulterande historiken, när inga valda commits bidrar till denna merge.
--ancestry-path[=<commit>]
När ett intervall av commits ska visas, till exempel:
<commit1>..<commit2>
eller:
<commit2> ^<commit1>
och en commit <commit> i intervallet anges, visas endast commits 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, som <commit>.
Flaggan kan anges flera gånger. Om så sker inkluderas en commit om den är någon av de angivna commitsen, eller om den är förfader eller ättling till någon av dem.
--simplify-by-decoration
Flaggan --simplify-by-decoration gör det möjligt att bara se den stora bilden av historikens topologi genom att utelämna commits som inte refereras av taggar.
Commits markeras som !TREESAME — med andra ord behålls de efter reglerna för historieförenkling ovan — om:
1. de refereras av taggar, eller 2. de ändrar innehållet i de sökvägar som anges på kommandoraden.
Alla andra commits markeras som TREESAME och kan därmed förenklas bort.
Hjälp för bisect
--bisect
Begränsa utdata till ett enda commit-objekt som ligger ungefär halvvägs mellan inkluderade och exkluderade commits.
Observera att den dåliga bisect-referensen:
refs/bisect/bad
läggs till bland de inkluderade commitsen, om den finns. De goda bisect-referenserna:
refs/bisect/good-*
läggs till bland de exkluderade commitsen, om de finns.
Om det inte finns några referenser i:
refs/bisect/
och följande kommando:
$ git rev-list --bisect foo ^bar ^baz
skriver ut midpoint, kommer följande två kommandon att ge utdata av ungefär samma längd:
$ git rev-list foo ^midpoint $ git rev-list midpoint ^bar ^baz
Att hitta den ändring som introducerar en regression reduceras därmed till en binär sökning: generera och testa upprepade gånger nya "mittpunkter" tills commit-kedjan har längden ett.
--bisect-vars
Beräknar samma sak som --bisect, men använder inte referenser i:
refs/bisect/
Dessutom skrivs text ut som är redo att köras med shellens eval.
Raderna tilldelar:
bisect_rev
Namnet på mittpunktsrevisionen.
bisect_nr
Förväntat antal commits som återstår att testa efter att bisect_rev har testats.
bisect_good
Förväntat antal commits som återstår att testa om bisect_rev visar sig vara god.
bisect_bad
Förväntat antal commits som återstår att testa om bisect_rev visar sig vara dålig.
bisect_all
Antalet commits som för närvarande ingår i bisect-sökningen.
--bisect-all
Skriver ut alla commit-objekt mellan inkluderade och exkluderade commits, sorterade efter deras avstånd till de inkluderade och exkluderade commitsen.
Referenser i:
refs/bisect/
används inte.
Den commit som ligger längst bort visas först. Det är denna enda commit som visas när --bisect används.
Detta är användbart eftersom det gör det enkelt att välja en bra commit att testa när man av någon anledning vill undvika att testa vissa commits, till exempel om de inte kan kompileras.
Flaggan kan användas tillsammans med --bisect-vars. I så fall skrivs samma text ut som med --bisect-vars efter alla sorterade commit-objekt.
Commit-sortering
Som standard visas commits i omvänd kronologisk ordning.
--date-order
Visa ingen parent före att alla dess children har visats, men visa i övrigt commits i ordning efter commit-tidsstämpel.
--author-date-order
Visa ingen parent före att alla dess children har visats, men visa i övrigt commits i ordning efter author-tidsstämpel.
--topo-order
Visa ingen parent före att alla dess children har visats, och undvik att blanda commits från flera parallella historiklinjer.
Exempel på commit-historik:
---1----2----4----7
\ \
3----5----6----8---
där siffrorna anger commit-tidsstämplarnas ordning.
Med git rev-list och liknande kommandon med --date-order visas commits i tidsstämpelordning:
8 7 6 5 4 3 2 1
Med --topo-order kan de i stället visas som:
8 6 5 3 7 4 2 1
eller:
8 7 4 2 6 5 3 1
Det innebär att vissa äldre commits kan visas före nyare commits för att undvika att parallella utvecklingsspår blandas ihop.
--reverse
Skriv ut de valda commitsen i omvänd ordning.
Kan inte kombineras med --walk-reflogs.
Objekttraversering
Dessa flaggor är främst avsedda för packning av Git-arkiv.
--objects
Skriv ut objekt-ID:n för alla objekt som refereras av de listade commitsen.
Exempel:
--objects foo ^bar
betyder ungefär: "ge mig alla objekt-ID:n som jag behöver ladda ner om jag har commit-objektet bar men inte foo".
Se även --object-names nedan.
--in-commit-order
Skriv ut träd- och blob-ID:n i commit-ordning. Träd- och blob-ID:n skrivs ut efter att de först refererats av en commit.
--objects-edge
Liknar --objects, men skriver även ut ID:n för exkluderade commits med ett - framför.
Detta används av git-pack-objects(1) för att bygga ett "tunt" pack, där objekt lagras i deltaform baserat på objekt som finns i dessa exkluderade commits. Det minskar nätverkstrafiken.
--objects-edge-aggressive
Liknar --objects-edge, men försöker hårdare att hitta exkluderade commits, till priset av längre körningstid.
Detta används i stället för --objects-edge för att bygga tunna pack för grunda arkiv.
--indexed-objects
Låtsas som om alla träd och blobbar som används av indexet angivits på kommandoraden.
Observera att man troligen även vill använda --objects.
--unpacked
Endast användbar tillsammans med --objects. Skriv ut objekt-ID:n som inte finns i packfiler.
--object-names
Endast användbar tillsammans med --objects. Skriv ut namnen på de objekt-ID:n som hittas. Detta är standardbeteendet.
Observera att "namnet" på varje objekt är tvetydigt och främst är avsett som en ledtråd vid packning av objekt.
I synnerhet gäller:
- ingen skillnad görs mellan namn på taggar, träd och blobbar,
- sökvägsnamn kan ändras för att ta bort radbrytningar,
- om ett objekt förekommer flera gånger med olika namn visas endast ett namn.
--no-object-names
Endast användbar tillsammans med --objects. Skriv inte ut namnen på objekt-ID:n som hittas.
Detta inverterar --object-names och gör utdata enklare att tolka för kommandon som git-cat-file(1).
--filter=<filter-spec>
Endast användbar tillsammans med någon av --objects-flaggorna. Utelämnar objekt, vanligen blobbar, från listan över utskrivna objekt.
<filter-spec> kan ha följande former:
--filter=blob:none
Utelämnar alla blobbar.
--filter=blob:limit=<n>[kmg]
Utelämnar blobbar med storlek minst <n> byte eller enheter. <n> kan vara noll.
Suffixen k, m och g kan användas för KiB, MiB eller GiB.
Exempel:
blob:limit=1k
är samma som:
blob:limit=1024
--filter=object:type=(tag|commit|tree|blob)
Utelämnar alla objekt som inte är av den begärda typen.
Observera att uttryckligen angivna objekt ignorerar filter och alltid skrivs ut, om inte --filter-provided-objects också anges.
--filter=sparse:oid=<blob-ish>
Använder en sparse-checkout-specifikation som finns i blobben, eller blob-uttrycket, <blob-ish> för att utelämna blobbar som inte skulle krävas för en sparse checkout på de begärda referenserna.
--filter=tree:<djup>
Utelämnar alla blobbar och träd vars djup från rotträdet är större än eller lika med <djup>.
Om ett objekt finns på flera djup används minsta djup.
<djup>=0
inkluderar inga träd eller blobbar, om de inte uttryckligen anges på kommandoraden eller via standard in när --stdin används.
<djup>=1
inkluderar endast trädet och blobbarna som refereras direkt av en commit som kan nås från <commit>, eller från ett uttryckligen angivet objekt.
<djup>=2
är som <djup>=1, men inkluderar även träd och blobbar ytterligare en nivå bort från en uttryckligen angiven commit eller ett uttryckligen angivet träd.
Observera att formen:
--filter=sparse:path=<sökväg>
som ville läsa från en godtycklig sökväg i filsystemet har tagits bort av säkerhetsskäl.
Flera --filter=-flaggor kan anges för att kombinera filter. Endast objekt som accepteras av varje filter inkluderas.
Formen:
--filter=combine:<filter1>+<filter2>+...+<filterN>
kan också användas för att kombinera flera filter, men detta är svårare än att bara upprepa --filter och är normalt inte nödvändigt.
Filter fogas samman med + och enskilda filter procentkodas, det vill säga URL-kodas.
Förutom + och % är följande tecken reserverade och måste också kodas:
~ ! @ # $ ^ & * ( ) [ ] { } ; " , < > ? ' `
samt alla tecken med ASCII-kod mindre än eller lika med:
0x20
vilket inkluderar mellanslag och radbrytning.
Andra godtyckliga tecken kan också kodas.
Exempelvis är följande likvärdiga:
combine:tree:3+blob:none combine:tree%3A3+blob%3Anone
--no-filter
Stäng av tidigare angiven --filter=-flagga.
--filter-provided-objects
Filtrera listan över uttryckligen angivna objekt. Dessa skrivs annars alltid ut även om de inte matchar något filter.
Endast användbar tillsammans med --filter=.
--filter-print-omitted
Endast användbar tillsammans med --filter=. Skriver ut en lista över objekten som utelämnades av filtret. Objekt-ID:n får prefixet ~.
--missing=<åtgärd-för-saknat>
En felsökningsflagga som hjälper framtida utveckling av "partial clone". Den anger hur saknade objekt ska hanteras.
--missing=error
Stoppa rev-list med fel om ett saknat objekt påträffas. Detta är standard.
--missing=allow-any
Tillåt objekttraversering att fortsätta om ett saknat objekt påträffas. Saknade objekt utelämnas tyst från resultatet.
--missing=allow-promisor
Som allow-any, men tillåt endast traversering att fortsätta för förväntade promisor-saknade objekt. Oväntade saknade objekt ger fel.
--missing=print
Som allow-any, men skriver också ut en lista över saknade objekt. Objekt-ID:n får prefixet ?.
--missing=print-info
Som print, men skriver även ut ytterligare information om det saknade objektet, härledd från det objekt som innehåller det.
Informationen skrivs på samma rad som det saknade objektets ID i formen:
?<oid> [<token>=<värde>]...
Par av typen <token>='<värde> separeras med mellanslag.
Värdet kodas på ett sätt som beror på token-typen, men mellanslag och radbrytningar i värdet förväntas alltid representeras så att resultatet inte innehåller någon av dessa problematiska byte.
Möjliga token-värden är bland annat:
path=<sökväg>
Visar sökvägen för det saknade objektet, härledd från ett innehållande objekt. En sökväg som innehåller mellanslag eller specialtecken omges med dubbla citattecken i C-stil vid behov.
type=<typ>
Visar typen för det saknade objektet, härledd från ett innehållande objekt.
Om vissa tips som skickas till traverseringen saknas, betraktas de också som saknade och traverseringen ignorerar dem. Om deras objekt-ID inte kan hämtas uppstår dock ett fel.
--exclude-promisor-objects
Endast för internt bruk.
Förfiltrerar objekttraversering vid promisor-gränsen. Detta används med partial clone.
Detta ä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 commitsen, men traversera inte deras förfäder.
Detta har ingen effekt om ett intervall anges.
Om argumentet unsorted anges visas commits i den ordning de gavs på kommandoraden.
Annars, om sorted anges eller inget argument ges, visas commits i omvänd kronologisk ordning efter commit-tid.
Kan inte kombineras med --graph.
--do-walk
Åsidosätter tidigare --no-walk.