Git --force-with-lease with + in branch (refspec)

Question

在当前的 Git 上，git push --force-with-lease origin +somebranch 和 git push --force-with-lease origin somebranch 之间是否存在实质性差异？ > 和 git push origin +somebranch(没有加号)？这三个似乎都在做同样的事情。

我试图寻找文档。我试着查看 refspec in documentation ，但我不知道是否存在差异，如果存在差异，例如，当我喜欢通过 git pull --rebase origin master pull 到工作分支时，默认情况下应该更喜欢哪个。

Answer 1

这是个好问题；文档有点模棱两可，而且来源非常困惑(强制标志的实际应用广泛分散)。

一个答案就足够清楚了。这是the git push documentation说，加上我的黑体字:

--[no-]force-with-lease
--force-with-lease=<refname>
--force-with-lease=<refname>:<expect>

      Usually, "git push" refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it.

      This option overrides this restriction if the current value of the remote ref is the expected value. "git push" fails otherwise.

      Imagine that you have to rebase what you have already published. You will have to bypass the "must fast-forward" rule in order to replace the history you originally published with the rebased history. If somebody else built on top of your original history while you are rebasing, the tip of the branch at the remote may advance with her commit, and blindly pushing with --force will lose her work.

      This option allows you to say that you expect the history you are updating is what you rebased and want to replace. If the remote ref still points at the commit you specified, you can be sure that no other people did anything to the ref. It is like taking a "lease" on the ref without explicitly locking it, and the remote ref is updated only if the "lease" is still valid.

      --force-with-lease alone, without specifying the details, will protect all remote refs that are going to be updated by requiring their current value to be the same as the remote-tracking branch we have for them.

      --force-with-lease=<refname>, without specifying the expected value, will protect the named ref (alone), if it is going to be updated, by requiring its current value to be the same as the remote-tracking branch we have for it.

      --force-with-lease=<refname>:<expect> will protect the named ref (alone), if it is going to be updated, by requiring its current value to be the same as the specified value (which is allowed to be different from the remote-tracking branch we have for the refname, or we do not even have to have such a remote-tracking branch when this form is used).

      Note that all forms other than --force-with-lease=<refname>:<expect> that specifies the expected current value of the ref explicitly are still experimental and their semantics may change as we gain experience with this feature.

      "--no-force-with-lease" will cancel all the previous --force-with-lease on the command line.

因此，如果传输支持比较和交换选项¹，并且您已编写--force-with-lease而不是 --no-force-with-lease ，然后所有更新，无论是否强制，都使用租用模式。

--no-force-with-lease , 但是，清除存储的 push_cas_option结构，当这些存储的值应用于每个 refspec 时，对我来说并不是很明显。

使用显式 <refname>也清楚地只保护一个引用，不管为它设置任何强制标志。

我也不清楚当底层传输缺乏对比较和交换的支持时会发生什么。幸运的是，GitHub 的 Git 服务器支持它，如果您专门指的是 GitHub，这只会分散您的注意力。

---

¹在内部，Git 源代码使用宏 CAS_OPT_NAME : force-with-lease 的功能受到现代 CPU 的比较和交换指令的启发，该指令以原子方式测试某个变量 ² 是否设置为预测值，如果是否将其替换为新值所以，并以某种形式返回在变量中找到的实际值。

如果 CPU 体系结构使用条件代码，这可能会设置条件代码，但在大多数情况下，如果不是所有情况，您都会获得旧值，以便您可以在适当的情况下重试比较和交换。例如，要实现原子加一，您可以循环使用:load r1,(r0); label: add r1,1,r2; cas r1,r2,(r0); bne label ;实现位 2 的原子测试和设置:load r1,(r0); label: or r1,4,r2; cas r1,r2,(r0); bne label ;等等。例如，此方法用于 Intel Pentium 和 SPARC 系统。

有些 CPU 使用缓存机制代替。如果最靠近 CPU 的缓存具有共享模式与独占模式(例如，MESI 或 MOESI)，我们可以使用“加载链接”或“加载锁定”指令，然后是“条件存储”指令。仅当缓存行仍由当前 CPU 独占时，条件存储才会成功。在这种情况下，我们必须重新进行变量的初始锁定加载，我们的循环看起来更像:label: ll r1,(r0); add 1,r1; sc (r0),r1; bne label .这用于 PowerPC 和 MIPS 架构。

²通常，所讨论的变量是内存位置，通常具有对齐约束，即使在名义上支持未对齐内存的 CPU 上也是如此。例如，在 Intel Haswell 上，比较和交换 8 字节指令将在 4 字节边界上运行完成，但它实际上不是原子的。当一位同事的内存分配器仅提供 4 字节对齐时，我发现了这一点。 :-)