É seguro clonar superficialmente com - profundidade 1, criar confirmações e receber atualizações novamente?

A --depth 1opção em git clone:

Crie um clone superficial com um histórico truncado para o número especificado de revisões. Um repositório superficial possui várias limitações (você não pode clonar ou buscar dele, nem empurrá-lo nem empurrá-lo), mas é adequado se você estiver interessado apenas no histórico recente de um grande projeto com um longo histórico e desejar envie correções como patches.

Mas fiz com sucesso um clone superficial, cometeu algumas alterações e as levei de volta à origem (clone nu).

Faz sentido para mim - quero dizer, por que não? quando o HEAD clonado é identificável na origem e meu commit vem por cima disso, parece que não há razão. Mas o manual diz o contrário.

Gosto da ideia de clone superficial - por exemplo, do núcleo do drupal: não há como eu precisar saber o que aconteceu no drupal 4 quando comecei a partir do 7. -, mas não quero me dar um tiro no pé.

Portanto, é seguro clonar superficialmente, desenvolver commits, puxar novamente para acompanhar as atualizações de origem?

Observe que o Git 1.9 / 2.0 (primeiro trimestre de 2014) removeu essa limitação.
Veja commit 82fba2b , de Nguyễn Thái Ngọc Duy ( pclouds) :

Agora que o git suporta a transferência de dados de ou para um clone superficial, essas limitações não são mais verdadeiras.

A documentação agora diz :

--depth <depth>::

Crie um clone 'superficial' com um histórico truncado para o número especificado de revisões.

Isso resulta de confirmações como 0d7d285 , f2c681c e c29a7b8 que suportam clone, pacote de envio / pacote de recebimento com / de clones rasos.
O smart-http agora também suporta busca / clone superficial .

Todos os detalhes estão em " shallow.c: as 8 etapas para selecionar novos commits para.git/shallow ".

Atualização em junho de 2015: o Git 2.5 permitirá até buscar um único commit !
(Caso superficial final)

Atualização em janeiro de 2016: o Git 2.8 (Mach 2016) agora documenta oficialmente a prática de obter um histórico mínimo.
Consulte commit 99487cf , commit 9cfde9e (30 de dezembro de 2015), commit 9cfde9e (30 de dezembro de 2015), commit bac5874 (29 de dezembro de 2015) e commit 1de2e44 (28 de dezembro de 2015) por Stephen P. Smith (``) .
^{(Mesclado por Junio ​​C Hamano - gitster- na confirmação 7e3e80a , 20 de janeiro de 2016)}

Isso é " Documentation/user-manual.txt"

A <<def_shallow_clone,shallow clone>>é criado especificando a git-clone --depthopção.
A profundidade pode ser alterada posteriormente com a git-fetch --depthopção ou o histórico completo restaurado com --unshallow.

Mesclar dentro de um <<def_shallow_clone,shallow clone>>funcionará enquanto uma base de mesclagem estiver no histórico recente.
Caso contrário, será como mesclar histórias não relacionadas e pode ter que resultar em enormes conflitos.
Essa limitação pode tornar esse repositório inadequado para ser usado em fluxos de trabalho baseados em mesclagem.

Atualização 2020:

• O git 2.11.1 introduziu a opção git fetch --shallow-exclude=para impedir a busca de todo o histórico
• O git 2.11.1 introduziu a opção git fetch --shallow-since=para evitar a busca de confirmações antigas.

Para obter mais informações sobre o processo de atualização do clone superficial, consulte " Como atualizar um clone superficial do git? ".

Como comentado por Richard Michael :

para preencher o histórico: git pull --unshallow

E Olle Härstedt acrescenta nos comentários :

Para aterrar parte da história: git fetch --depth=100.

Veja algumas das respostas para minha pergunta semelhante: por que não consigo pressionar um clone superficial e o link para o tópico recente na lista git.

Por fim, a medição da 'profundidade' não é consistente entre os repositórios, porque eles medem a partir de suas CABEÇAS individuais, em vez de (a) sua Cabeça, ou (b) o (s) commit (s) que você clonou / buscou, ou (c) outra coisa você tinha em mente.

O difícil é acertar o Caso de Uso de um usuário (ou seja, autoconsistente), para que os repositórios distribuídos e, portanto, provavelmente divergentes ainda funcionem felizes juntos.

Parece que checkout --orphané o estágio certo de 'configuração', mas ainda não possui orientações claras (isto é, um simples comando compreensível de uma linha) na etapa "clone". Em vez disso, parece que você precisa fazer initum repo, configurar um remoteramo de rastreamento (você quer apenas um ramo?) E, em seguida, fetchesse ramo único, que parece muito ocupado com mais oportunidades de erros.

Edit: Para a etapa 'clone', veja esta resposta