我想如果检查出的版本是不一样的记录在树中的版本自动更新一个git子模块作为我们的编译系统的一部分时,它是不同步的,即中。自动更新子模块
目前我做git submodule status ‹path›
并检查所生成输出的第一个字符是空格(同步)或别的东西(-
对于未初始化,+
对于超出的同步提交,或U
对合并冲突)。
有一些便宜的(在执行时间方面)命令来获取这些信息?我是否可以比较两个适当选择的文件的时间戳以确定子模块是否需要更新?
我想如果检查出的版本是不一样的记录在树中的版本自动更新一个git子模块作为我们的编译系统的一部分时,它是不同步的,即中。自动更新子模块
目前我做git submodule status ‹path›
并检查所生成输出的第一个字符是空格(同步)或别的东西(-
对于未初始化,+
对于超出的同步提交,或U
对合并冲突)。
有一些便宜的(在执行时间方面)命令来获取这些信息?我是否可以比较两个适当选择的文件的时间戳以确定子模块是否需要更新?
我不知道这个回答您的问题(一个或多个),但它可能有助于获得你的最终目标:
git submodule update --checkout [<submodule>]
这将签出存储在树中的子模块的版本,除非已检出的子模块具有冲突的修改,在这种情况下它会中止。
你可以将其添加为post-checkout
钩来自动执行。
如果你喜欢住危险的是,你可以使用下面的重置子模块(一个或多个)之前结账,以免冲突检查出的新版本时。
git submodule foreach git reset --hard HEAD
git submodule foreach git clean -f
当然,这将消除您在子模块中所做的任何更改,请谨慎使用。
git submodule
命令是作为shell脚本实现的,虽然它的确请求git submodule--helper
的一些帮助。该relevant line手头的问题是这样的:
git diff-files --ignore-submodules=dirty --quiet -- "$sm_path"
这区分匹配从不同的一个(+
地位)提交(在git submodule status
空间)。有其他代码段落入之前并且用于detect U
conflicts(与help of git submodule--helper
)或-
uninitialized submodules。
在我的实验中,冲突的情况(即父级回购中的合并在子模块的使用承诺上有冲突的输入)也导致diff-files
命令的非零退出状态。不过,未初始化的存储库未被报告。所以我建议使用以下命令来检查子模块是否是最新的:
test -f "$sm_path/.git" -o -d "$sm_path/.git" && \
git diff-files --ignore-submodules=dirty --quiet -- "$sm_path"
检查选项'--cached'的帮助。 – Gregg
@Gregg你确定吗?用肠道的说法,“缓存”往往指的是分段区域。所以,我读了'--cached'标志为“不HEAD比较实际状态但上演的变化,而不是”下落之前,这甚至可能会更昂贵,因为它必须检查临时区域(通常是无一命中)回头比较HEAD。 – MvG
当文件在索引中时,已知的git中的哈希只需要检查它(只是散列)和最新的哈希。我不确定,所以这只是一个评论。 – Gregg