[英]Is it safe to shallow clone with --depth 1, create commits, and pull updates again?
The --depth 1
option in git clone
: git clone
的--depth 1
选项:
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.
当克隆的 HEAD 在源中可识别,并且我的提交位于此之上时,似乎没有任何理由。 But the manual says otherwise.
但手册上另有说明。
I like the idea of shallow clone - eg 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.我喜欢浅层克隆的想法 - 例如 drupal 核心:当我从 7 开始时,我没有办法知道在 drupal 4 中发生了什么。 - 但我不想用脚射击自己。
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.请注意,Git 1.9/2.0(2014 年第一季度)已删除该限制。
See commit 82fba2b , from Nguyễn Thái Ngọc Duy ( pclouds
) :请参阅来自Nguyễn Thái Ngọc Duy (
pclouds
) 的提交 82fba2b :
Now that git supports data transfer from or to a shallow clone, these limitations are not true anymore.
现在 git 支持从浅层克隆或向浅层克隆传输数据,这些限制不再成立。
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.这源于诸如0d7d285 、 f2c681c和c29a7b8 之类的提交,它们支持克隆、使用/来自浅层克隆的发送包/接收包。
smart-http now supports shallow fetch/clone too . smart-http 现在也支持浅取/克隆。
All the details are in " shallow.c
: the 8 steps to select new commits for .git/shallow
".所有细节都在“
shallow.c
:为.git/shallow
选择新提交的 8 个步骤”中。
Update June 2015: Git 2.5 will even allow for fetching a single commit ! 2015 年 6 月更新: Git 2.5 甚至允许获取单个提交!
(Ultimate shallow case) (终极浅表)
Update January 2016: Git 2.8 (Mach 2016) now documents officially the practice of getting a minimal history. 2016 年 1 月更新:Git 2.8(2016 年马赫数)现在正式记录了获取最小历史记录的做法。
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 (``) .请参阅提交 99487cf 、 提交 9cfde9e (2015 年 12 月 30 日)、 提交 9cfde9e (2015 年 12 月 30 日)、 提交 bac5874 (2015 年 12 月 29 日)和提交 1de2e44 (2015 年 12 月 28 日)由Stephen P. Smith (``) 提交。
(Merged by Junio C Hamano -- gitster
-- in commit 7e3e80a , 20 Jan 2016) (由Junio C
gitster
合并-- gitster
-- in commit 7e3e80a ,2016 年 1 月 20 日)
This is " Documentation/user-manual.txt
"这是“
Documentation/user-manual.txt
”
A
<<def_shallow_clone,shallow clone>>
is created by specifying thegit-clone --depth
switch.<<def_shallow_clone,shallow clone>>
是通过指定git-clone --depth
开关创建的。
The depth can later be changed with thegit-fetch --depth
switch, or full history restored with--unshallow
.稍后可以使用
git-fetch --depth
开关更改深度,或者使用--unshallow
恢复完整历史记录。Merging inside a
<<def_shallow_clone,shallow clone>>
will work as long as a merge base is in the recent history.只要合并基础在最近的历史记录中,就可以在
<<def_shallow_clone,shallow clone>>
内部合并。
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.这种限制可能使这样的存储库不适合在基于合并的工作流中使用。
Update 2020: 2020 年更新:
git fetch --shallow-exclude=
to prevent fetching all history git fetch --shallow-exclude=
以防止获取所有历史记录git fetch --shallow-since=
to prevent fetching old commits. git fetch --shallow-since=
以防止获取旧提交。 For more on the shallow clone update process, see " How to update a git shallow clone? ".有关浅克隆更新过程的更多信息,请参阅“如何更新 git 浅克隆? ”。
As commented by Richard Michael :正如理查德迈克尔评论的那样:
to backfill history:
git pull --unshallow
回填历史:
git pull --unshallow
And Olle Härstedt adds in the comments : Olle Härstedt 在评论中补充道:
To backfill part of the history:
git fetch --depth=100
.回填部分历史记录:
git fetch --depth=100
。
See some of the answers to my similar question why-cant-i-push-from-a-shallow-clone and the link to the recent thread on the git list.查看我的类似问题为什么-cant-i-push-from-a-shallow-clone 的一些答案以及指向 git 列表上最近线程的链接。
Ultimately, the 'depth' measurement isn't consistent between repos, because they measure from their individual HEADs, rather than (a) your Head, or (b) the commit(s) you cloned/fetched, or (c) something else you had in mind.最终,repos 之间的“深度”测量不一致,因为它们从各自的 HEAD 进行测量,而不是 (a) 您的 Head,或 (b) 您克隆/获取的提交,或 (c) 其他东西你想到了。
The hard bit is getting one's Use Case right (ie self-consistent), so that distributed, and therefore probably divergent repos will still work happily together.难点是让一个用例正确(即自洽),这样分布式的,因此可能不同的存储库仍然可以愉快地一起工作。
It does look like the checkout --orphan
is the right 'set-up' stage, but still lacks clean (ie a simple understandable one line command) guidance on the "clone" step.看起来
checkout --orphan
是正确的“设置”阶段,但仍然缺乏关于“克隆”步骤的清晰(即简单易懂的单行命令)指导。 Rather it looks like you have to init
a repo, set up a remote
tracking branch (you do want the one branch only?), and then fetch
that single branch, which feels long winded with more opportunity for mistakes.相反,看起来您必须
init
一个 repo,设置一个remote
跟踪分支(您确实只想要一个分支?),然后fetch
该单个分支,这感觉很长,有更多的错误机会。
Edit: For the 'clone' step see this answer编辑:对于“克隆”步骤,请参阅此答案
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.