För att underlätta felsökning av framändor ignorerar fast-import alla rader som börjar med # (ASCII-pund/hash) upp till och inklusive raden som slutar LF. En kommentarsrad kan innehålla vilken bytesekvens som helst som inte innehåller en LF och kan därför användas för att inkludera detaljerad felsökningsinformation som kan vara specifik för framändan och användbar vid inspektion av en snabbimportdataström.

Följande datumformat stöds. Ett gränssnitt bör välja det format som ska användas för denna import genom att skicka formatnamnet i kommandoradsalternativet --date-format=<fmt>.

fast-import accepterar flera kommandon för att uppdatera det aktuella förvaret och kontrollera den aktuella importprocessen. Mer detaljerad diskussion (med exempel) av varje kommando följer senare.

Skapa eller uppdatera en gren med en ny incheckning, och registrera en logisk ändring i projektet.

där <ref> är namnet på grenen att göra incheckning på. Vanligtvis har grennamn prefixet refs/heads/ i Git, så import av CVS-grensymbolen RELENG-1_0 skulle använda refs/heads/RELENG-1_0 för värdet för <ref>. Värdet för <ref> måste vara ett giltigt refnamn i Git. Eftersom LF inte är giltigt i ett Git-refnamn, stöds ingen citerande eller escape-syntax här.

Ett mark-kommando kan valfritt visas och begär snabbimport för att spara en referens till den nyskapade incheckningen för framtida bruk av framändan (se nedan för format). Det är mycket vanligt att framändor markerar varje incheckning de skapar, vilket möjliggör framtida skapande av grenar från alla importerade incheckningar.

Kommandot data som följer efter committer måste tillhandahålla inchecknings-meddelandet (se nedan för data-kommandosyntax). För att importera ett tomt inchecknings-meddelande, använd en data-kod med längden 0. Inchecknings-meddelanden är fritt formaterade och tolkas inte av Git. För närvarande måste de kodas i UTF-8, eftersom snabbimport inte tillåter att andra kodningar anges.

Noll eller fler filemodify, filedelete, filecopy, filerename, filedeleteall och notemodify-kommandon kan inkluderas för att uppdatera innehållet i grenen innan incheckning skapas. Dessa kommandon kan anges i valfri ordning. Det rekommenderas dock att ett filedeleteall-kommando föregår alla filemodify, filecopy, filerename och notemodify-kommandon i samma incheckning, eftersom filedeleteall rensar grenen (se nedan).

LF efter kommandot är valfritt (det var tidigare obligatoriskt). Observera att av bakåtkompatibilitetsskäl, om inchecknings-kommandot avslutas med ett data-kommando (dvs. det har inga from-, merge-, filemodify-, filedelete-, filecopy-, filerename-, filedeleteall- eller notemodify-kommandon) så kan två LF-kommandon visas i slutet av kommandot istället för bara ett.

Ordnar snabbimport för att spara en referens till det aktuella objektet, vilket gör att gränssnittet kan hämta detta objekt vid en framtida tidpunkt, utan att känna till dess SHA-1. Här är det aktuella objektet det objektskapandekommando som mark-kommandot visas i. Detta kan vara commit, tag och blob, men commit är den vanligaste användningen.

där <idnum> är det nummer som tilldelats av användargränssnittet till detta märke. Värdet för <idnum> uttrycks som ett ASCII-decimaltal. Värdet 0 är reserverat och kan inte användas som ett märke. Endast värden större än eller lika med 1 får användas som märken.

Nya märkningar skapas automatiskt. Befintliga märkningar kan flyttas till ett annat objekt genom att helt enkelt återanvända samma <idnum> i ett annat mark-kommando.

Anger namnet på objektet i det ursprungliga källkontrollsystemet. fast-import ignorerar helt enkelt detta direktiv, men filtreringsprocesser som arbetar på och modifierar strömmen innan de matas till fast-import kan ha användningsområden för denna information

där <objekt-identifierare> är en sträng som inte innehåller LF.

Skapar en kommenterad tagg som refererar till en specifik incheckning. För att skapa lätta (icke-kommenterade) taggar, se kommandot reset nedan.

där <namn> är namnet på taggen som ska skapas.

Taggnamn får automatiskt prefixet refs/tags/ när de lagras i Git, så om man importerar CVS-grensymbolen RELENG-1_0-FINAL skulle man bara använda RELENG-1_0-FINAL för <namn>, och snabbimport kommer att skriva motsvarande referens som refs/tags/RELENG-1_0-FINAL.

Värdet för <namn> måste vara ett giltigt refnamn i Git och kan därför innehålla snedstreck. Eftersom LF inte är giltigt i ett Git-refnamn stöds ingen citerande eller escape-syntax här.

from-kommandot är detsamma som i commit-kommandot; se ovan för detaljer.

Kommandot tagger använder samma format som committer inom commit; se återigen ovan för detaljer.

Kommandot data som följer efter tagger måste tillhandahålla det kommenterade taggmeddelandet (se nedan för data-kommandosyntax). För att importera ett tomt taggmeddelande, använd en data med längden 0. Taggmeddelanden är fritt formaterade och tolkas inte av Git. För närvarande måste de kodas i UTF-8, eftersom snabbimport inte tillåter att andra kodningar anges.

Det stöds inte att signera kommenterade taggar under import från snabbimport. Att försöka inkludera din egen PGP/GPG-signatur rekommenderas inte, eftersom framändan inte (lätt) har tillgång till den kompletta uppsättningen byte som normalt ingår i en sådan signatur. Om signering krävs, skapa lättviktiga taggar från snabbimport med reset och skapa sedan de kommenterade versionerna av dessa taggar offline med standardprocessen git tag.

Skapar (eller återskapar) den namngivna grenen, valfritt med början från en specifik revision. Kommandot reset tillåter ett gränssnitt att utfärda ett nytt from-kommando för en befintlig gren, eller att skapa en ny gren från en befintlig incheckning utan att skapa en ny incheckning.

För en detaljerad beskrivning av <ref> och <incheckning-igt>, se ovan under commit och from.

LF efter kommandot är valfritt (det var tidigare obligatoriskt).

Kommandot reset kan också användas för att skapa lätta (icke-annoterade) taggar. Till exempel:

skulle skapa den lättviktiga taggen refs/tags/938 som refererar till vad det är som incheckning-märkning :938 refererar.

Begär att en filrevision skrivs till packfilen. Revisionen är inte kopplad till någon incheckning; denna koppling måste skapas i ett efterföljande commit-kommando genom att referera till blobben via ett tilldelat märke.

Kommandot mark är valfritt här eftersom vissa framända-användare har valt att generera Git SHA-1 för blobben på egen hand och mata in det direkt till commit. Detta är dock vanligtvis mer arbete än det är värt, eftersom märken är billiga att lagra och enkla att använda.

Tillhandahåller rådata (för användning som blob-/filinnehåll, inchecknings-meddelanden eller kommenterade taggmeddelanden) för snabbimport. Data kan levereras med ett exakt byte-antal eller avgränsas med en avslutande linje. Riktiga gränssnitt avsedda för konverteringar av produktionskvalitet bör alltid använda det exakta byte-antalformatet, eftersom det är mer robust och presterar bättre. Det avgränsade formatet är främst avsett för testning av snabbimport.

Kommentarrader som visas i <raw>-delen av data-kommandon tas alltid som en del av datamängden och ignoreras därför aldrig av snabbimport. Detta gör det säkert att importera fil-/meddelandeinnehåll vars rader kan börja med #.

Registrera att ett märke hänvisar till ett givet objekt utan att först skapa något nytt objekt.

För en detaljerad beskrivning av <incheckning-igt> se ovan under from.

Tvingar snabbimport att stänga den aktuella paketfilen, starta en ny och spara alla aktuella grenreferenser, taggar och märken.

Observera att snabbimport automatiskt växlar packfiler när den aktuella packfilen når --max-pack-size, eller 4 GiB, beroende på vilken gräns som är minst. Under ett automatiskt packfilsbyte uppdaterar inte snabbimport grenreferenser, taggar eller märken.

Eftersom en checkpoint kan kräva en avsevärd mängd CPU-tid och disk-IO (för att beräkna den totala paketets SHA-1-kontrollsumma, generera motsvarande indexfil och uppdatera referenserna) kan det lätt ta flera minuter för ett enda checkpoint-kommando att slutföras.

Framända-gränssnitt kan välja att utfärda kontrollpunkter under extremt stora och långvariga importer, eller när de behöver ge en annan Git-process åtkomst till en gren. Men med tanke på att ett 30 GiB Subversion-arkiv kan laddas in i Git via snabbimport på cirka 3 timmar, kanske explicit kontrollpunktshantering inte är nödvändig.

LF efter kommandot är valfritt (det var tidigare obligatoriskt).

Gör att fast-import skriver ut hela progress-raden oförändrad till dess standardutdatakanal (filbeskrivning 1) när kommandot bearbetas från indataströmmen. Kommandot har annars ingen inverkan på den aktuella importen eller på något av fast-imports interna tillstånd.

<any>-delen av kommandot kan innehålla vilken bytesekvens som helst som inte innehåller LF. LF efter kommandot är valfritt. Anropare kan vilja bearbeta utdata med ett verktyg som sed för att ta bort den inledande delen av raden, till exempel:

Att placera ett progress-kommando direkt efter en checkpoint informerar läsaren när checkpoint har slutförts och den säkert kan komma åt referenserna som snabbimporterades och uppdaterades.

Gör att snabbimport skriver ut SHA-1 som motsvarar en märkning till stdout eller till filbeskrivningen som tidigare arrangerats med argumentet --cat-blob-fd. Kommandot har annars ingen inverkan på den aktuella importen; dess syfte är att hämta SHA-1:or som senare incheckningar kan vilja referera till i sina inchecknings-meddelanden.

Se “Svar på kommandon” nedan för detaljer om hur du läser denna utdata på ett säkert sätt.

Gör att fast-import skriver ut en blob till en fildeskriptor som tidigare arrangerats med argumentet --cat-blob-fd. Kommandot har annars ingen inverkan på den aktuella importen; dess huvudsyfte är att hämta blobbar som kan finnas i fast-imports minne men inte är tillgängliga från målarkivet.

<dataref> kan antingen vara en märkes-referens (:<idnum>) som ställts in tidigare eller en fullständig 40-byte SHA-1 av en Git-blob, som redan finns eller är redo att skrivas.

Utdata använder samma format som git cat-file --batch:

Det här kommandot kan användas där ett filemodify-direktiv kan förekomma, vilket gör att det kan användas mitt i en incheckning. För ett filemodify som använder ett inline-direktiv kan det också förekomma precis före data-direktivet.

Se “Svar på kommandon” nedan för detaljer om hur du läser denna utdata på ett säkert sätt.

Skriver ut information om objektet vid en sökväg till en fildeskriptor som tidigare arrangerats med argumentet --cat-blob-fd. Detta gör det möjligt att skriva ut en blob från den aktiva incheckningen (med cat-blob) eller kopiera en blob eller ett träd från en tidigare incheckning för användning i den aktuella (med filemodify).

ls-kommandot kan också användas där ett filemodify-direktiv kan förekomma, vilket gör att det kan användas mitt i en incheckning.

Se filemodify ovan för en detaljerad beskrivning av <sökväg>.

Utdata använder samma format som git ls-tree <träd> -- <sökväg>:

<dataref> representerar blobben, trädet eller inchecknings-objektet vid <sökväg> och kan användas i senare kommandon av typen get-mark, cat-blob, filemodify eller ls.

Om det inte finns någon fil eller underträd vid den sökvägen kommer git fast-import istället att rapportera

Se “Svar på kommandon” nedan för detaljer om hur du läser denna utdata på ett säkert sätt.

Kräv att snabbimporten stöder den angivna funktionen, eller avbryt om den inte gör det.

<feature>-delen av kommandot kan vara något av följande:

Bearbetar det angivna alternativet så att git fast-import beter sig på ett sätt som passar framändas behov. Observera att alternativ som anges av framändan åsidosätts av alla alternativ som användaren kan ange för att git fast-import ska fungera.

<alternativ>-delen av kommandot kan innehålla vilket som helst av alternativen som helst som listas i OPTIONS-sektionen som inte ändrar importsemantiken, utan det inledande -- och behandlas på samma sätt.

Alternativkommandon måste vara de första kommandona på ingången (funktionskommandon räknas inte), för att ge ett alternativkommando efter att ett icke-alternativskommando är ett fel.

Följande kommandoradsalternativ ändrar importsemantik och får därför inte skickas som alternativ:

Om funktionen done inte används, behandlas det som om EOF hade lästs. Detta kan användas för att ange att snabbimporten ska slutföras tidigare.

Om kommandoradsalternativet --done eller kommandot feature done används är kommandot done obligatoriskt och markerar slutet på strömmen.

När du gör en förvars-konvertering, använd en unik markering per incheckning (mark :<n>) och ange alternativet --export-marks på kommandoraden. fast-import kommer att dumpa en fil som listar varje markering och Git-objektet SHA-1 som motsvarar den. Om gränssnittet kan koppla markeringarna tillbaka till källkodsrepositoriet är det enkelt att verifiera importens noggrannhet och fullständighet genom att jämföra varje Git-incheckning med motsvarande källkodsrevision.

Om det kommer från ett system som Perforce eller Subversion, borde detta vara ganska enkelt, eftersom snabbimportmarkeringen också kan vara Perforce changeset-numret eller Subversions revisionsnummer.

Bry dig inte om att försöka optimera framända-programmet så att det håller sig till en gren i taget under en import. Även om det kan vara något snabbare vid snabbimport, tenderar det att öka komplexiteten i framända-koden avsevärt.

Gren-LRU:n som är inbyggd för snabbimport tenderar att bete sig mycket bra, och kostnaden för att aktivera en inaktiv gren är så låg att det att studsa runt mellan grenar praktiskt taget inte har någon inverkan på importprestandan.

När du importerar en omdöpt fil eller katalog, radera helt enkelt det/de gamla namnet och ändra det/de nya namnet under motsvarande incheckning. Git utför namnbytesdetektering i efterhand, snarare än explicit under en incheckning.

Vissa andra SCM-system låter användaren skapa en tagg från flera filer som inte kommer från samma incheckning/ändringsset. Eller skapa taggar som är en delmängd av filerna som finns tillgängliga i förvaret.

Att importera dessa taggar som de är i Git är omöjligt utan att göra minst en incheckning som "fixar" filerna så att de matchar innehållet i taggen. Använd fast-imports kommando reset för att återställa en dummy-gren utanför ditt vanliga grenutrymme till bas-incheckningen för taggen, chacka-in sedan en eller flera filfixup-incheckningar och tagga slutligen dummy-grenen.

Till exempel, eftersom alla vanliga grenar lagras under refs/heads/, döp taggen fixup-grenen till TAG_FIXUP. På så sätt är det omöjligt för fixup-grenen som används av importören att ha namnrymdskonflikter med riktiga grenar som importerats från källan (namnet TAG_FIXUP är inte refs/heads/TAG_FIXUP).

När du checka-in i fixups, överväg att använda merge för att koppla den/de incheckningar som levererar filrevisioner till fixup-grenen. Genom att göra det kan verktyg som git blame spåra den verkliga inchecknings-historiken och korrekt kommentera källfilerna.

Efter att snabbimporten avslutas måste framända-programmet utföra rm .git/TAG_FIXUP för att ta bort dummy-grenen.

Så snart snabbimporten är klar är Git-arkivet helt giltigt och klart att användas. Vanligtvis tar detta bara en mycket kort tid, även för betydligt större projekt (100 000+ incheckningar).

Att packa om förvaret är dock nödvändigt för att förbättra datalokalitet och åtkomstprestanda. Det kan också ta timmar på extremt stora projekt (särskilt om -f och en stor --window-parameter används). Eftersom ompackning är säkert att köra tillsammans med läsare och skrivare, kör ompackningen i bakgrunden och låt den slutföras när den är klar. Det finns ingen anledning att vänta med att utforska ditt nya Git-projekt!

Om du väljer att vänta på ompackningen, försök inte köra prestandatester eller prestandatester förrän ompackningen är klar. Snabbimport ger ut suboptimala packfiler som helt enkelt aldrig syns i verkliga användningssituationer.

Om du packar om mycket gammal importerad data (t.ex. äldre än förra året), överväg att lägga ner lite extra CPU-tid och ange --window=50 (eller högre) när du kör git repack. Detta tar längre tid, men kommer också att producera en mindre packfil. Du behöver bara lägga ner ansträngningen en gång, och alla som använder ditt projekt kommer att dra nytta av det mindre förvaret.

Låt då och då ditt gränssnitt skicka ett "förlopp"-meddelande för snabbimport. Innehållet i meddelandena är helt fritt format, så ett förslag är att mata ut aktuell månad och år varje gång det aktuella inchecknings-datumet flyttas in i nästa månad. Dina användare kommer att känna sig bättre över att veta hur mycket av dataströmmen som har bearbetats.

Fast-import upprätthåller en minnesstruktur för varje objekt som skrivs i denna körning. På ett 32-bitarssystem är strukturen 32 byte, på ett 64-bitarssystem är strukturen 40 byte (på grund av de större pekarstorlekarna). Objekt i tabellen avallokeras inte förrän fast-import avslutas. Att importera 2 miljoner objekt på ett 32-bitarssystem kräver cirka 64 MiB minne.

Objekttabellen är egentligen en hashtabell som är kopplad till objektnamnet (den unika SHA-1). Denna lagringskonfiguration möjliggör snabbimport för att återanvända ett befintligt eller redan skrivet objekt och undvika att skriva dubbletter till utdatapaketfilen. Duplicerade blobbar är förvånansvärt vanliga vid import, vanligtvis på grund av grensammanslagningar i källkoden.

Märken lagras i en gles array, med 1 pekare (4 byte eller 8 byte, beroende på pekarstorlek) per märke. Även om arrayen är gles, rekommenderas fortfarande starkt att gränssnitt använder märken mellan 1 och n, där n är det totala antalet märken som krävs för denna import.

Grenar klassificeras som aktiva och inaktiva. Minnesanvändningen för de två klasserna skiljer sig markant åt.

Inaktiva grenar lagras i en struktur som använder 96 eller 120 byte (32-bitars respektive 64-bitars system), plus längden på grennamnet (vanligtvis under 200 byte), per gren. Fast-Import hanterar enkelt så många som 10 000 inaktiva grenar på under 2 MiB minne.

Aktiva grenar har samma overhead som inaktiva grenar, men innehåller också kopior av varje träd som nyligen har modifierats på den grenen. Om underträdet include inte har modifierats sedan grenen blev aktiv, kommer dess innehåll inte att laddas in i minnet, men om underträdet src har modifierats av en incheckning sedan grenen blev aktiv, kommer dess innehåll att laddas in i minnet.

Eftersom aktiva grenar lagrar metadata om filerna som finns på den grenen, kan deras lagringsstorlek i minnet växa till en avsevärd storlek (se nedan).

fast-import flyttar automatiskt aktiva grenar till inaktiv status baserat på en enkel algoritm för minst nyligen använda grenar. LRU-kedjan uppdateras för varje commit-kommando. Det maximala antalet aktiva grenar kan ökas eller minskas på kommandoraden med --active-branches=.

Träd (även kända som kataloger) använder bara 12 byte minne utöver det minne som krävs för deras poster (se "per aktiv fil" nedan). Kostnaden för ett träd är praktiskt taget noll, eftersom dess omkostnader amorteras ut över de enskilda filposterna.

Filer (och pekare till underträd) inom aktiva träd kräver 52 eller 64 byte (32/64-bitars plattformar) per post. För att spara utrymme samlas fil- och trädnamn i en gemensam strängtabell, vilket gör att filnamnet "Makefile" bara använder 16 byte (efter att stränghuvudet har inkluderats) oavsett hur många gånger det förekommer inom projektet.

Den aktiva grenens LRU, i kombination med filnamnssträngpoolen och lat laddning av underträd, möjliggör snabb import för att effektivt importera projekt med 2 000+ grenar och 45 114+ filer med ett mycket begränsat minnesfotavtryck (mindre än 2,7 MiB per aktiv gren).