git-fast-import - Online sa Cloud

PROGRAMA:

NAME

git-fast-import - Backend para sa mabilis na mga import ng data ng Git

SINOPSIS

frontend | pumunta mabilis na pag-import [mga pagpipilian]

DESCRIPTION

Ang program na ito ay karaniwang hindi kung ano ang gusto ng end user na direktang tumakbo. Gusto ng karamihan sa mga end user
upang gamitin ang isa sa mga kasalukuyang frontend na programa, na nag-parse ng isang partikular na uri ng dayuhan
pinagmumulan at pinapakain ang mga nilalamang nakaimbak doon pumunta mabilis na pag-import.

ang fast-import ay nagbabasa ng pinaghalong command/data stream mula sa karaniwang input at nagsusulat ng isa o higit pa
packfiles nang direkta sa kasalukuyang repositoryo. Kapag natanggap ang EOF sa karaniwang input,
Ang mabilis na pag-import ay nagsusulat ng mga na-update na branch at tag ref, ganap na ina-update ang kasalukuyang repositoryo
kasama ang bagong na-import na data.

Ang fast-import na backend mismo ay maaaring mag-import sa isang walang laman na imbakan (isa na mayroon na
pinasimulan ng pumunta sa loob) o unti-unting i-update ang isang umiiral na populated na repository.
Depende kung sinusuportahan o hindi ang mga incremental na pag-import mula sa isang partikular na dayuhang pinagmulan
sa frontend program na ginagamit.

Opsyon

--puwersa
Pilitin ang pag-update ng mga nabagong kasalukuyang branch, kahit na ang paggawa nito ay magiging sanhi ng mga commit
nawala (dahil ang bagong commit ay hindi naglalaman ng lumang commit).

--tahimik
Huwag paganahin ang lahat ng hindi nakamamatay na output, na ginagawang tahimik ang mabilis na pag-import kapag ito ay matagumpay. Ito
hindi pinapagana ng opsyon ang output na ipinapakita ng --stats.

--stats
Ipakita ang ilang pangunahing istatistika tungkol sa mga bagay na ginawa ng mabilisang pag-import, ang mga packfile
sila ay naka-imbak sa, at ang memorya na ginagamit ng mabilis na pag-import sa panahon ng pagtakbo na ito. Nagpapakita
ang output na ito ay kasalukuyang default, ngunit maaaring i-disable gamit ang --quiet.

Options para Mga Pauna
--cat-blob-fd=
Sumulat ng mga tugon sa mga query na get-mark, cat-blob, at ls sa descriptor ng file
sa halip na stdout. Nagbibigay-daan sa pag-usad na output na inilaan para sa end-user na paghiwalayin
mula sa iba pang output.

--date-format=
Tukuyin ang uri ng mga petsa na ibibigay ng frontend sa mabilis na pag-import sa loob ng may-akda,
committer at tagger commands. Tingnan ang "Mga Format ng Petsa" sa ibaba para sa mga detalye tungkol sa kung alin
suportado ang mga format, at ang kanilang syntax.

--tapos na
Tapusin nang may error kung walang tapos na command sa dulo ng stream. Ang pagpipiliang ito
Maaaring maging kapaki-pakinabang para sa pag-detect ng mga error na nagiging sanhi ng pagwawakas ng frontend bago ito
ay nagsimulang magsulat ng isang stream.

lokasyon of Mga Mark File
--export-marks=
Itinatapon ang talahanayan ng mga panloob na marka sa kapag kumpleto na. Ang mga marka ay isinusulat ng isa sa bawat linya
bilang :markid SHA-1. Maaaring gamitin ng mga frontend ang file na ito upang patunayan ang mga pag-import pagkatapos ng mga ito
nakumpleto, o upang i-save ang talahanayan ng mga marka sa mga incremental na pagtakbo. Bilang ay lamang
binuksan at pinutol sa checkpoint (o pagkumpleto) ang parehong landas ay maaari ding maging ligtas
ibinigay sa --import-marks.

--import-marks=
Bago iproseso ang anumang input, i-load ang mga markang tinukoy sa . Ang input file ay dapat
umiiral, dapat na nababasa, at dapat gumamit ng parehong format tulad ng ginawa ng --export-marks.
Maraming mga opsyon ang maaaring ibigay upang mag-import ng higit sa isang hanay ng mga marka. Kung ang isang marka ay
na tinukoy sa iba't ibang mga halaga, ang huling file ay nanalo.

--import-marks-if-exists=
Tulad ng --import-marks ngunit sa halip na magkamali, tahimik na nilalaktawan ang file kung nangyari ito
hindi umiiral.

--[no-]relative-marks
Pagkatapos tukuyin --relative-marks ang mga path na tinukoy sa --import-marks= at
--export-marks= ay nauugnay sa isang panloob na direktoryo sa kasalukuyang repositoryo. Sa
git-fast-import nangangahulugan ito na ang mga path ay nauugnay sa .git/info/fast-import
direktoryo. Gayunpaman, ang ibang mga importer ay maaaring gumamit ng ibang lokasyon.

Ang mga kamag-anak at hindi kamag-anak na mga marka ay maaaring pagsamahin sa pamamagitan ng interweaving --(no-)-relative-marks
gamit ang --(import|export)-marks= mga opsyon.

pagganap at Pagpiga Apina
--active-branches=
Pinakamataas na bilang ng mga sangay upang mapanatili ang aktibo nang sabay-sabay. Tingnan ang "Paggamit ng Memorya" sa ibaba
para sa mga detalye. Ang default ay 5.

--big-file-threshold=
Maximum na laki ng isang blob na susubukan ng mabilis na pag-import na gumawa ng delta para sa, ipinahayag
sa bytes. Ang default ay 512m (512 MiB). Maaaring naisin ng ilang importer na ibaba ito sa
mga system na may limitadong memorya.

--lalim=
Maximum delta depth, para sa blob at tree deltification. Ang default ay 10.

--export-pack-edges=
Pagkatapos gumawa ng packfile, mag-print ng linya ng data sa listahan ng filename ng
packfile at ang huling commit sa bawat branch na isinulat sa packfile na iyon. Ito
maaaring maging kapaki-pakinabang ang impormasyon pagkatapos mag-import ng mga proyekto na ang kabuuang hanay ng bagay ay lumampas sa
4 GiB packfile na limitasyon, dahil ang mga commit na ito ay maaaring gamitin bilang mga edge point sa panahon ng mga tawag sa pumunta
pack-objects.

--max-pack-size=
Pinakamataas na laki ng bawat output packfile. Ang default ay walang limitasyon.

PAGGANAP

Ang disenyo ng mabilis na pag-import ay nagbibigay-daan dito upang mag-import ng malalaking proyekto sa isang minimum na halaga ng memorya
oras ng paggamit at pagproseso. Ipagpalagay na ang frontend ay nakakasabay sa mabilis na pag-import at
pakainin ito ng tuluy-tuloy na stream ng data, mga oras ng pag-import para sa mga proyektong may hawak na 10+ taon ng kasaysayan
at naglalaman ng 100,000+ indibidwal na commit ay karaniwang nakumpleto sa loob lamang ng 1-2 oras sa
medyo katamtaman (~$2,000 USD) na hardware.

Karamihan sa mga bottleneck ay lumilitaw na nasa pag-access ng data ng dayuhang mapagkukunan (hindi kaya ng pinagmulan
i-extract ang mga rebisyon nang sapat na mabilis) o disk IO (mabilis na pag-import ay nagsusulat nang kasing bilis ng gagawin ng disk
kunin ang data). Ang mga pag-import ay tatakbo nang mas mabilis kung ang pinagmulan ng data ay nakaimbak sa ibang drive
kaysa sa patutunguhan na Git repository (dahil sa mas kaunting IO contention).

Pag-unlad Magkahalaga

Ang isang karaniwang frontend para sa mabilis na pag-import ay may posibilidad na tumitimbang sa humigit-kumulang 200 linya ng
Perl/Python/Ruby code. Karamihan sa mga developer ay nakagawa ng mga nagtatrabahong importer sa loob lamang
ilang oras, kahit na ito ang kanilang unang pagkakalantad sa mabilis na pag-import, at kung minsan
kahit kay Git. Ito ay isang perpektong sitwasyon, dahil ang karamihan sa mga tool sa conversion ay itinapon
(gamitin nang isang beses, at huwag nang lumingon sa likod).

PARALLEL OPERASYON

katulad pumunta itulak or pumunta kunin, ang mga pag-import na pinangangasiwaan ng mabilis na pag-import ay ligtas na tumakbo kasama
parallel git repack -a -d o git gc invocations, o anumang iba pang operasyon ng Git (kabilang ang pumunta
putulin, dahil ang mga maluwag na bagay ay hindi kailanman ginagamit ng mabilis na pag-import).

Ang fast-import ay hindi nakakandado sa sangay o tag ref na aktibong ini-import nito. Pagkatapos ng
import, sa yugto ng pag-update ng ref nito, sinusuri ng mabilis na pag-import ang bawat umiiral na ref ng sangay upang ma-verify
ang pag-update ay magiging isang fast-forward na update (ang commit na nakaimbak sa ref ay nakapaloob sa
bagong kasaysayan ng pangakong isusulat). Kung ang update ay hindi isang fast-forward na update,
laktawan ng fast-import ang pag-update ng ref na iyon at sa halip ay magpi-print ng mensahe ng babala. mabilis na pag-import
ay palaging susubukang i-update ang lahat ng mga branch ref, at hindi hihinto sa unang pagkabigo.

Maaaring pilitin ang mga pag-update ng branch sa --force, ngunit inirerekomenda na gamitin lang ito sa
isang tahimik na repositoryo. Ang paggamit ng --force ay hindi kinakailangan para sa isang paunang pag-import sa
isang walang laman na imbakan.

TEKNIKAL Pagtalakay

sinusubaybayan ng fast-import ang isang set ng mga branch sa memorya. Anumang sangay ay maaaring gawin o baguhin sa
anumang punto sa panahon ng proseso ng pag-import sa pamamagitan ng pagpapadala ng commit command sa input stream. Ito
Binibigyang-daan ng disenyo ang isang frontend program na magproseso ng walang limitasyong bilang ng mga sangay
sabay-sabay, pagbuo ng mga commit sa pagkakasunud-sunod na magagamit ang mga ito mula sa pinagmulang data.
Pinapasimple din nito nang husto ang mga frontend na programa.

hindi ginagamit o binabago ng fast-import ang kasalukuyang gumaganang direktoryo, o anumang file sa loob nito.
(Gayunpaman, ina-update nito ang kasalukuyang repositoryo ng Git, gaya ng tinukoy ng GIT_DIR.) Samakatuwid
maaaring gamitin ng isang import frontend ang gumaganang direktoryo para sa sarili nitong mga layunin, gaya ng pag-extract
mga pagbabago sa file mula sa banyagang pinagmulan. Ito kamangmangan ng gumaganang direktoryo din
nagbibigay-daan sa mabilis na pag-import na tumakbo nang napakabilis, dahil hindi nito kailangang magsagawa ng anumang magastos na file
i-update ang mga operasyon kapag lumipat sa pagitan ng mga sangay.

INPUT FORMAT

Maliban sa raw file data (na hindi binibigyang kahulugan ng Git) ang mabilis na pag-import ng input
ang format ay text (ASCII) based. Pinapasimple ng format na ito na nakabatay sa text ang pag-develop at pag-debug
ng mga frontend program, lalo na kapag ang isang mas mataas na antas ng wika tulad ng Perl, Python o Ruby
ay ginagamit.

ang fast-import ay napakahigpit tungkol sa input nito. Kung saan sinasabi naming SP sa ibaba ang ibig naming sabihin tamang-tama isa
space. Gayundin ang ibig sabihin ng LF ay isa (at isa lamang) linefeed at HT isa (at isa lamang) pahalang
tab. Ang pagbibigay ng karagdagang mga character na whitespace ay magdudulot ng mga hindi inaasahang resulta, gaya ng
mga pangalan ng sangay o mga pangalan ng file na may mga puwang sa unahan o trailing sa kanilang pangalan, o maaga
pagwawakas ng mabilis na pag-import kapag nakatagpo ito ng hindi inaasahang input.

sapa Comments
Upang tumulong sa pag-debug ng mga frontend, binabalewala ng mabilis na pag-import ang anumang linya na nagsisimula sa # (ASCII
pound/hash) hanggang sa at kabilang ang linyang nagtatapos sa LF. Ang isang linya ng komento ay maaaring maglaman ng anuman
pagkakasunud-sunod ng mga byte na hindi naglalaman ng LF at samakatuwid ay maaaring gamitin upang isama ang anuman
detalyadong impormasyon sa pag-debug na maaaring partikular sa frontend at kapaki-pakinabang kapag
pagsisiyasat ng mabilis na pag-import ng data stream.

petsa Format ng
Ang mga sumusunod na format ng petsa ay suportado. Dapat piliin ng frontend ang format na gagamitin nito
para sa pag-import na ito sa pamamagitan ng pagpasa sa pangalan ng format sa --date-format= opsyon sa command-line.

hilaw
Ito ang Git native na format at ay SP . Fast-import din ito
default na format, kung hindi tinukoy ang --date-format.

Ang oras ng kaganapan ay tinukoy ng bilang bilang ng mga segundo mula noong UNIX
epoch (hatinggabi, Ene 1, 1970, UTC) at isinulat bilang ASCII decimal integer.

Ang lokal na offset ay tinukoy ng bilang positibo o negatibong offset mula sa UTC.
Halimbawa, ang EST (na 5 oras sa likod ng UTC) ay ipapakita sa sa pamamagitan ng "-0500"
habang ang UTC ay “+0000”. Ang lokal na offset ay hindi nakakaapekto ; ito ay ginagamit lamang bilang isang
payo upang makatulong sa pag-format ng mga nakagawiang ipakita ang timestamp.

Kung ang lokal na offset ay hindi available sa pinagmulang materyal, gamitin ang "+0000", o ang pinaka
karaniwang lokal na offset. Halimbawa maraming mga organisasyon ang may isang CVS repository na mayroon
na-access lamang ng mga user na matatagpuan sa parehong lokasyon at time zone.
Sa kasong ito, maaaring ipagpalagay ang isang makatwirang offset mula sa UTC.

Hindi tulad ng rfc2822 format, ang format na ito ay napakahigpit. Anumang pagkakaiba-iba sa pag-format
ay magiging sanhi ng mabilis na pag-import upang tanggihan ang halaga.

rfc2822
Ito ang karaniwang format ng email gaya ng inilarawan ng RFC 2822.

Ang isang halimbawang value ay "Martes Peb 6 11:22:18 2007 -0500". Ang Git parser ay tumpak, ngunit a
maliit sa maluwag na bahagi. Ito ay ang parehong parser na ginamit ng pumunta am kapag nag-aaplay ng mga patch
natanggap mula sa email.

Maaaring tanggapin ang ilang maling nabuong string bilang mga wastong petsa. Sa ilan sa mga kasong ito, gagawin ni Git
maaari pa ring makuha ang tamang petsa mula sa malformed string. Meron din
ilang uri ng mga maling pagkakabuo ng mga string na mali-parse ng Git, ngunit itinuturing na wasto.
Tatanggihan ang mga seryosong malform na string.

Hindi tulad ng raw na format sa itaas, ang time zone/UTC offset na impormasyon na nasa isang RFC
Ang string ng petsa ng 2822 ay ginagamit upang ayusin ang halaga ng petsa sa UTC bago ang imbakan. Samakatuwid
mahalagang maging tumpak ang impormasyong ito hangga't maaari.

Kung ang pinagmulang materyal ay gumagamit ng RFC 2822 style na mga petsa, dapat hayaan ng frontend ang mabilis na pag-import
pangasiwaan ang pag-parse at conversion (sa halip na subukang gawin ito mismo) bilang Git
Ang parser ay mahusay na nasubok sa ligaw.

Dapat na mas gusto ng mga frontend ang raw na format kung ang pinagmulang materyal ay gumagamit na ng UNIX-epoch
format, maaaring suyuin upang magbigay ng mga petsa sa format na iyon, o ang format nito ay madali
mapapalitan dito, dahil walang kalabuan sa pag-parse.

ngayon
Palaging gamitin ang kasalukuyang oras at time zone. Ang literal ngayon ay dapat palaging ibinibigay
.

Ito ay isang laruang format. Ang kasalukuyang time at time zone ng system na ito ay palaging kinokopya
sa string ng pagkakakilanlan sa oras na ginagawa ito ng mabilis na pag-import. Walang
paraan upang tukuyin ang ibang oras o time zone.

Ang partikular na format na ito ay ibinibigay dahil ito ay maikli upang ipatupad at maaaring maging kapaki-pakinabang sa a
proseso na gustong gumawa ng bagong commit ngayon, nang hindi kinakailangang gumamit ng gumagana
direktoryo o pumunta update-index.

Kung ang magkahiwalay na utos ng may-akda at committer ay ginagamit sa isang commit, maaaring hindi ang mga timestamp
tugma, dahil ang system clock ay susuriin ng dalawang beses (isang beses para sa bawat command). Ang tanging paraan
upang matiyak na ang impormasyon ng pagkakakilanlan ng may-akda at committer ay may parehong timestamp
ay tanggalin ang may-akda (kaya ang pagkopya mula sa committer) o gumamit ng format ng petsa maliban sa
ngayon.

Command
tumatanggap ang fast-import ng ilang utos para i-update ang kasalukuyang repositoryo at kontrolin ang
kasalukuyang proseso ng pag-import. Ang mas detalyadong talakayan (na may mga halimbawa) ng bawat utos ay sumusunod
mamaya.

gumawa
Gumagawa ng bagong branch o nag-a-update ng kasalukuyang branch sa pamamagitan ng paggawa ng bagong commit at
pag-update ng sangay upang ituro ang bagong likhang commit.

mga tag
Gumagawa ng annotated na tag object mula sa isang umiiral na commit o branch. Magaan na mga tag
ay hindi suportado ng utos na ito, dahil hindi ito inirerekomenda para sa pagre-record
makabuluhang mga punto sa oras.

i-reset ang
I-reset ang isang umiiral nang branch (o isang bagong branch) sa isang partikular na rebisyon. Ang utos na ito ay dapat
gamitin upang baguhin ang isang sangay sa isang partikular na rebisyon nang hindi gumagawa ng pangako dito.

patak
I-convert ang raw file data sa isang blob, para magamit sa hinaharap sa isang commit command. Ang utos na ito ay
opsyonal at hindi kailangan para magsagawa ng pag-import.

checkpoint
Pinipilit ang mabilis na pag-import upang isara ang kasalukuyang packfile, bumuo ng natatanging SHA-1 checksum nito
at index, at magsimula ng bagong packfile. Ang utos na ito ay opsyonal at hindi kinakailangan
magsagawa ng pag-import.

pag-unlad
Nagiging sanhi ng mabilis na pag-import upang i-echo ang buong linya sa sarili nitong karaniwang output. Ang utos na ito ay
opsyonal at hindi kailangan para magsagawa ng pag-import.

tapos
Minarkahan ang dulo ng stream. Ang utos na ito ay opsyonal maliban kung ang tapos na tampok ay
hiniling gamit ang --done command-line na opsyon o feature done command.

makakuha ng marka
Nagiging sanhi ng mabilis na pag-import upang i-print ang SHA-1 na naaayon sa isang marka sa descriptor ng file
itakda sa --cat-blob-fd, o stdout kung hindi tinukoy.

pusa-patak
Nagiging sanhi ng mabilis na pag-import upang mag-print ng blob cat-file --batch format sa file descriptor
itakda sa --cat-blob-fd o stdout kung hindi tinukoy.

ls
Nagiging sanhi ng mabilis na pag-import upang mag-print ng isang linya na naglalarawan sa isang entry sa direktoryo ls-puno format sa
ang file descriptor set na may --cat-blob-fd o stdout kung hindi tinukoy.

tampok
Paganahin ang tinukoy na tampok. Nangangailangan ito na ang mabilis na pag-import ay sumusuporta sa tinukoy
tampok, at abort kung hindi.

opsyon
Tukuyin ang alinman sa mga opsyon na nakalista sa ilalim ng OPTIONS na hindi nagbabago ng semantic ng stream
umangkop sa mga pangangailangan ng frontend. Ang utos na ito ay opsyonal at hindi kailangan upang magsagawa ng isang
angkat.

gumawa
Gumawa o mag-update ng isang sangay na may bagong commit, na nagre-record ng isang lohikal na pagbabago sa proyekto.

'commit' SP LF
marka?
('may-akda' (SP )? SP LT GT SP LF)?
'committer' (SP )? SP LT GT SP LF
data
('mula sa' SP LF)?
('pagsamahin' SP LF)?
(filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
LF?

saan ay ang pangalan ng sangay na gagawa ng commit. Karaniwan ang mga pangalan ng sangay ay
prefixed na may refs/heads/ sa Git, kaya ang pag-import ng simbolo ng sangay ng CVS na RELENG-1_0 ay gagamit
refs/heads/RELENG-1_0 para sa halaga ng . Ang halaga ng dapat ay isang wastong refname
sa Git. Dahil ang LF ay hindi wasto sa isang Git refname, walang quoting o escaping syntax ang sinusuportahan
dito.

Ang isang mark command ay maaaring opsyonal na lumitaw, na humihiling ng mabilis na pag-import upang mag-save ng isang reference sa
bagong likhang commit para sa hinaharap na paggamit ng frontend (tingnan sa ibaba para sa format). Ito ay napaka
karaniwan para sa mga frontend na markahan ang bawat commit na kanilang gagawin, sa gayon ay nagbibigay-daan sa hinaharap na sangay
paglikha mula sa anumang na-import na commit.

Ang data command na sumusunod sa committer ay dapat magbigay ng commit message (tingnan sa ibaba para sa data
command syntax). Upang mag-import ng walang laman na mensahe ng commit, gumamit ng 0 haba na data. Mag-commit ng mga mensahe
ay malayang anyo at hindi binibigyang-kahulugan ng Git. Sa kasalukuyan, dapat silang naka-encode sa UTF-8, bilang
hindi pinapayagan ng fast-import na tukuyin ang iba pang mga encoding.

Zero o higit pang filemodify, filedelete, filecopy, filerename, filedeleteall at notemodify
maaaring isama ang mga utos upang i-update ang mga nilalaman ng sangay bago gawin ang
mangako. Ang mga utos na ito ay maaaring ibigay sa anumang pagkakasunud-sunod. Gayunpaman, inirerekomenda na a
filedeleteall command nangunguna sa lahat ng filemodify, filecopy, filerename at notemodify commands
sa parehong commit, habang pinupunasan ng filedeleteall ang sangay (tingnan sa ibaba).

Ang LF pagkatapos ng utos ay opsyonal (kailangan ito noon).

may-akda
Maaaring opsyonal na lumabas ang isang command ng may-akda, kung maaaring iba ang impormasyon ng may-akda
ang impormasyon ng committer. Kung ang may-akda ay tinanggal, ang mabilis na pag-import ay awtomatikong
gamitin ang impormasyon ng committer para sa bahagi ng may-akda ng commit. Tingnan sa ibaba para sa a
paglalarawan ng mga patlang sa may-akda, dahil magkapareho ang mga ito sa committer.

tagapamahala
Ipinapahiwatig ng committer command kung sino ang gumawa ng commit na ito, at kung kailan nila ginawa ito.

Dito ay ang display name ng tao (halimbawa “Com M Itter”) at ay
email address ng tao (“cm@example.com”). Ang LT at GT ay ang literal na mas mababa
(\x3c) at mas mataas kaysa sa (\x3e) na mga simbolo. Kinakailangan ang mga ito upang ma-delimitahan ang email
address mula sa iba pang mga field sa linya. Tandaan na at ay malayang anyo
at maaaring maglaman ng anumang pagkakasunud-sunod ng mga byte, maliban sa LT, GT at LF. ay karaniwang UTF-8
naka-encode.

Ang oras ng pagbabago ay tinukoy ng gamit ang format ng petsa na napili
sa pamamagitan ng --date-format= opsyon sa command-line. Tingnan ang "Mga Format ng Petsa" sa itaas para sa set
ng mga sinusuportahang format, at ang kanilang syntax.

mula
Ang from command ay ginagamit upang tukuyin ang commit para simulan ang branch na ito mula sa. Ito
ang rebisyon ang magiging unang ninuno ng bagong commit. Ang estado ng puno na itinayo sa
ang commit na ito ay magsisimula sa estado sa mula sa commit, at babaguhin ng
mga pagbabago sa nilalaman sa commit na ito.

Ang pag-alis sa command mula sa unang commit ng isang bagong sangay ay magdudulot ng mabilis na pag-import
upang lumikha ng pangako na walang ninuno. Ito ay may posibilidad na naisin lamang para sa inisyal
gumawa ng isang proyekto. Kung ang frontend ay lumilikha ng lahat ng mga file mula sa simula kapag gumagawa ng bago
branch, maaaring gumamit ng merge command sa halip na mula sa simula ng commit na may walang laman
puno. Ang pagtanggal ng utos mula sa mga umiiral na sangay ay karaniwang nais, bilang ang
ang kasalukuyang commit sa sangay na iyon ay awtomatikong ipinapalagay na ang unang ninuno ng
bagong commit.

Dahil ang LF ay hindi wasto sa isang Git refname o SHA-1 expression, walang pagsipi o escaping syntax
ay suportado sa loob .

Dito ay alinman sa mga sumusunod:

· Ang pangalan ng isang umiiral nang sangay na nasa panloob na talahanayan ng sangay ng fast-import. Kung
hindi alam ng fast-import ang pangalan, ito ay itinuturing bilang isang SHA-1 na expression.

· Isang sanggunian sa marka, : , saan ay ang markang numero.

Ang dahilan ng mabilis na pag-import ay gumagamit ng : upang tukuyin ang isang markang sanggunian ay ang karakter na ito ay hindi
legal sa isang pangalan ng sangay ng Git. Ang nangungunang : ginagawang madaling makilala sa pagitan ng
markahan ang 42 (:42) at ang sangay na 42 (42 o refs/heads/42), o isang pinaikling SHA-1
na nangyari na binubuo lamang ng base-10 digit.

Dapat ideklara ang mga marka (sa pamamagitan ng marka) bago sila magamit.

· Isang kumpletong 40 byte o pinaikling commit SHA-1 sa hex.

· Anumang wastong Git SHA-1 na expression na nalutas sa isang commit. Tingnan ang “PAGTUTUKOY
MGA REBISYO” sa gitrevisions(7) para sa mga detalye.

· Ang espesyal na null SHA-1 (40 zeros) ay tumutukoy na ang sangay ay aalisin.

Ang espesyal na kaso ng pag-restart ng incremental na pag-import mula sa kasalukuyang halaga ng sangay
dapat isulat bilang:

mula sa ref/heads/branch^0

Ang ^0 suffix ay kinakailangan dahil ang mabilis na pag-import ay hindi nagpapahintulot sa isang sangay na magsimula mula sa
mismo, at ang sangay ay nilikha sa memorya bago basahin ang mula sa utos
ang input. Ang pagdaragdag ng ^0 ay pipilitin ang mabilis na pag-import upang malutas ang commit sa pamamagitan ng Git's
revision parsing library, sa halip na ang panloob na talahanayan ng sangay nito, sa gayo'y naglo-load
ang umiiral na halaga ng sangay.

pagsamahin
May kasamang isang karagdagang ancestor commit. Ang karagdagang link ng ninuno ay hindi nagbabago
ang paraan ng pagtatayo ng estado ng puno sa commit na ito. Kung ang mula sa utos ay tinanggal kapag
paglikha ng isang bagong sangay, ang unang merge commit ay ang unang ninuno ng
kasalukuyang commit, at magsisimula ang sangay nang walang mga file. Isang walang limitasyong bilang ng
Ang mga merge command sa bawat commit ay pinahihintulutan ng mabilis na pag-import, sa gayon ay nagtatag ng isang n-way
pagsamahin.

Dito ay alinman sa mga expression ng commit specification na tinatanggap din ng from
(tingnan sa itaas).

filemodify
Kasama sa isang commit command upang magdagdag ng bagong file o baguhin ang nilalaman ng isang umiiral na
file. Ang utos na ito ay may dalawang magkaibang paraan ng pagtukoy sa nilalaman ng file.

Panlabas na format ng data
Ang nilalaman ng data para sa file ay naibigay na ng isang naunang blob command. Ang
kailangan lang ikonekta ito ng frontend.

'M' SP SP SP LF

Dito kadalasan dapat ay alinman sa isang sanggunian ng marka (: ) na itinakda ng nauna
blob command, o isang buong 40-byte na SHA-1 ng isang umiiral na object ng Git blob. Kung ay
040000` tapos dapat ang buong 40-byte na SHA-1 ng isang umiiral na puno ng Git
bagay o isang hanay ng sanggunian ng marka na may --import-marks.

Inline na format ng data
Ang nilalaman ng data para sa file ay hindi pa naibibigay. Gusto ng frontend
ibigay ito bilang bahagi ng modify command na ito.

'M' SP SP 'inline' SP LF
data

Tingnan sa ibaba para sa isang detalyadong paglalarawan ng utos ng data.

Sa parehong mga format ay ang uri ng file entry, na tinukoy sa octal. Git lang
sumusuporta sa mga sumusunod na mode:

· 100644 o 644: Isang normal (not-executable) file. Ang karamihan ng mga file sa karamihan
ginagamit ng mga proyekto ang mode na ito. Kung may pagdududa, ito ang gusto mo.

· 100755 o 755: Isang normal, ngunit maipapatupad, na file.

· 120000: Isang symlink, ang nilalaman ng file ang magiging target ng link.

· 160000: Ang isang gitlink, SHA-1 ng object ay tumutukoy sa isang commit sa isa pang repository.
Ang mga link sa Git ay maaari lamang tukuyin ng SHA o sa pamamagitan ng isang commit mark. Nakasanayan na nila
ipatupad ang mga submodules.

· 040000: Isang subdirectory. Ang mga subdirectory ay maaari lamang tukuyin ng SHA o sa pamamagitan ng a
tree mark set na may --import-marks.

Sa parehong mga format ay ang kumpletong landas ng file na idaragdag (kung hindi pa
umiiral na) o binago (kung mayroon na).

A string ay dapat gumamit ng UNIX-style directory separator (forward slash /), maaaring
naglalaman ng anumang byte maliban sa LF, at hindi dapat magsimula sa double quote (").

Ang isang landas ay maaaring gumamit ng C-style string quoting; ito ay tinatanggap sa lahat ng kaso at sapilitan kung
ang filename ay nagsisimula sa double quote o naglalaman ng LF. Sa C-style quoting, ang kumpleto
ang pangalan ay dapat na napapalibutan ng double quote, at anumang LF, backslash, o double quote
characters must be escaped by preceding them with a backslash (e.g., "path/with\n, \
at \"sa loob nito").

Ang halaga ng dapat nasa canonical form. Iyon ay hindi dapat:

· naglalaman ng walang laman na bahagi ng direktoryo (hal. foo//bar ay hindi wasto),

· magtatapos sa isang directory separator (hal. foo/ ay hindi wasto),

· magsimula sa isang directory separator (hal. /foo ay hindi wasto),

· naglalaman ng espesyal na bahagi. o .. (hal. foo/./bar at foo/../bar ay
hindi wasto).

Ang ugat ng puno ay maaaring kinakatawan ng isang walang laman na string bilang .

Inirerekomenda na palaging naka-encode gamit ang UTF-8.

filedelete
Kasama sa isang commit command na mag-alis ng file o recursively magtanggal ng kabuuan
direktoryo mula sa sangay. Kung ang pag-aalis ng file o direktoryo ay gumagawa ng parent directory nito
walang laman, awtomatikong aalisin din ang direktoryo ng magulang. Ito cascades up ang
tree hanggang sa maabot ang unang hindi walang laman na direktoryo o ang ugat.

'D' SP LF

dito ay ang kumpletong landas ng file o subdirectory na aalisin mula sa
sangay. Tingnan ang filemodify sa itaas para sa isang detalyadong paglalarawan ng .

filecopy
Paulit-ulit na kinokopya ang isang umiiral na file o subdirectory sa ibang lokasyon sa loob ng
sangay. Ang umiiral na file o direktoryo ay dapat na umiiral. Kung ang patutunguhan ay umiiral ito
ganap na mapalitan ng nilalamang kinopya mula sa pinagmulan.

'C' SP SP LF

eto muna ay ang pinagmulang lokasyon at ang pangalawa ay ang patutunguhan.
Tingnan ang filemodify sa itaas para sa isang detalyadong paglalarawan ng kung ano maaaring magmukhang. Upang gumamit ng a
source path na naglalaman ng SP dapat na quote ang path.

Ang isang filecopy command ay magkakabisa kaagad. Kapag nakopya na ang lokasyon ng pinagmulan
sa patutunguhan ang anumang mga utos sa hinaharap na inilapat sa pinagmulang lokasyon ay hindi makakaapekto
ang patutunguhan ng kopya.

filerename
Pinapalitan ang pangalan ng isang umiiral na file o subdirectory sa ibang lokasyon sa loob ng sangay.
Ang umiiral na file o direktoryo ay dapat na umiiral. Kung ang patutunguhan ay umiiral ito ay magiging
pinalitan ng direktoryo ng pinagmulan.

'R' SP SP LF

eto muna ay ang pinagmulang lokasyon at ang pangalawa ay ang patutunguhan.
Tingnan ang filemodify sa itaas para sa isang detalyadong paglalarawan ng kung ano maaaring magmukhang. Upang gumamit ng a
source path na naglalaman ng SP dapat na quote ang path.

Ang isang filerename na utos ay magkakabisa kaagad. Kapag ang lokasyon ng pinagmulan ay naging
pinalitan ng pangalan sa patutunguhan ang anumang mga utos sa hinaharap na ilalapat sa pinagmulang lokasyon
lumikha ng mga bagong file doon at hindi makakaapekto sa destinasyon ng pagpapalit ng pangalan.

Tandaan na ang isang filerename ay kapareho ng isang filecopy na sinusundan ng isang filedelete ng
lokasyon ng pinagmulan. Mayroong bahagyang kalamangan sa pagganap sa paggamit ng filerename, ngunit ang
Ang bentahe ay napakaliit na hindi kailanman sulit na subukang mag-convert ng isang tanggalin/pagdagdag ng pares
pinagmulan ng materyal sa isang palitan ng pangalan para sa mabilis na pag-import. Ang utos ng filerename na ito ay ibinigay
para lang pasimplehin ang mga frontend na mayroon nang rename information at ayaw ng abala
sa pag-decompose nito sa isang filecopy na sinusundan ng isang filedelete.

filedeleteall
Kasama sa isang commit command upang alisin ang lahat ng mga file (at gayundin ang lahat ng mga direktoryo) mula sa
sangay. Nire-reset ng command na ito ang panloob na istraktura ng sangay upang walang mga file sa loob nito,
na nagpapahintulot sa frontend na idagdag ang lahat ng kawili-wiling mga file mula sa simula.

'deleteall' LF

Ang utos na ito ay lubhang kapaki-pakinabang kung ang frontend ay hindi alam (o walang pakialam
alam) kung anong mga file ang kasalukuyang nasa sangay, at samakatuwid ay hindi makabuo ng nararapat
filedelete command para i-update ang content.

Pag-isyu ng isang filedeleteall na sinusundan ng mga kinakailangang filemodify command upang itakda ang tama
content ay magbubunga ng parehong mga resulta gaya ng pagpapadala lamang ng kinakailangang filemodify at
filedelete na mga utos. Ang filedeleteall approach ay maaaring gayunpaman ay nangangailangan ng mabilis na pag-import upang magamit
bahagyang mas maraming memorya sa bawat aktibong sangay (mas mababa sa 1 MiB para sa kahit na karamihan sa malalaking proyekto);
kaya ang mga frontend na madaling makuha lamang ang mga apektadong path para sa isang commit ay
hinihikayat na gawin ito.

notemodify
Kasama sa isang commit utos na magdagdag ng bagong tala na nag-annot ng a
o baguhin ang mga nilalaman ng anotasyong ito. Sa panloob ito ay katulad ng filemodify 100644 on
path (maaaring hatiin sa mga subdirectory). Hindi pinapayuhan na gumamit ng iba pa
utos na sumulat sa tree maliban sa filedeleteall upang tanggalin ang lahat ng umiiral
mga tala sa punong ito. Ang utos na ito ay may dalawang magkaibang paraan ng pagtukoy sa nilalaman ng
ang tala.

Panlabas na format ng data
Ang nilalaman ng data para sa tala ay naibigay na ng isang naunang blob command. Ang
Kailangan lang ikonekta ito ng frontend sa commit na dapat i-annotate.

'N' SP SP LF

Dito maaaring maging sanggunian ng marka (: ) na itinakda ng isang naunang patak
command, o isang buong 40-byte na SHA-1 ng isang umiiral na object ng Git blob.

Inline na format ng data
Ang nilalaman ng data para sa tala ay hindi pa naibibigay. Gusto ng frontend
ibigay ito bilang bahagi ng modify command na ito.

'N' SP 'inline' SP LF
data

Tingnan sa ibaba para sa isang detalyadong paglalarawan ng utos ng data.

Sa parehong mga format ay alinman sa mga expression ng commit specification din
tinanggap ng mula sa (tingnan sa itaas).

markahan
Nag-aayos para sa mabilis na pag-import upang mag-save ng isang reference sa kasalukuyang bagay, na nagpapahintulot sa frontend
upang maalala ang bagay na ito sa hinaharap, nang hindi nalalaman ang SHA-1 nito. Dito ang
ang kasalukuyang bagay ay ang utos sa paglikha ng bagay na lalabas sa loob ng utos ng marka. Ito ay maaaring
commit, tag, at blob, ngunit commit ang pinakakaraniwang paggamit.

'mark' SP ':' LF

saan ay ang numerong itinalaga ng frontend sa markang ito. Ang halaga ng ay
ipinahayag bilang isang ASCII decimal integer. Ang value na 0 ay nakalaan at hindi maaaring gamitin bilang a
marka. Ang mga halaga lamang na mas malaki sa o katumbas ng 1 ang maaaring gamitin bilang mga marka.

Ang mga bagong marka ay awtomatikong nilikha. Ang mga umiiral na marka ay maaaring ilipat sa ibang bagay nang simple
sa pamamagitan ng muling paggamit ng pareho sa isa pang utos ng marka.

mga tag
Gumagawa ng annotated na tag na tumutukoy sa isang partikular na commit. Upang lumikha ng magaan
(hindi naka-annotate) na mga tag ay makikita ang reset command sa ibaba.

'tag' SP LF
'mula sa' SP LF
'tagger' (SP )? SP LT GT SP LF
data

saan ay ang pangalan ng tag na gagawin.

Ang mga pangalan ng tag ay awtomatikong na-prefix ng mga ref/tag/ kapag naka-store sa Git, kaya ang pag-import ng
Ang simbolo ng sangay ng CVS na RELENG-1_0-FINAL ay gagamit lamang ng RELENG-1_0-FINAL para sa , at
isusulat ng fast-import ang kaukulang ref bilang refs/tags/RELENG-1_0-FINAL.

Ang halaga ng Dapat ay isang wastong refname sa Git at samakatuwid ay maaaring naglalaman ng forward
mga slash. Dahil ang LF ay hindi wasto sa isang Git refname, walang quoting o escaping syntax ang sinusuportahan
dito.

Ang mula sa utos ay kapareho ng sa commit command; tingnan sa itaas para sa mga detalye.

Ang tagger command ay gumagamit ng parehong format bilang committer sa loob ng commit; tingnan muli sa itaas para sa
mga detalye.

Ang data command na sumusunod sa tagger ay dapat magbigay ng annotated na mensahe ng tag (tingnan sa ibaba para sa
data command syntax). Upang mag-import ng walang laman na mensahe ng tag, gumamit ng 0 haba na data. Ang mga mensahe ng tag ay
free-form at hindi binibigyang-kahulugan ng Git. Sa kasalukuyan, dapat silang naka-encode sa UTF-8, bilang
hindi pinapayagan ng fast-import na tukuyin ang iba pang mga encoding.

Hindi sinusuportahan ang paglagda ng mga annotated na tag sa panahon ng pag-import mula sa loob ng fast-import. Sinusubukan mong
isama ang iyong sariling PGP/GPG na lagda ay hindi inirerekomenda, dahil ang frontend ay hindi (madali)
magkaroon ng access sa kumpletong hanay ng mga byte na karaniwang napupunta sa naturang lagda. Kung
kailangan ang pagpirma, gumawa ng mga magaan na tag mula sa loob ng fast-import na may reset, pagkatapos
gawin ang mga annotated na bersyon ng mga tag na iyon nang offline gamit ang pamantayan pumunta mga tag proseso.

i-reset ang
Ginagawa (o muling likhain) ang pinangalanang sangay, na opsyonal na nagsisimula sa isang partikular na rebisyon. Ang
reset command ay nagbibigay-daan sa isang frontend na mag-isyu ng bago mula sa command para sa isang umiiral nang branch, o sa
lumikha ng bagong sangay mula sa isang umiiral nang commit nang hindi gumagawa ng bagong commit.

'i-reset' ang SP LF
('mula sa' SP LF)?
LF?

Para sa isang detalyadong paglalarawan ng at tingnan sa itaas sa ilalim ng commit at from.

Ang LF pagkatapos ng utos ay opsyonal (kailangan ito noon).

Ang reset command ay maaari ding gamitin para gumawa ng magaan (hindi naka-annotate) na mga tag. Para sa
halimbawa:

i-reset ang mga ref/tag/938
mula sa:938

gagawa ng magaan na tag refs/tags/938 na tumutukoy sa anumang commit mark :938
sanggunian.

patak
Humihiling ng pagsulat ng isang rebisyon ng file sa packfile. Ang rebisyon ay hindi konektado sa alinman
mangako; ang koneksyon na ito ay dapat mabuo sa isang kasunod na commit command sa pamamagitan ng pagtukoy sa
patak sa isang nakatalagang marka.

'blob' LF
marka?
data

Opsyonal ang mark command dito dahil pinili ng ilang frontend na bumuo ng Git SHA-1
para sa blob sa kanilang sarili, at i-feed iyon nang direkta upang mag-commit. Ito ay karaniwang mas maraming trabaho
gayunpaman kaysa sa sulit, dahil ang mga marka ay murang iimbak at madaling gamitin.

data
Nagbibigay ng raw data (para gamitin bilang blob/file content, commit messages, o annotated na tag
mga mensahe) upang mabilis na mag-import. Maaaring ibigay ang data gamit ang eksaktong bilang ng byte o delimited sa
isang linya ng pagtatapos. Ang mga totoong frontend na nilayon para sa mga conversion na kalidad ng produksyon ay dapat
palaging gamitin ang eksaktong format ng bilang ng byte, dahil ito ay mas matatag at mas mahusay na gumaganap. Ang
ang delimited na format ay pangunahing inilaan para sa pagsubok ng mabilis na pag-import.

Mga linya ng komento na lumalabas sa loob ng bahagi ng mga utos ng data ay palaging itinuturing na bahagi
ng katawan ng data at samakatuwid ay hindi kailanman binabalewala ng mabilis na pag-import. Ginagawa nitong ligtas
upang mag-import ng anumang nilalaman ng file/mensahe na ang mga linya ay maaaring magsimula sa #.

Eksaktong format ng bilang ng byte
Dapat tukuyin ng frontend ang bilang ng mga byte ng data.

'data' SP LF
LF?

saan ay ang eksaktong bilang ng mga byte na lumalabas sa loob . Ang halaga ng
ay ipinahayag bilang isang ASCII decimal integer. Ang LF sa magkabilang gilid ng ay
hindi kasama sa at hindi isasama sa na-import na data.

Ang LF pagkatapos ay opsyonal (kinakailangan noon) ngunit inirerekomenda. Laging
kasama nito na ginagawang mas madali ang pag-debug ng isang stream ng mabilis na pag-import bilang ang susunod na command palagi
nagsisimula sa column 0 ng susunod na linya, kahit na hindi natapos sa isang LF.

Delimited na format
Ginagamit ang delimiter string upang markahan ang dulo ng data. ang mabilis na pag-import ay kalkulahin ang
haba sa pamamagitan ng paghahanap para sa delimiter. Ang format na ito ay pangunahing kapaki-pakinabang para sa pagsubok at
ay hindi inirerekomenda para sa totoong data.

'data' SP '<<' LF
LF
LF
LF?

saan ay ang napiling delimiter string. Ang tali hindi dapat lumitaw sa a
linya mismo sa loob , dahil kung hindi, iisipin ng mabilis na pag-import na magtatapos nang mas maaga ang data
kaysa sa talagang ginagawa nito. Ang LF ay agad na humahabol ay bahagi ng . Ito ang isa
sa mga limitasyon ng delimited na format, imposibleng magbigay ng data chunk
na walang LF bilang huling byte nito.

Ang LF pagkatapos Ang LF ay opsyonal (kailangan ito noon).

checkpoint
Pinipilit ang mabilis na pag-import upang isara ang kasalukuyang packfile, magsimula ng bago, at i-save ang lahat
kasalukuyang mga ref, tag at marka ng sangay.

'checkpoint' LF
LF?

Tandaan na ang mabilis na pag-import ay awtomatikong nagpapalit ng mga packfile kapag umabot na ang kasalukuyang packfile
--max-pack-size, o 4 GiB, alinmang limitasyon ang mas maliit. Sa panahon ng isang awtomatikong packfile switch
hindi ina-update ng fast-import ang mga ref, tag o marka ng sangay.

Bilang isang checkpoint ay maaaring mangailangan ng isang malaking halaga ng oras ng CPU at disk IO (upang makalkula ang
pangkalahatang pack na SHA-1 checksum, bumuo ng kaukulang index file, at i-update ang ref)
madaling tumagal ng ilang minuto para makumpleto ang isang checkpoint command.

Maaaring piliin ng mga frontend na mag-isyu ng mga checkpoint sa panahon ng napakalaki at matagal na pag-import,
o kapag kailangan nilang payagan ang isa pang proseso ng Git na ma-access sa isang sangay. Gayunpaman, ibinigay na isang 30
Maaaring i-load ang GiB Subversion repository sa Git sa pamamagitan ng mabilis na pag-import sa loob ng halos 3 oras,
maaaring hindi kailangan ang tahasang checkpointing.

Ang LF pagkatapos ng utos ay opsyonal (kailangan ito noon).

pag-unlad
Nagiging sanhi ng mabilis na pag-import upang i-print ang buong linya ng pag-unlad na hindi nabago sa karaniwang output nito
channel (file descriptor 1) kapag ang command ay naproseso mula sa input stream. Ang
command kung hindi man ay walang epekto sa kasalukuyang pag-import, o sa alinman sa mga panloob na fast-import
estado.

'pag-unlad' SP LF
LF?

Ang bahagi ng utos ay maaaring maglaman ng anumang pagkakasunud-sunod ng mga byte na hindi naglalaman ng LF.
Ang LF pagkatapos ng command ay opsyonal. Maaaring naisin ng mga tumatawag na iproseso ang output sa pamamagitan ng a
tool tulad ng sed upang alisin ang nangungunang bahagi ng linya, halimbawa:

frontend | git fast-import | sed 's/^progress //'

Ang paglalagay ng progress command kaagad pagkatapos ng checkpoint ay magsasabi sa mambabasa kapag ang
Nakumpleto na ang checkpoint at ligtas nitong ma-access ang mga ref na na-update ng mabilis na pag-import.

makakuha ng marka
Nagiging sanhi ng mabilis na pag-import upang i-print ang SHA-1 na naaayon sa isang marka sa stdout o sa file
descriptor na dating inayos gamit ang --cat-blob-fd argument. Ang utos kung hindi man ay mayroon
walang epekto sa kasalukuyang pag-import; ang layunin nito ay kunin ang mga SHA-1 na gagawin sa ibang pagkakataon
maaaring gustong sumangguni sa kanilang mga commit na mensahe.

'get-mark' SP ':' LF

Maaaring gamitin ang command na ito kahit saan sa stream na tinatanggap ang mga komento. Sa partikular,
ang get-mark command ay maaaring gamitin sa gitna ng isang commit ngunit hindi sa gitna ng isang data
utos.

Tingnan ang "Mga Tugon Sa Mga Utos" sa ibaba para sa mga detalye tungkol sa kung paano basahin nang ligtas ang output na ito.

pusa-patak
Nagiging sanhi ng mabilis na pag-import upang mag-print ng blob sa isang file descriptor na dati nang nakaayos sa
--cat-blob-fd argumento. Ang utos kung hindi man ay walang epekto sa kasalukuyang pag-import; nito
pangunahing layunin ay upang kunin ang mga blob na maaaring nasa memorya ng mabilis na pag-import ngunit hindi naa-access
mula sa target na imbakan.

'cat-blob' SP LF

Ang maaaring maging sanggunian ng marka (: ) itinakda dati o isang buong 40-byte
SHA-1 ng isang Git blob, dati nang umiiral o handa nang isulat.

Gumagamit ang output ng parehong format tulad ng git cat-file --batch:

SP 'blob' SP LF
LF

Maaaring gamitin ang command na ito kahit saan sa stream na tinatanggap ang mga komento. Sa partikular,
ang cat-blob command ay maaaring gamitin sa gitna ng isang commit ngunit hindi sa gitna ng isang data
utos.

Tingnan ang "Mga Tugon Sa Mga Utos" sa ibaba para sa mga detalye tungkol sa kung paano basahin nang ligtas ang output na ito.

ls
Nagpi-print ng impormasyon tungkol sa bagay sa isang path sa isang file descriptor na dati nang nakaayos
gamit ang --cat-blob-fd argument. Nagbibigay-daan ito sa pag-print ng blob mula sa aktibong commit (na may
cat-blob) o pagkopya ng isang blob o puno mula sa isang dating commit para magamit sa kasalukuyan
(na may filemodify).

Ang ls command ay maaaring gamitin saanman sa stream na tinatanggap ang mga komento, kasama ang
gitna ng isang commit.

Pagbasa mula sa aktibong commit
Magagamit lang ang form na ito sa gitna ng isang commit. Pinangalanan ng path ang isang entry sa direktoryo
sa loob ng aktibong commit ng fast-import. Ang landas ay dapat na sinipi sa kasong ito.

'ls' SP LF

Pagbasa mula sa isang pinangalanang puno
Ang maaaring maging sanggunian ng marka (: ) o ang buong 40-byte na SHA-1 ng isang Git
tag, commit, o tree object, preexisting o naghihintay na maisulat. Ang landas ay
kaugnay sa pinakamataas na antas ng puno na pinangalanan ni .

'ls' SP SP LF

Tingnan ang filemodify sa itaas para sa isang detalyadong paglalarawan ng .

Gumagamit ang output ng parehong format tulad ng git ls-tree -- :

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

Ang kumakatawan sa blob, puno, o commit object sa at maaaring gamitin sa
mamaya makakuha ng marka, pusa-patak, filemodify, O ls utos.

Kung walang file o subtree sa path na iyon, pumunta mabilis na pag-import sa halip ay mag-uulat

nawawala ang SP LF

Tingnan ang "Mga Tugon Sa Mga Utos" sa ibaba para sa mga detalye tungkol sa kung paano basahin nang ligtas ang output na ito.

tampok
Hilingin na ang mabilis na pag-import ay sumusuporta sa tinukoy na tampok, o i-abort kung hindi.

'tampok' SP ('=' )? LF

Ang bahagi ng utos ay maaaring alinman sa mga sumusunod:

date-format, export-marks, relative-marks, no-relative-marks, force
Kumilos na parang ang kaukulang command-line na opsyon na may nangunguna -- ay ipinasa
ang command line (tingnan ang OPTIONS, sa itaas).

import-marks, import-marks-kung-umiiral
Tulad ng --import-marks maliban sa dalawang aspeto: una, isa lang ang "feature import-marks" o
Ang command na "feature import-marks-if-exists" ay pinapayagan sa bawat stream; pangalawa, isang
--import-marks= o --import-marks-kung-umiiral ang command-line na opsyon ay na-override ang alinman sa mga ito
"feature" na mga utos sa stream; pangatlo, "feature import-marks-if-exists" tulad ng a
Ang kaukulang command-line na opsyon ay tahimik na nilaktawan ang isang hindi umiiral na file.

get-mark, cat-blob, ls
Atasan na suportahan ng backend ang makakuha ng marka, pusa-patak, O ls utos ayon sa pagkakabanggit.
Ang mga bersyon ng fast-import na hindi sumusuporta sa tinukoy na command ay lalabas na may mensahe
nagpapahiwatig ng gayon. Hinahayaan nitong lumabas ang error sa pag-import nang maaga gamit ang isang malinaw na mensahe, sa halip na
pag-aaksaya ng oras sa unang bahagi ng isang pag-import bago ang hindi suportadong utos
nakita.

mga tala
Atasan na suportahan ng backend ang notemodify (N) subcommand sa gumawa utos.
Lalabas ang mga bersyon ng mabilis na pag-import na hindi sumusuporta sa mga tala na may mensaheng nagsasaad nito.

tapos
Error out kung magtatapos ang stream nang walang a tapos utos. Kung wala ang tampok na ito, mga error
nagiging sanhi ng biglang pagwawakas ng frontend sa isang maginhawang punto sa stream ay maaaring pumunta
hindi natukoy. Ito ay maaaring mangyari, halimbawa, kung ang isang import front end ay namatay sa kalagitnaan ng operasyon
nang hindi naglalabas ng SIGTERM o SIGKILL sa subordinate nito na git fast-import instance.

opsyon
Pinoproseso ang tinukoy na opsyon upang ang git fast-import ay kumilos sa paraang nababagay sa
mga pangangailangan ng frontend. Tandaan na ang mga opsyon na tinukoy ng frontend ay na-override ng anuman
mga opsyon na maaaring tukuyin ng user para git fast-import mismo.

'pagpipilian' SP LF

Ang bahagi ng command ay maaaring maglaman ng alinman sa mga opsyon na nakalista sa OPTIONS
seksyon na hindi nagbabago ng import semantics, nang walang nangunguna -- at ginagamot sa
parehong paraan.

Ang mga utos ng opsyon ay dapat ang unang mga utos sa input (hindi binibilang ang mga utos ng tampok),
upang magbigay ng opsyon na command pagkatapos ng anumang hindi opsyon na command ay isang error.

Ang mga sumusunod na opsyon sa command-line ay nagbabago ng import semantics at maaaring hindi maipasa
bilang pagpipilian:

· format ng petsa

· import-marka

· mga export-mark

· cat-blob-fd

· puwersa

tapos
Kung hindi ginagamit ang tapos na feature, ituring na parang nabasa ang EOF. Ito ay maaaring gamitin upang sabihin
fast-import para matapos ng maaga.

Kung ang --done command-line na opsyon o feature done command ay ginagamit, ang tapos na command ay
ipinag-uutos at minarkahan ang pagtatapos ng batis.

MGA TUGON SA UTOS

Ang mga bagong bagay na isinulat ng fast-import ay hindi kaagad magagamit. Pinakamabilis na pag-import
Ang mga command ay walang nakikitang epekto hanggang sa susunod na checkpoint (o pagkumpleto). Ang frontend
ay maaaring magpadala ng mga utos upang punan ang input pipe ng fast-import nang hindi nababahala kung gaano kabilis ang mga ito
magkakabisa, na magpapahusay sa pagganap sa pamamagitan ng pagpapasimple ng pag-iiskedyul.

Para sa ilang mga frontend, gayunpaman, ito ay kapaki-pakinabang na makapagbasa pabalik ng data mula sa kasalukuyang
repository habang ina-update ito (halimbawa kapag ang pinagmulang materyal ay naglalarawan ng mga bagay
sa mga tuntunin ng mga patch na ilalapat sa dati nang na-import na mga bagay). Ito ay maaaring
nagawa sa pamamagitan ng pagkonekta sa frontend at mabilis na pag-import sa pamamagitan ng mga bidirectional pipe:

mkfifo mabilis-import-output
frontend
git fast-import >fast-import-output

Ang isang frontend na naka-set up sa ganitong paraan ay maaaring gumamit ng progreso, get-mark, ls, at cat-blob na mga utos upang basahin
impormasyon mula sa kasalukuyang pag-import.

Upang maiwasan ang deadlock, dapat na ganap na ubusin ng naturang frontend ang anumang nakabinbing output mula sa
pag-unlad, ls, get-mark, at cat-blob bago magsagawa ng mga pagsusulat sa mabilis na pag-import na maaaring iyon
harangan.

KULANG REPORTS

Kung ang mabilis na pag-import ay ibinibigay na hindi wastong pag-input, ito ay magwawakas sa isang non-zero na katayuan sa paglabas at
lumikha ng ulat ng pag-crash sa pinakamataas na antas ng Git repository kung saan ito ini-import. Bumagsak
ang mga ulat ay naglalaman ng snapshot ng panloob na estado ng mabilis na pag-import pati na rin ang pinakabago
mga utos na humahantong sa pag-crash.

Ang lahat ng kamakailang mga utos (kabilang ang mga komento sa stream, mga pagbabago sa file at mga utos ng pag-unlad) ay
ipinapakita sa kasaysayan ng command sa loob ng ulat ng pag-crash, ngunit ang raw file data at commit
ang mga mensahe ay hindi kasama sa ulat ng pag-crash. Ang pagbubukod na ito ay nakakatipid ng espasyo sa loob ng ulat
file at binabawasan ang dami ng buffering na dapat gawin ng mabilisang pag-import sa panahon ng pagpapatupad.

Pagkatapos magsulat ng ulat ng pag-crash, isasara ng fast-import ang kasalukuyang packfile at i-export ang
talahanayan ng mga marka. Nagbibigay-daan ito sa developer ng frontend na suriin ang estado ng repositoryo at ipagpatuloy
ang pag-import mula sa punto kung saan ito nag-crash. Ang mga binagong sangay at tag ay hindi na-update
sa panahon ng pag-crash, dahil hindi matagumpay na nakumpleto ang pag-import. Impormasyon ng branch at tag
ay matatagpuan sa ulat ng pag-crash at dapat ilapat nang manu-mano kung kinakailangan ang pag-update.

Isang halimbawa ng pag-crash:

$ pusa >sa <
# ang pinakaunang test commit ko
gumawa ng refs/heads/master
committer Shawn O. Pearce 19283 -0400
# sino kaya yung lalaki na yun?
data <
ito ang aking pangako
EOF
M 644 inline .gitignore
data <
.gignignore
EOF
M 777 inline bob
END_OF_INPUT

$ git fast-import
nakamamatay: Corrupt mode: M 777 inline bob
fast-import: dumping crash report sa .git/fast_import_crash_8434

$ cat .git/fast_import_crash_8434
mabilis na pag-import ng ulat ng pag-crash:
mabilis na proseso ng pag-import: 8434
proseso ng magulang: 1391
sa Sab Set 1 00:58:12 2007

nakamamatay: Corrupt mode: M 777 inline bob

Pinakabagong Mga Utos Bago Mag-crash
---------------------------------
# ang pinakaunang test commit ko
gumawa ng refs/heads/master
committer Shawn O. Pearce 19283 -0400
# sino kaya yung lalaki na yun?
data <
M 644 inline .gitignore
data <
* M 777 inline bob

Aktibong Sangay LRU
-----------------
active_branches = 1 cur, 5 max

pangalan ng orasan ng pos
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) 0 ref/heads/master

Mga Di-aktibong Sangay
-----------------
refs/heads/master:
status : active loaded marumi
tip commit : 0000000000000000000000000000000000000000
lumang puno : 0000000000000000000000000000000000000000
puno ng cur : 0000000000000000000000000000000000000000
gumawa ng orasan: 0
huling pakete:

-------------------
END OF CRASH REPORT

TIP AT MGA TRIK

Ang mga sumusunod na tip at trick ay nakolekta mula sa iba't ibang user ng fast-import, at
ay inaalok dito bilang mga mungkahi.

paggamit Isa Utak ng buto Bawat gumawa
Kapag gumagawa ng conversion ng repository, gumamit ng natatanging marka sa bawat commit (mark : ) at supply
ang --export-marks na opsyon sa command line. ang fast-import ay magtapon ng isang file na naglilista
bawat marka at ang Git object SHA-1 na tumutugma dito. Kung ang frontend ay maaaring itali ang
marks pabalik sa source repository, ito ay madaling i-verify ang katumpakan at pagkakumpleto ng
ang pag-import sa pamamagitan ng paghahambing ng bawat Git commit sa kaukulang rebisyon ng pinagmulan.

Mula sa isang sistema tulad ng Perforce o Subversion, ito ay dapat na medyo simple, tulad ng
Ang mabilis na pag-import na marka ay maaari ding ang Perforce changeset na numero o ang Subversion revision
numero.

Malaya Laktawan sa paligid Sangay
Huwag mag-abala na subukang i-optimize ang frontend upang manatili sa isang sangay sa isang pagkakataon sa panahon ng isang
angkat. Bagama't ang paggawa nito ay maaaring bahagyang mas mabilis para sa mabilis na pag-import, malamang na tumaas ito
malaki ang pagiging kumplikado ng frontend code.

Ang sangay na LRU na binuo sa mabilis na pag-import ay malamang na kumilos nang napakahusay, at ang halaga ng
Ang pag-activate ng hindi aktibong sangay ay napakababa na ang pagtalbog sa pagitan ng mga sanga
halos walang epekto sa pagganap ng pag-import.

Pag-asikaso Mga Pangalan
Kapag nag-import ng pinalitan ng pangalan na file o direktoryo, tanggalin lang ang (mga) lumang pangalan at baguhin ang
bagong (mga) pangalan sa panahon ng kaukulang commit. Gumagawa ang Git ng rename detection pagkatapos ng katotohanan,
sa halip na tahasan sa panahon ng commit.

paggamit Tag Iayos Sangay
Ang ilang iba pang mga sistema ng SCM ay nagbibigay-daan sa gumagamit na lumikha ng isang tag mula sa maraming mga file na hindi mula sa
ang parehong commit/changeset. O upang lumikha ng mga tag na isang subset ng mga file na available sa
ang imbakan.

Imposible ang pag-import ng mga tag na ito sa Git nang hindi gumagawa ng kahit isang commit
"Inaayos" ang mga file upang tumugma sa nilalaman ng tag. Gamitin ang utos ng pag-reset ng fast-import sa
i-reset ang isang dummy branch sa labas ng iyong normal na branch space sa base commit para sa tag,
pagkatapos ay gumawa ng isa o higit pang file fixup commit, at sa wakas ay i-tag ang dummy branch.

Halimbawa dahil ang lahat ng normal na sangay ay naka-imbak sa ilalim ng ref/heads/ pangalanan ang tag fixup
sangay TAG_FIXUP. Sa ganitong paraan, imposible para sa fixup branch na ginagamit ng importer
may mga salungat sa namespace sa mga totoong sangay na na-import mula sa pinagmulan (ang pangalang TAG_FIXUP
ay hindi refs/heads/TAG_FIXUP).

Kapag nagsasagawa ng mga pag-aayos, isaalang-alang ang paggamit ng merge para ikonekta ang (mga) commit na nagbibigay
mga pagbabago sa file sa sangay ng fixup. Ang paggawa nito ay magbibigay-daan sa mga tool tulad ng pumunta magbigay-sala upang subaybayan
sa pamamagitan ng totoong commit history at maayos na i-annotate ang mga source file.

Pagkatapos ng mabilis na pag-import, kakailanganin ng frontend na gawin ang rm .git/TAG_FIXUP upang alisin ang
dummy branch.

Angkat Ngayon, I-repack Mamaya
Sa sandaling makumpleto ng mabilis na pag-import ang Git repository ay ganap na wasto at handa nang gamitin.
Kadalasan ito ay tumatagal lamang ng napakaikling panahon, kahit na para sa mga malalaking proyekto
(100,000+ commit).

Gayunpaman, ang pag-repack ng repositoryo ay kinakailangan upang mapabuti ang lokalidad at pag-access ng data
pagganap. Maaari din itong tumagal ng mga oras sa napakalaking proyekto (lalo na kung -f at a
malaking --window parameter ang ginagamit). Dahil ang repacking ay ligtas na tumakbo kasama ng mga mambabasa at
mga manunulat, patakbuhin ang repack sa background at hayaang matapos ito kapag natapos na. Walang
dahilan para maghintay upang galugarin ang iyong bagong proyekto sa Git!

Kung pipiliin mong maghintay para sa repack, huwag subukang magpatakbo ng mga benchmark o mga pagsubok sa pagganap
hanggang sa matapos ang repacking. mabilis-import na mga output suboptimal packfiles na simple
hindi pa nakikita sa totoong paggamit ng mga sitwasyon.

Nagre-repack makasaysayan data
Kung nagre-repack ka ng napakalumang na-import na data (hal. mas luma kaysa sa nakaraang taon), isaalang-alang
gumugugol ng ilang dagdag na oras ng CPU at nagbibigay ng --window=50 (o mas mataas) kapag tumakbo ka pumunta
repack. Magtatagal ito, ngunit gagawa din ng mas maliit na packfile. Kailangan mo lang
gugulin ang pagsisikap nang isang beses, at lahat ng gumagamit ng iyong proyekto ay makikinabang sa mas maliit
imbakan.

isama ilan Pag-unlad Pagpapaskil
Paminsan-minsan, hayaan ang iyong frontend na magpalabas ng mensahe ng pag-unlad upang mabilis na mag-import. Ang
ang mga nilalaman ng mga mensahe ay ganap na libre, kaya ang isang mungkahi ay ang paglabas ng
kasalukuyang buwan at taon sa tuwing lilipat ang kasalukuyang petsa ng commit sa susunod na buwan. Iyong
mas magiging maganda ang pakiramdam ng mga user kapag nalaman kung gaano karami ang naproseso na stream ng data.

PACKFILE optimization

Kapag nag-iimpake ng blob fast-import palaging sinusubukang i-deltify laban sa huling blob na isinulat.
Maliban kung partikular na inayos ng frontend, malamang na hindi ito magiging priority
bersyon ng parehong file, kaya ang nabuong delta ay hindi magiging pinakamaliit na posible. Ang
ang magreresultang packfile ay mai-compress, ngunit hindi magiging pinakamainam.

Mga frontend na may mahusay na access sa lahat ng mga rebisyon ng isang file (halimbawa
pagbabasa ng isang RCS/CVS ,v file) ay maaaring pumili upang ibigay ang lahat ng mga rebisyon ng file na iyon bilang isang pagkakasunud-sunod
ng magkakasunod na blob command. Nagbibigay-daan ito sa mabilis na pag-import na i-deltify ang iba't ibang file
mga pagbabago laban sa isa't isa, na nagtitipid ng espasyo sa panghuling packfile. Maaaring gamitin ang mga marka
sa ibang pagkakataon ay tukuyin ang mga indibidwal na rebisyon ng file sa panahon ng pagkakasunod-sunod ng mga commit command.

Ang (mga) packfile na nilikha ng mabilis na pag-import ay hindi naghihikayat ng magandang disk access pattern. Ito ay
sanhi ng mabilis na pag-import ng pagsulat ng data sa pagkakasunud-sunod na natanggap ito sa karaniwang input,
habang ang Git ay karaniwang nag-aayos ng data sa loob ng mga packfile upang gawin ang pinakabago (kasalukuyang tip)
lumalabas ang data bago ang makasaysayang data. Ang mga kumpol ng Git ay nagko-commit nang sama-sama, nagpapabilis
rebisyon traversal sa pamamagitan ng mas mahusay na cache lokalidad.

Para sa kadahilanang ito, lubos na inirerekomenda na i-repack ng mga user ang repositoryo gamit ang git
repack -a -d pagkatapos makumpleto ang mabilis na pag-import, na nagpapahintulot sa Git na muling ayusin ang mga packfile para sa
mas mabilis na pag-access ng data. Kung ang mga blob deltas ay suboptimal (tingnan sa itaas) pagkatapos ay idagdag din ang -f
Ang opsyon na pilitin ang recomputation ng lahat ng deltas ay maaaring makabuluhang bawasan ang panghuling packfile
laki (30-50% na mas maliit ay maaaring maging karaniwan).

ALAALA PAGGAMIT

Mayroong ilang mga kadahilanan na nakakaapekto sa kung gaano karaming memorya ang kinakailangan upang gumanap ng mabilis na pag-import
isang import. Tulad ng mga kritikal na seksyon ng core Git, ang fast-import ay gumagamit ng sarili nitong mga allocator ng memory
upang bayaran ang anumang mga overhead na nauugnay sa malloc. Sa pagsasagawa, ang mabilis na pag-import ay madalas
amortise ang anumang malloc overhead sa 0, dahil sa paggamit nito ng malalaking block allocations.

para bagay
Ang fast-import ay nagpapanatili ng in-memory na istraktura para sa bawat bagay na nakasulat sa pagpapatupad na ito.
Sa isang 32 bit system ang istraktura ay 32 bytes, sa isang 64 bit system ang istraktura ay 40 bytes
(dahil sa mas malalaking sukat ng pointer). Ang mga bagay sa talahanayan ay hindi na-deallocate hanggang
matatapos ang mabilis na pag-import. Ang pag-import ng 2 milyong bagay sa isang 32 bit system ay mangangailangan
humigit-kumulang 64 MiB ng memorya.

Ang object table ay talagang isang hashtable na naka-key sa object name (ang natatanging SHA-1). Ito
Ang configuration ng imbakan ay nagbibigay-daan sa mabilis na pag-import upang muling gamitin ang isang umiiral na o nakasulat na bagay
at iwasang magsulat ng mga duplicate sa output packfile. Ang mga duplicate na blobs ay nakakagulat
karaniwan sa isang pag-import, kadalasang dahil sa mga pagsasanib ng sangay sa pinagmulan.

para markahan
Ang mga marka ay iniimbak sa isang kalat-kalat na hanay, gamit ang 1 pointer (4 byte o 8 byte, depende sa
laki ng pointer) bawat marka. Kahit na ang array ay kalat-kalat, ang mga frontend ay malakas pa rin
hinihikayat na gumamit ng mga marka sa pagitan ng 1 at n, kung saan ang n ay ang kabuuang bilang ng mga marka na kinakailangan para sa
ang import na ito.

para sangay
Ang mga sangay ay inuri bilang aktibo at hindi aktibo. Ang paggamit ng memorya ng dalawang klase ay
makabuluhang naiiba.

Ang mga hindi aktibong sanga ay iniimbak sa isang istraktura na gumagamit ng 96 o 120 bytes (32 bit o 64 bit
system, ayon sa pagkakabanggit), kasama ang haba ng pangalan ng sangay (karaniwang wala pang 200 bytes),
bawat sangay. Ang mabilis na pag-import ay madaling makakahawak ng hanggang 10,000 hindi aktibong mga sangay sa ilalim ng 2
MiB ng memorya.

Ang mga aktibong branch ay may parehong overhead gaya ng mga hindi aktibong branch, ngunit naglalaman din ng mga kopya ng
bawat puno na kamakailang binago sa sanga na iyon. Kung ang subtree kasama ay hindi pa
binago mula noong naging aktibo ang sangay, ang mga nilalaman nito ay hindi mailo-load sa memorya, ngunit
kung ang subtree src ay binago ng isang commit mula noong naging aktibo ang sangay, ito ay
ang mga nilalaman ay mai-load sa memorya.

Habang ang mga aktibong sangay ay nag-iimbak ng metadata tungkol sa mga file na nakapaloob sa sangay na iyon, ang kanilang
Ang laki ng in-memory na imbakan ay maaaring lumaki sa isang malaking sukat (tingnan sa ibaba).

ang mabilis na pag-import ay awtomatikong naglilipat ng mga aktibong sangay sa hindi aktibong katayuan batay sa isang simple
pinakakamakailang-ginamit na algorithm. Ang LRU chain ay ina-update sa bawat commit command. Ang
maximum na bilang ng mga aktibong sanga ay maaaring dagdagan o bawasan sa command line na may
--active-branches=.

para aktibo puno
Ang mga puno (aka mga direktoryo) ay gumagamit lamang ng 12 bytes ng memory sa itaas ng memorya na kinakailangan para sa
kanilang mga entry (tingnan ang "bawat aktibong file" sa ibaba). Ang halaga ng isang puno ay halos 0, bilang nito
overhead amortizes out sa mga indibidwal na mga entry ng file.

para aktibo file pagpasok
Ang mga file (at mga pointer sa mga subtree) sa loob ng mga aktibong puno ay nangangailangan ng 52 o 64 byte (32/64 bit
platform) bawat entry. Para makatipid ng espasyo, pinagsama-sama ang mga pangalan ng file at puno sa isang karaniwang string
table, na nagpapahintulot sa filename na "Makefile" na gumamit lamang ng 16 bytes (pagkatapos isama ang string
header overhead) gaano man ito karaming beses mangyari sa loob ng proyekto.

Ang aktibong branch LRU, kapag isinama sa filename string pool at tamad na pag-load ng
subtree, nagbibigay-daan sa mabilis na pag-import upang mahusay na mag-import ng mga proyekto na may 2,000+ na sangay at
45,114+ na file sa isang napakalimitadong memory footprint (mas mababa sa 2.7 MiB bawat aktibong branch).

Mga TANDA

Nagpapadala ng SIGUSR1 sa pumunta mabilis na pag-import Ang proseso ay nagtatapos nang maaga sa kasalukuyang packfile, na ginagaya
isang checkpoint command. Maaaring gamitin ng naiinip na operator ang pasilidad na ito upang silipin ang mga bagay
at sumasangguni mula sa kasalukuyang pag-import, sa halaga ng ilang karagdagang oras ng pagpapatakbo at mas masahol pa
compression.

Gumamit ng git-fast-import online gamit ang mga serbisyo ng onworks.net