为什么"git clone"不接受refspec？

Question

似乎很多人已经git clone用组合替换了git init && git fetch.这看起来相当愚蠢,不幸的是像詹金斯这样的工具不会为你做那件事.那么为什么git clone不采用refspec,就像git fetch一样呢？

具体来说,如果您希望在Jenkins上运行gerrit触发的构建任务,则需要确保工作区存在,否则jenkins将无法签出包含gerrit更改的修订.这是因为gerrit使用的ref路径不属于git clone提取的路径.

Answer 1

git clone 可以采取refspec通过通用--config 选项:

在新创建的存储库中设置配置变量; 这在初始化存储库之后,但在获取远程历史记录或检出任何文件之前立即生效.[...]这样可以安全地,例如,向源远程添加额外的fetch 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在克隆时没有真正获取ref.它被正确添加到了.git/config,但我需要在克隆之后手动获取它

cd git-repo
git fetch

编辑:这结果是已知的错误.

Answer 2

请指定 gerrit 使用的 refname 是什么，在克隆之后缺少该名称。并且会简单地git clone --origin <gerrit-suitable-origin-name>解决问题？

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

refspecs - clone 初始化 repo 后，该命令的 remote-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命令行上预先支持多个初始refspecs，其唯一目的是将它们放在 .gitconfig 中。您甚至可以通过运行git clone然后sed在 .gitconfig 文件上编写几乎相同的脚本。考虑到许多可能的参考规范，在克隆时决定哪个是要检出的初始分支也是有问题的。

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

普通克隆只是复制现有的存储库并将“源”设置为创建源的远程。这带来了一些小烦恼——“origin”远程被强加给你，远程跟踪分支被创建，初始分支被设置，并且 HEAD 被检出。然而，如果你从你开始，git init你会稍微控制一些。您可以开始手动添加遥控器并获取特定分支而无需检查任何内容。

请注意，git clone行为的许多方面都可以由命令行开关控制——所以也许喜欢的开发人员git init不知道它们？问题中没有足够的信息来决定。与替代方案相比，git clone节省了一些打字的时间，避免了宇宙的热死亡，并设置了合理的上游默认值 - 例如拥有一个跟踪分支。我投克隆人一票。