È sicuro clonare in modo superficiale con –depth 1, creare commit e ritirare gli aggiornamenti?

L’opzione --depth 1 in git clone :

Creare un clone superficiale con una cronologia troncata al numero specificato di revisioni. Un repository poco profondo ha un certo numero di limitazioni (non puoi clonarlo o recuperarlo, né inviarlo né inserirlo), ma è adeguato se sei interessato solo alla storia recente di un grande progetto con una lunga storia e vorresti inviare correzioni come patch.

Ma ho fatto con successo un clone superficiale, ho commesso alcuni cambiamenti e ho spinto questi cambiamenti verso l’origine (clone nudo).

Ha senso per me, intendo perché no? quando il HEAD clonato è identificabile nell’origine, e il mio commit viene in cima a questo, non sembra esserci alcuna ragione. Ma il manuale dice il contrario.

Mi piace l’idea del clone superficiale – ad es. Del core drupal: non ho modo di sapere cosa è successo a drupal 4 quando ho iniziato da 7. – ma non voglio spararmi ai piedi.

Quindi è sicuro clonare superficialmente, sviluppare il commit in esso, tirare di nuovo per tenere il passo con gli aggiornamenti dall’origine?

Si noti che Git 1.9 / 2.0 (Q1 2014) ha rimosso tale limite.
Vedi commit 82fba2b , da Nguyễn Thái Ngọc Duy ( pclouds ) :

Ora che git supporta il trasferimento di dati da o verso un clone superficiale, queste limitazioni non sono più vere.

La documentazione ora dice :

 --depth :: 

Creare un clone “superficiale” con una cronologia troncata al numero specificato di revisioni.

Questo deriva da commit come 0d7d285 , f2c681c e c29a7b8 che supportano clone, send-pack / receive-pack con / da cloni poco profondi.
smart-http ora supporta anche shallow fetch / clone .

Tutti i dettagli sono in ” shallow.c : gli 8 passaggi per selezionare nuovi commit per .git/shallow “.

Aggiornamento giugno 2015: Git 2.5 consentirà persino di prelevare un singolo commit !
(Ultimo caso superficiale)


Aggiornamento gennaio 2016: Git 2.8 (Mach 2016) ora documenta ufficialmente la pratica di ottenere una cronologia minima.
Vedi commit 99487cf , commit 9cfde9e (30 dic 2015), commit 9cfde9e (30 dic 2015), commit bac5874 (29 dic 2015) e commit 1de2e44 (28 dic 2015) di Stephen P. Smith (“) .
(Fuso da Junio ​​C Hamano – gitster – in commit 7e3e80a , 20 gen 2016)

Questo è ” Documentation/user-manual.txt

Un <> viene creato specificando l’ git-clone --depth .
In seguito, la profondità può essere cambiata con l’ git-fetch --depth o la cronologia completa ripristinata con --unshallow .

Fondendosi all’interno di un <> funzionerà fintanto che una fusione si trova nella cronologia recente.
Altrimenti, sarà come fondere storie non correlate e potrebbe portare a enormi conflitti.
Questa limitazione può rendere tale repository inadatto per essere utilizzato nei flussi di lavoro basati su unione.


Per ulteriori informazioni sul processo di aggiornamento dei cloni superficiali, consultare ” Come aggiornare un clone di git shallow? “.


Come commentato da Richard Michael :

per eseguire il backfill della cronologia: git pull --unshallow

E Olle Härstedt aggiunge nei commenti :

Per recuperare parte della cronologia: git fetch --depth=100 .

Vedi alcune delle risposte alla mia domanda simile, perché -non-posso-spingere-da-un-basso-clone e il link al thread recente nella lista git.

In definitiva, la misurazione della “profondità” non è coerente tra i reposli, perché misurano dai loro singoli HEAD, piuttosto che (a) dalla tua Testa, o (b) dai commit che hai clonato / recuperato, o (c) qualcos’altro avevi in ​​mente.

La parte difficile è ottenere correttamente le Case d’Uso (cioè coerenti), in modo che i repository distribuiti, e quindi probabilmente divergenti, funzionino ancora felicemente insieme.

Assomiglia al checkout --orphan è il giusto palcoscenico ‘set-up’, ma manca ancora una guida pulita (cioè un semplice comando di linea semplice) sul passo “clone”. Piuttosto, sembra che tu debba iniziare un repo, impostare un ramo di localizzazione remote (vuoi solo un ramo?), E poi fetch quel singolo ramo, che sembra lungo con più possibilità di errori.

Modifica: per il passaggio ‘clone’ vedi questa risposta