Atunci când depozitul din care se clonează se află pe o mașină locală, acest indicator ocolește mecanismul normal de transport "Git aware" și clonează depozitul prin copierea lui HEAD și a tot ceea ce se află în directoarele objects și refs. Fișierele din directorul .git/objects/ sunt legate prin hardlinking pentru a economisi spațiu atunci când este posibil.

Forțează procesul de clonare de la un depozit pe un sistem de fișiere local să copieze fișierele din directorul .git/objects în loc să folosească hardlink-uri. Acest lucru poate fi de dorit dacă încercați să faceți o copie de siguranță a depozitului dumneavoastră.

Atunci când depozitul de clonat se află pe calculatorul local, în loc să folosiți legături dure, configurați automat .git/objects/info/alternates pentru a partaja obiectele cu depozitul sursă. Depozitul rezultat pornește fără niciun obiect propriu.

În cazul în care depozitul de referință se află pe calculatorul local, configurați automat .git/objects/info/alternates pentru a obține obiecte din depozitul de referință. Utilizarea unui depozit deja existent ca alternativă va necesita mai puține obiecte care să fie copiate din depozitul clonat, reducând costurile de rețea și de stocare locală. Atunci când se utilizează --reference-if-able, un director inexistent este sărit cu un avertisment în loc să se anuleze clonarea.

Împrumutați obiectele din depozitele de referință specificate cu opțiunile --reference numai pentru a reduce transferul de rețea și încetați să mai împrumutați din acestea după ce se face o clonă, făcând copiile locale necesare ale obiectelor împrumutate. Această opțiune poate fi utilizată și atunci când se clonează local dintr-un depozit care împrumută deja obiecte de la un alt depozit - noul depozit va împrumuta obiecte din același depozit, iar această opțiune poate fi utilizată pentru a opri împrumutul.

Funcționează în liniște. Progresul nu este raportat la fluxul de eroare standard.

Se execută la nivel verbal. Nu afectează raportarea stării de progres către fluxul de eroare standard.

Starea de progres este raportată în mod implicit pe fluxul de eroare standard atunci când este atașat la un terminal, cu excepția cazului în care se specifică --quiet. Acest indicator forțează starea de progres chiar dacă fluxul de eroare standard nu este direcționat către un terminal.

Transmite serverului șirul de caractere dat atunci când se comunică folosind versiunea 2 a protocolului. Șirul dat nu trebuie să conțină un caracter NUL sau LF. Gestionarea de către server a opțiunilor serverului, inclusiv a celor necunoscute, este specifică serverului. Atunci când sunt date mai multe --server-option=<option>, toate sunt trimise celeilalte părți în ordinea listată pe linia de comandă.

După finalizarea clonei, nu se efectuează nicio verificare a lui HEAD.

Eșuează dacă depozitul sursă este un depozit superficial. Variabila de configurare "clone.rejectShallow" poate fi utilizată pentru a specifica valoarea implicită.

Creați un depozit Git "gol". Adică, în loc să creați <directory> și să plasați fișierele administrative în <directory>/.git, faceți din <directory> însuși <directory> $GIT_DIR. Acest lucru implică în mod evident --no-checkout, deoarece nu există niciun loc unde să se verifice structura de lucru. De asemenea, capetele de branșă de la distanță sunt copiate direct în capetele de branșă locale corespunzătoare, fără a le cartografia în refs/remotes/origin/. Când se utilizează această opțiune, nu se creează nici branșele de urmărire la distanță, nici variabilele de configurare aferente.

Inițializați fișierul sparse-checkout astfel încât directorul de lucru să înceapă doar cu fișierele din root-ul depozitului. Fișierul sparse-checkout poate fi modificat pentru a mări directorul de lucru, după cum este necesar.

Utilizați funcția de clonare parțială și solicitați ca serverul să trimită un subset de obiecte accesibile în funcție de un anumit filtru de obiecte. Atunci când se utilizează --filter, se utilizează <filter-spec> furnizat pentru filtrul de clonare parțială. De exemplu, --filter=blob:none va filtra toate blob-urile (conținutul fișierelor) până când Git va avea nevoie de ele. De asemenea, --filter=blob:limit=<size> va filtra toate blob-urile cu o dimensiune de cel puțin <size>. Pentru mai multe detalii despre specificațiile filtrelor, consultați opțiunea --filter din git-rev-list[1].

Configurați o oglindă a depozitului sursă. Acest lucru implică --bare. În comparație cu --bare, --mirror nu numai că mapează branșele locale ale sursei în branșele locale ale țintei, ci mapează toate referințele (inclusiv branșele de urmărire la distanță, notele etc.) și stabilește o configurație refspec astfel încât toate aceste referințe să fie suprascrise de o git remote update în depozitul țintă.

În loc să folosiți numele de la distanță origin pentru a ține evidența depozitului din upstream, folosiți <name>. Suprascrie clone.defaultRemoteName din configurare.

În loc să direcționați HEAD nou creat către branșa indicată de HEAD-ul depozitului clonat, direcționați-l către ramura <name>. Într-un depozit non-bare, aceasta este branșa care va fi verificată. --branch poate, de asemenea, să primească etichete și detașează HEAD la acea confirmare în depozitul rezultat.

Atunci când este dată, iar depozitul din care se clonează este accesat prin ssh, aceasta specifică o cale diferită de cea implicită pentru comanda executată la celălalt capăt.

Specificați directorul din care vor fi utilizate șabloanele; (Consultați secțiunea "TEMPLATE DIRECTORY" din git-init[1])

Setați o variabilă de configurare în depozitul nou-creat; aceasta intră în vigoare imediat după ce depozitul este inițializat, dar înainte ca istoricul de la distanță să fie preluat sau ca orice fișier să fie verificat. Cheia este în același format ca cel așteptat de git-config[1] (de exemplu, core.eol=true). Dacă sunt date mai multe valori pentru aceeași cheie, fiecare valoare va fi scrisă în fișierul de configurare. Acest lucru face ca, de exemplu, să fie sigură adăugarea unor refspecs suplimentare de preluare la remote origin.

Creează o clonă "superficială" cu un istoric trunchiat la numărul specificat de comenzi. Implică --single-branch, cu excepția cazului în care se specifică --no-single-branch pentru a prelua istoricul din apropierea vârfurilor tuturor ramurilor. Dacă doriți să clonați submodulele superficial, treceți și --shallow-submodules.

Creează o clonă superficială cu un istoric după timpul specificat.

Creează o clonă superficială cu un istoric, excluzând comenzile care pot fi accesate de la o branșă sau etichetă la distanță specificată. Această opțiune poate fi specificată de mai multe ori.

Clonează numai istoricul care duce la vârful unei singure branșe, fie că este specificat de opțiunea --branch, fie că este vorba de ramura principală la care indică HEAD de la distanță. Preluările ulterioare în depozitul rezultat vor actualiza numai branșa de urmărire de la distanță pentru branșa pentru care această opțiune a fost utilizată pentru clonarea inițială. În cazul în care HEAD de la distanță nu a indicat nicio branșă atunci când s-a efectuat clonarea --single-branch, nu se creează nicio branșă de urmărire la distanță.

Nu clonați niciun tag și setați remote.<remote>.tagOpt=--no-tags în configurație, asigurându-vă că viitoarele operațiuni git pull și git fetch nu vor urmări niciun tag. Recuperările ulterioare explicite de etichete vor funcționa în continuare (a se vedea git-fetch[1]).

După ce clona este creată, inițializați și clonați submodulele din cadrul acesteia pe baza specificației de traseu furnizate. Dacă nu este furnizată nicio specificație de traseu, toate submodulele sunt inițializate și clonate. Această opțiune poate fi furnizată de mai multe ori pentru specificațiile de traseu compuse din mai multe intrări. Clona rezultată are submodule.active setat la specificația de traseu furnizată sau "." (însemnând toate submodulele) dacă nu este furnizată nicio specificație de traseu.

Toate submodulele care sunt clonate vor fi superficiale, cu o adâncime de 1.

Toate submodulele care sunt clonate vor utiliza starea branșei de urmărire la distanță a submodulelor pentru a actualiza submodulele, mai degrabă decât SHA-1 înregistrat de superproiect. Echivalent cu trecerea --remote la git submodule update.

În loc să plasați depozitul clonat acolo unde ar trebui să fie, plasați depozitul clonat în directorul specificat, apoi creați o legătură simbolică Git agnostică pentru sistemul de fișiere. Rezultatul este că depozitul Git poate fi separat de structura de lucru.

Numărul de submodule preluate în același timp. Valoarea implicită este cea a opțiunii submodule.fetchJobs.

Depozitul (eventual la distanță) din care se clonează. Consultați secțiunea GIT URLS de mai jos pentru mai multe informații despre specificarea depozitelor.

Numele unui nou director în care se clonează. Partea "humanish" a depozitului sursă este utilizată dacă nu se indică în mod explicit un director (repo pentru /path/to/repo.git și foo pentru host.xz:foo/.git). Clonarea într-un director existent este permisă numai dacă directorul este gol.