【问题标题】:How to add submodule correctly with non-standart refspec?如何使用非标准 refspec 正确添加子模块?
【发布时间】:2012-09-24 03:17:14
【问题描述】:

我们正在使用 Gerrit 进行代码审查。 Gerrit 将审查过的代码存储在非标准参考路径 - refs/changes 中。 因此,对提交的引用看起来像 refs/changes/95/295/2 。 我想将 Gerrit 中的项目作为子模块添加到我的超级项目中。

我可以分两步完成:

  • 将我的项目作为子模块添加到 master 当前指向的 commit-hash
  • 执行git fetch origin refs/changes/95/295/2 && git checkout FETCH_HEAD 并提交更改。

但是当我尝试检查我的超级项目并执行 git update --init 时,git 报告失败。 Git在子模块中找不到hash,因为git默认没有看到refs/changes中的引用,也不会从中下载对象。

好的,我可以通过在我的 gerrit repo 中执行 git config --add remote.origin.fetch '+refs/changes/*:refs/remotes/origin/changes/*' 来修复它,然后重试子模块更新,就可以了。

问题是,我可以像通常的工作流程那样一步完成“添加”和“初始化/更新”子模块吗?基本上,我需要在“clone”/“pull”/“submodule add”/“sumbodule update”执行开始之前设置 refspec。

【问题讨论】:

  • 最后我在 git 上实现了我自己的抽象级别。它有效,而且很丑陋。我不高兴,但也许我可以修复 git 行为,为 Linus 提供补丁。

标签: git gerrit git-submodules refspec


【解决方案1】:

您不想通过指向 refs/changes 的提交的子模块来推动更改。 Gerrit 在审查期间将代码存储在那里,但在审查完成并提交更改后,可以从标准 refs/heads/ 访问它。您的子模块应指向 refs/heads/BRANCH_NAME 中已审核和提交的代码。

【讨论】:

  • 不,我想这样做。我需要使用新推送的更改执行构建,并且可以将其构建为超级项目中的子模块。
  • 在这种情况下,我知道的唯一选择是按照您的指示添加远程获取规范。这就是我们的构建机器人在我的工作中所做的工作,以验证未合并的更改。
  • 是的,我可以添加 fetch-spec,但这将是 submodule update --init 失败后的附加步骤。我可以做到,但这很难看,恕我直言。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-05-19
  • 1970-01-01
  • 1970-01-01
  • 2021-12-03
  • 2020-07-03
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多