Svenska ▾ Topics ▾ Latest version ▾ git-shortlog last updated in 2.53.0

NAMN

git-shortlog - Sammanfatta utdata från git log

SYNOPSIS

git shortlog [<flaggor>] [<revision-omfång>] [[--] <sökväg>…​]
git log --pretty=short | git shortlog [<flaggor>]

BESKRIVNING

Sammanfattar utdata från git log i ett format som är lämpligt för inkludering i utgivningsmeddelanden. Varje incheckning grupperas efter författare och titel.

Dessutom kommer "[PATCH]" att tas bort från incheckningsbeskrivningen.

Om inga revisioner skickas på kommandoraden och antingen standardinmatningen inte är en terminal eller om det inte finns någon aktuell gren, kommer git shortlog att mata ut en sammanfattning av loggen som lästs från standardinmatningen, utan referens till det aktuella kodförrådet.

ALTERNATIV

-n
--numbered

Sortera utdata efter antal incheckningar per författare i stället för författarens alfabetiska ordning.

-s
--summary

Undertryck incheckningsbeskrivningen och ge endast en sammanfattning av antalet incheckningar.

-e
--email

Visa e-postadress för varje författare.

--format[=<format>]

I stället för incheckningsrubriken, använd annan information för att beskriva varje incheckning. <format> kan vara vilken sträng som helst som accepteras av --format-alternativet i git log, till exempel * [%h] %s. (Se avsnittet "VACKRA FORMAT" i git-log[1].)

Varje vackert utskriven incheckning kommer att ompaketeras innan den visas.

--date=<format>

Visa datum formaterade enligt den givna datumsträngen. (Se alternativet --date i avsnittet "Incheckningsformatering" i git-log[1]). Användbart med --group=format:<format>.

--group=<typ>

Gruppincheckningar baserade på <typ>. Om inget --group-alternativ anges är standardvärdet author. <typ> är en av:

  • author, incheckningar grupperas efter författare

  • incheckare, incheckningar grupperas efter incheckare (samma som -c)

  • trailer:<fält>, <fält> tolkas som en trailer för incheckningsmeddelanden som inte är skiftlägeskänslig (se git-interpret-trailers[1]). Om ditt projekt till exempel använder trailers för Reviewed-by kanske du vill se vem som har granskat med git shortlog -ns --group=trailer:reviewed-by.

  • format:<format>, vilken sträng som helst som accepteras av --format-alternativet i git log. (Se avsnittet "VACKRA FORMAT" i git-log[1].)

    Observera att incheckningar som inte inkluderar slutraden inte kommer att räknas. Likaså kan incheckningar med flera slutrader (t.ex. flera signoffs) räknas mer än en gång (men bara en gång per unikt slutradsvärde i den incheckningen).

    Shortlog kommer att försöka tolka varje slutradsvärde som en name <mejl>-identitet. Om det lyckas tillämpas e-postmappningen och e-postadressen utelämnas om inte alternativet --email anges. Om värdet inte kan tolkas som en identitet kommer det att tas bokstavligt och fullständigt.

Om --group anges flera gånger räknas incheckningar under varje värde (men återigen, bara en gång per unikt värde i den incheckningen). Till exempel räknar git shortlog --group=author --group=trailer:co-authored-by både författare och medförfattare.

-c
--committer

Detta är ett alias för --group=committer.

-w[<bredd>[,<indent1>[,<indent2>]]]

Radbryt utdata genom att radbryta varje rad vid bredd. Den första raden i varje post är indenterad med indent1-mellanslag, och den andra och efterföljande raderna är indenterade med indent2-mellanslag. width, indent1 och indent2 är som standard 76, 6 respektive 9.

Om bredden är 0 (noll) dra då in raderna i utdata utan att radbryta dem.

<revisionsintervall>

Visa endast incheckningar inom det angivna revisionsintervallet. När inget <revisionsintervall> anges används som standard HEAD (d.v.s. hela historiken som leder till den aktuella incheckningen). origin..HEAD anger alla incheckningar som är åtkomliga från den aktuella incheckningen (d.v.s. HEAD), men inte från origin. För en komplett lista över sätt att stava <revisionsintervall>, se avsnittet "Ange intervall" i gitrevisions[7].

[--] <sökväg>…​

Betrakta endast incheckningar som är tillräckliga för att förklara hur filerna som matchar de angivna sökvägarna kom till.

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

Inchecknings Begränsning

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

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

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

-<nummer>
-n <nummer>
--max-count=<nummer>

Begränsa utdata till <nummer> incheckningar.

--skip=<nummer>

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

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

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

--since-as-filter=<datum>

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

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

Visa incheckningar äldre än <datum>.

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

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

--grep-reflog=<mönster>

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

--grep=<mönster>

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

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

--all-match

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

--invert-grep

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

-i
--regexp-ignore-case

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

--basic-regexp

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

-E
--extended-regexp

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

-F
--fixed-strings

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

-P
--perl-regexp

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

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

--remove-empty

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

--merges

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

--no-merges

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

--min-parents=<nummer>
--max-parents=<nummer>
--no-min-parents
--no-max-parents

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

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

--first-parent

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

--exclude-first-parent-only

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

--not

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

--all

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

--branches[=<mönster>]

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

--tags[=<mönster>]

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

--remotes[=<mönster>]

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

--glob=<glob-mönster>

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

--exclude=<glob-mönster>

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

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

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

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

--reflog

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

--alternate-refs

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

--single-worktree

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

--ignore-missing

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

--bisect

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

--stdin

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

--cherry-mark

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

--cherry-pick

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

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

--left-only
--right-only

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

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

--cherry

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

-g
--walk-reflogs

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

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

  1. Om startpunkten anges som ref@{<N:te>}, visa indexformatet.

  2. Om startpunkten angavs som ref@{now}, visa tidsstämpelformatet.

  3. Om ingetdera användes, men --date angavs på kommandoraden, visa tidsstämpeln i det format som begärs av --date.

  4. Annars, visa indexformatet.

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

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

--merge

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

--boundary

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

Historisk förenkling

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

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

<sökvägar>

Incheckningar som ändrar de angivna <sökvägarna> är markerade.

--simplify-by-decoration

Incheckningar som refereras av någon gren eller tagg väljs.

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

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

Standardläge

Förenklar historiken till den enklaste historiken som förklarar trädets slutliga tillstånd. Enklast eftersom den beskär vissa sidogrenar om slutresultatet är detsamma (dvs. sammanfogar grenar med samma innehåll)

--show-pulls

Inkludera alla incheckningar från standardläget, men även alla sammanslagnings-incheckningar som inte är TRÄDSAMA till den första föräldern men är TRÄDSAMA till en senare förälder. Det här läget är användbart för att visa de sammanslagnings-incheckningar som "först introducerade" en ändring i en gren.

--full-history

Samma som standardläget, men rensar inte bort en del historik.

--dense

Endast de valda incheckningar visas, plus några för att ha en meningsfull historik.

--sparse

Alla incheckningar i den förenklade historiken visas.

--simplify-merges

Ytterligare ett alternativ till --full-history för att ta bort onödiga sammanslagningar från den resulterande historiken, eftersom det inte finns några valda incheckningar som bidrar till denna sammanslagning.

--ancestry-path[=<incheckning>]

När ett intervall av incheckningar ges att visa (t.ex. <incheckning1>..<incheckning2> eller <incheckning2> ^<incheckning1>), och en incheckning_<incheckning>_ inom det intervallet, visas endast incheckningar i det intervallet som är förfäder till <incheckning>, underordnade till <incheckning>, eller <incheckning> självt. Om ingen incheckning anges, använd <incheckning1> (den exkluderade delen av intervallet) som <incheckning>. Kan skickas flera gånger; i så fall inkluderas en incheckning om det är någon av de angivna incheckningarna eller om det är en förfader eller ättling till en av dem.

En mer detaljerad förklaring följer.

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

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

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

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

  • I är den initiala incheckningen, där foo finns med innehållet asdf, och en fil quux finns med innehållet quux. Initiala incheckningar jämförs med ett tomt träd, så I är !TRÄDSAMA.

  • I A innehåller foo bara foo.

  • B innehåller samma ändring som A. Dess sammanslagning M är trivial och därför TRÄDSAMA för alla föräldrar.

  • C ändrar inte foo, men dess sammanslagning N ändrar det till foobar, så det är inte TRÄDSAMA med någon förälder.

  • D sätter foo till baz. Dess sammanslagning O kombinerar strängarna från N och D till foobarbaz; d.v.s. den är inte TRÄDSAMA med någon förälder.

  • E ändrar quux till xyzzy, och dess sammanslagning P kombinerar strängarna till quux xyzzy. P är TRÄDSAMA till O, men inte till E.

  • X är en oberoende rot-incheckning som lade till en ny fil side, och Y modifierade den. Y är TRÄDSAMA till X. Dess sammanslagning Q lade till side till P, och Q är TRÄDSAMA till P, men inte till Y.

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

Standardläge

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

Detta resulterar i:

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

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

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

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

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

	I  A  B  N  D  O  P  Q

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

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

--full-history med föräldraomskrivning

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

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

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

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

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

--dense

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

--sparse

Alla incheckningar som gnomgås inkluderas.

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

--simplify-merges

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

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

  • Sätt C till C.

  • Ersätt varje förälder P till C' med dess förenklingsmässiga P'. I processen, ta bort föräldrar som är förfäder till andra föräldrar eller som är rot-incheckningar TRÄDSAMA till ett tomt träd, och ta bort dubbletter, men var noga med att aldrig ta bort alla föräldrar som vi är TRÄDSAMA till.

  • Om efter denna föräldern omskrivning, C' är en root- eller sammanslagnings-incheckning (har noll eller >1 förälder), en gräns-incheckning eller !TRÄDSAMA, så finns den kvar. Annars ersätts den med sin enda förälder.

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

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

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

  • N`s föräldralista hade `I borttagen, eftersom den är en förfader till den andra föräldern M. Ändå fanns N kvar eftersom den är !TRÄDSAMA.

  • På liknande sätt togs I bort från P`s föräldralista. `P togs sedan bort helt, eftersom den hade en förälder och är TRÄDSAMA.

  • Q`s föräldralista förenklade `Y till X. X togs sedan bort eftersom det var en TRÄDSAMA-rot. Q togs sedan bort helt eftersom den hade en förälder och är TRÄDSAMA.

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

--ancestry-path[=<incheckning>]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	I---X

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

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

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

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

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

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

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

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

--show-pulls

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

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

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

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

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

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

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

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

KARTLÄGG FÖRFATTARE

Se gitmailmap[5].

Observera att om git shortlog körs utanför ett kodförråd (för att bearbeta logginnehåll på standardindata), kommer den att leta efter en .mailmap-fil i den aktuella katalogen.

GIT

En del av git[1]-sviten