为什么“git clone”不能使用refspec？

看来，很多人已经去替换git clone与组合git init && git fetch。这看起来很愚蠢，不幸的是Jenkins这样的工具不会为你做。那么为什么git clone不会采用refspec，就像git fetch所做的一样？为什么“git clone”不能使用refspec？

具体而言，如果您希望在Jenkins上运行gerrit触发的构建任务，则需要确保工作区存在，否则jenkins将无法检出包含gerrit更改的修订版。这是因为gerrit使用的是不在git clone获取的ref路径。

来源

2013-12-17 Christian Goetze

答案可能取决于人们为什么选择'git clone''git init && git fetch'组合。 –

解释问题中的用例。 –

请指定gerrit使用的refname，克隆后缺少的名称。而只需git clone --origin <gerrit-suitable-origin-name>解决问题？

现在的长版。你的问题可能是两个问题的结合。为什么git init，git remote add和git fetch这是有利的，为什么在最初克隆存储库时没有办法方便地过滤refspecs？

refspecs - 克隆初始化回购后，该命令的远程的Refspec行为是默认的部分添加到概述获取规格的的.gitconfig：

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

这些都是很好的和理智默认值，并且提供的refspecs用于从远程获取所有内容。如果您需要更改refspecs，只需编辑文件即可手动完成。例如，

[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的refspecs的选项。

总体而言，它并不是一个简单的设计，它可以在git clone命令行上支持多个初始参考，仅用于将它们放置在.gitconfig中。通过在.gitconfig文件上运行git clone，然后sed，您甚至可以编写相同的脚本。当克隆给出许多可能的参考规格时，决定哪个是最初的分支结账也是有问题的。

初始化过克隆 - 假设我们避免讨论更先进的git clone设置，如利用--reference，浅深度--depth，或创建裸回购，区分初始化加取和克隆是您非常轻微日常生活。

普通克隆只是复制一个现有的存储库，并将设置“origin”作为创建源的远程设备。这带来一些轻微的烦恼 - “原点”远程被强制在你身上，远程追踪分支被创建，初始分支被设置，HEAD被检出。但是，如果你从git init开始，你的控制力就会稍微好一些。您可以开始手动添加遥控器并获取特定的分支而不检查任何东西。

请注意，git clone行为的许多方面可以通过命令行开关控制 - 所以也许开发人员更喜欢git init只是不知道他们？问题中没有足够的信息来决定。与其他选项相比，git clone为您节省了一些打字费用，避免了宇宙的热量死亡，并设置了合理的上游默认值 - 例如掌握跟踪分支。我投票赞成克隆。

来源

2013-12-19 10:18:02 mockinterface

我想这是一个公平的答案，但与git中的许多事情一样，它诱使编码人员犯错误。我现在已经看到了几个使用以下错误逻辑的代码：'如果存在repo，则git fetch else git clone fi'。正确的逻辑需要'如果不回购 - 然后git克隆fi; git fetch'。我认为git设计会导致这个错误。哦，gerrit使用refs/changes /为/ /，所以它完全没有标准，并且打破了jenkins关于克隆的假设，这就是问题的原因。 –

Git为您提供了一系列可供选择的选项，并且我认为这是一个很好且功能强大的选项。所以我不同意这样一个事实，即任何使用git方式都会诱发开发者犯错误。处理变异性和错误的一种方法是制定一个让每个人都遵守的程序，但是不能强制执行这个程序。 – mockinterface

对于gerrit部分，克隆/初始化后，将映射fetch = + refs/changes/for/*：refs/remotes/origin/*（正如我的答案中所述）帮助jenkins？它应该规范名称。 – mockinterface

git clone可以经由通用--configoption采取refspec：

设置在新创建的储存库中的配置变量;这会在储存库初始化之后立即生效，但是在获取远程历史记录或检出任何文件之前。 [...]这使得它很安全，例如，向原始远程添加额外的提取参数。

例子：

git clone -c remote.origin.fetch=+refs/changes/*:refs/remotes/origin/changes/* https://gerrit.googlesource.com/git-repo

然而，我才意识到如预期的我git version 2.12.2.windows.2为changes裁判是不是克隆时候，确实牵强这不起作用。它得到正确添加到.git/config，但我需要通过

cd git-repo 
git fetch

编辑克隆后手动获取它：这原来是known bug。

来源

2017-05-03 12:05:20 sschuberth

为什么“git clone”不能使用refspec？

回答

相关问题