子模块更新时会调用哪些 githook?
情况是这样的。我有一个包含多个子模块的 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这应该可以作为父存储库上的
更新后挂钩
:您需要监视 .gitmodules 文件中的任何更改,以便检测该文件中的任何更改(表明父存储库的另一个克隆已更改子模块并在父存储库中提交了新引用)回购)。
然后您可以:
git submodule update --recursive
)但这假设是父存储库的克隆已修改为引用子模块的新提交。
如果子模块独立于任何父存储库进行更新,则在检出/更新父存储库时,相同的
post-update
挂钩(仍在父存储库上)需要:您可以在每个子模块上设置更新后挂钩,但是当您添加或删除时,上述方法可以更好地扩展来自父存储库的子模块,因为它将检测过程集中在一处(父存储库的
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:
git submodule update --recursive
)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: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).