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，但是我不知道是否存在差異，如果是這樣的話，當我想通過git pull --rebase origin master拉到工作分支時，默認情況下應該更喜歡哪個，例如。

Answer 1

這是一個很好的問題; 文檔有點模糊，源代碼非常混亂（強制標志的實際應用廣泛分散）。

一個答案很清楚。 這是git push文檔所說的內容，我的粗體添加了：

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

通常，“git push”拒絕更新遠程ref，該遠程ref不是用於覆蓋它的本地ref的祖先。

如果遠程ref的當前值是預期值，則此選項將覆蓋此限制。 “git push”否則失敗。

想象一下，你必須改變你已發表的內容。 您必須繞過“必須快進”規則才能將最初發布的歷史記錄替換為重新定位的歷史記錄。 如果其他人在您重新定位時建立在原始歷史之上，那么遠程分支的提示可能會隨着她的提交而提前，盲目推動--force將失去她的工作。

此選項允許您說您希望更新的歷史記錄是您重新定義和想要替換的內容。 如果遠程引用仍然指向您指定的提交，您可以確定沒有其他人對引用做任何事情。 這就像在ref上接受“租約”而沒有明確地鎖定它，並且僅當“lease”仍然有效時才更新遠程ref。

--force-with-lease單獨，沒有指定細節，將通過要求他們的當前值與我們為他們提供的遠程跟蹤分支相同來保護將要更新的所有遠程ref 。

--force-with-lease = <refname>，未指定預期值，將保護命名ref（單獨） ，如果要更新，則要求其當前值與遠程跟蹤分支相同我們有它。

--force-with-lease = <refname>：<expect>將保護命名ref（單獨） ，如果要更新，則要求其當前值與指定值相同（允許與我們對refname的遠程跟蹤分支不同，或者在使用此表單時我們甚至不必擁有這樣的遠程跟蹤分支）。

請注意，除了--force-with-lease = <refname>：<expect>之外的所有形式都明確指定了ref的預期當前值仍然是實驗性的，並且隨着我們獲得此功能的經驗，它們的語義可能會發生變化。

“--no-force-with-lease”將在命令行中取消之前的所有--force-with-lease 。

因此， 如果傳輸支持比較和交換選項¹ ， 並且您已經編寫了--force-with-lease而不是--no-force-with-lease ， 那么所有更新（強制與否）都使用租賃模式。

然而，-- push_cas_option --no-force-with-lease清除了存儲的push_cas_option結構，當這些存儲的值應用於每個push_cas_option ，對我來說並不是很明顯。

使用顯式<refname>也清楚地保護只有一個引用，無論為它設置任何強制標志。

確切地說，當基礎傳輸缺乏對比較和交換的支持時會發生什么，我也不清楚。 幸運的是，GitHub的Git服務器支持它，如果你特別指的是GitHub，這只會讓你分心。

---

^1在內部，Git源代碼使用宏CAS_OPT_NAME ：force-with-lease的功能受到現代CPU的比較和交換指令的啟發，這些指令以原子方式測試某個變量²是否設置為預測值，將其替換為如果是這樣的新值，並且還以某種形式返回變量中找到的實際值。

如果CPU架構使用條件代碼，則可以設置條件代碼，但在大多數情況下（如果不是所有情況），您都會獲得舊值，以便在適當時重試比較和交換。 例如，要實現原子add-one，你可以循環使用： load r1,(r0); label: add r1,1,r2; cas r1,r2,(r0); bne label load r1,(r0); label: add r1,1,r2; cas r1,r2,(r0); bne label 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 load r1,(r0); label: or r1,4,r2; cas r1,r2,(r0); bne label 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 label: ll r1,(r0); add 1,r1; sc (r0),r1; bne label label: ll r1,(r0); add 1,r1; sc (r0),r1; bne label 。 這用於PowerPC和MIPS架構。

²通常，所討論的變量是一個內存位置，通常具有對齊約束，即使在名義上支持未對齊內存的CPU上也是如此。 例如，在Intel Haswell上，比較和交換8字節指令將在4字節邊界上運行完成，但它實際上不是原子的。 當同事的內存分配器只提供4字節對齊時，我發現這很難。 :-)

Answer 2

當我想通過git pull --rebase origin master拉到工作分支時 ，默認情況下應該更喜歡哪一個？

我在2013年報告了git 1.8.5的 force-with-lease ，以及2016年3月的git 2.8 “。

我會說......沒有一個。
執行pull --rebase以避免強制推送（有或沒有租賃）任何東西。

我只是設置（ 因為git 2.6 ）

git config pull.rebase true
git config rebase.autoStash true

這允許我做一些簡單的git pull ，然后是簡單的git push （不涉及強制推送）