使用--depth 1进行浅层克隆是否安全,创建提交并再次提取更新?

时间:2011-08-04 13:02:42

标签: performance git git-clone

git clone中的--depth 1选项:

  

创建一个克隆,其历史记录被截断为指定的修订版本数。浅存储库有许多限制(您不能克隆或获取它,也不能从中推送或插入它),但如果您只对历史悠久的大型项目的近期历史感兴趣并且希望将修补程序作为补丁发送。

但我已经成功完成了一个浅层克隆,提交了一些更改并将这些更改推回到(裸克隆)原点。

这对我有意义 - 我的意思是为什么不呢?当克隆的HEAD在原点可识别时,我的提交就在此之上,似乎没有理由。但是手册说不然。

我喜欢浅层克隆的想法 - 例如drupal核心:当我从7开始的时候,我无法知道drupal 4中发生了什么。 - 但我不想用脚射击自己。

浅层克隆是否安全,在其中开发提交,再次拉动以跟上来自原点的更新?

2 个答案:

答案 0 :(得分:272)

请注意,Git 1.9 / 2.0(2014年第一季度)已删除该限制 请参阅commit 82fba2b中的Nguyễn Thái Ngọc Duy (pclouds)

  

现在git支持从浅层克隆到浅层克隆的数据传输,这些限制不再适用。

documentation now reads

--depth <depth>::
  

创建一个“浅”克隆,其历史记录被截断为指定的修订版本。

这源于0d7d285f2c681cc29a7b8这样的提交,它们支持带有/来自浅克隆的clone,send-pack / receive-pack。
smart-http now supports shallow fetch/clone too

所有细节都在“shallow.c: the 8 steps to select new commits for .git/shallow”中。

2015年6月更新:Git 2.5 will even allow for fetching a single commit!
(终极浅层案例)


2016年1月更新:Git 2.8(2016年马赫)现在正式记录了获得最小历史的做法 请参阅commit 99487cfcommit 9cfde9e(2015年12月30日),commit 9cfde9e(2015年12月30日),commit bac5874(2015年12月29日)和commit 1de2e44(2015年12月28日) )Stephen P. Smith (``) (由Junio C Hamano -- gitster --合并于commit 7e3e80a,2016年1月20日)

这是“Documentation/user-manual.txt

  

通过指定git-clone --depth开关创建<<def_shallow_clone,shallow clone>>   稍后可以使用git-fetch --depth开关更改深度,或使用--unshallow恢复完整历史记录。

     

只要合并基础在最近的历史记录中,在<<def_shallow_clone,shallow clone>>内部合并就会起作用   否则,它就像合并不相关的历史,可能会导致巨大的冲突   此限制可能使此类存储库不适合在基于合并的工作流中使用。


有关浅层克隆更新过程的详细信息,请参阅“How to update a git shallow clone?”。


Richard Michael评论:

  

回填历史记录: git pull --unshallow

Olle Härstedt添加了in the comments

  

要回填历史记录的部分 git fetch --depth=100

答案 1 :(得分:7)

查看我的类似问题why-cant-i-push-from-a-shallow-clone的一些答案以及git列表中最近线程的链接。

最终,repos之间的'深度'测量值并不一致,因为它们是从他们各自的HEAD中测量的,而不是(a)你的头,或者(b)你克隆/获取的提交,或者(c) )你想到的其他东西。

硬比特正在使用一个用例(即自我一致),因此分布式的,因此可能不同的回购仍然可以愉快地一起工作。

看起来checkout --orphan是正确的'设置'阶段,但仍然缺乏关于“克隆”步骤的干净(即简单易懂的一行命令)指导。相反,看起来你必须init一个回购,设置一个remote跟踪分支(你只想要一个分支吗?),然后fetch那个感觉很长的单个分支为错误提供更多机会。

编辑:有关“克隆”步骤,请参阅this answer