git-fast-import - Online in de cloud

PROGRAMMA:

NAAM

git-fast-import - Backend voor snelle importeurs van Git-gegevens

KORTE INHOUD

voorkant | git snel importeren [Opties]

PRODUCTBESCHRIJVING

Dit programma is meestal niet wat de eindgebruiker direct wil uitvoeren. De meeste eindgebruikers willen
om een ​​van de bestaande frontend-programma's te gebruiken, die een specifiek type buitenlands parseert
bron en voert de daar opgeslagen inhoud naar toe git snel importeren.

fast-import leest een gemengde commando-/datastroom van standaardinvoer en schrijft er een of meer
packfiles rechtstreeks naar de huidige repository. Wanneer EOF wordt ontvangen op standaardinvoer,
snelle import schrijft bijgewerkte branch- en tag-referenties uit, waardoor de huidige repository volledig wordt bijgewerkt
met de nieuw geïmporteerde gegevens.

De fast-import-backend zelf kan importeren in een lege repository (een die al
geïnitialiseerd door git init) of update stapsgewijs een bestaande gevulde repository.
Of incrementele import al dan niet vanuit een bepaalde buitenlandse bron wordt ondersteund, hangt ervan af
op het frontend-programma dat wordt gebruikt.

OPTIES

--kracht
Forceer het bijwerken van gewijzigde bestaande branches, zelfs als dit tot commits zou leiden
verloren (aangezien de nieuwe commit niet de oude commit bevat).

--stil
Schakel alle niet-fatale uitvoer uit, zodat de snelle import stilstaat als deze succesvol is. Dit
optie schakelt de uitvoer uit die wordt weergegeven door --stats.

--statistieken
Geef enkele basisstatistieken weer over de objecten die fast-import heeft gemaakt, de packfiles
waarin ze zijn opgeslagen, en het geheugen dat tijdens deze run door fast-import werd gebruikt. Tonen
deze uitvoer is momenteel de standaard, maar kan worden uitgeschakeld met --quiet.

opties besteld, front-ends
--cat-blob-fd=
Schrijf antwoorden op get-mark-, cat-blob- en ls-query's naar de bestandsdescriptor
in plaats van stout. Maakt het mogelijk om de voortgangsoutput die bedoeld is voor de eindgebruiker te scheiden
uit andere uitvoer.

--datumformaat=
Specificeer het type datums dat de frontend zal leveren voor snelle import binnen de auteur,
committer- en tagger-opdrachten. Zie “Datumformaten” hieronder voor meer informatie hierover
formaten worden ondersteund, en hun syntaxis.

--gedaan
Beëindig met een fout als er aan het einde van de stream geen voltooide opdracht is. Deze optie
kan handig zijn voor het detecteren van fouten die ervoor zorgen dat de frontend eerder wordt beëindigd
is begonnen met het schrijven van een stream.

Locaties of Marks Bestanden
--export-markeringen=
Dumpt de tabel met interne markeringen naar wanneer voltooid. Markeringen worden één per regel geschreven
als: markante SHA-1. Frontends kunnen dit bestand gebruiken om importen te valideren nadat ze zijn uitgevoerd
voltooid, of om de cijfertabel over incrementele runs op te slaan. Als is alleen
geopend en afgekapt bij het controlepunt (of voltooiing) kan hetzelfde pad ook veilig zijn
gegeven aan --import-marks.

--import-markeringen=
Voordat u enige invoer verwerkt, laadt u de markeringen die zijn opgegeven in . Het invoerbestand moet
bestaat, moet leesbaar zijn en moet hetzelfde formaat gebruiken als geproduceerd door --export-marks.
Er kunnen meerdere opties worden geleverd om meer dan één set markeringen te importeren. Als er een merkteken is
gedefinieerd met verschillende waarden, wint het laatste bestand.

--import-marks-if-exists=
Zoals --import-marks, maar in plaats van een foutmelding te geven, wordt het bestand stilzwijgend overgeslagen als dit het geval is
bestaat niet.

--[no-]relatieve-markeringen
Na het opgeven van --relative-marks worden de paden opgegeven met --import-marks= en
--export-marks= zijn relatief ten opzichte van een interne map in de huidige repository. In
git-fast-import dit betekent dat de paden relatief zijn ten opzichte van de .git/info/fast-import
map. Andere importeurs kunnen echter een andere locatie gebruiken.

Relatieve en niet-relatieve markeringen kunnen worden gecombineerd door --(geen-)-relatieve-markeringen met elkaar te verweven
met de --(import|export)-marks= opties.

Prestaties en Compression Stemming
--actieve-takken=
Maximaal aantal vertakkingen dat tegelijk actief moet blijven. Zie “Geheugengebruik” hieronder
voor details. Standaard is 5.

--big-file-drempel=
Maximale grootte van een blob waarvoor snel importeren zal proberen een delta te maken, uitgedrukt
in bytes. De standaardwaarde is 512 m (512 MiB). Sommige importeurs willen dit misschien verlagen
systemen met beperkt geheugen.

--diepte=
Maximale deltadiepte, voor blob- en boomdeltificatie. Standaard is 10.

--export-pack-edges=
Nadat u een packfile hebt gemaakt, drukt u een regel met gegevens af naar met vermelding van de bestandsnaam van het
packfile en de laatste commit op elke branch die naar dat packfile is geschreven. Dit
informatie kan nuttig zijn na het importeren van projecten waarvan de totale objectset groter is dan de
4 GiB packfile-limiet, omdat deze commits kunnen worden gebruikt als randpunten tijdens aanroepen naar git
pack-objecten.

--max-verpakkingsgrootte=
Maximale grootte van elk uitvoerpakketbestand. De standaardinstelling is onbeperkt.

PRESTATIES

Dankzij het snelle importontwerp kunnen grote projecten in een minimale hoeveelheid geheugen worden geïmporteerd
gebruik en verwerkingstijd. Ervan uitgaande dat de frontend snelle import en
voer het een constante stroom gegevens in en importeer tijden voor projecten met meer dan 10 jaar geschiedenis
en die meer dan 100,000 individuele commits bevatten, worden over het algemeen binnen slechts 1-2 uur voltooid
vrij bescheiden (~ $ 2,000 USD) hardware.

De meeste knelpunten lijken te liggen in de toegang tot gegevens uit buitenlandse bronnen (de bron kan dat gewoon niet).
revisies snel genoeg uitpakken) of schijf-IO (snel importeren schrijft zo snel als de schijf wil
neem de gegevens). Het importeren verloopt sneller als de brongegevens op een ander station zijn opgeslagen
dan de doel-Git-repository (vanwege minder IO-conflicten).

ONTWIKKELING KOSTEN

Een typische frontend voor snelle import weegt meestal ongeveer 200 regels
Perl/Python/Ruby-code. De meeste ontwikkelaars zijn erin geslaagd om in slechts enkele stappen werkende importeurs te maken
een paar uur, ook al is het hun eerste blootstelling aan snelle import, en soms
zelfs voor Git. Dit is een ideale situatie, aangezien de meeste conversietools weggegooid kunnen worden
(één keer gebruiken en nooit meer terugkijken).

PARALLEL OPERATIE

Like git duwen or git halen, importen die via fast-import worden afgehandeld, kunnen veilig naast elkaar worden uitgevoerd
parallelle git repack -a -d of git gc aanroepen, of een andere Git-bewerking (inclusief git
snoeien, aangezien losse objecten nooit worden gebruikt bij snelimport).

fast-import vergrendelt de vertakkings- of tagreferenties die het actief importeert niet. Na de
import, tijdens de ref-updatefase, test fast-import elke bestaande vertakkingsreferentie om te verifiëren
de update zal een fast-forward update zijn (de commit opgeslagen in de ref is opgenomen in de
nieuwe geschiedenis van de commit die geschreven moet worden). Als de update geen versnelde update is,
fast-import zal het bijwerken van die ref overslaan en in plaats daarvan een waarschuwingsbericht afdrukken. snel importeren
zal altijd proberen alle vertakkingsreferenties bij te werken, en stopt niet bij de eerste fout.

Branch-updates kunnen worden geforceerd met --force, maar het wordt aanbevolen dit alleen te gebruiken op
een verder stille opslagplaats. Het gebruik van --force is niet nodig voor een eerste import in
een lege opslagplaats.

TECHNISCHE DISCUSSIE

fast-import volgt een reeks vertakkingen in het geheugen. Elke vestiging kan worden aangemaakt of gewijzigd op
elk punt tijdens het importproces door een commit-opdracht naar de invoerstroom te verzenden. Dit
Dankzij het ontwerp kan een frontend-programma een onbeperkt aantal vertakkingen verwerken
tegelijkertijd het genereren van commits in de volgorde waarin ze beschikbaar zijn vanuit de brongegevens.
Het vereenvoudigt ook de frontend-programma's aanzienlijk.

fast-import gebruikt of wijzigt de huidige werkmap of enig bestand daarin niet.
(Het werkt echter wel de huidige Git-repository bij, waarnaar wordt verwezen door GIT_DIR.) Daarom
een importfrontend kan de werkmap voor zijn eigen doeleinden gebruiken, zoals uitpakken
bestandsrevisies uit de buitenlandse bron. Deze onwetendheid over de werkmap ook
zorgt ervoor dat fast-import zeer snel kan worden uitgevoerd, omdat er geen kostbaar bestand hoeft te worden uitgevoerd
updatebewerkingen bij het schakelen tussen vestigingen.

INVOER FORMAT

Met uitzondering van onbewerkte bestandsgegevens (die Git niet interpreteert) de snelimportinvoer
formaat is op tekst (ASCII) gebaseerd. Dit op tekst gebaseerde formaat vereenvoudigt de ontwikkeling en het opsporen van fouten
van frontend-programma's, vooral als het een taal op een hoger niveau betreft, zoals Perl, Python of Ruby
wordt gebruikt.

fast-import is zeer streng in zijn invoer. Waar we hieronder SP zeggen, bedoelen we precies een
ruimte. Op dezelfde manier betekent LF één (en slechts één) regelinvoer en HT één (en slechts één) horizontaal
tabblad. Het opgeven van extra witruimtetekens zal onverwachte resultaten veroorzaken, zoals
filiaalnamen of bestandsnamen met spaties vooraan of achteraan in hun naam, of vroeg
beëindiging van de snelle import wanneer er onverwachte invoer wordt aangetroffen.

Stroom Heb je vragen? Stel ze hier.
Om te helpen bij het debuggen van frontends negeert fast-import elke regel die begint met # (ASCII
pound/hash) tot en met de regel die eindigt op LF. Een commentaarregel kan deze bevatten
reeks bytes die geen LF bevat en daarom kan worden gebruikt om er wel een op te nemen
gedetailleerde foutopsporingsinformatie die specifiek kan zijn voor de frontend en nuttig kan zijn wanneer
het inspecteren van een snel geïmporteerde gegevensstroom.

Datum Formaten
De volgende datumnotaties worden ondersteund. Een frontend moet het formaat selecteren dat het zal gebruiken
voor deze import door de formaatnaam door te geven in --date-format= opdrachtregeloptie.

rauw
Dit is het oorspronkelijke Git-formaat en is SP . Het is ook snelimport
standaardformaat, als --date-format niet is opgegeven.

Het tijdstip van de gebeurtenis wordt gespecificeerd door als het aantal seconden sinds de UNIX
tijdperk (middernacht, 1 januari 1970, UTC) en is geschreven als een decimaal geheel getal in ASCII.

De lokale offset wordt gespecificeerd door als een positieve of negatieve compensatie ten opzichte van UTC.
EST (dat 5 uur achterloopt op UTC) zou bijvoorbeeld worden uitgedrukt in door “-0500”
terwijl UTC “+0000” is. De lokale offset heeft geen invloed ; het wordt alleen gebruikt als een
advies om formatteringsroutines te helpen de tijdstempel weer te geven.

Als de lokale offset niet beschikbaar is in het bronmateriaal, gebruik dan “+0000”, of de hoogste
gemeenschappelijke lokale offset. Veel organisaties hebben bijvoorbeeld een CVS-repository met
alleen toegankelijk voor gebruikers die zich op dezelfde locatie en tijdzone bevinden.
In dit geval kan worden uitgegaan van een redelijke compensatie ten opzichte van UTC.

In tegenstelling tot het rfc2822-formaat is dit formaat erg strikt. Elke variatie in opmaak
zorgt ervoor dat fast-import de waarde verwerpt.

rfc2822
Dit is het standaard e-mailformaat zoals beschreven door RFC 2822.

Een voorbeeldwaarde is 'Di 6 februari 11:22:18 2007 -0500'. De Git-parser is nauwkeurig, maar a
beetje aan de milde kant. Het is dezelfde parser die wordt gebruikt door git am bij het aanbrengen van pleisters
ontvangen via e-mail.

Sommige verkeerd opgemaakte tekenreeksen kunnen als geldige datums worden geaccepteerd. In sommige van deze gevallen zal Git dat wel doen
nog steeds de juiste datum uit de verkeerd opgemaakte string kunnen halen. Er zijn ook
sommige soorten verkeerd opgemaakte strings die Git verkeerd zal parseren, en toch als geldig beschouwt.
Ernstig misvormde snaren worden afgewezen.

In tegenstelling tot het bovenstaande onbewerkte formaat, is de tijdzone/UTC-offsetinformatie opgenomen in een RFC
2822-datumtekenreeks wordt gebruikt om de datumwaarde vóór opslag aan te passen aan UTC. Daarom
Het is belangrijk dat deze informatie zo nauwkeurig mogelijk is.

Als het bronmateriaal RFC 2822-stijldatums gebruikt, moet de frontend snel importeren mogelijk maken
het parseren en converteren afhandelen (in plaats van het zelf te proberen) als Git
parser is goed getest in het wild.

Frontends zouden de voorkeur moeten geven aan het onbewerkte formaat als het bronmateriaal al UNIX-epoch gebruikt
formaat, kan worden overgehaald om datums in dat formaat op te geven, of het formaat ervan is gemakkelijk
converteerbaar, omdat er geen dubbelzinnigheid is bij het parseren.

nu
Gebruik altijd de huidige tijd en tijdzone. Er moet altijd voor het letterlijke nu worden gezorgd
.

Dit is een speelgoedformaat. De huidige tijd en tijdzone van dit systeem wordt altijd gekopieerd
in de identiteitsreeks op het moment dat deze wordt gemaakt door snel importeren. Er is geen
manier om een ​​andere tijd of tijdzone op te geven.

Dit specifieke formaat wordt geleverd omdat het kort is om te implementeren en nuttig kan zijn voor:
proces dat nu een nieuwe commit wil maken, zonder een werkende
map of git update-index.

Als afzonderlijke auteur- en committer-opdrachten worden gebruikt in een commit, is het mogelijk dat de tijdstempels dat niet doen
overeenkomen, omdat de systeemklok twee keer wordt opgevraagd (één keer voor elke opdracht). De enige manier
om ervoor te zorgen dat de identiteitsinformatie van zowel de auteur als de committer hetzelfde tijdstempel heeft
is het weglaten van de auteur (en dus kopiëren van de committer) of het gebruiken van een ander datumformaat dan
.

commando's
fast-import accepteert verschillende opdrachten om de huidige repository bij te werken en de
huidige importproces. Een meer gedetailleerde bespreking (met voorbeelden) van elke opdracht volgt
later.

plegen
Creëert een nieuwe branch of werkt een bestaande branch bij door een nieuwe commit te maken en
het bijwerken van de branch zodat deze naar de nieuw gemaakte commit verwijst.

label
Creëert een geannoteerd tagobject van een bestaande commit of branch. Lichtgewicht labels
worden niet ondersteund door deze opdracht, omdat ze niet worden aanbevolen voor opname
betekenisvolle momenten in de tijd.

opnieuw in te stellen
Reset een bestaande vestiging (of een nieuwe vestiging) naar een specifieke revisie. Dit commando moet
kan worden gebruikt om een ​​branch naar een specifieke revisie te veranderen zonder er een commit voor te doen.

bobbel
Converteer onbewerkte bestandsgegevens naar een blob, voor toekomstig gebruik in een commit-opdracht. Deze opdracht is
optioneel en is niet nodig om een ​​import uit te voeren.

checkpoint
Forceert snelle import om het huidige pakketbestand te sluiten en genereert de unieke SHA-1-controlesom
en index, en start een nieuw packfile. Deze opdracht is optioneel en is niet nodig
een import uitvoeren.

voortgang
Zorgt ervoor dat fast-import de hele regel echoot naar zijn eigen standaarduitvoer. Deze opdracht is
optioneel en is niet nodig om een ​​import uit te voeren.

gedaan
Markeert het einde van de stroom. Deze opdracht is optioneel, tenzij de voltooide functie was
aangevraagd met behulp van de opdrachtregeloptie --done of de opdracht feature done.

haal-markering
Zorgt ervoor dat snel importeren de SHA-1 afdrukt die overeenkomt met een markering in de bestandsdescriptor
ingesteld met --cat-blob-fd, of stdout als dit niet is opgegeven.

kat-blob
Zorgt ervoor dat snel importeren een blob afdrukt cat-bestand --partij formaat naar de bestandsdescriptor
ingesteld met --cat-blob-fd of stdout indien niet gespecificeerd.

ls
Zorgt ervoor dat fast-import een regel afdrukt die een directory-item beschrijft ls-boom formatteren naar
de bestandsdescriptor is ingesteld met --cat-blob-fd of stdout als deze niet is opgegeven.

kenmerken
Schakel de opgegeven functie in. Dit vereist dat fast-import het opgegeven ondersteunt
functie en wordt afgebroken als dit niet het geval is.

optie
Geef een van de opties op die worden vermeld onder OPTIES, waarbij de semantische stream niet wordt gewijzigd
voldoen aan de behoeften van de frontend. Deze opdracht is optioneel en is niet nodig om een
importeren.

plegen
Maak of update een branch met een nieuwe commit, waarbij één logische wijziging in het project wordt vastgelegd.

'commit' SP LF
markering?
(‘auteur’ (SP )? SP LT GT SP LF)?
'committor' (SP )? SP LT GT SP LF
gegevens
('van' SP LF)?
('samenvoegen' SP LF)?
(filemodify | filelete | filecopy | filerename | fileleteall | notemodify)*
LF?

waar is de naam van de branch waarop de commit moet worden gemaakt. Typisch zijn filiaalnamen
voorafgegaan door refs/heads/ in Git, dus het importeren van het CVS-taksymbool RELENG-1_0 zou gebruiken
refs/heads/RELENG-1_0 voor de waarde van . De waarde van moet een geldige refnaam zijn
in Git. Omdat LF niet geldig is in een Git-refname, wordt er geen syntaxis met aanhalingstekens of escape-tekens ondersteund
hier.

Optioneel kan er een markeercommando verschijnen, waarin wordt gevraagd om snel te importeren om een ​​verwijzing naar het
nieuw aangemaakte commit voor toekomstig gebruik door de frontend (zie hieronder voor formaat). Het is heel
Het is gebruikelijk dat frontends elke commit die ze maken markeren, waardoor toekomstige branch mogelijk wordt
creatie van elke geïmporteerde commit.

Het datacommando dat volgt op de committer moet het commit-bericht leveren (zie hieronder voor data
opdrachtsyntaxis). Om een ​​leeg commit-bericht te importeren, gebruikt u gegevens met een lengte van 0. Commit-berichten
zijn vrije vorm en worden niet door Git geïnterpreteerd. Momenteel moeten ze gecodeerd zijn in UTF-8, zoals
fast-import staat niet toe dat andere coderingen worden gespecificeerd.

Nul of meer filemodify, filedelete, filecopy, filerename, fileleteall en notemodify
Er kunnen opdrachten worden opgenomen om de inhoud van de vertakking bij te werken voordat de
verbinden. Deze commando's kunnen in willekeurige volgorde worden gegeven. Het wordt echter aanbevolen om a
De opdracht fileleteall gaat vooraf aan alle opdrachten filemodify, filecopy, filerename en notemodify
in dezelfde commit, terwijl fileleteall de branch schoonveegt (zie hieronder).

De LF na het commando is optioneel (vroeger was dit vereist).

auteur
Optioneel kan een auteursopdracht verschijnen als de auteursinformatie hiervan kan afwijken
de committer-informatie. Als de auteur wordt weggelaten, wordt de snelle import automatisch uitgevoerd
gebruik de informatie van de committer voor het auteursgedeelte van de commit. Zie hieronder voor een
beschrijving van de velden in auteur, omdat deze identiek zijn aan committer.

committer
Het committer commando geeft aan wie deze commit heeft gemaakt, en wanneer.

Hier is de weergavenaam van de persoon (bijvoorbeeld “Com M Itter”) en is
het e-mailadres van de persoon (“cm@voorbeeld.com”). LT en GT zijn letterlijk minder dan
(\x3c) en groter dan (\x3e) symbolen. Deze zijn nodig om de e-mail af te bakenen
adres uit de andere velden in de regel. Let daar op En zijn vrije vorm
en kan elke reeks bytes bevatten, behalve LT, GT en LF. is doorgaans UTF-8
gecodeerd.

Het tijdstip van de wijziging wordt gespecificeerd door met behulp van de geselecteerde datumnotatie
door de --date-format= opdrachtregeloptie. Zie “Datumformaten” hierboven voor de set
van ondersteunde formaten en hun syntaxis.

vanaf
Het from commando wordt gebruikt om de commit te specificeren waaruit deze branch moet worden geïnitialiseerd. Dit
revisie zal de eerste voorouder van de nieuwe commit zijn. De staat van de boom gebouwd in
deze commit begint met de status van de from commit, en wordt gewijzigd door de
inhoudswijzigingen in deze commit.

Het weglaten van het commando from in de eerste commit van een nieuwe branch zal een snelle import veroorzaken
om die commit zonder voorouder aan te maken. Dit is meestal alleen gewenst voor de initiaal
vastleggen van een project. Als de frontend alle bestanden helemaal opnieuw maakt bij het maken van een nieuw
branch kan een merge-commando worden gebruikt in plaats van from om de commit te starten met een leeg bestand
boom. Het weglaten van het commando from op bestaande branches is meestal gewenst, omdat de
Er wordt automatisch aangenomen dat de huidige commit op die branch de eerste voorloper is van de
nieuwe toezegging.

Omdat LF niet geldig is in een Git-refname of SHA-1-expressie, is er geen syntaxis tussen aanhalingstekens of escape-tekens
wordt binnen ondersteund .

Hier is een van de volgende:

· De naam van een bestaande vertakking die al in de interne vertakkingstabel van fast-import staat. Als
fast-import kent de naam niet, het wordt behandeld als een SHA-1-expressie.

· Een merkreferentie, : , waar is het merknummer.

De reden dat fast-import wordt gebruikt: om een ​​merkreferentie aan te duiden is dit teken dat niet
legal in een Git-branchnaam. De leidende: maakt het gemakkelijk om onderscheid te maken tussen de
merk 42 (:42) en de tak 42 (42 of refs/heads/42), of een verkorte SHA-1
die toevallig alleen uit tien cijfers bestond.

Merken moeten worden aangegeven (via merk) voordat ze kunnen worden gebruikt.

· Een volledige commit SHA-40 van 1 bytes of afgekort in hex.

· Elke geldige Git SHA-1-expressie die wordt omgezet in een commit. Zie “SPECIFICEREN
HERZIENINGEN” in gitrevisies(7) voor details.

· De speciale nul SHA-1 (40 nullen) geeft aan dat de vertakking moet worden verwijderd.

Het speciale geval van het opnieuw starten van een incrementele import vanaf de huidige vertakkingswaarde
moet worden geschreven als:

van refs/heads/branch^0

Het achtervoegsel ^0 is nodig omdat fast-import niet toestaat dat een vertakking begint
zelf, en de branch wordt in het geheugen aangemaakt voordat het from-commando zelfs maar wordt gelezen
de invoer. Het toevoegen van ^0 zal een snelle import forceren om de commit via Git's op te lossen
revisie-parseringsbibliotheek, in plaats van de interne vertakkingstabel, waardoor deze wordt geladen
de bestaande waarde van de vestiging.

samensmelten
Bevat één extra voorouder-commit. De aanvullende afkomstlink verandert niet
de manier waarop de boomstatus bij deze commit wordt opgebouwd. Als het commando from wordt weggelaten wanneer
door een nieuwe branch aan te maken, zal de eerste merge commit de eerste voorloper zijn van de
huidige commit, en de branch zal beginnen zonder bestanden. Een onbeperkt aantal
merge-opdrachten per commit zijn toegestaan ​​door fast-import, waardoor een n-way tot stand wordt gebracht
samenvoegen.

Hier is een van de commit-specificatie-expressies die ook worden geaccepteerd door from
(zie hierboven).

bestand wijzigen
Opgenomen in een commit-opdracht om een ​​nieuw bestand toe te voegen of de inhoud van een bestaand bestand te wijzigen
bestand. Met deze opdracht kunt u op twee verschillende manieren de inhoud van het bestand opgeven.

Extern gegevensformaat
De gegevensinhoud voor het bestand is al geleverd door een eerdere blob-opdracht. De
frontend hoeft het alleen maar aan te sluiten.

'M'SP SP SP LF

Hier meestal moet een merkreferentie zijn (: ) ingesteld door een prior
blob-opdracht, of een volledige SHA-40 van 1 bytes van een bestaand Git-blob-object. Als is
040000` dan moet de volledige 40-byte SHA-1 van een bestaande Git-boom zijn
object of een merkreferentie ingesteld met --import-marks.

Inline gegevensformaat
De gegevensinhoud voor het bestand is nog niet aangeleverd. De frontend wil dat
geef het op als onderdeel van deze wijzigingsopdracht.

'M'SP SP 'inline' SP LF
gegevens

Zie hieronder voor een gedetailleerde beschrijving van de dataopdracht.

In beide formaten is het type bestandsinvoer, gespecificeerd in octaal. Alleen Git
ondersteunt de volgende modi:

· 100644 of 644: een normaal (niet-uitvoerbaar) bestand. Het merendeel van de bestanden in de meeste
projecten gebruiken deze modus. Als je twijfelt, is dit wat je wilt.

· 100755 of 755: een normaal, maar uitvoerbaar bestand.

· 120000: Een symlink, de inhoud van het bestand zal het linkdoel zijn.

· 160000: Een gitlink, SHA-1 van het object verwijst naar een commit in een andere repository.
Git-links kunnen alleen worden gespecificeerd door SHA of via een commit-markering. Ze zijn gewend om
submodules implementeren.

· 040000: een submap. Submappen kunnen alleen worden opgegeven door SHA of via a
boommarkering ingesteld met --import-markeringen.

In beide formaten is het volledige pad van het bestand dat moet worden toegevoegd (als dat nog niet het geval is
bestaand) of aangepast (indien al bestaand).

A string moet mapscheidingstekens in UNIX-stijl gebruiken (slash /), may
bevatten een andere byte dan LF, en mogen niet beginnen met dubbele aanhalingstekens (").

Een pad kan tekenreeksaanhalingstekens in C-stijl gebruiken; dit wordt in alle gevallen geaccepteerd en is verplicht indien
de bestandsnaam begint met dubbele aanhalingstekens of bevat LF. In C-stijl citeren: het volledige
naam moet tussen dubbele aanhalingstekens staan, en eventuele LF, backslash of dubbele aanhalingstekens
tekens moeten worden geëscaped door ze vooraf te laten gaan door een backslash (bijvoorbeeld "path/with\n, \
en \"erin").

De waarde van moet in canonieke vorm zijn. Dat is het mag niet:

· een lege mapcomponent bevatten (bijv. foo//bar is ongeldig),

· eindigen met een mapscheidingsteken (bijvoorbeeld foo/ is ongeldig),

· begin met een mapscheidingsteken (bijvoorbeeld /foo is ongeldig),

· bevatten de speciale component. of .. (foo/./bar en foo/../bar zijn bijvoorbeeld
ongeldig).

De wortel van de boom kan worden weergegeven door een lege string als .

Het is aanbevolen dat altijd gecodeerd worden met UTF-8.

bestandverwijderen
Opgenomen in een commit-opdracht om een ​​bestand te verwijderen of recursief een geheel te verwijderen
directory van het filiaal. Als het bestand of de map wordt verwijderd, wordt de bovenliggende map
leeg is, wordt de bovenliggende map automatisch ook verwijderd. Dit stroomt naar boven
boom totdat de eerste niet-lege map of de root is bereikt.

'D' SP LF

hier is het volledige pad van het bestand of de submap die moet worden verwijderd uit de
tak. Zie filemodify hierboven voor een gedetailleerde beschrijving van .

bestandskopie
Kopieert recursief een bestaand bestand of submap naar een andere locatie binnen het
tak. Het bestaande bestand of de bestaande map moet bestaan. Als de bestemming bestaat, zal dat ook zo zijn
volledig worden vervangen door de inhoud die van de bron is gekopieerd.

'C'SP SP LF

hier de eerste is de bronlocatie en de tweede is de bestemming.
Zie filemodify hierboven voor een gedetailleerde beschrijving van wat eruit kan zien. Om een ​​te gebruiken
bronpad dat SP bevat, het pad moet tussen aanhalingstekens staan.

Een filecopy-opdracht wordt onmiddellijk van kracht. Zodra de bronlocatie is gekopieerd
op de bestemming hebben eventuele toekomstige opdrachten die op de bronlocatie worden toegepast geen invloed
de bestemming van de kopie.

bestandsnaam
Hernoemt een bestaand bestand of submap naar een andere locatie binnen de vertakking.
Het bestaande bestand of de bestaande map moet bestaan. Als de bestemming bestaat, zal dat zo zijn
vervangen door de bronmap.

'R' SP SP LF

hier de eerste is de bronlocatie en de tweede is de bestemming.
Zie filemodify hierboven voor een gedetailleerde beschrijving van wat eruit kan zien. Om een ​​te gebruiken
bronpad dat SP bevat, het pad moet tussen aanhalingstekens staan.

Een opdracht voor het wijzigen van de bestandsnaam wordt onmiddellijk van kracht. Zodra de bronlocatie is geweest
hernoemd naar de bestemming, alle toekomstige opdrachten die op de bronlocatie worden toegepast, zullen dat doen
maak daar nieuwe bestanden en heb geen invloed op de bestemming van de hernoeming.

Merk op dat een bestandsnaam hetzelfde is als een bestandskopie gevolgd door een filedelete van het
bron locatie. Er is een klein prestatievoordeel bij het gebruik van de bestandsnaam, maar de
Het voordeel is zo klein dat het nooit de moeite waard is om een ​​verwijder/toevoeg-paar te proberen om te zetten
bronmateriaal omzetten in een nieuwe naam voor snelle import. Deze opdracht voor het wijzigen van de bestandsnaam wordt gegeven
gewoon om frontends te vereenvoudigen die al hernoemingsinformatie hebben en geen moeite willen doen
door het op te splitsen in een bestandskopie gevolgd door een filedelete.

ingediendalles verwijderen
Inbegrepen in een commit-opdracht om alle bestanden (en ook alle mappen) uit de
tak. Met deze opdracht wordt de interne vertakkingsstructuur gereset zodat deze geen bestanden meer bevat,
waardoor de frontend vervolgens alle interessante bestanden helemaal opnieuw kan toevoegen.

'alles verwijderen' LF

Deze opdracht is uiterst handig als de frontend het niet weet (of er niet om geeft).
weet) welke bestanden zich momenteel in de branch bevinden en daarom niet het juiste bestand kunnen genereren
filedelete-opdrachten om de inhoud bij te werken.

Het uitgeven van een fileleteall gevolgd door de benodigde filemodify-opdrachten om het juiste bestand in te stellen
inhoud zal dezelfde resultaten opleveren als het verzenden van alleen het benodigde bestand, modify en
filedelete-opdrachten. Voor het gebruik van de fileleteall-aanpak is mogelijk snelle import vereist
iets meer geheugen per actieve vertakking (minder dan 1 MiB voor zelfs de meeste grote projecten);
dus frontends die eenvoudig alleen de getroffen paden voor een commit kunnen verkrijgen, zijn dat wel
daartoe aangemoedigd.

notitiewijzigen
Opgenomen in een commit commando om een ​​nieuwe notitie toe te voegen met annotaties van a
of wijzig de inhoud van deze annotatie. Intern is het vergelijkbaar met filemodify 100644 op
pad (misschien opgesplitst in submappen). Het wordt afgeraden om andere te gebruiken
opdrachten om naar de boom behalve fileleteall om alle bestaande te verwijderen
notities in deze boom. Dit commando heeft twee verschillende manieren om de inhoud van te specificeren
de notitie.

Extern gegevensformaat
De gegevensinhoud voor de notitie is al geleverd door een eerdere blob-opdracht. De
frontend hoeft het alleen maar te verbinden met de commit die moet worden geannoteerd.

'N' SP SP LF

Hier kan een merkreferentie zijn (: ) ingesteld door een eerdere blob
opdracht, of een volledige SHA-40 van 1 bytes van een bestaand Git-blob-object.

Inline gegevensformaat
De gegevensinhoud voor de notitie is nog niet verstrekt. De frontend wil dat
geef het op als onderdeel van deze wijzigingsopdracht.

'N' SP 'inline' SP LF
gegevens

Zie hieronder voor een gedetailleerde beschrijving van de dataopdracht.

In beide formaten is ook een van de commit-specificatie-expressies
aanvaard door van (zie hierboven).

Mark
Zorgt voor een snelle import om een ​​verwijzing naar het huidige object op te slaan, waardoor de frontend mogelijk wordt
om dit object op een toekomstig tijdstip terug te roepen, zonder de SHA-1 te kennen. Hier de
huidige object is de opdracht voor het maken van objecten waarin de opdracht Markeren verschijnt. Dit kan zijn
commit, tag en blob, maar commit is het meest voorkomende gebruik.

'markeer' SP ':' LF

waar is het nummer dat door de frontend aan dit merk is toegewezen. De waarde van is
uitgedrukt als een decimaal geheel getal in ASCII. De waarde 0 is gereserveerd en kan niet worden gebruikt als
markering. Alleen waarden groter dan of gelijk aan 1 mogen als markering worden gebruikt.

Nieuwe markeringen worden automatisch aangemaakt. Bestaande markeringen kunnen eenvoudig naar een ander object worden verplaatst
door hetzelfde te hergebruiken in een ander markeercommando.

label
Creëert een geannoteerde tag die verwijst naar een specifieke commit. Om lichtgewicht te creëren
(niet-geannoteerde) tags zie de reset-opdracht hieronder.

'tag' SP LF
'van' SP LF
'takker' (SP )? SP LT GT SP LF
gegevens

waar is de naam van de tag die moet worden gemaakt.

Tagnamen worden automatisch voorafgegaan door refs/tags/ wanneer ze in Git worden opgeslagen, dus het importeren van de
CVS-taksymbool RELENG-1_0-FINAL zou alleen RELENG-1_0-FINAL gebruiken voor , En
fast-import zal de corresponderende ref schrijven als refs/tags/RELENG-1_0-FINAL.

De waarde van moet een geldige refname zijn in Git en kan daarom forward
schuine strepen. Omdat LF niet geldig is in een Git-refname, wordt er geen syntaxis met aanhalingstekens of escape-tekens ondersteund
hier.

Het from-commando is hetzelfde als het commit-commando; zie hierboven voor details.

Het tagger-commando gebruikt hetzelfde formaat als committer binnen commit; zie opnieuw hierboven voor
details.

Het datacommando dat volgt op de tagger moet het geannoteerde tagbericht leveren (zie hieronder voor
syntaxis van gegevensopdrachten). Om een ​​leeg tagbericht te importeren, gebruikt u gegevens met een lengte van 0. Tag-berichten zijn
vrije vorm en worden niet geïnterpreteerd door Git. Momenteel moeten ze gecodeerd zijn in UTF-8, zoals
fast-import staat niet toe dat andere coderingen worden gespecificeerd.

Het ondertekenen van geannoteerde tags tijdens het importeren vanuit snel importeren wordt niet ondersteund. Proberen
het toevoegen van uw eigen PGP/GPG-handtekening wordt niet aanbevolen, aangezien de frontend dit niet (gemakkelijk) doet
hebben toegang tot de volledige set bytes die normaal gesproken in een dergelijke handtekening past. Als
Ondertekening is vereist. Maak vervolgens lichtgewicht tags vanuit snel importeren met reset
maak de geannoteerde versies van die tags offline met de standaard git label proces.

opnieuw in te stellen
Creëert (of hercreëert) de genoemde vertakking, optioneel beginnend vanaf een specifieke revisie. De
Met het reset-commando kan een frontend een nieuw from-commando geven voor een bestaande branch, of to
maak een nieuwe branch van een bestaande commit zonder een nieuwe commit te maken.

SP 'resetten' LF
('van' SP LF)?
LF?

Voor een gedetailleerde beschrijving van En zie hierboven onder commit en from.

De LF na het commando is optioneel (vroeger was dit vereist).

De reset-opdracht kan ook worden gebruikt om lichtgewicht (niet-geannoteerde) tags te maken. Voor
voorbeeld:

refs/tags/938 resetten
van :938

zou de lichtgewicht tag refs/tags/938 creëren, verwijzend naar het commit-teken :938
gevonden.

bobbel
Verzoekt om één bestandsrevisie naar het pakketbestand te schrijven. De herziening is nergens mee verbonden
verbinden; deze verbinding moet tot stand worden gebracht in een volgend commit-commando door te verwijzen naar de
klodder door een toegewezen merkteken.

'blob' LF
markering?
gegevens

Het mark-commando is hier optioneel, omdat sommige frontends ervoor hebben gekozen om de Git SHA-1 te genereren
voor de klodder op zichzelf, en voer die rechtstreeks in om vast te leggen. Dit is doorgaans meer werk
dan het echter waard is, omdat merken goedkoop op te bergen en gemakkelijk te gebruiken zijn.

gegevens
Levert onbewerkte gegevens (voor gebruik als blob-/bestandsinhoud, commit-berichten of geannoteerde tag
berichten) om snel te importeren. Gegevens kunnen worden geleverd met behulp van een exact aantal bytes of worden gescheiden met
een eindlijn. Echte frontends bedoeld voor conversies van productiekwaliteit zouden dat wel moeten doen
gebruik altijd het exacte bytetellingformaat, omdat dit robuuster is en beter presteert. De
het gescheiden formaat is voornamelijk bedoeld voor het testen van snelle import.

Commentaarregels verschijnen binnen de een deel van de gegevensopdrachten wordt altijd als onderdeel beschouwd
van de hoofdtekst van de gegevens en worden daarom nooit genegeerd door snel importeren. Dit maakt het veilig
om alle bestands-/berichtinhoud te importeren waarvan de regels kunnen beginnen met #.

Exacte bytetelling-indeling
De frontend moet het aantal bytes aan gegevens specificeren.

'gegevens' SP LF
LF?

waar is het exacte aantal bytes dat erin verschijnt . De waarde van
wordt uitgedrukt als een decimaal geheel getal in ASCII. De LF aan weerszijden van is
niet inbegrepen en worden niet opgenomen in de geïmporteerde gegevens.

De LF erna is optioneel (vroeger verplicht), maar aanbevolen. Altijd
het opnemen ervan maakt het debuggen van een snel importstream eenvoudiger dan altijd de volgende opdracht
begint in kolom 0 van de volgende regel, zelfs als eindigde niet met een LF.

Gescheiden formaat
Er wordt een scheidingstekenreeks gebruikt om het einde van de gegevens aan te geven. fast-import berekent de
lengte door te zoeken naar het scheidingsteken. Dit formaat is vooral nuttig voor het testen en
wordt niet aanbevolen voor echte gegevens.

'gegevens' SP '<<' LF
LF
LF
LF?

waar is de gekozen scheidingstekenreeks. De snaar mag niet voorkomen op a
lijn vanzelf naar binnen , omdat fast-import anders denkt dat de gegevens eerder eindigen
dan het werkelijk doet. De LF stond onmiddellijk achter is onderdeel van . Dit is een
Vanwege de beperkingen van het gescheiden formaat is het onmogelijk een gegevensfragment aan te leveren
die geen LF als laatste byte heeft.

De LF erna LF is optioneel (vroeger was dit vereist).

checkpoint
Forceert snelle import om het huidige pakketbestand te sluiten, een nieuw pakketbestand te starten en alles op te slaan
huidige branchereferenties, tags en markeringen.

'controlepunt' LF
LF?

Merk op dat fast-import automatisch van pakketbestand wisselt wanneer het huidige pakketbestand bereikt
--max-pack-size, of 4 GiB, afhankelijk van welke limiet kleiner is. Tijdens een automatische packfile-wisseling
fast-import werkt de vertakkingsreferenties, tags of markeringen niet bij.

Omdat een controlepunt een aanzienlijke hoeveelheid CPU-tijd en schijf-IO kan vereisen (om de
overall pack SHA-1 checksum, genereer het overeenkomstige indexbestand en update de refs)
het kan gemakkelijk enkele minuten duren voordat een enkel controlepuntcommando is voltooid.

Frontends kunnen ervoor kiezen om controlepunten uit te geven tijdens extreem grote en langlopende importen,
of wanneer ze een ander Git-proces toegang moeten geven tot een branch. Maar gezien het feit dat een 30
De GiB Subversion-repository kan via snelle import in ongeveer 3 uur in Git worden geladen,
expliciete controlepunten zijn mogelijk niet nodig.

De LF na het commando is optioneel (vroeger was dit vereist).

voortgang
Zorgt ervoor dat fast-import de gehele voortgangsregel ongewijzigd afdrukt naar de standaarduitvoer
kanaal (bestandsbeschrijving 1) wanneer de opdracht vanuit de invoerstroom wordt verwerkt. De
anders heeft het commando geen invloed op de huidige import, of op de interne import van fast-import
staat.

'vooruitgang' SP LF
LF?

De een deel van de opdracht kan elke reeks bytes bevatten die geen LF bevat.
De LF na het commando is optioneel. Bellers willen de uitvoer mogelijk verwerken via een
hulpmiddel zoals sed om het leidende deel van de lijn te verwijderen, bijvoorbeeld:

frontend | git snelle import | sed 's/^voortgang //'

Als u onmiddellijk na een controlepunt een voortgangscommando plaatst, wordt de lezer geïnformeerd wanneer de
controlepunt is voltooid en het heeft veilig toegang tot de refs die snel worden geïmporteerd.

haal-markering
Zorgt ervoor dat snel importeren de SHA-1 afdrukt die overeenkomt met een markering naar stdout of naar het bestand
descriptor die eerder is gerangschikt met het argument --cat-blob-fd. Het commando heeft anders
geen impact op de huidige import; het doel is om SHA-1's op te halen die later worden vastgelegd
waarnaar ze misschien willen verwijzen in hun commit-berichten.

'get-mark' SP ':' LF

Deze opdracht kan overal in de stream worden gebruikt waar opmerkingen worden geaccepteerd. In het bijzonder,
het get-mark commando kan midden in een commit gebruikt worden, maar niet midden in een databestand
opdracht.

Zie “Reacties op opdrachten” hieronder voor details over hoe u deze uitvoer veilig kunt lezen.

kat-blob
Zorgt ervoor dat fast-import een blob afdrukt naar een bestandsdescriptor die eerder is gerangschikt met de
--cat-blob-fd-argument. Het commando heeft verder geen invloed op de huidige import; zijn
Het belangrijkste doel is het ophalen van blobs die zich mogelijk in het geheugen van Fast Import bevinden, maar niet toegankelijk zijn
uit de doelrepository.

'kattenblob' SP LF

De kan een merkreferentie zijn (: ) eerder ingesteld of een volledige 40 bytes
SHA-1 van een Git-blob, bestaand of klaar om te worden geschreven.

Uitvoer gebruikt hetzelfde formaat als git cat-file --batch:

SP 'blob' SP LF
LF

Deze opdracht kan overal in de stream worden gebruikt waar opmerkingen worden geaccepteerd. In het bijzonder,
het cat-blob commando kan midden in een commit gebruikt worden, maar niet midden in een databestand
opdracht.

Zie “Reacties op opdrachten” hieronder voor details over hoe u deze uitvoer veilig kunt lezen.

ls
Drukt informatie over het object af op een pad naar een eerder gerangschikte bestandsdescriptor
met het argument --cat-blob-fd. Hierdoor wordt het mogelijk om een ​​blob af te drukken van de actieve commit (met
cat-blob) of het kopiëren van een blob of boom uit een vorige commit voor gebruik in de huidige
(met bestandswijziging).

Het ls-commando kan overal in de stream worden gebruikt waar opmerkingen worden geaccepteerd, inclusief
het midden van een commit.

Lezen van de actieve commit
Dit formulier kan alleen tijdens een commit worden gebruikt. Het pad noemt een directory-item
binnen de actieve commit van fast-import. In dit geval moet het pad tussen aanhalingstekens worden vermeld.

'ls' SP LF

Lezen van een genoemde boom
De kan een merkreferentie zijn (: ) of de volledige 40-byte SHA-1 van een Git
tag-, commit- of boomobject, dat al bestaat of wacht om te worden geschreven. Het pad is
relatief ten opzichte van het hoogste niveau van de boom genoemd door .

'ls' SP SP LF

Zie filemodify hierboven voor een gedetailleerde beschrijving van .

Uitvoer gebruikt hetzelfde formaat als git ls-tree -- :

SP ('blob' | 'boom' | 'commit') SP HT LF

De vertegenwoordigt het blob-, boom- of commit-object op en kan erin gebruikt worden
later haal-markering, kat-blob, bestand wijzigenof ls commando's.

Als er zich geen bestand of subboom op dat pad bevindt, git snel importeren zal in plaats daarvan rapporteren

ontbrekende SP LF

Zie “Reacties op opdrachten” hieronder voor details over hoe u deze uitvoer veilig kunt lezen.

kenmerken
Vereisen dat snel importeren de opgegeven functie ondersteunt, of afbreken als dit niet het geval is.

'eigenschap' SP ('=' )? LF

De een deel van de opdracht kan een van de volgende zijn:

datumformaat, exportmarkeringen, relatieve markeringen, geen relatieve markeringen, kracht
Gedraag u alsof de overeenkomstige opdrachtregeloptie met een regelafstand ervoor staat -- werd doorgegeven
de opdrachtregel (zie OPTIES hierboven).

import-marks, import-marks-indien-bestaat
Net als --import-marks, behalve in twee opzichten: ten eerste, slechts één "feature import-marks" of
De opdracht "feature import-marks-if-exists" is per stream toegestaan; ten tweede, een
--import-marks= of --import-marks-if-exists opdrachtregeloptie overschrijft al deze opties
"feature"-opdrachten in de stream; ten derde, "feature import-marks-if-exists" zoals a
de bijbehorende opdrachtregeloptie slaat stilletjes een niet-bestaand bestand over.

get-mark, cat-blob, ls
Vereisen dat de backend de haal-markering, kat-blobof ls respectievelijk commando.
Versies van fast-import die de opgegeven opdracht niet ondersteunen, worden afgesloten met een bericht
dat aangeeft. Hierdoor komt de importfout vroegtijdig naar buiten met een duidelijke boodschap, in plaats van
tijd verspillen aan het eerste deel van een import voordat de niet-ondersteunde opdracht wordt uitgevoerd
gedetecteerd.

aantekeningen
Vereisen dat de backend de notitiewijzigen (N) subopdracht voor de plegen opdracht.
Versies van snel importeren die notities niet ondersteunen, worden afgesloten met een bericht dat dit aangeeft.

gedaan
Foutmelding als de stream eindigt zonder een gedaan commando. Zonder deze functie, fouten
ervoor zorgen dat de frontend abrupt eindigt op een geschikt punt in de stream kan verdwijnen
onopgemerkt. Dit kan bijvoorbeeld gebeuren als een importfrontend halverwege de bewerking uitvalt
zonder SIGTERM of SIGKILL uit te zenden op zijn ondergeschikte git fast-import instance.

optie
Verwerkt de opgegeven optie zodat git fast-import zich gedraagt ​​op een manier die past bij de
frontend-behoeften. Houd er rekening mee dat opties die door de frontend zijn opgegeven, door alle opties worden overschreven
opties die de gebruiker kan specificeren om git fast-import zelf te maken.

'optie' SP LF

De een deel van de opdracht kan een van de opties bevatten die worden vermeld in de OPTIONS
sectie die de importsemantiek niet verandert, zonder de leidende sectie -- en wordt behandeld in de
zelfde manier.

Optieopdrachten moeten de eerste opdrachten op de ingang zijn (functieopdrachten niet meegerekend),
het geven van een optiecommando na een niet-optiecommando is een fout.

De volgende opdrachtregelopties wijzigen de importsemantiek en kunnen daarom niet worden doorgegeven
als optie:

· datumnotatie

· importmerken

· exportmerken

· cat-blob-fd

· kracht

gedaan
Als de voltooide functie niet in gebruik is, wordt deze behandeld alsof EOF is gelezen. Dit kan worden gebruikt om te vertellen
snel importeren om eerder klaar te zijn.

Als de opdrachtregeloptie --done of feature done in gebruik is, is de opdracht done dat wel
verplicht en markeert het einde van de stream.

ANTWOORDEN TO COMMANDO'S

Nieuwe objecten geschreven door fast-import zijn niet onmiddellijk beschikbaar. Meest snelle import
commando's hebben geen zichtbaar effect tot het volgende controlepunt (of voltooiing). De voorkant
kunnen opdrachten verzenden om de invoerpijp van fast-import te vullen zonder zich zorgen te hoeven maken over hoe snel ze zullen zijn
zal van kracht worden, wat de prestaties verbetert door de planning te vereenvoudigen.

Voor sommige frontends is het echter handig om gegevens uit de stroom terug te kunnen lezen
repository terwijl deze wordt bijgewerkt (bijvoorbeeld wanneer het bronmateriaal objecten beschrijft).
in termen van patches die moeten worden toegepast op eerder geïmporteerde objecten). Dit kan zijn
Dit wordt bereikt door de frontend te verbinden en snel te importeren via bidirectionele leidingen:

mkfifo snelle import-output
voorkant
git snelle import>snelle import-output

Een frontend die op deze manier is opgezet, kan de opdrachten progress, get-mark, ls en cat-blob gebruiken om te lezen
informatie over de lopende import.

Om een ​​impasse te voorkomen, moeten dergelijke frontends alle openstaande uitvoer volledig verbruiken
progress, ls, get-mark en cat-blob voordat u schrijfbewerkingen uitvoert om dat mogelijk snel te importeren
blok.

CRASH VERSLAGEN

Als de snelle import ongeldige invoer krijgt, wordt deze beëindigd met een exit-status die niet nul is
maak een crashrapport op het hoogste niveau van de Git-repository waarin het importeerde. Botsing
rapporten bevatten een momentopname van de interne snelle importstatus en de meest recente
commando's die tot de crash hebben geleid.

Alle recente opdrachten (inclusief streamopmerkingen, bestandswijzigingen en voortgangsopdrachten) zijn dat wel
weergegeven in de opdrachtgeschiedenis in het crashrapport, maar onbewerkte bestandsgegevens en commit
berichten worden uitgesloten van het crashrapport. Deze uitsluiting bespaart ruimte binnen het rapport
bestand en vermindert de hoeveelheid buffering die fast-import moet uitvoeren tijdens de uitvoering.

Na het schrijven van een crashrapport zal fast-import het huidige pakketbestand sluiten en het
markeert tafel. Hierdoor kan de frontend-ontwikkelaar de status van de repository inspecteren en hervatten
de import vanaf het punt waar deze crashte. De gewijzigde takken en tags worden niet bijgewerkt
tijdens een crash, omdat het importeren niet succesvol is voltooid. Tak- en taginformatie
is te vinden in het crashrapport en moet handmatig worden toegepast als de update nodig is.

Een voorbeeld van een crash:

$ kat >in <
# mijn allereerste testcommit
commit refs/heads/master
inzender Shawn O. Pearce 19283-0400
# wie is die kerel eigenlijk?
gegevens <
dit is mijn belofte
EOF
M 644 inline. gitnegeren
gegevens <
.gitignore
EOF
M 777 inline-bob
END_OF_INPUT

$ git snel importeren
fataal: Corrupte modus: M 777 inline bob
fast-import: crashrapport dumpen naar .git/fast_import_crash_8434

$ kat .git/fast_import_crash_8434
crashrapport voor snel importeren:
snel importproces: 8434
ouderproces: 1391
op zaterdag 1 september 00:58:12 2007

fataal: Corrupte modus: M 777 inline bob

Meest recente opdrachten vóór crash
---------------------------------
# mijn allereerste testcommit
commit refs/heads/master
inzender Shawn O. Pearce 19283-0400
# wie is die kerel eigenlijk?
gegevens <
M 644 inline. gitnegeren
gegevens <
* M 777 inlinebob

Actieve tak LRU
-----------------
actieve_branches = 1 cur, 5 max

pos kloknaam
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) 0 scheidsrechters/hoofden/meester

Inactieve takken
-----------------
refs/hoofden/master:
status: actief geladen vuil
tip commit: 0000000000000000000000000000000000000000
oude boom: 0000000000000000000000000000000000000000
cur boom: 0000000000000000000000000000000000000000
commit-klok: 0
laatste pakket:

-------------------
EINDE VAN HET CRASHRAPPORT

TIPS EN TRUCS

De volgende tips en trucs zijn verzameld van verschillende gebruikers van fast-import, en
worden hier aangeboden als suggesties.

Gebruik One Mark Per Plegen
Wanneer je een repositoryconversie uitvoert, gebruik dan een unieke markering per commit (markering: ) en aanbod
de optie --export-marks op de opdrachtregel. fast-import dumpt een bestand met een lijst
elk merkteken en het Git-object SHA-1 dat ermee correspondeert. Als de frontend de
terugverwijst naar de bronrepository, is het eenvoudig om de juistheid en volledigheid ervan te verifiëren
de import door elke Git-commit te vergelijken met de corresponderende bronrevisie.

Afkomstig van een systeem als Perforce of Subversion zou dit vrij eenvoudig moeten zijn, zoals de
Het snelimportteken kan ook het Perforce-wijzigingssetnummer of de Subversion-revisie zijn
nummer.

Vrij overslaan Rond Branches
Doe geen moeite om de frontend te optimaliseren om tijdens een
importeren. Hoewel dit bij snel importeren wellicht iets sneller gaat, neemt dit doorgaans toe
de complexiteit van de frontend-code aanzienlijk.

De tak-LRU die is ingebouwd om snel te importeren, gedraagt ​​zich meestal heel goed, en de kosten daarvan zijn ook hoog
het activeren van een inactieve tak is zo laag dat het heen en weer stuiteren tussen takken dat wel doet
vrijwel geen invloed op de importprestaties.

Behandeling Hernoemt
Wanneer u een hernoemd bestand of map importeert, verwijdert u eenvoudigweg de oude naam(en) en wijzigt u de
nieuwe naam/namen tijdens de overeenkomstige commit. Git voert achteraf hernoemingsdetectie uit,
in plaats van expliciet tijdens een commit.

Gebruik Tag opknappen Branches
Bij sommige andere SCM-systemen kan de gebruiker een tag maken van meerdere bestanden die niet afkomstig zijn
dezelfde commit/changeset. Of om tags te maken die een subset vormen van de bestanden die beschikbaar zijn in
de bewaarplaats.

Het importeren van deze tags zoals ze zijn in Git is onmogelijk zonder minstens één commit te maken
“repareert” de bestanden zodat ze overeenkomen met de inhoud van de tag. Gebruik de reset-opdracht van fast-import om
reset een dummy branch buiten je normale branch ruimte naar de basis commit voor de tag,
voer vervolgens een of meer commits voor het repareren van bestanden uit en tag ten slotte de dummy-branch.

Omdat bijvoorbeeld alle normale vertakkingen worden opgeslagen onder refs/heads/name, wordt de tag fixup gebruikt
filiaal TAG_FIXUP. Op deze manier is het onmogelijk voor de fixup-branch die door de importeur wordt gebruikt
hebben naamruimteconflicten met echte vertakkingen geïmporteerd uit de bron (de naam TAG_FIXUP
is niet refs/heads/TAG_FIXUP).

Bij het committen van fixups, overweeg om merge te gebruiken om de commit(s) die leveren te verbinden
bestandsrevisies naar de fixup-branch. Als u dit doet, zijn hulpmiddelen zoals git schuld bijhouden
door de echte commitgeschiedenis en annoteer de bronbestanden op de juiste manier.

Nadat de snelle import is beëindigd, moet de frontend rm .git/TAG_FIXUP uitvoeren om de
nep tak.

import Nu, Herpakken Later
Zodra de snelle import is voltooid, is de Git-repository volledig geldig en klaar voor gebruik.
Meestal duurt dit slechts zeer korte tijd, zelfs bij aanzienlijk grote projecten
(meer dan 100,000 commits).

Het opnieuw inpakken van de repository is echter noodzakelijk om de locatie en toegang tot de gegevens te verbeteren
prestatie. Het kan ook uren duren bij extreem grote projecten (vooral als -f en a
large --window parameter wordt gebruikt). Omdat het opnieuw inpakken veilig is om samen met lezers en
schrijvers, voer het opnieuw inpakken op de achtergrond uit en laat het klaar zijn als het klaar is. Er is geen
reden om te wachten met het verkennen van je nieuwe Git-project!

Als u ervoor kiest te wachten op het opnieuw inpakken, probeer dan geen benchmarks of prestatietests uit te voeren
totdat het opnieuw inpakken is voltooid. fast-import levert suboptimale packfiles op die eenvoudigweg zijn
nog nooit gezien in echte gebruikssituaties.

ompakken Historisch Data
Als u zeer oude geïmporteerde gegevens opnieuw inpakt (bijvoorbeeld ouder dan vorig jaar), overweeg dan
wat extra CPU-tijd besteden en --window=50 (of hoger) leveren tijdens het uitvoeren git
herpakken. Dit duurt langer, maar levert ook een kleiner pakketbestand op. Dat hoeft alleen maar
besteed de moeite één keer, en iedereen die uw project gebruikt, zal profiteren van de kleinere
repository.

omvatten sommige Voortgang Berichten
Laat uw frontend af en toe een voortgangsbericht uitzenden om snel te importeren. De
De inhoud van de berichten is volledig in vrije vorm, dus een suggestie zou zijn om het
huidige maand en jaar telkens wanneer de huidige vastlegdatum naar de volgende maand verschuift. Jouw
gebruikers zullen zich beter voelen als ze weten hoeveel van de datastroom is verwerkt.

PAKKETBESTAND OPTIMIZATION

Bij het inpakken van een blob probeert fast-import altijd te deltificeren op basis van de laatst geschreven blob.
Tenzij dit specifiek door de frontend is geregeld, zal dit waarschijnlijk geen prioriteit zijn
versie van hetzelfde bestand, zodat de gegenereerde delta niet de kleinst mogelijke zal zijn. De
het resulterende pakketbestand zal worden gecomprimeerd, maar zal niet optimaal zijn.

Frontends die efficiënte toegang hebben tot alle revisies van één bestand (bijvoorbeeld
het lezen van een RCS/CVS ,v-bestand) kan ervoor kiezen om alle revisies van dat bestand in volgorde aan te bieden
van opeenvolgende blob-opdrachten. Dit maakt snelle import mogelijk om het verschillende bestand te deltificeren
revisies tegen elkaar, waardoor ruimte wordt bespaard in het uiteindelijke pakketbestand. Markeringen kunnen hiervoor worden gebruikt
identificeer later individuele bestandsrevisies tijdens een reeks commit-opdrachten.

De packfile(s) die door fast-import zijn gemaakt, stimuleren geen goede schijftoegangspatronen. Dit is
veroorzaakt door het snel importeren van de gegevens in de volgorde waarin ze bij standaardinvoer worden ontvangen,
terwijl Git data doorgaans binnen packfiles organiseert om de meest recente (huidige tip) te maken
gegevens verschijnen vóór historische gegevens. Git clustert ook commits, waardoor het sneller gaat
revisie-traversal door betere cachelocatie.

Om deze reden wordt het sterk aanbevolen dat gebruikers de repository opnieuw inpakken met git
repack -a -d nadat het snel importeren is voltooid, waardoor Git de packbestanden voor kan reorganiseren
snellere gegevenstoegang. Als blobdelta's suboptimaal zijn (zie hierboven), voeg dan ook de -f toe
De optie om herberekening van alle delta's te forceren kan het uiteindelijke pakketbestand aanzienlijk verkleinen
maat (30-50% kleiner kan vrij typisch zijn).

GEHEUGEN GEBRUIK

Er zijn een aantal factoren die van invloed zijn op de hoeveelheid geheugen die snel importeren vereist
een import. Net als kritische secties van core Git gebruikt fast-import zijn eigen geheugenallocators
om eventuele overheadkosten in verband met malloc af te schrijven. In de praktijk neigt snelimport ertoe
schrijf eventuele malloc-overheadkosten af ​​tot 0, vanwege het gebruik van grote bloktoewijzingen.

voor object
fast-import onderhoudt een structuur in het geheugen voor elk object dat tijdens deze uitvoering wordt geschreven.
Op een 32-bits systeem is de structuur 32 bytes, op een 64-bits systeem is de structuur 40 bytes
(vanwege de grotere wijzergroottes). De toewijzing van objecten in de tabel wordt pas ongedaan gemaakt
snel importeren wordt beëindigd. Voor het importeren van 2 miljoen objecten op een 32-bits systeem is dit vereist
ongeveer 64 MiB geheugen.

De objecttabel is eigenlijk een hashtabel die is gekoppeld aan de objectnaam (de unieke SHA-1). Dit
opslagconfiguratie maakt snelle import mogelijk om een ​​bestaand of reeds geschreven object opnieuw te gebruiken
en vermijd het schrijven van duplicaten naar het uitvoerpakketbestand. Dubbele klodders zijn verrassend
gebruikelijk bij een import, meestal als gevolg van vertakkingen in de bron.

voor Mark
Markeringen worden opgeslagen in een schaarse array, met behulp van 1 pointer (4 bytes of 8 bytes, afhankelijk van
wijzergrootte) per teken. Hoewel de array schaars is, zijn frontends nog steeds sterk
aangemoedigd om cijfers tussen 1 en n te gebruiken, waarbij n het totale aantal vereiste cijfers is
deze import.

voor tak
Takken worden geclassificeerd als actief en inactief. Het geheugengebruik van de twee klassen is
significant anders.

Inactieve takken worden opgeslagen in een structuur die 96 of 120 bytes gebruikt (32 bit of 64 bit
systemen, respectievelijk), plus de lengte van de filiaalnaam (doorgaans minder dan 200 bytes),
per vestiging. fast-import kan gemakkelijk maar liefst 10,000 inactieve filialen verwerken in minder dan 2 jaar
MiB geheugen.

Actieve takken hebben dezelfde overhead als inactieve takken, maar bevatten ook kopieën van
elke boom die onlangs op die tak is aangepast. Als subboom include niet is geweest
gewijzigd sinds de vertakking actief werd, zal de inhoud ervan niet in het geheugen worden geladen, maar
als subtree src is gewijzigd door een commit sinds de branch actief werd, dan is dat zo
de inhoud wordt in het geheugen geladen.

Omdat actieve branches metagegevens opslaan over de bestanden in die branch, kunnen hun
De opslaggrootte in het geheugen kan aanzienlijk groter worden (zie hieronder).

fast-import verplaatst actieve takken automatisch naar de inactieve status op basis van een simpele
minst recent gebruikte algoritme. De LRU-keten wordt bij elke commit-opdracht bijgewerkt. De
het maximale aantal actieve vertakkingen kan op de opdrachtregel worden verhoogd of verlaagd met
--actieve-takken=.

voor actieve boom
Bomen (ook wel mappen genoemd) gebruiken slechts 12 bytes geheugen bovenop het geheugen dat daarvoor nodig is
hun invoer (zie “per actief bestand” hieronder). De kosten van een boom zijn vrijwel nul, net als zijn
overhead wordt afgeschreven over de individuele bestandsinvoer.

voor actieve filet toegang
Bestanden (en verwijzingen naar subbomen) binnen actieve bomen vereisen 52 of 64 bytes (32/64 bit
perrons) per inzending. Om ruimte te besparen worden bestands- en boomnamen samengevoegd in een gemeenschappelijke string
tabel, waardoor de bestandsnaam “Makefile” slechts 16 bytes mag gebruiken (na het opnemen van de string
header overhead), ongeacht hoe vaak dit binnen het project voorkomt.

De actieve vertakking LRU, indien gekoppeld aan de tekenreekspool voor bestandsnamen en lui laden van
subbomen, maakt snelle import mogelijk om projecten met meer dan 2,000 vestigingen efficiënt te importeren en
45,114+ bestanden in een zeer beperkte geheugenvoetafdruk (minder dan 2.7 MiB per actieve vertakking).

SIGNALEN

Verzending SIGUSR1 aan de git snel importeren proces beëindigt het huidige pakketbestand vroegtijdig en simuleert
een controlepuntcommando. De ongeduldige operator kan deze mogelijkheid gebruiken om naar de objecten te gluren
en referenties van een lopende import, ten koste van wat extra speeltijd en erger
compressie.

Gebruik git-fast-import online met behulp van onworks.net-services