子模块更新时会调用哪些 githook?

发布于 2024-11-04 11:47:58 字数 287 浏览 0 评论 0原文

情况是这样的。我有一个包含多个子模块的 git 存储库。顶级目录和所有子模块都包含 Visual Studio 2010 解决方案。

顶级存储库取决于子模块是否是最新的,并且子模块每次更新时都需要重新构建。由于有任意数量的子模块,我想做的是在 git 中创建某种更新后挂钩来编译刚刚更新的子模块。

所以我的问题是:更新子模块时会调用哪些钩子(如果有)?看来结账后可能是我想要的,但我不确定。

我们使用 TortoiseGit 和 Git for Windows(msysgit) 作为后端,如果这有什么区别的话。

So here's the situation. I have a git repository with multiple submodules. Both the top level directory and all of the submodules contain Visual Studio 2010 solutions.

The top level repository depends on the submodules being up to date and the submodules need to be rebuilt every time they are updated. What I want to do, since there are an arbitrary number of submodules, is to make some kind of post-update hook in git to compile the submodule that was just updated.

So my question is this: what hooks (if any) are called when a submodule is updated? It seems like post-checkout might be what I want but I'm not sure.

We're using TortoiseGit with Git for Windows(msysgit) as the backend if that makes a difference.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

无力看清 2024-11-11 11:47:58

这应该可以作为存储库上的更新后挂钩
您需要监视 .gitmodules 文件中的任何更改,以便检测该文件中的任何更改(表明父存储库的另一个克隆已更改子模块并在父存储库中提交了新引用)回购)。
然后您可以:

  • 检测哪些子模块已更改
  • 决定是否要使子模块保持最新(git submodule update --recursive
  • 重新编译相关子模块

但这假设是父存储库的克隆已修改为引用子模块的新提交。

如果子模块独立于任何父存储库进行更新,则在检出/更新父存储库时,相同的 post-update 挂钩(仍在父存储库上)需要:

  • 进入每个子模块并执行提取
  • 检查,如果提取引入任何新的提交,
  • 决定是否要使子模块保持最新,这次通过从子模块中提取更改
  • 返回到父存储库并提交,以便注册新的更改子模块的 SHA1
  • 重新编译需要 git pull 的子模块(即已更改的子模块)

您可以在每个子模块上设置更新后挂钩,但是当您添加或删除时,上述方法可以更好地扩展来自父存储库的子模块,因为它将检测过程集中在一处(父存储库的 post-update 挂钩)。

That should work, as a post-update hook on the parent repo:
You would need to monitor the .gitmodules file for any changes, in order to detect any changes in that file (indicating that another clone of your parent repo has changed a submodule and committed the new reference in the parent repo).
Then you can:

  • detect which submodules has changed
  • decide if you want to bring your submodules up-to-date (git submodule update --recursive)
  • recompile the relevant submodules

But that supposes a clone of the parent repo has been modified to reference new commits of your submodules.

If you submodules are updated independently of any parent repo, then the same post-update hook (still on the parent repo), on a checkout/update of the parent repo, needs to:

  • go in each submodules and perform a fetch
  • check if the fetch introduces any new commits
  • decide if you want to bring your submodules up-to-date, this time by pulling the changes from the submodules
  • go back in the parent repo and commit, in order to register the new SHA1 of the changes submodules
  • recompiles the ones that needed a git pull (i.e. that has changed)

You could setup post-update hook on each of the submodules, but the above approach scales better when you add or remove submodules from your parent repo, as it centralizes the detection process in one place (the post-update hook of the parent repo).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文