git浅克隆到特定的标记

我想克隆Linux内核回购，但只从版本3.0开始，因为内核回购是如此之大，它使我的版本控制工具运行速度更快，如果我可以做一个浅层克隆。我的问题的核心是：我怎么能告诉git的“n”值是--depth参数？我希望这会工作：git浅克隆到特定的标记

混帐克隆http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git --depth 3.0

感谢。

来源

2012-01-19 Chris H

另请参阅[如何从git存储库中删除旧的历史记录？]（http://stackoverflow.com/questions/4515580/how-do-i-remove-the-old-history-from-a- git-repository） – Alberto

不幸的是，--depth参数git clone只接受一个数字，即克隆存储库应该截断的修订版本号。

一个可能的解决方案是克隆整个存储库，然后截断其历史记录以保留v3.0之后的仅提交。这里是一个很好的操作方法： http://bogdan.org.ua/2011/03/28/how-to-truncate-git-history-sample-script-included.html

git checkout --orphan temp v3.0 
git commit -m "Truncated history" 
git rebase --onto temp v3.0 master 
git branch -D temp 
git gc

来源

2012-01-19 21:42:37 tomgi

这应该和我提供的解决方案一样好，但我也建议删除所有其他本地引用并运行我在解决方案中的清理步骤。没有这一点，回购将仍然包含完整的历史和额外的对象。这个回购大约有200万件物品悬挂在需要的地方。 – James

好注意事项，增加了 – tomgi

这个策略需要管理冲突的合并，并且根据合并的处理方式产生不是最终主数据的确切副本的风险。由于回购是如此之大，所以您不太可能手工合并，因此您可以将'-Xours'或'-Xtheirs'选项添加到rebase命令。我相信你会发现最终结果与主裁判的来源不同。 – James

完全了解一个解决方案，但不幸的是，git的克隆不会在您所请求的方式工作。参数--depth的数量不限于commits的revisions的数量。没有限制提交数量的克隆参数。在你的情况下，即使你知道只有最多10个版本差异的文件在v3.0和最新的HEAD之间有所变化，并且使用了--depth 10，你仍然可以获得大部分或整个回购历史记录。因为有些对象可能没有多达10个修订版本，并且您将从它们首次出现在回购库中的开始就获得它们的历史记录。

现在这里是怎么做的，你喜欢什么：你的问题的关键是，你需要V3.0和最近你最想要的参考值之间的提交。下面是我做的步骤来做到这一点：

git clone http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git --depth 10075 smaller_kernel_repo
cd smaller_kerenel_repo
确定V3.0的SHA git log --oneline v3.0^..v3.0
开始创建这个沙移植点（这是02f8c6aee8df3cdc935e9bdd4f2d020306035dbe）
echo "02f8c6aee8df3cdc935e9bdd4f2d020306035dbe" > .git/info/grafts
解决一些内核日志条目的问题：export GIT_AUTHOR_NAME="tmp"和 export GIT_COMMITTER_NAME="tmp"
有一个很好的警告有关手册页约git filter-branch按照移植点改写历史......所以让我们的滥用行为，现在运行git filter-branch和守株待兔...（和等待，等待）

现在，你需要清理一切：

git reflog expire --expire=now --all 
git repack -ad # Remove dangling objects from packfiles 
git prune  # Remove dangling loose objects

这个过程是费时，但不是很复杂。希望从长远来看，它一直能为你节省所有的时间。在这一点上，你将基本上是一个回购，修订历史从linux-stable.git回购只有v3.0起。就像在克隆上使用--depth一样，您对repo具有相同的限制，并且只能修改和发送已有历史记录中的修补程序。有办法解决..但它值得自己Q &答：

我正在测试出最后几个步骤自己，但git filter-branch操作仍在继续。我会在任何问题上更新这篇文章，但我会继续并发布它，以便您可以在此过程中开始使用，前提是您认为它可以接受。

更新问题

解决方法（致命：空的ident <>不允许的）。这个问题源于Linux repo提交历史中的问题。

更改git filter-branch命令：

git filter-branch --commit-filter ' 
    if [ "$GIT_AUTHOR_EMAIL" = "" ]; 
    then 
      GIT_AUTHOR_EMAIL="[email protected]"; 
      GIT_AUTHOR_NAME='tmp' 
      GIT_COMMITTER_NAME='Me' 
      GIT_COMMITTER_EMAIL='[email protected]' 
      git commit-tree "[email protected]"; 
    else 
      git commit-tree "[email protected]"; 
    fi '

来源

2012-01-19 21:59:24 James

我认为在这里严格区分* revision *和* commit *是过于复杂的事情。虽然我知道[形式差异]（http://stackoverflow.com/a/11792712/1127485），在'git clone --depth '的上下文中，修订的数量等于来自提示。 – sschuberth

的--depth参数似乎是唯一的数（即“指定的修订版数”），而不是一个标签。

可能的想法（待测试）：

你可以使用git describe但为了得到你目前的HEAD最新的标签，以及承诺之间的数量所述标签和HEAD。
如果“最近的标签”不是您的标签，只需重复该过程，从最新标签引用的提交开始，直到您找到您的标签（例如v3.0）。

如果您的标签可从当前的HEAD访问，那么所有这些提交编号的总和将会给予您深入的git clone命令。

来源

2012-01-19 22:45:12 VonC

如何将标签克隆到1的深度？

git clone --branch mytag0.1 --depth 1 https://example.com/my/repo.git

来源

2016-08-21 19:12:23 n8henrie

这不是**接受的答案？ – tftd

有人谁已经拥有了克隆此命令将获得当前分支的末端和标签5.6之间提交的数目：

$ git rev-list HEAD ^5.6 --count 
407

我发现这个项目实施使用GitHub API的rev-list： https://github.com/cjlarose/github-rev-list

rev-list上非常冗长的手册页表明幕后有很多事情要做。有许多不同的路径可能会通过分支和合并进行计数提交。（？）对于这种使用情况虽然这大概可以忽略不计

来源

2017-12-08 18:44:21

为了使@ n8henrie回答更完整一点，你可以添加--single-branch选项，如：

git clone --single-branch --branch mytag0.1 --depth 1 https://example.com/my/repo.git

在这你只能得到与这个特定标签相关的存储库对象，在我的经验中，在许多情况下，它占用了相当多的空间。从git-clone docs：

- [无糖]单分支

克隆仅历史导致单个分支的前端，或者由--branch选项或主支路远程的HEAD点指定在。进一步提取到生成的存储库中将只会更新分支的远程跟踪分支，此选项用于初始克隆。如果在制作--single-branch克隆时远程的HEAD未指向任何分支，则不会创建远程跟踪分支。

额外的注意事项：如果你从另一个文件夹在同一台计算机上克隆一个本地回购，有必要使用file://协议提及，而不是仅指定文件夹名称，以它。

来源

2018-03-07 12:27:38 JotaBe

git浅克隆到特定的标记

回答

相关问题