为什么拉取请求和获取它的可能性之间存在延迟（在存储中）？答案

【问题标题】：Why is there a delay between a pull request and the possibility to fetch it (in stash)?为什么拉取请求和获取它的可能性之间存在延迟（在存储中）？
【发布时间】：2015-10-06 03:53:35
【问题描述】：

我正在尝试 Stash，但我观察到一些我无法理解的东西：

我推送了一个新分支；
我创建了一个拉取请求（来自浏览器）；

那我正在尝试做：

$ git fetch origin +refs/pull-requests/*:refs/remotes/origin/pr/* --dry-run

有时，它会立即工作，但有时，拉取请求仅在长时间延迟（30 分钟左右）后才会显示。

stash是本地安装的，所以延迟不是来自网络，其他交互还可以。

【问题讨论】：

标签： git pull-request bitbucket-server git-fetch

【解决方案1】：

Pull 请求引用是根据人们在 UI 中查看差异或某些其他操作来延迟计算的。这样做是出于性能原因，并且您获取的 refs 不是 Stash API 的正式一部分。这是我们正在考虑更改的内容，购买时我们需要注意性能影响。

我可以问一下您要对理论上的合并参考做什么吗？也许有另一种方法。

（我是 Stash 的产品经理）

【讨论】：

感谢您的解释。这让我快疯了。我首先在 Jenkins 中观察到这种奇怪的行为，它能够看到有一个新的拉取请求，但无法获取正确的分支......所以，为了让它工作，我们需要在之后“玩”UI公关创作？
理想情况下，只需获取并构建源分支。虽然可以按照您的建议构建有效的合并，但如果目标分支完全移动，所有结果的相关性都会变得不那么相关，除非您不断为任一分支尖端移动而重建。
我想获取并构建 /from 部分的拉取请求（不是 /merge ），即源分支。但我不能在分支本身上这样做，因为它通常来自另一个我不需要许可的存储库。
啊，我明白了。答案在这种情况下仍然适用，而且我们至少希望改进这一点。
同时来自开发人员的一个建议：您可以编写一个插件来监听 PullRequestRescopedEvent，检测 from ref 何时移动，并调用 PullRequestService.canMerge 这将确保 from ref 始终是最新的