Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
-
2.54.0
2026-04-20
-
2.53.0
2026-02-02
-
2.52.0
2025-11-17
- 2.51.2 no changes
-
2.51.1
2025-10-15
-
2.51.0
2025-08-18
- 2.50.1 no changes
-
2.50.0
2025-06-16
- 2.49.1 no changes
-
2.49.0
2025-03-14
- 2.48.1 → 2.48.2 no changes
-
2.48.0
2025-01-10
- 2.45.1 → 2.47.3 no changes
-
2.45.0
2024-04-29
- 2.43.3 → 2.44.4 no changes
-
2.43.2
2024-02-13
- 2.43.1 no changes
-
2.43.0
2023-11-20
- 2.42.1 → 2.42.4 no changes
-
2.42.0
2023-08-21
- 2.41.1 → 2.41.3 no changes
-
2.41.0
2023-06-01
- 2.40.1 → 2.40.4 no changes
-
2.40.0
2023-03-12
- 2.39.1 → 2.39.5 no changes
-
2.39.0
2022-12-12
- 2.38.1 → 2.38.5 no changes
-
2.38.0
2022-10-02
- 2.37.1 → 2.37.7 no changes
-
2.37.0
2022-06-27
- 2.36.1 → 2.36.6 no changes
-
2.36.0
2022-04-18
- 2.35.1 → 2.35.8 no changes
-
2.35.0
2022-01-24
- 2.33.3 → 2.34.8 no changes
-
2.33.2
2022-03-23
-
2.33.1
2021-10-12
-
2.33.0
2021-08-16
- 2.32.1 → 2.32.7 no changes
-
2.32.0
2021-06-06
- 2.31.1 → 2.31.8 no changes
-
2.31.0
2021-03-15
- 2.30.1 → 2.30.9 no changes
-
2.30.0
2020-12-27
- 2.29.1 → 2.29.3 no changes
-
2.29.0
2020-10-19
- 2.28.1 no changes
-
2.28.0
2020-07-27
- 2.27.1 no changes
-
2.27.0
2020-06-01
- 2.26.1 → 2.26.3 no changes
-
2.26.0
2020-03-22
- 2.25.1 → 2.25.5 no changes
-
2.25.0
2020-01-13
- 2.24.1 → 2.24.4 no changes
-
2.24.0
2019-11-04
- 2.23.1 → 2.23.4 no changes
-
2.23.0
2019-08-16
- 2.22.1 → 2.22.5 no changes
-
2.22.0
2019-06-07
- 2.21.1 → 2.21.4 no changes
-
2.21.0
2019-02-24
- 2.20.1 → 2.20.5 no changes
-
2.20.0
2018-12-09
- 2.19.3 → 2.19.6 no changes
-
2.19.2
2018-11-21
- 2.17.1 → 2.19.1 no changes
-
2.17.0
2018-04-02
-
2.16.6
2019-12-06
-
2.15.4
2019-12-06
-
2.14.6
2019-12-06
-
2.13.7
2018-05-22
-
2.12.5
2017-09-22
-
2.11.4
2017-09-22
-
2.10.5
2017-09-22
-
2.9.5
2017-07-30
-
2.8.6
2017-07-30
-
2.7.6
2017-07-30
-
2.6.7
2017-05-05
-
2.5.6
2017-05-05
-
2.4.12
2017-05-05
-
2.3.10
2015-09-28
-
2.2.3
2015-09-04
-
2.1.4
2014-12-17
-
2.0.5
2014-12-17
BESKRIVNING
Lista incheckningar som kan nås genom att följa parent-länkarna från de angivna incheckningarna, men exkludera incheckningar som kan nås från de som anges med ett {caret} framför sig. Utdata ges som standard i omvänd kronologisk ordning.
Du kan tänka på detta som en mängdoperation. Incheckningar som kan nås från någon av de incheckningar som anges på kommandoraden bildar en mängd, och sedan subtraheras incheckningar som kan nås från någon av dem som anges med ^ framför från den mängden. De återstående incheckningarna är det som visas i kommandots utdata. Olika andra alternativ och sökvägsparametrar kan användas för att ytterligare begränsa resultatet.
Således, följande kommando:
$ git rev-list foo bar ^baz
betyder "lista alla incheckningar som är nåbara från foo eller bar, men inte från baz".
En särskild notation "<inchecking1>..<inchecking2>" kan användas som en förkortning för "^<inchecking1> <inchecking2>". Till exempel, kan något av följande användas omväxlande:
$ git rev-list origin..HEAD $ git rev-list HEAD ^origin
En annan speciell notation är "<inchecking1>...<inchecking2>" vilket är användbart för sammanslagningar. Den resulterande uppsättningen commits är den symmetriska skillnaden mellan de två operanderna. Följande två kommandon är ekvivalenta:
$ git rev-list A B --not $(git merge-base --all A B) $ git rev-list A...B
rev-list är ett viktigt Git-kommando eftersom det ger möjlighet att bygga och gå igenom incheckning-härkomst-grafer. Av denna anledning har det många olika alternativ som gör att det kan användas av kommandon så olika som git bisect och git repack.
ALTERNATIV
Begränsning av incheckningar
Förutom att ange ett intervall av incheckningar som ska listas med hjälp av de speciella notationer som förklaras i beskrivningen kan ytterligare begränsningar av incheckningar tillämpas.
Att använda fler alternativ begränsar generellt sett utdata ytterligare (t.ex. --since=<datum1> begränsar till incheckningar nyare än <datum1>, och att använda det med --grep=<mönster> begränsar ytterligare till incheckningar vars loggmeddelande har en rad som matchar <mönster>), om inget annat anges.
Observera att dessa tillämpas före alternativ för incheckningsordning och formatering, såsom --reverse.
-
-<nummer> -
-n<nummer> -
--max-count=<nummer> -
Begränsa utdata till <nummer> incheckningar.
-
--skip=<nummer> -
Hoppa över <nummer> incheckningar innan incheckningsutdata visas.
-
--since=<datum> -
--after=<datum> -
Visa incheckningar som är nyare än <datum>.
-
--since-as-filter=<datum> -
Visa alla incheckningar som är nyare än <datum>. Detta besöker alla incheckningar i intervallet, i stället för att stanna vid den första incheckningen som är äldre än <datum>.
-
--until=<datum> -
--before=<datum> -
Visa incheckningar äldre än <datum>.
-
--max-age=<tidsstämpel> -
--min-age=<tidsstämpel> -
Begränsa incheckningsutdata till angivet tidsintervall.
-
--author=<mönster> -
--committer=<mönster> -
Begränsa utdata för incheckningar till de med författar/incheckare-huvud-rader som matchar det reguljära uttrycket <mönster>. Med mer än ett
--author=<mönster> väljs incheckningar vars författare matchar någon av <mönster> (på samma sätt för flera--committer=<mönster>). -
--grep-reflog=<mönster> -
Begränsa utdata för incheckningar till de med reflog-poster som matchar det reguljära uttrycket <mönster>. Med mer än ett
--grep-reflogväljs incheckningar vars reflog-meddelande matchar något av de givna mönstren. Det är ett fel att använda det här alternativet om inte--walk-reflogsanvänds. -
--grep=<mönster> -
Begränsa utdata för incheckningar till de med ett loggmeddelande som matchar det reguljära uttrycket <mönster>. Med mer än ett
--grep=<mönster> väljs incheckningar vars meddelande matchar någon av <mönster> (men se--all-match). -
--all-match -
Begränsa utdata till de incheckningar som matchar alla givna
--grep, i stället för de som matchar minst en. -
--invert-grep -
Begränsa utdata till de incheckningar med ett loggmeddelande som inte matchar <mönster> som anges med
--grep=<mönster>. -
-i -
--regexp-ignore-case -
Matcha de reguljära uttrycks begränsande mönstren utan hänsyn till gemener och versaler.
-
--basic-regexp -
Betrakta de begränsande mönstren som grundläggande reguljära uttryck; detta är standardinställningen.
-
-E -
--extended-regexp -
Behandla de begränsande mönstren som utökade reguljära uttryck i stället för de grundläggande reguljära standarduttrycken.
-
-F -
--fixed-strings -
Betrakta de begränsande mönstren som fasta strängar (tolka inte mönster som ett reguljärt uttryck).
-
-P -
--perl-regexp -
Betrakta de begränsande mönstren som Perl-kompatibla reguljära uttryck.
Stöd för den här typen av reguljära uttryck är ett valfritt kompilerings-tids beroende. Om Git inte kompilerades med stöd för dem kommer det att dö om det här alternativet anges.
-
--remove-empty -
Stanna när en given sökväg försvinner från trädet.
-
--merges -
Skriv bara ut sammanslagningsincheckningar. Detta är exakt samma sak som
--min-parents=2. -
--no-merges -
Skriv inte ut incheckningar med mer än en förälder. Detta är exakt samma sak som
--max-parents=1. -
--min-parents=<nummer> -
--max-parents=<nummer> -
--no-min-parents -
--no-max-parents -
Visa bara incheckningar som har minst (eller högst) så många föräldraincheckningar. I synnerhet är
--max-parents=1samma sak som--no-merges, och--min-parents=2samma sak som--merges.--max-parents=0ger alla rotincheckningar och--min-parents=3alla bläckfisksammanslagningar.--no-min-parentsoch--no-max-parentsåterställer dessa gränser (till ingen gräns) igen. Motsvarande former är--min-parents=0(alla incheckningar har 0 eller fler föräldrar) och--max-parents=-1(negativa tal betyder ingen övre gräns). -
--first-parent -
När du letar efter incheckningar att inkludera, följ bara den första föräldraincheckningen när du stöter på en sammanslagningsincheckning. Det här alternativet kan ge bättre överblick när du granskar utvecklingen av en viss ämnesgren, eftersom sammanslagningar till en ämnesgren ofta bara handlar om att anpassa sig till uppdateringar uppströms, och då kan du ignorera de enskilda incheckningar som en sådan sammanslagning för in i historiken.
-
--exclude-first-parent-only -
När du letar efter incheckningar att exkludera (med ^), följ bara den första föräldraincheckningen när du stöter på en sammanslagningsincheckning. Detta kan användas för att hitta mängden ändringar i en ämnesgren från punkten där den avvek från fjärrgrenen, givet att godtyckliga sammanslagningar kan vara giltiga ändringar i ämnesgrenen.
-
--maximal-only -
Restrict the output commits to be those that are not reachable from any other commits in the revision range.
-
--not -
Vänder betydelsen av prefixet ^ (eller avsaknaden av det) för alla efterföljande revisionsspecifikationer, upp till nästa
--not. När det används på kommandoraden före --stdin, kommer revisionerna som skickas via stdin inte att påverkas av det. Omvänt, när det skickas via standardindata, kommer revisionerna som skickas på kommandoraden inte att påverkas av det. -
--all -
Låtsas som om alla referenser i
refs/, tillsammans medHEAD, listas på kommandoraden som <incheckning>. -
--branches[=<mönster>] -
Låtsas som om alla referenser i
refs/headslistas på kommandoraden som <incheckning>. Om <mönster> anges, begränsa grenar till de som matchar given shell-glob. Om <mönster> saknar ?, * eller [, antyds /* i slutet. -
--tags[=<mönster>] -
Låtsas som om alla referenser i
refs/tagslistas på kommandoraden som <incheckning>. Om <mönster> anges, begränsa taggarna till de som matchar den givna shell-globen. Om mönstret saknar ?, * eller [, antyds /* i slutet. -
--remotes[=<mönster>] -
Låtsas som om alla referenser i
refs/remoteslistas på kommandoraden som <incheckning>. Om <mönster> anges, begränsas fjärrspårade grenar till de som matchar given shell-glob. Om mönstret saknar ?, * eller [, antyds /* i slutet. -
--glob=<glob-mönster> -
Låtsas som om alla referenser som matchar skalglob <glob-mönster> listas på kommandoraden som <incheckning>. Inledande refs/ läggs automatiskt till om det saknas. Om mönstret saknar ?, * eller [, antyds /* i slutet.
-
--exclude=<glob-mönster> -
Inkludera inte referenser som matchar <glob-mönster> och som nästa
--all,--branches,--tags,--remoteseller--globannars skulle ta med. Upprepningar av detta alternativ ackumulerar exkluderingsmönster fram till nästa--all,--branches,--tags,--remoteseller--glob(andra alternativ eller argument nollställer inte de ackumulerade mönstren).Mönstren som anges ska inte börja med
refs/heads,refs/tagsellerrefs/remotesnär de tillämpas på--branches,--tagsrespektive--remotes, och de måste börja medrefs/när de tillämpas på--globeller--all. Om ett efterföljande /* är avsett måste det anges explicit. -
Inkludera inte referenser som skulle döljas av
git-fetch,git-receive-packellergit-upload-packenligt konfigurationenfetch.hideRefs,receive.hideRefselleruploadpack.hideRefstillsammans medtransfer.hideRefs(se git-config[1]). Detta alternativ påverkar nästa pseudo-ref-alternativ--alleller--globoch nollställs efter att de har behandlats. -
--reflog -
Låtsas som om alla objekt som nämns av refloggar listas på kommandoraden som <incheckning>.
-
--alternate-refs -
Låtsas som om alla objekt som nämns som referens-toppar för alternativa kodförråd listades på kommandoraden. Ett alternativt kodförråd är vilket kodförråd som helst vars objektkatalog är angiven i
objects/info/alternates. Uppsättningen av inkluderade objekt kan modifieras avcore.alternateRefsCommand, etc. Se git-config[1]. -
--single-worktree -
Som standard granskas alla arbetsträd av följande alternativ när det finns fler än ett (se git-worktree[1]):
--all,--reflogoch--indexed-objects. Detta alternativ tvingar dem att endast granska det aktuella arbetsträdet. -
--ignore-missing -
När ett ogiltigt objektnamn förekommer i indata, låtsas som om den felaktiga inmatningen inte angavs.
-
--stdin -
Förutom att hämta argument från kommandoraden, läs dem även från standardinmatning. Detta accepterar incheckningar och pseudo-alternativ som
--alloch--glob=. När en---avgränsare setts, behandlas följande inmatning som sökvägar och används för att begränsa resultatet. Flaggor som--notsom läses via standardinmatning respekteras endast för argument som skickas på samma sätt och kommer inte att påverka några efterföljande kommandoradsargument. -
--quiet -
Skriv inte ut något till standardutdata. Den här formen är främst avsedd att låta anroparen testa utgångsstatusen för att se om ett objektområde är helt anslutet (eller inte). Det är snabbare än att omdirigera stdout till
/dev/nulleftersom utdata inte behöver formateras. -
--disk-usage -
--disk-usage=human -
Undertryck normal utdata; skriv i stället ut summan av byte som används för disklagring av de valda incheckningar eller objekten. Detta motsvarar att skicka utdata till
gitcat-file--batch-check='%(objectsize:disk), förutom att det körs mycket snabbare (särskilt med--use-bitmap-index). Se avsnittet FÖRBEHÅLL i git-cat-file[1] för begränsningarna av vad "disklagring" betyder. Med det valfria värdethumanvisas disklagringsstorleken i en människoläsbar sträng (t.ex. 12.24 Kib, 3.50 Mib). -
--cherry-mark -
Liksom
--cherry-pick(se nedan) men markera motsvarande incheckningar med=i stället för att utelämna dem, och ojämlika med+. -
--cherry-pick -
Utelämna alla incheckningar som introducerar samma förändring som en annan incheckning på den "andra sidan" när uppsättningen incheckningar är begränsad med symmetrisk skillnad.
Om du till exempel har två grenar,
AochB, är ett vanligt sätt att lista incheckningar på bara ena sidan att använda--left-right(se exemplet nedan i beskrivningen av alternativet--left-right). Då visas dock även incheckningar som cherry-pickats från den andra grenen (t.ex. kan “3rd on b” vara cherry-pickad från gren A). Med detta alternativ exkluderas sådana incheckningspar från utdata. -
--left-only -
--right-only -
Lista endast incheckningar på respektive sida av en symmetrisk skillnad, d.v.s. endast de som skulle markeras < respektive > med
--left-right.Till exempel
--cherry-pick--right-onlyA...Butelämnar de incheckningar frånBsom finns iAeller är patch-ekvivalenta med en incheckning iA. Med andra ord listar detta+incheckningar frångitcherryAB. Mer exakt ger--cherry-pick--right-only--no-mergesden exakta listan. -
--cherry -
En synonym för
--right-only--cherry-mark--no-merges; användbar för att begränsa utdata till incheckningar på vår sida och markera de som har tillämpats på den andra sidan av en förgrenad historik medgitlog--cherryupstream...mybranch, liknandegitcherryupstreammybranch. -
-g -
--walk-reflogs -
I stället för att gå igenom incheckningarnas förfäderskedja, gå igenom reflog-poster från den senaste till äldre. När detta alternativ används kan du inte ange incheckningar att exkludera (det vill säga notationerna
^<incheckning>, <incheckning1>..<incheckning2> och <incheckning1>...<incheckning2> kan inte användas).Med
--pretty-format annat änonelineochreference(av uppenbara skäl) får utdata två extra informationsrader hämtade från refloggen. Reflog-beteckningen i utdata kan visas somref@{<Nth>}(där <Nth> är det omvänd kronologiska indexet i refloggen) eller somref@{<timestamp>}(med <timestamp> för posten), beroende på några regler:-
Om startpunkten anges som ref@{<N:te>}, visa indexformatet.
-
Om startpunkten angavs som
ref@{now}, visa tidsstämpelformatet. -
Om ingetdera användes, men
--dateangavs på kommandoraden, visa tidsstämpeln i det format som begärs av--date. -
Annars, visa indexformatet.
Under
--pretty=onelineprefixas incheckningsmeddelandet med denna information på samma rad. Alternativet kan inte kombineras med--reverse. Se även git-reflog[1].Under
--pretty=referencekommer denna information inte att visas alls. -
-
--merge -
Visa incheckningar som berör konflikterande sökvägar i intervallet
HEAD...<andra>, där <andra> är den första befintliga pseudoreferensen iMERGE_HEAD,CHERRY_PICK_HEAD,REVERT_HEADellerREBASE_HEAD. Fungerar bara när indexet har ej sammanfogade poster. Det här alternativet kan användas för att visa relevanta incheckningar när konflikter från en trevägssammanslagning löses. -
--boundary -
Utdata exkluderar gräns-incheckningar. Gräns-incheckningar har prefixet
-. -
--use-bitmap-index -
Försök att snabba upp genomgången med hjälp av paketets bitmapindex (om ett sådant finns tillgängligt). Observera att när du genomsöker med
--objectskommer träd och blobbar inte att få sin tillhörande sökväg utskriven. -
--progress=<rubrik> -
Visa förloppsrapporter på stderr när objekt beaktas. Texten <rubrik> kommer att skrivas ut med varje förloppsuppdatering.
-
-z -
I stället för att vara avgränsat med nyrad, avgränsas varje utmatat objekt och dess tillhörande metadata med hjälp av NUL-byte. Utdata skrivs ut i följande form:
<OID> NUL [<token>=<värde> NUL]...
Ytterligare objektmetadata, såsom objektsökvägar eller gränsobjekt, skrivs ut med formen <token>
=<värde>. Tokenvärden skrivs ut som de är utan kodning/trunkering. En OID-post innehåller aldrig tecknet = och används därför för att signalera starten 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]...
Det här läget är endast kompatibelt med utdataalternativen
--objects,--boundaryoch--missing.
Historisk förenkling
Ibland är man bara intresserad av delar av historiken, till exempel incheckningar som ändrar en viss <sökväg>. Men det finns två delar av Historik förenkling, en del handlar om att välja incheckningar och den andra är hur man gör det, eftersom det finns olika strategier för att förenkla historiken.
Följande alternativ väljer vilka incheckningar som ska visas:
Observera att extra incheckningar kan visas för att ge en meningsfull historik.
Följande alternativ påverkar hur förenklingen utförs:
- Standardläge
-
Förenklar historiken till den enklaste historiken som förklarar trädets slutliga tillstånd. Enklast eftersom den beskär vissa sidogrenar om slutresultatet är detsamma (d.v.s. sammanfogar grenar med samma innehåll)
-
--show-pulls -
Inkludera alla incheckningar från standardläget, men även alla sammanslagningsincheckningar som inte är TREESAME till den första föräldern men är TREESAME till en senare förälder. Det här läget är användbart för att visa de sammanslagningsincheckningar som "först introducerade" en ändring i en gren.
-
--full-history -
Samma som standardläget, men rensar inte bort en del historik.
-
--dense -
Endast de valda incheckningar visas, plus några för att ha en meningsfull historik.
-
--sparse -
Alla incheckningar i den förenklade historiken visas.
-
--simplify-merges -
Ytterligare ett alternativ till
--full-historyför att ta bort onödiga sammanslagningar från den resulterande historiken, eftersom det inte finns några valda incheckningar som bidrar till denna sammanslagning. -
--ancestry-path[=<incheckning>] -
När ett intervall av incheckningar ges att visa (t.ex. <incheckning1>
..<incheckning2> eller <incheckning2>^<incheckning1>), och en incheckning_<incheckning>_ inom det intervallet, visas endast incheckningar i det intervallet som är förfäder till <incheckning>, underordnade till <incheckning>, eller <incheckning> självt. Om ingen incheckning anges, använd <incheckning1> (den exkluderade delen av intervallet) som <incheckning>. Kan skickas flera gånger; i så fall inkluderas en incheckning om det är någon av de angivna incheckningarna eller om det är en förfader eller ättling till en av dem.
En mer detaljerad förklaring följer.
Anta att du angav foo som <sökvägar>. Vi ska anropa incheckningar som modifierar foo !TREESAME, och resten TREESAME. (I en diff filtrerad för foo ser de olika respektive lika ut.)
I det följande kommer vi alltid att hänvisa till samma exempelhistorik för att illustrera skillnaderna mellan förenklingsinställningarna. Vi antar att du filtrerar efter en fil foo i denna commit-graf:
.-A---M---N---O---P---Q / / / / / / I B C D E Y \ / / / / / `-------------' X
Den horisontella historiklinjen A---Q tas som den första föräldern till varje sammanslagning. Incheckningarna är:
-
Iär den initiala incheckningen, därfoofinns med innehålletasdf, och en filquuxfinns med innehålletquux. Initiala incheckningar jämförs med ett tomt träd, såIär !TREESAME. -
I
Ainnehållerfoobarafoo. -
Binnehåller samma ändring somA. Dess sammanslagningMär trivial och därför TREESAME för alla föräldrar. -
Cändrar intefoo, men dess sammanslagningNändrar det tillfoobar, så det är inte TREESAME med någon förälder. -
Dsätterfootillbaz. Dess sammanslagningOkombinerar strängarna frånNochDtillfoobarbaz; d.v.s. den är inte TREESAME med någon förälder. -
Eändrarquuxtillxyzzy, och dess sammanslagningPkombinerar strängarna tillquuxxyzzy.Pär TREESAME tillO, men inte tillE. -
Xär en oberoende rot-incheckning som lade till en ny filside, ochYmodifierade den.Yär TREESAME tillX. Dess sammanslagningQlade tillsidetillP, ochQär TREESAME tillP, men inte tillY.
rev-list går bakåt genom historiken, inklusive eller exkluderar incheckningar baserat på om --full-history och/eller omskrivning av överordnade kommandon (via --parents eller --children) används. Följande inställningar är tillgängliga.
- Standardläge
-
Incheckningar inkluderas om de inte är TREESAME till någon förälder (även om detta kan ändras, se
--sparsenedan). Om incheckningen var en sammanslagning, och den var TREESAME till en förälder, följ endast den föräldern. (Även om det finns flera TREESAME-föräldrar, följ endast en av dem.) Annars, följ alla föräldrar.Det här resulterar i:
.-A---N---O / / / I---------D
Observera hur regeln att bara följa TREESAME-föräldern, om en sådan finns tillgänglig, tog bort
Bhelt från beaktande.Cbeaktades viaN, men är TREESAME. Rotincheckningar jämförs med ett tomt träd, såIär !TREESAME.Förälder/barn-relationer är bara synliga med
--parents, men det påverkar inte de incheckningar som är valda i standardläget, så vi har visat förälder-linjerna. -
--full-historyutan förälder omskrivning -
Det här läget skiljer sig från standardläget på en punkt: följ alltid alla föräldrar till en sammanslagning, även om den är TREESAME till en av dem. Även om mer än en sida av sammanslagningen har inkluderade incheckningar, betyder det inte att själva sammanslagningen är det! I exemplet får vi
I A B N D O P Q
Mexkluderades eftersom det är TREESAME för båda föräldrarna.E,CochBfick alla gå, men endastBvar !TREESAME, så de andra visas inte.Observera att utan omskrivning av föräldern är det inte riktigt möjligt att prata om förälder/barn-relationerna mellan incheckningar, så vi visar dem frånkopplade.
-
--full-historymed föräldraomskrivning -
Vanliga incheckningar inkluderas endast om de är !TREESAME (även om detta kan ändras, se
--sparsenedan).Sammanslagningar inkluderas alltid. Emellertid skrivs deras föräldralista om: längs varje förälder, beskär bort incheckningar som inte själva inkluderas. Detta resulterar i
.-A---M---N---O---P---Q / / / / / I B / D / \ / / / / `-------------'
Jämför med
--full-historyutan att skriva om ovan. Observera attEbeskars bort eftersom det är TREESAME, men föräldralistan till P skrevs om för att innehålla E`s föräldra `I. Detsamma hände förCochN, ochX,YochQ.
Utöver ovanstående inställningar, kan du ändra om TREESAME påverkar inkludering:
-
--dense -
Incheckningar som genomgås inkluderas om de inte är TREESAME med någon förälder.
-
--sparse -
Alla incheckningar som traverseras inkluderas.
Observera att utan
--full-historyförenklar detta fortfarande sammanslagningar: om en av föräldrarna är TREESAME följer vi bara den, så de andra sidorna av sammanslagningen genomgås aldrig. -
--simplify-merges -
Först, bygg en historikgraf på samma sätt som
--full-historymed föräldraomskrivning gör (se ovan).Förenkla sedan varje incheckning
Ctill dess ersättningC'i den slutliga historiken enligt följande regler:-
Sätt
C'tillC. -
Ersätt varje förälder
PtillC'med dess förenklingP'. I processen tas föräldrar bort som är förfäder till andra föräldrar eller som är rotincheckningar TREESAME till ett tomt träd, och dubbletter tas bort. Var dock noga med att aldrig ta bort alla föräldrar som vi är TREESAME till. -
Om
C'efter denna föräldraomskrivning är en rot- eller sammanslagningsincheckning (har noll eller >1 föräldrar), en gränsincheckning eller !TREESAME, så behålls den. Annars ersätts den med sin enda förälder.
Effekten av detta visas bäst genom att jämföra med
--full-historymed föräldraomskrivning. Exemplet blir:.-A---M---N---O / / / I B D \ / / `---------'
Notera de största skillnaderna i
N,PochQjämfört med--full-history:-
N`s föräldralista hade `I borttagen, eftersom den är en förfader till den andra föräldern
M. Ändå fannsNkvar eftersom den är !TREESAME. -
På liknande sätt togs
Ibort från P`s föräldralista. `P togs sedan bort helt, eftersom den hade en förälder och är TREESAME. -
Q`s föräldralista förenklade `Y till
X.Xtogs sedan bort eftersom det var en TREESAME-rot.Qtogs sedan bort helt eftersom den hade en förälder och är TREESAME.
-
Det finns ytterligare ett förenklingsläge tillgängligt:
-
--ancestry-path[=<incheckning>] -
Begränsa visade incheckningar till dem som är förfäder till <incheckning>, ättlingar till <incheckning>, eller <incheckning> själv.
Som exempel på användningsfall, betrakta följande incheckningshistorik:
D---E-------F / \ \ B---C---G---H---I---J / \ A-------K---------------L--M
En vanlig D..M beräknar mängden incheckningar som är förfäder till M, men exkluderar de som är förfäder till D. Detta är användbart för att se vad som hände med historiken som ledde till M sedan D, i den meningen att "vad har M som inte existerade i D". Resultatet i det här exemplet skulle vara alla incheckningar, förutom A och B (och D självt, förstås).
När vi vill ta reda på vilka incheckningar i
Msom är kontaminerade med programfelet som introducerades avDoch behöver åtgärdas, kanske vi bara vill visa den delmängd avD..Msom faktiskt är ättlingar tillD, d.v.s. exklusiveCochK. Det är precis vad alternativet--ancestry-pathgör. Tillämpat påD..M-intervallet resulterar det i:E-------F \ \ G---H---I---J \ L--M
Vi kan också använda
--ancestry-path=Di stället för--ancestry-pathvilket betyder samma sak när det tillämpas påD..M-intervallet men är bara mer explicit.Om vi i stället är intresserade av ett givet ämne inom detta intervall, och alla incheckningar som påverkas av det ämnet, kanske vi bara vill se den delmängd av
D..Msom innehåller det ämnet i sin förfäders-sökväg. Så att använda--ancestry-path=HD..Mtill exempel skulle resultera i:E \ C---G---H---I---J \ L--M
Medan
--ancestry-path=KD..Mskulle resultera iK---------------L--M
Innan vi diskuterar ett annat alternativ, --show-pulls, behöver vi skapa en ny exempel historik.
Ett vanligt problem som användare stöter på när de tittar på förenklad historik är att en incheckning som de vet har ändrat en fil på något sätt inte visas i filens förenklade historik. Låt oss visa ett nytt exempel och visa hur alternativ som --full-history och --simplify-merges fungerar i så fall:
.-A---M-----C--N---O---P / / \ \ \/ / / I B \ R-'`-Z' / \ / \/ / \ / /\ / `---X--' `---Y--'
I det här exemplet, anta att I skapade file.txt som modifierades av A, B och X på olika sätt. De ensamstående föräldra-incheckningen C, Z och Y ändrar inte file.txt. Sammanslagnings-incheckningen M skapades genom att lösa sammanslagnings-konflikten för att inkludera både ändringar från A och B och är därför inte TREESAME till någon av dem. Sammanslagningens-incheckningen R skapades dock genom att ignorera innehållet i file.txt vid M och endast ta innehållet i file.txt vid X. Därför är R TREESAME till X men inte M. Slutligen är den naturliga sammanslagningslösningen för att skapa N att ta innehållet i file.txt vid R, så N är TREESAME till R men inte C. Sammanslagnings-incheckningen O och P är TREESAME till sina första föräldrar, men inte till sina andra föräldrar, Z respektive Y.
När standardläget används har både N och R en TREESAME-förälder, så dessa kanter genomgångna och de andra ignoreras. Den resulterande historikgrafen är:
I---X
När man använder --full-history går Git runt på varje kant. Detta kommer att upptäcka incheckningar A och B och sammanslagningen M, men kommer också att avslöja sammanslagningsincheckningar O och P. Med omskrivning av föräldern, blir den resulterande grafen:
.-A---M--------N---O---P / / \ \ \/ / / I B \ R-'`--' / \ / \/ / \ / /\ / `---X--' `------'
Här bidrar sammanslagningsincheckningar O och P med extra brus, eftersom de faktiskt inte bidrog med någon ändring i file.txt. De slog bara samman ett ämne som baserades på en äldre version av file.txt. Detta är ett vanligt problem i kodförråd som använder ett arbetsflöde där många bidragsgivare arbetar parallellt och slår samman sina ämnesgrenar längs en enda stam: många orelaterade sammanslagningar visas i --full-history-resultaten.
När man använder alternativet --simplify-merges försvinner incheckningar O och P från resultaten. Detta beror på att de omskrivna andra föräldrarna till O och P är nåbara från sina första föräldrar. Dessa kanter tas bort och då ser incheckningarna ut som ensamstående-förälder-incheckningar som är TREESAME som sin förälder. Detta händer även med incheckning N, vilket resulterar i en historikvy enligt följande:
.-A---M--. / / \ I B R \ / / \ / / `---X--'
I den här vyn ser vi alla viktiga ändringar med en förälder från A, B och X. Vi ser också den noggrant lösta sammanslagningen M och den mindre noggrant lösta sammanslagningen R. Detta är oftast tillräckligt för att avgöra varför incheckningarna A och B "försvann" från historiken i standardvyn. Det finns dock några problem med den här metoden.
Det första problemet är prestanda. Till skillnad från tidigare alternativ kräver --simplify-merges att hela incheckningshistoriken traverseras innan ett enda resultat returneras. Det kan göra alternativet svårt att använda för mycket stora kodförråd.
Det andra problemet gäller granskning. När många bidragsgivare arbetar på samma kodförråd är det viktigt vilka sammanslagningsincheckningar som introducerade en ändring i en viktig gren. Den problematiska sammanslagningsincheckningen R ovan är sannolikt inte den sammanslagningsincheckning som användes för att slå samman den med en viktig gren. I stället användes sammanslagningsincheckningen N för att slå samman R och X med den viktiga grenen. Denna incheckning kan innehålla information om varför ändringen X åsidosatte ändringarna från A och B i sitt incheckningsmeddelande.
-
--show-pulls -
Förutom de incheckningar som visas i standardhistoriken, visa varje sammanslagningsincheckning som inte är TREESAME till sin första förälder men är TREESAME till en senare förälder.
När en sammanslagningsincheckning inkluderas av
--show-pulls, behandlas sammanslagningsincheckningen som om den "hämtat" ändringen från en annan gren. När--show-pullsanvänds i detta exempel (och inga andra alternativ) är den resulterande grafen:I---X---R---N
Här inkluderas sammanslagningsincheckningarna
RochNeftersom de drog in incheckningarnaXrespektiveRi basgrenen. Dessa sammanslagningar är anledningen till att incheckningarnaAochBinte visas i standardhistoriken.När
--show-pullsparas ihop med--simplify-mergesinnehåller grafen all nödvändig information:.-A---M--. N / / \ / I B R \ / / \ / / `---X--'
Observera att eftersom
Mkan nås frånRhar kanten frånNtillMförenklats bort.Nvisas dock fortfarande i historiken som en viktig incheckning eftersom den drog in ändringenRi huvudgrenen.
Alternativet --simplify-by-decoration låter dig bara se den övergripande bilden av historikens topologi, genom att utelämna incheckningar som inte refereras till av taggar. Incheckningar markeras som !TREESAME (med andra ord, behålls efter historikförenklingsreglerna som beskrivs ovan) om (1) de refereras till av taggar, eller (2) de ändrar innehållet i sökvägarna som anges på kommandoraden. Alla andra incheckningar markeras som TREESAME (med förbehåll för att förenklas bort).
Bisektionshjälpare
-
--bisect -
Begränsa utdata till det enda incheckningsobjektet som ligger ungefär halvvägs mellan inkluderade och exkluderade incheckningar. Observera att den dåliga bisektionsreferensen
refs/bisect/badläggs till de inkluderade incheckningarna (om den finns) och de bra bisektionsreferensernarefs/bisect/good-*läggs till de exkluderade incheckningarna (om de finns). Om vi antar att det inte finns några referenser irefs/bisect/, om$ git rev-list --bisect foo ^bar ^baz
blir utdata midpoint, d.v.s. utdata från de två kommandona
$ git rev-list foo ^midpoint $ git rev-list midpoint ^bar ^baz
skulle vara ungefär lika långa. Att hitta ändringen som introducerar en regression reduceras därmed till en binärsökning: generera och testa upprepade gånger nya midpoint tills incheckningskedjan har längd ett.
-
--bisect-vars -
Det här beräknar samma sak som
--bisect, förutom att referenser irefs/bisect/inte används och att texten skrivs ut i format som kan evalueras av skalet. Dessa rader tilldelar namnet på mittpunktsrevisionen till variabelnbisect_rev, det förväntade antalet incheckningar att testa efter attbisect_revtestats tillbisect_nr, det förväntade antalet incheckningar att testa ombisect_revvisar sig vara bra tillbisect_good, det förväntade antalet incheckningar att testa ombisect_revvisar sig vara dålig tillbisect_bad, samt antalet incheckningar vi bisekterar just nu tillbisect_all. -
--bisect-all -
Det här matar ut alla incheckningsobjekt mellan de inkluderade och exkluderade incheckningarna, sorterade efter deras avstånd till de inkluderade och exkluderade incheckningarna. Referenser i
refs/bisect/används inte. Den längst bort från dem visas först. (Detta är det enda som visas av--bisect.)Det är användbart eftersom det gör det enkelt att välja en bra incheckning att testa när du vill undvika att testa vissa av dem av någon anledning (de kanske till exempel inte kompilerar).
Det här alternativet kan användas tillsammans med
--bisect-vars. I det här fallet, efter alla sorterade incheckningsobjekt, kommer det att finnas samma text som om--bisect-varshade använts ensamt.
Incheckningsordning
Som standard visas incheckningar i omvänd kronologisk ordning.
-
--date-order -
Visa inga föräldrar innan alla dess barn visas, men annars visa incheckningar i incheckningstidsstämpelordningen.
-
--author-date-order -
Visa inga föräldrar innan alla dess barn visas, men annars visa incheckningar i författar-tidsstämpel-ordning.
-
--topo-order -
Visa inga föräldrar innan alla dess barn visas, och undvik att visa incheckningar på flera historikrader blandade.
Till exempel i en incheckningshistorik som denna:
---1----2----4----7 \ \ 3----5----6----8---
där siffrorna anger ordningen på tidsstämplarna för incheckningar, visar
gitrev-listoch vänner med--date-orderincheckningar i tidsstämpelordningen: 8 7 6 5 4 3 2 1.Med
--topo-orderskulle de visa 8 6 5 3 7 4 2 1 (eller 8 7 4 2 6 5 3 1); vissa äldre incheckningar visas före nyare för att undvika att visa incheckningar från två parallella utvecklingsspår blandade. -
--reverse -
Skriv ut de incheckningar som valts att visas (se avsnittet Begränsning av incheckningar ovan) i omvänd ordning. Kan inte kombineras med
--walk-reflogs.
Objekt-traversering
Dessa alternativ är främst avsedda för packning av Git-kodförråd.
-
--objects -
Skriv ut objekt-ID:n för alla objekt som refereras av de listade incheckningarna.
--objectsfoo^barbetyder alltså "skicka mig alla objekt-ID:n som jag behöver ladda ner om jag har incheckningsobjektetbarmen intefoo". Se även--object-namesnedan. -
--in-commit-order -
Skriv ut träd- och blob-id:n i incheckningarnas ordning. Träd- och blob-id:n skrivs ut efter att de först refererats av en incheckning.
-
--objects-edge -
Liknar
--objects, men skriver även ut ID:n för exkluderade incheckningar med prefixet "-". Detta används av git-pack-objects[1] för att bygga ett “tunt” pack, som registrerar objekt i deltakodad form baserat på objekt i dessa exkluderade incheckningar för att minska nätverkstrafik. -
--objects-edge-aggressive -
Liknar
--objects-edge, men den försöker hårdare hitta exkluderade incheckningar på bekostnad av ökad tid. Detta används i stället för--objects-edgeför att bygga “tunna” paket för ytliga kodförråd. -
--indexed-objects -
Låtsas som om alla träd och blobbar som används av indexet listas på kommandoraden. Observera att du förmodligen också vill använda
--objects. -
--unpacked -
Endast användbart med
--objects; skriv ut objekt-ID:n som inte finns i paket. -
--object-names -
Endast användbart med
--objects; skriv ut namnen på de objekt-ID:n som hittas. Detta är standardbeteendet. Observera att "namnet" på varje objekt är tvetydigt och mestadels avsett som en ledtråd för att packa objekt. I synnerhet: ingen skillnad görs mellan namnen på taggar, träd och blobbar; sökvägsnamn 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; skriver inte ut namnen på de objekt-ID:n som hittas. Detta inverterar--object-names. Denna flagga gör att utdata lättare kan tolkas av kommandon som git-cat-file[1]. -
--filter=<filter-spec> -
Endast användbart med ett av
--objects*; utelämnar objekt (vanligtvis blobbar) från listan över utskrivna objekt. <filter-spec> kan vara ett av följande:Formen
--filter=blob:noneutelämnar alla blobbar.Formen
--filter=blob:limit=<n>[kmg] utelämnar blobbar med en storlek på minst <n> byte eller enheter. <n> kan vara noll. Suffixenk,mochgkan användas för att namnge enheter i KiB, MiB eller GiB. Till exempel ärblob:limit=1kdetsamma som blob:limit=1024.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-objectsockså anges.Formen
--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.Formen
--filter=tree:<djup> utelämnar alla blobbar och träd vars djup från rotträdet är >= <djup> (minimum djup om ett objekt finns på flera djup i de incheckningar som passeras). <djup>=0 inkluderar inga träd eller blobbar om de inte inkluderas explicit i kommandoraden (eller standardindata när--stdinanvänds). <djup>=1 inkluderar endast trädet och blobbar som refereras direkt av en incheckning som kan nås från <incheckning> eller ett explicit givet objekt. <djup>=2 är som <djup>=1 men inkluderar även träd och blobbar ytterligare en nivå bort från en explicit given incheckning eller träd.Observera att formen
--filter=sparse:path=<sökväg> som vill 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-flaggan och är vanligtvis inte nödvändigt. Filter sammanfogas med + och individuella filter är %-kodade (dvs. URL-kodade). Förutom tecknen + och % är följande tecken reserverade och måste också kodas: ~!@#$^&*()[]{}\;",<>?'` samt alla tecken med ASCII-kod <=0x20, vilket inkluderar mellanslag och nyrad.Andra godtyckliga tecken kan också kodas. Till exempel är
combine:tree:3+blob:noneochcombine:tree%3A3+blob%3Anonelikvärdiga. -
--no-filter -
Stäng av alla tidigare
--filter=-argument. -
--filter-provided-objects -
Filtrera listan över explicit angivna objekt, som annars alltid skulle skrivas ut även om de inte matchade något av filtren. Endast användbart med
--filter=. -
--filter-print-omitted -
Endast användbart med
--filter=; skriver ut en lista över objekt som utelämnats av filtret. Objekt-ID:n har prefixet “~”. -
--missing=<saknad-åtgärd> -
Ett felsökningsalternativ som hjälper till med framtida utveckling av "partiell klon". Det här alternativet anger hur saknade objekt hanteras.
Formen
--missing=errorbegär att rev-list ska stoppas med ett felmeddelande om ett saknat objekt påträffas. Detta är standardåtgärden.Formen
--missing=allow-anytillåter objektgenomgång att fortsätta om ett saknat objekt påträffas. Saknade objekt kommer tyst att utelämnas från resultaten.Formen
--missing=allow-promisorär somallow-any, men tillåter bara objektgenomgång att fortsätta för FÖRVÄNTADE löftesgivare-saknade objekt. Oväntade saknade objekt kommer att orsaka ett fel.Formen
--missing=printär somallow-any, men skriver också ut en lista över de saknade objekten. Objekt-ID:n har prefixet “?”.Formen
--missing=print-infoär somprint, men kommer också att skriva ut ytterligare information om det saknade objektet som härleds från dess innehållande objekt. All information skrivs ut på samma rad med det saknade objekt-ID:t i formen: ?<oid> [<token>=<värde>].... Paren <token>=<värde> som innehåller ytterligare information är separerade från varandra med en SP. Värdet kodas på ett tokenspecifikt sätt, men SP eller LF som ingår i värde förväntas alltid representeras på ett sådant sätt att det resulterande kodade värdet inte har någon av dessa två problematiska byte. Varje <token>=<värde> kan vara ett av följande:-
path=<sökväg> visar sökvägen till det saknade objektet, härledd från ett innehållande objekt. En sökväg som innehåller SP eller specialtecken omges av dubbla citattecken i C-stilen efter behov. -
type=<typ> visar typen av det saknade objektet som härleds från ett innehållande objekt.
Om några toppar som skickats till traverseringen saknas, kommer de också att betraktas som saknade, och traverseringen kommer att ignorera dem. Om vi inte kan hämta deras objekt-ID kommer ett felmeddelande att genereras.
-
-
--exclude-promisor-objects -
(Endast för internt bruk.) Förfiltrera objekttraverseringen vid löftesgivargränsen. Detta används med partiell klon. Det är starkare än
--missing=allow-promisoreftersom det begränsar traverseringen i stället för att bara tysta fel om saknade objekt. -
--no-walk[=(sorted|unsorted)] -
Visa bara de angivna incheckningarna, men traversera inte deras förfäder. Detta har ingen effekt om ett intervall anges. Om argumentet
unsortedanges visas incheckningarna i den ordning de angavs på kommandoraden. Annars (omsortedeller inget argument anges) visas incheckningarna i omvänd kronologisk ordning efter incheckningstid. Kan inte kombineras med--graph. -
--do-walk -
Åsidosätter en tidigare
--no-walk.
Incheckningsformatering
Med dessa alternativ fungerar git-rev-list[1] på liknande sätt som den mer specialiserade familjen av incheckningsloggverktyg: git-log[1], git-show[1] och git-whatchanged[1].
-
--pretty[=<format>] -
--format=<format> -
Skriv ut innehållet i incheckningsloggarna i ett givet format med en pretty-print, där <format> kan vara ett av följande:
oneline,short,medium,full,fuller,reference,email,raw,format:<string> ochtformat:<string>. När <format> inte är något av ovanstående, och innehåller%<placeholder>, fungerar det som om--pretty=tformat:<format> vore angivet.Se avsnittet "VACKERT FORMAT" för ytterligare information om varje format. När
=<format>-delen utelämnas användsmediumsom standard.NoteDu kan ange standardformatet för pretty i kodförråds-konfigurationen (se git-config[1]). -
--abbrev-commit -
I stället för att visa det fullständiga 40-byte hexadecimala incheckningsobjektnamnet, visa ett prefix som namnger objektet unikt. Alternativet
--abbrev=<n> (som också modifierar diff-utdata, om det visas) kan användas för att ange prefixets minsta längd.Det borde göra
--pretty=onelinemycket mer läsbar för personer som använder terminaler med 80 kolumner. -
--no-abbrev-commit -
Visa det fullständiga 40-byte hexadecimala incheckningsobjektnamnet. Detta negerar
--abbrev-commit, antingen explicit eller underförstått av andra alternativ som--oneline. Det åsidosätter också variabelnlog.abbrevCommit. -
--oneline -
Det är en förkortning för
--pretty=oneline--abbrev-commitsom används tillsammans. -
--encoding=<kodning> -
Incheckningsobjekt registrerar teckenkodningen som används för loggmeddelandet i sitt kodningshuvud; det här alternativet kan användas för att ange att kommandot ska koda om incheckningsloggmeddelandet i den kodning som användaren föredrar. För högnivåkommandon är standardvärdet UTF-8. Observera att om ett objekt påstår sig vara kodat i
Xoch vi matar ut iX, kommer vi att mata ut objektet ordagrant; det betyder att ogiltiga sekvenser i den ursprungliga incheckningen kan kopieras till utdata. På samma sätt, om iconv(3) misslyckas med att konvertera incheckningen, kommer vi att mata ut det ursprungliga objektet ordagrant i tysthet. -
--expand-tabs=<n> -
--expand-tabs -
--no-expand-tabs -
Utför en tabbexpandering (ersätt varje tabb med tillräckligt med mellanslag för att fylla till nästa visningskolumn som är en multipel av <n>) i loggmeddelandet innan det visas i utdata.
--expand-tabsär en förkortning för--expand-tabs=8, och--no-expand-tabsär en förkortning för--expand-tabs=0, vilket inaktiverar tabbexpandering.Som standard expanderas flikarna i snygga format som indenterar loggmeddelandet med 4 mellanslag (dvs.
medium, som är standard,fullochfuller). -
--show-signature -
Kontrollera giltigheten hos ett signerat incheckningsobjekt genom att skicka signaturen till
gpg--verifyoch visa utdata.
-
--relative-date -
Synonym för
--date=relative. -
--date=<format> -
Gäller endast för datum som visas i människoläsbart format, till exempel när
--prettyanvänds. Konfigurationsvariabelnlog.dateanger ett standardvärde för log-kommandots--date-alternativ. Som standard visas datum i den ursprungliga tidszonen (antingen incheckarens eller författarens). Om-localläggs till i formatet (t.ex.iso-local) används användarens lokala tidszon i stället.--date=relativevisar datum i förhållande till aktuell tid, t.ex. “2 hours ago”. Alternativet-localhar ingen effekt för--date=relative.--date=localär ett alias för--date=default-local.--date=iso(eller--date=iso8601) visar tidsstämplar i ett ISO 8601-liknande format. Skillnaderna mot det strikta ISO 8601-formatet är:-
ett mellanslag i stället för datum-/tidsavgränsaren
T -
ett mellanrum mellan tid och tidszon
-
inget kolon mellan timmar och minuter i tidszonen
--date=iso-strict(eller--date=iso8601-strict) visar tidsstämplar i strikt ISO 8601-format.--date=rfc(eller--date=rfc2822) visar tidsstämplar i RFC 2822-format, som ofta finns i e-postmeddelanden.--date=shortvisar bara datumet, men inte tiden, i formatetYYYY-MM-DD.--date=rawvisar datumet som sekunder sedan epoken (1970-01-01 00:00:00 UTC), följt av ett mellanslag, och sedan tidszonen som en förskjutning från UTC (ett+eller-med fyra siffror; de två första är timmar och de två andra är minuter). Dvs. som om tidsstämpeln formaterades medstrftime("%s%z")). Observera att alternativet-localinte påverkar värdet sekunder-sedan-epoken (som alltid mäts i UTC), men ändrar det tillhörande tidszonvärdet.--date=humanvisar tidszonen om tidszonen inte matchar den aktuella tidszonen, och skriver inte ut hela datumet om det matchar (d.v.s. hoppa över utskriften av år för datum som är "i år", men hoppar även över hela själva datumet om det är under de senaste dagarna och vi bara kan ange vilken veckodag det var). För äldre datum utelämnas också timme och minut.--date=unixvisar datumet som en Unix-epoktidsstämpel (sekunder sedan 1970). Precis som med--rawär detta alltid i UTC och därför har-localingen effekt.--date=format:<format> matar <format> till ditt systemstrftime, förutom%s,%zoch%Z, som hanteras internt. Använd--date=format:%cför att visa datumet i ditt systemspråks föredragna format. Se manualen förstrftime(3) för en komplett lista över formatplatshållare. När du använder-localär den korrekta syntaxen--date=format-local:<format>.--date=defaultär standardformatet och baseras på ctime(3)-utdata. Det visar en enda rad med tre bokstäver för veckodag, tre bokstäver för månad, dag i månaden, timme-minut-sekunder i formatet "HH:MM:SS", följt av ett fyrsiffrigt årtal plus tidszoninformation, såvida inte den lokala tidszonen används, t.ex.ThuJan100:00:001970+0000. -
-
--header -
Skriv ut incheckningens innehåll i råformat; varje post separeras med ett NUL-tecken.
-
--no-commit-header -
Undertryck rubrikraden som innehåller "commit" och objekt-ID:t som skrivs ut före det angivna formatet. Detta påverkar inte de inbyggda formaten; bara anpassade format påverkas.
-
--commit-header -
Åsidosätter en tidigare
--no-commit-header. -
--parents -
Skriv även ut föräldrarna till incheckningen (i formen "commit parent…"). Aktiverar också föräldraomskrivning, se History Simplification ovan.
-
--children -
Skriv även ut barn till incheckningen (i formen "commit child…"). Aktiverar också föräldraomskrivning, se History Simplification ovan.
-
--timestamp -
Skriv ut rå incheckningstidsstämpel.
-
--left-right -
Markera vilken sida av en symmetrisk skillnad en incheckning är nåbar från. Incheckningar från vänster sida har prefixet < och de från höger med >. Om de kombineras med
--boundaryhar dessa incheckningar prefixet-.Till exempel om du har denna topologi:
y---b---b gren B / \ / / . / / \ o---x---a---a gren A
du skulle få utdata som detta:
$ git rev-list --left-right --boundary --pretty=oneline A...B >bbbbbbb... 3:a på b >bbbbbbb... 2:a på b <aaaaaaa... 3:a på a <aaaaaaa... 2:a på a -yyyyyyy... 1:a på b -xxxxxxx...1:a på a
-
--graph -
Rita en textbaserad grafisk representation av inchecknings-historiken till vänster om utdata. Detta kan orsaka att extra rader skrivs ut mellan incheckningar, för att grafhistoriken ska kunna ritas korrekt. Kan inte kombineras med
--no-walk.Det här aktiverar föräldraomskrivning, se History Simplification ovan.
Det här innebär att alternativet
--topo-orderär standard, men alternativet--date-orderkan också anges. -
--show-linear-break[=<barriär>] -
När
--graphinte används plattas alla historikgrenar ut, vilket kan göra det svårt att se att två på varandra följande incheckningar inte tillhör en linjär gren. Det här alternativet placerar då en avskiljare mellan dem. Om <barrier> anges är det strängen som visas i stället för standardsträngen. -
--count -
Skriv ut ett tal som anger hur många incheckningar som skulle ha listats och undertryck all annan utdata. När det används tillsammans med
--left-right, skriv i stället ut antalet för vänster och höger incheckningar, separerade med en tabb. När det används tillsammans med--cherry-mark, utelämna patch-ekvivalenta incheckningar från dessa antal och skriv ut antalet för ekvivalenta incheckningar separerade med en tabb.
VISNINGSFORMAT
Om incheckningen är en sammanslagning, och om visningsformatet inte är oneline, email eller raw, infogas en extra rad före raden Author:. Denna rad börjar med "Merge:" och hasherna för föräldraincheckningar skrivs ut, separerade med mellanslag. Observera att de listade incheckningar inte nödvändigtvis är listan över de direkta föräldraincheckningarna om du har begränsat din historikvy: till exempel om du bara är intresserad av ändringar relaterade till en viss katalog eller fil.
Det finns flera inbyggda format, och du kan definiera ytterligare format genom att sätta ett pretty.<namn>-konfigurationsalternativ till antingen ett annat formatnamn eller en format:-sträng, enligt beskrivningen nedan (se git-config[1]). Här är detaljerna för de inbyggda formaten:
-
oneline -
<hash> <title-line>Det är utformat för att vara så kompakt som möjligt.
-
short -
commit <hash> Author: <author> _ <titelrad>_ -
medium -
commit <hash> Author: <author> Date: <author-date> _ <titelrad> <fullt-incheckningsmeddelande>_ -
full -
commit <hash> Author: <author> Commit: <committer> _ <titelrad> <fullt-incheckningsmeddelande>_ -
fuller -
commit <hash> Author: <författare> AuthorDate: <författar-datum> Commit: <incheckare> CommitDate: <inchecknings-datum> _ <title-line> <full-commit-message>_ -
reference -
<förkortad-hash> (<titelrad>,<kort-författar-datum>)Formatet används för att referera till en annan incheckning i ett incheckningsmeddelande och är detsamma som
--pretty='format:%C(auto)%h(%s,%ad). Som standard formateras datumet med--date=shortom inte ett annat--date-alternativ uttryckligen anges. Precis som med allaformat:med formatplatshållare påverkas inte dess utdata av andra alternativ som--decorateoch--walk-reflogs. -
email -
From <hash> <datum> From: <författare> Date: <författar-datum> Subject: [PATCH] <titelrad> _ <fullt-incheckningsmeddelande>_ -
mboxrd -
Som
email, men rader i inchecknings-meddelandet som börjar med "From " (föregångna av noll eller fler ">") citeras med ">" så att de inte förväxlas med att starta en ny incheckning. -
raw -
raw-formatet visar hela incheckningen exakt så som den lagras i incheckningsobjektet. Det är värt att notera att hasherna visas i sin helhet, oavsett om--abbreveller--no-abbrevanvänds, och informationen iparentsvisar de verkliga föräldra-incheckningen, utan att ta hänsyn till grafts eller historikförenkling. Observera att detta format påverkar hur incheckningar visas, men inte hur diffen visas, t.ex. medgitlog--raw. För att få fullständiga objektnamn i ett rått diff-format, använd--no-abbrev. -
format:<formatsträng> -
Formatet
format:<format-sträng> låter dig ange vilken information du vill visa. Det fungerar lite som printf-formatet, med det anmärkningsvärda undantaget att du får en nyrad med%ni stället för \n.T.ex., format:"Författaren till %h var %an, %ar%nTiteln var >>%s<<%n" skulle visa något liknande:
The author of fe6e0ee was Junio C Hamano, 23 hours ago The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
Platshållarna är:
-
Platshållare som expanderar till ett enda bokstavstecken:
-
Platshållare som påverkar formateringen av senare platshållare:
-
%Cred -
byt färg till röd
-
%Cgreen -
byt färg till grönt
-
%Cblue -
byt färg till blå
-
%Creset -
återställ färg
-
%C(<spec>) -
färgspecifikation, som beskrivs under Värden i avsnittet "KONFIGURATIONSFIL" i git-config[1]. Som standard visas färger endast när de är aktiverade för loggutdata (av
color.diff,color.uieller--color, och med respekt förauto-inställningarna för den förra om vi går till en terminal).%C(auto,<spec>) accepteras som en historisk synonym för standardvärdet (t.ex.%C(auto,red)). Att ange%C(always,<spec>) kommer att visa färgerna även när färg inte är aktiverad på annat sätt (men överväg att bara använda--color=alwaysför att aktivera färg för hela utdata, inklusive detta format och allt annat som git kan färga). Enbartauto(d.v.s.%C(auto)) kommer att aktivera automatisk färgning på nästa platshållare tills färgen byts igen. -
%m -
vänster (<), höger (>) eller gränsmärke (
-) -
%w([<w>[,<i1>[,<i2>]]]) -
växla radbrytning, som alternativet
-wi git-shortlog[1]. - %<(<n>[
,(trunc|ltrunc|mtrunc)]) -
make the next placeholder take at least N column widths, padding spaces on the right if necessary. Optionally truncate (with ellipsis
..) at the left (ltrunc)..ft, the middle (mtrunc)mi..le, or the end (trunc)rig.., if the output is longer than <n> columns. Note 1: that truncating only works correctly with <n> >= 2. Note 2: spaces around the <n> and <m> (see below) values are optional. Note 3: Emojis and other wide characters will take two display columns, which may over-run column boundaries. Note 4: decomposed character combining marks may be misplaced at padding boundaries. - %<|(<m> )
-
låt nästa platshållare ta minst fram till <m>:e visningskolumnen, fyll ut mellanslag till höger om det behövs. Använd negativa <m>-värden för kolumnpositioner mätt från terminalfönstrets högra kant.
- %>(<n>)
- %>|(<m>)
-
liknar %<(<n>), %<|(<m>) respektive, men fyller ut mellanslag till vänster
- %>>(<n>)
- %>>|(<m>)
-
liknande %>(<n>), %>|(<m>) respektive, förutom att om nästa platshållare tar fler mellanslag än angivet och det finns mellanslag till vänster om den, använd dessa mellanslag
- %><(<n>)
- %><|(<m>)
-
liknar %<(<n>), %<|(<m>) respektive, men utfyllnad på båda sidor (dvs. texten centreras)
-
-
Platshållare som expanderar till information som extraheras från incheckningen:
-
%H -
incheckning hash
-
%h -
förkortad incheckningshash
-
%T -
trädhash
-
%t -
förkortad trädhash
-
%P -
förälder-hashkoder
-
%p -
förkortade föräldra-hashkoder
-
%an -
författarnamn
-
%aN -
författarnamn (angående .mailmap, se git-shortlog[1] eller git-blame[1])
-
%ae -
författarens e-postadress
-
%aE -
författarens e-postadress (angående .mailmap, se git-shortlog[1] eller git-blame[1])
-
%al -
författarens e-postadress lokal-del (delen före
@-tecknet) -
%aL -
författarens lokala del (se
%al) avseende .mailmap, se git-shortlog[1] eller git-blame[1]) -
%ad -
författardatum (formatet respekterar --date= alternativet)
-
%aD -
författardatum, RFC2822-stil
-
%ar -
författardatum, relativ
-
%at -
författardatum, UNIX-tidsstämpel
-
%ai -
författardatum, ISO 8601-liknande format
-
%aI -
författardatum, strikt ISO 8601-format
-
%as -
författardatum, kortformat (ÅÅÅÅ-MM-DD)
-
%ah -
författardatum, mänsklig stil (som alternativet
--date=humani git-rev-list[1]) -
%cn -
incheckare-namn
-
%cN -
namn på incheckare (för .mailmap, se git-shortlog[1] eller git-blame[1])
-
%ce -
e-postadress för incheckare
-
%cE -
e-postadress för incheckare (respekterar .mailmap, se git-shortlog[1] eller git-blame[1])
-
%cl -
e-postadress för incheckare lokal-del (delen före
@-tecknet) -
%cL -
incheckare lokal-del (se
%cl) respekterar .mailmap, se git-shortlog[1] eller git-blame[1]) -
%cd -
incheckare-datum (formatet respekterar --date= alternativet)
-
%cD -
incheckare-datum, RFC2822-stil
-
%cr -
incheckare-datum, relativ
-
%ct -
incheckare-datum, UNIX-tidsstämpel
-
%ci -
incheckare-datum, ISO 8601-liknande format
-
%cI -
incheckare-datum, strikt ISO 8601-format
-
%cs -
incheckare-datum, kortformat (ÅÅÅÅ-MM-DD)
-
%ch -
incheckare-datum, mänsklig stil (som alternativet
--date=humani git-rev-list[1]) -
%d -
referensnamn, som --decorate alternativet i git-log[1]
-
%D -
referensnamn utan " (", ")" omslag.
-
%(count) -
the number of a patch within a patch series. Used only in
--commit-list-formatinformat-patch -
%(total) -
the total number of patches in a patch series. Used only in
--commit-list-formatinformat-patch -
%(decorate[:<option>,...]) -
referensnamn med anpassade dekorationer. Strängen
decoratekan följas av ett kolon och noll eller fler kommaseparerade alternativ. Alternativvärden kan innehålla bokstavliga formateringskoder. Dessa måste användas för kommatecken (%x2C) och avslutande parenteser (%x29) på grund av deras roll i alternativsyntaxen.-
prefix=<värde> -
Visas före listan med referensnamn. Standard är " (".
-
suffix=<värde> -
Visas efter listan med referensnamn. Standard är ")".
-
separator=<värde> -
Visas mellan referensnamn. Standard är "
,". -
pointer=<värde> -
Shown between HEAD and the branch it points to, if any. Defaults to " → ".
-
tag=<value> -
Shown before tag names. Defaults to "
tag:".
Till exempel, för att skapa dekorationer utan radbrytning eller taggannoteringar, och med mellanslag som avgränsare:
-
%(decorate:prefix=,suffix=,tag=,separator= )
-
%(describe[:<option>,...]) -
human-readable name, like git-describe[1]; empty string for undescribable commits. The
describestring may be followed by a colon and zero or more comma-separated options. Descriptions can be inconsistent when tags are added or removed at the same time.-
tags[=<bool-value>] -
Instead of only considering annotated tags, consider lightweight tags as well.
-
abbrev=<number> -
Instead of using the default number of hexadecimal digits (which will vary according to the number of objects in the repository with a default of 7) of the abbreviated object name, use <number> digits, or as many digits as needed to form a unique object name.
-
match=<mönster> -
Only consider tags matching the given
glob(7) <pattern>, excluding therefs/tags/prefix. -
exclude=<mönster> -
Do not consider tags matching the given
glob(7) <pattern>, excluding therefs/tags/prefix.
-
-
%S -
referensnamnet som anges på kommandoraden genom vilket incheckningen nåddes (som
gitlog--source), fungerar bara medgitlog -
%e -
kodning
-
%s -
ämne
-
%f -
sanerad ämnesrad, lämplig för ett filnamn
-
%b -
kropp
-
%B -
rå kropp (ej radbruten ämnesrad och kropp)
-
%GG -
rått verifieringsmeddelande från GPG för en signerad incheckning
- %G?
-
visa "G" för en bra (giltig) signatur, "B" för en felaktig signatur, "U" för en bra signatur med okänd giltighetstid, "X" för en bra signatur som har gått ut, "Y" för en bra signatur gjord av en utgången nyckel, "R" för en bra signatur gjord av en återkallad nyckel, "E" om signaturen inte kan kontrolleras (t.ex. saknad nyckel) och "N" för ingen signatur
-
%GS -
visa namnet på signeraren för en signerad incheckning
-
%GK -
visa nyckeln som används för att signera en signerad incheckning
-
%GF -
visa fingeravtrycket på nyckeln som används för att signera en signerad incheckning
-
%GP -
visa fingeravtrycket för den primärnyckel vars undernyckel användes för att signera en signerad incheckning
-
%GT -
visa förtroendenivån för nyckeln som används för att signera en signerad incheckning
-
%gD -
reflog-väljare, t.ex.
refs/stash@{1}ellerrefs/stash@{2minutesago}; formatet följer reglerna som beskrivs för alternativet-g. Delen före@är refnamnet som det anges på kommandoraden (sågitlog-grefs/heads/masterskulle gerefs/heads/master@{0}). -
%gd -
förkortad reflog-väljare; samma som
%gD, men refname-delen är förkortad för mänsklig läsbarhet (sårefs/heads/masterblir baramaster). -
%gn -
reflog-identitets namn
-
%gN -
namn på reflog-identitet (för .mailmap, se git-shortlog[1] eller git-blame[1])
-
%ge -
reflog-identitet e-postadress
-
%gE -
reflog-identitet e-postadress (respekterar .mailmap, se git-shortlog[1] eller git-blame[1])
-
%gs -
reflog ämne
-
%(trailers[:<alternativ>,...]) -
visa slutrad för brödtexten så som de tolkas av git-interpret-trailers[1]. Strängen
trailerskan följas av ett kolon och noll eller fler kommaseparerade alternativ. Om något alternativ anges flera gånger vinner den sista förekomsten.-
key=<nyckel> -
Visar bara slutrader med angiven <nyckel>. Matchning sker skiftlägesokänsligt och avslutande kolon är valfritt. Om flaggan anges flera gånger visas slutrader som matchar någon av nycklarna. Flaggan aktiverar automatiskt
onlyså att rader som inte är slutrader i slutradsblocket döljs. Om det inte önskas kan det inaktiveras medonly=false. T.ex. visar%(trailers:key=Reviewed-by) slutrader med nyckelnReviewed-by. -
only[=<bool>] -
Välj om rader som inte är slutrader i slutradsblocket ska inkluderas.
-
separator=<sep> -
Ange avgränsaren som infogas mellan slutrader. Standard är ett radmatningstecken. Strängen <sep> kan innehålla de bokstavliga formateringskoder som beskrivs ovan. För att använda kommatecken som avgränsare måste man använda
%x2Ceftersom det annars tolkas som nästa alternativ. T.ex. visar%(trailers:key=Ticket,separator=%x2C) alla slutrader vars nyckel ärTicketavgränsade med kommatecken och mellanslag. -
unfold[=<bool>] -
Gör att det beter sig som om interpret-trailers
--unfold-flagga angetts. T.ex. vecklar%(trailers:only,unfold=true) ut och visar alla slutrader. -
keyonly[=<bool>] -
Visa bara nyckeldelen av slutraden.
-
valueonly[=<bool>] -
Visa bara värdedelen av slutraden.
-
key_value_separator=<sep> -
Ange avgränsaren som infogas mellan nyckel och värde i varje slutrad. Standard är ": ". I övrigt har den samma semantik som
separator=<sep> ovan.Anger avgränsaren som infogas mellan nyckeln och värdet för varje slutrad. Standardvärdet är ": ". Annars delar den samma semantik somseparator=<sep> ovan.
-
NoteVissa platshållare kan vara beroende av andra alternativ som ges till revisionsgenomgångsmotorn. Till exempel kommer reflog-alternativen %g*att infoga en tom sträng om vi inte går igenom reflog-poster (t.ex. medgitlog-g). Platshållarna%doch%Dkommer att använda det "korta" dekorationsformatet om--decorateinte redan angavs på kommandoraden.De booleska alternativen accepterar ett valfritt värde [
=<bool-value>]. Värdena som tas av--type=boolgit-config[1], somyesochoff, accepteras alla. Att ge ett booleskt alternativ utan=<värde> är liktydigt med att ge det med=true.Om du lägger till ett
+(plustecken) efter%för en platshållare infogas en radmatning omedelbart före expansionen om och endast om platshållaren expanderar till en sträng som inte är tom.Om du lägger till ett
-(minustecken) efter%för en platshållare, raderas alla radmatningar omedelbart före expansionen om och endast om platshållaren expanderar till en tom sträng.Om du lägger till ett (mellanslag) efter
%av en platshållare, infogas ett mellanslag omedelbart före expansionen om och endast om platshållaren expanderar till en sträng som inte är tom. -
-
-
tformat: -
Formatet
tformat:fungerar precis somformat:, förutom att det tillhandahåller "terminator"-semantik i stället för "separator"-semantik. Med andra ord har varje incheckning meddelandets terminatortecken (vanligtvis en nyrad) tillagt, snarare än en avgränsare placerad mellan poster. Detta innebär att den sista posten i ett enradigt format avslutas korrekt med en ny rad, precis som formatet "enradigt" gör. Till exempel:$ git log -2 --pretty=format:%h 4da45bef \ | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' 4da45be 7134973 -- NO NEWLINE $ git log -2 --pretty=tformat:%h 4da45bef \ | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' 4da45be 7134973
Dessutom, tolkas alla okända strängar som innehåller
%som om de hartformat:framför sig. Till exempel är dessa två likvärdiga:$ git log -2 --pretty=tformat:%h 4da45bef $ git log -2 --pretty=%h 4da45bef
EXEMPEL
-
Skriv ut listan över incheckningar som kan nås från den aktuella grenen.
git rev-list HEAD
-
Skriv ut listan över incheckningar på den här grenen, men som inte finns i uppströmsgrenen.
git rev-list @{upstream}..HEAD -
Formatera incheckningar med deras författare och incheckningsmeddelande (se även högnivåkommandot git-log[1]).
git rev-list --format=medium HEAD
-
Formatera incheckningar tillsammans med deras diffar (se även användarkommandot 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 incheckningar på den aktuella grenen som berörde någon fil i katalogen
Dokumentation.git rev-list HEAD -- Dokumentation/
-
Skriv ut listan över incheckningar som du har författat under det senaste året, på valfri gren, tagg eller annan referens.
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 (d.v.s. alla incheckningar och de blobbar och träd de innehåller).
git rev-list --objects HEAD
-
Jämför diskstorleken för alla nåbara objekt, med de som är nåbara från refloggar, och den totala packade storleken. Detta kan avgöra om
gitrepack-adkan minska kodförrådets storlek (genom att ta bort oåtkomliga objekt), och om utgångna refloggar kan hjälpa.# nåbara objekt git rev-list --disk-usage --objects --all # plus refloggar git rev-list --disk-usage --objects --all --reflog # total diskstorlek som används du -c .git/objects/pack/*.pack .git/objects/??/* # alternativ till du: lägg ihop fälten "size" och "size-pack" git count-objects -v
-
Rapportera diskstorleken för varje gren, exklusive objekt som används av den aktuella grenen. Detta kan hitta extremvärden som bidrar till en uppblåst kodförråds-storlek (t.ex. för att någon av misstag har genomfört 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å disken för grenar i en grupp av referenser, med undantag för en annan. Om du blandar objekt från flera fjärrar i ett enda arkiv kan detta visa vilka fjärrar som bidrar till kodförrådets storlek (med storleken på
originsom baslinje).git rev-list --disk-usage --objects --remotes=$suspect --not --remotes=origin
GIT
En del av git[1]-sviten