为什么“ git clone”不采用refspec？

Question

看来，许多人已经开始用git clone组合代替git init && git fetch。这似乎很愚蠢，不幸的是，像Jenkins这样的工具无法为您做到这一点。那么，为什么git clone不采用refspec，就像git
fetch一样？

具体来说，如果您希望在Jenkins上运行gerrit触发的构建任务，则需要确保工作空间存在，否则jenkins将无法检出包含gerrit更改的修订。这是因为gerrit使用的引用路径不在git克隆获取的引用路径中。

Answer 1

请指定gerrit使用的refname是什么，克隆后将丢失。并会简单地git clone --origin <gerrit-suitable- origin-name>解决问题吗？

现在是长版。您的问题可能是两个问题加在一起。为什么对和有好处git init，为什么在初次克隆存储库时没有办法方便地过滤refspec？git remote add``git fetch

refspecs- 克隆初始化存储库后，该命令的remote-refspec行为是在.gitconfig中添加概述提取指令的默认部分：

[remote "origin"]
url = ssh://host/your.git
fetch = +refs/heads/*:refs/remotes/origin/*

这些是很好的默认设置，提供的refspec用于从远程获取所有内容。如果您需要更改refspec，则只需编辑文件即可手动进行。例如，

[remote "origin"]
url = ssh://host/your.git
fetch = +refs/heads/atari:refs/remotes/origin/atari
fetch = +refs/heads/vertigo:refs/remotes/origin/vertigo

编辑后，获取将仅涉及来自原始远程服务器的atari和vertigo分支master，例如，通常存在的远程分支以及可能存在于远程数据库上的所有其他分支将被忽略。当然，这类似于git fetch在命令行上提供refspec的选项。

总体而言，这不是必须的，我认为这不是一个干净的设计，因为它能够在git clone命令行上预先支持多个初始refspecs，其唯一目的是将它们放在.gitconfig中。您甚至可以通过运行git clone然后sed在.gitconfig文件上编写几乎相同的脚本。在给定许多可能的refspec的情况下，在克隆时决定要结帐的初始分支也是有问题的。

init over clone- 假设我们避免讨论更高级的git clone设置，例如，利用--reference，浅深度--depth或创建裸仓库，init-add-
fetch和clone之间的区别对于您的日常工作来说是很小的。

纯克隆仅复制现有的存储库，并将“源”设置为创建源的远程目录。这带来了一些小麻烦-
强制您使用“原始”远程，创建远程跟踪分支，设置初始分支以及检出HEAD。但是，如果您从开始做起，git init那么您的掌控力会稍微提高一些。您可以开始手动添加遥控器并获取特定分支，而无需检出任何内容。

请注意，尽管git clone行为的许多方面都可以通过命令行开关来控制-也许git init只是偏爱它们的开发人员还不知道它们吗？问题中没有足够的信息来决定。与其他方法相比，git clone可以节省一些键入时间，避免出现宇宙热死并设置合理的上游默认值，例如拥有一个跟踪分支。我投票支持克隆。