相关疑难解决方法(0)

我想自动将后接收挂钩中的提交从我们LAN上的中央仓库推送到云中的另一个中央仓库.LAN repo使用git clone --mirror git@cloud:/path/to/repo或等效命令创建.

因为提交的文件相对于我们的上游带宽会很大,所以完全有可能发生这样的事情:

1. Alice启动了对LAN repo的推送.
2. 在收件后挂钩运行时,Bill从LAN repo中拉出来.
   • 局域网回购正在推动云回购.
   • 这也意味着Bill的本地仓库包含Alice推送的提交.通过测试确认.
3. 比尔开始推动局域网回购.
   • 比尔的推动是爱丽丝推进的快速前进,因此局域网回购将接受它.

当LAN repo的后接收挂钩执行时,将从LAN repo到cloud repo的第二次推送开始,并且两者将同时运行.

我并不担心git对象.最糟糕的情况是两个推送都会从Alice的推送中上传所有对象,但就我理解git的内部结构而言,这应该无关紧要.

我很担心裁判.假设Alice推动使用更慢的连接,因此Bill的推送首先完成.假设数据包丢失或其他原因导致挂钩从局域网仓库推送到Bill的推送云完成,然后钩子从局域网回购推送到Alice的推送云.如果Alice和Bill都在推动主分支并且Bill的推送首先完成,那么主要参与者将在云回购中做什么？我希望它成为比尔的头,因为那是后来的推动,但我担心这将是爱丽丝的头.

进一步澄清:

我意识到,如果比尔从他的机器推送到局域网回购完成,那么爱丽丝从她的机器到局域网回购的推动将会失败.在这种情况下,LAN repo的post-receive挂钩将不会执行.此外,请假设没有人会进行强制推送,因此如果后续接收挂钩在LAN repo上运行,则所有参考更改都是快进的.