使用--depth 1进行浅克隆是否安全，创建提交并再次提取更新？ [英] Is it safe to shallow clone with --depth 1, create commits, and pull updates again?

问题描述

中的 - 深度1 选项 git clone ：

创建一个克隆与历史截断到指定数量的修订。一个浅层存储库有一些限制（你不能从中克隆或取出，也不能从中推入或插入），但如果你只关心一个历史悠久的大型项目的最近历史，并且想要发送修补程序作为补丁。

但我已经成功完成了一个浅层克隆，提交了一些更改，并将这些更改推回到 （裸克隆）的起源。

它对我有意义 - 我的意思是为什么不？当克隆的HEAD在起源中是可识别的，并且我的承诺出现在此之上时，似乎没有理由。但手册中另有说明。

我喜欢浅克隆的想法 - 例如drupal core：我从7开始不需要知道drupal 4中发生了什么事情 - 但我不想在脚下自己拍摄。

那么浅层克隆是否安全，开发提交，再次拉动以跟上源自更新？ 解决方案

请注意，Git 1.9 / 2.0（2014年第1季度）已删除这个限制。

请参阅 commit 82fba2b ，来自NguyễnTháiNgọcDuy（ pclouds ）：

既然git支持从浅层克隆进行数据传输，那么这些限制不再是真的。

文档现在显示为：

   - 深度<深度> :: 
  

创建一个历史截断为指定修订版数的'浅'克隆。

源自提交，如 0d7d285 ， f2c681c 和 c29a7b8 ，它支持克隆，发送包/接收包与/从浅层克隆。

smart-http现在也支持浅取/克隆。

所有细节都在 shallow.c ：为 .git / shallow 选择新提交的8个步骤。

2015年6月更新： Git 2.5甚至允许获取单个提交！
$

b

2016年1月更新：Git 2.8（2016年的马赫）现在正式记录了获取最少的历史记录。

查看提交99487cf ， commit 9cfde9e （2015年12月30日）， commit 9cfde9e （2015年12月30日），提交bac5874 （2015年12月29日）和 Stephen P. Smith（``） 。
^{（由 Junio C Hamano - gitster - 在提交7e3e80a ，20 2016年1月）}

这是 Documentation / user-manual.txt

通过指定<<<< def_shallow_clone，shallow clone>>< / code> git-scm.com/docs/git-fetchrel =noreferrer> git-clone --depth 开关。

深度稍后可以通过 git-fetch --depth 开关，或者使用 - unshallow 恢复的完整历史记录。 $ b

在<<<< def_shallow_clone，浅度克隆>>< / code>内合并只要一个合并库是在最近的历史。

否则，它将像合并不相关的历史，并可能必须导致巨大的冲突。

此限制可能会使这样一个存储库不适合用于合并工作流程。






---

有关浅克隆更新过程的更多信息，请参阅 a href =https://stackoverflow.com/a/41369314/6309>如何更新git浅层克隆？。

---

正如理查德迈克尔所评论的那样：

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

和 OlleHärstedt增加了在评论中：

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

The --depth 1 option in git clone:

Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.

But I've successfully done a shallow clone, committed some changes and pushed those changes back to the (bare clone) origin.

It makes sense to me - I mean why not? when the cloned HEAD is identifiable in the origin, and my commit comes on top of this, there seems no reason. But the manual says otherwise.

I like the idea of shallow clone - e.g. of drupal core: there's no way I need to know what went on in drupal 4 when I've started from 7. - but I don't want to shoot myself in the foot.

So is it safe to shallow clone, develop commits in it, pull again to keep up with updates from origin?

解决方案

Note that Git 1.9/2.0 (Q1 2014) has removed that limitation.
See commit 82fba2b, from Nguyễn Thái Ngọc Duy (pclouds):

Now that git supports data transfer from or to a shallow clone, these limitations are not true anymore.

The documentation now reads:

--depth <depth>::

Create a 'shallow' clone with a history truncated to the specified number of revisions.

That stems from commits like 0d7d285, f2c681c, and c29a7b8 which support clone, send-pack /receive-pack with/from shallow clones.
smart-http now supports shallow fetch/clone too.

All the details are in "shallow.c: the 8 steps to select new commits for .git/shallow".

Update June 2015: Git 2.5 will even allow for fetching a single commit!
(Ultimate shallow case)

---

Update January 2016: Git 2.8 (Mach 2016) now documents officially the practice of getting a minimal history.
See commit 99487cf, commit 9cfde9e (30 Dec 2015), commit 9cfde9e (30 Dec 2015), commit bac5874 (29 Dec 2015), and commit 1de2e44 (28 Dec 2015) by Stephen P. Smith (``).
^{(Merged by Junio C Hamano -- gitster -- in commit 7e3e80a, 20 Jan 2016)}

This is "Documentation/user-manual.txt"

A <<def_shallow_clone,shallow clone>> is created by specifying the git-clone --depth switch.
The depth can later be changed with the git-fetch --depth switch, or full history restored with --unshallow.

Merging inside a <<def_shallow_clone,shallow clone>> will work as long as a merge base is in the recent history.
Otherwise, it will be like merging unrelated histories and may have to result in huge conflicts.
This limitation may make such a repository unsuitable to be used in merge based workflows.

---

For more on the shallow clone update process, see "How to update a git shallow clone?".

---

As commented by Richard Michael:

to backfill history: git pull --unshallow

And Olle Härstedt adds in the comments:

To backfill part of the history: git fetch --depth=100.

这篇关于使用--depth 1进行浅克隆是否安全，创建提交并再次提取更新？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！