È sicuro clonare in modo superficiale con --depth 1, creare commit ed estrarre nuovamente gli aggiornamenti?

L' --depth 1opzione in git clone:

Crea un clone superficiale con una cronologia troncata al numero specificato di revisioni. Un repository superficiale presenta una serie di limitazioni (non è possibile clonare o recuperare da esso, né spingere da né all'interno di esso), ma è adeguato se si è interessati solo alla storia recente di un grande progetto con una lunga storia e si desidera invia correzioni come patch.

Ma ho fatto con successo un clone superficiale, ho apportato alcune modifiche e ho riportato quelle modifiche all'origine (clone nudo).

Per me ha senso - intendo, perché no? quando HEAD clonato è identificabile nell'origine e il mio commit si aggiunge a questo, non sembra esserci alcun motivo. Ma il manuale dice il contrario.

Mi piace l'idea del clone superficiale - ad es. Del nucleo di drupal: non c'è modo di sapere cosa è successo in drupal 4 quando ho iniziato da 7. - ma non voglio spararmi al piede.

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

Nota che Git 1.9 / 2.0 (Q1 2014) ha rimosso questa limitazione.
Vedi commit 82fba2b , di 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 legge :

--depth <depth>::

Crea un clone 'superficiale' con una cronologia troncata al numero specificato di revisioni.

Ciò deriva da commit come 0d7d285 , f2c681c e c29a7b8 che supportano il clone, send-pack / ricezione-pack con / da cloni superficiali.
smart-http ora supporta anche fetch / clone superficiali .

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 recuperare un singolo commit !
(Ultimo caso superficiale)

Aggiornamento gennaio 2016: Git 2.8 (Mach 2016) ora documenta ufficialmente la pratica di ottenere una storia 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 (``) .
^{(Unito da Junio ​​C Hamano - gitster- in commit 7e3e80a , 20 gennaio 2016)}

Questo è " Documentation/user-manual.txt"

A <<def_shallow_clone,shallow clone>>viene creato specificando l' git-clone --depthopzione.
La profondità può essere successivamente modificata con l' git-fetch --depthinterruttore, oppure è possibile ripristinare la cronologia completa con --unshallow.

La fusione all'interno di un <<def_shallow_clone,shallow clone>>funzionerà finché una base di unione è nella storia recente.
Altrimenti, sarà come fondere storie non correlate e potrebbe dover provocare enormi conflitti.
Questa limitazione potrebbe rendere un repository inadatto all'uso nei flussi di lavoro basati sulla fusione.

Aggiornamento 2020:

• git 2.11.1 ha introdotto l'opzione git fetch --shallow-exclude=per impedire il recupero di tutta la cronologia
• git 2.11.1 ha introdotto l'opzione git fetch --shallow-since=per impedire il recupero di vecchi commit.

Per ulteriori informazioni sul processo di aggiornamento del clone shallow, consultare " Come aggiornare un clone git shallow? ".

Come commentato da Richard Michael :

per riempire la cronologia: git pull --unshallow

E Olle Härstedt aggiunge nei commenti :

Per riempire parte della storia: git fetch --depth=100.

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

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

La cosa difficile è che il caso d'uso sia corretto (cioè auto-coerente), in modo che i repository distribuiti e quindi probabilmente divergenti funzionino ancora felicemente insieme.

Sembra che checkout --orphansia il giusto stadio 'set-up', ma manca ancora una guida chiara (cioè un semplice comando comprensibile di una riga) sul passaggio "clone". Piuttosto sembra che devi fare initun repository, impostare un remoteramo di tracciamento (vuoi un solo ramo?), E poi fetchquel singolo ramo, che sembra a lungo avvolto con più possibilità di errori.

Modifica: per il passaggio 'clone' vedere questa risposta