2016-06-07 25 views
4

在當前Git上,git push --force-with-lease origin +somebranch,git push --force-with-lease origin somebranchgit push origin +somebranch(沒有加號)之間是否有重大區別?三人似乎都做同樣的事情。Git -force-with-lease with +分支(refspec)

我試圖尋找文檔。我試圖看看refspec in documentation,但我不知道是否有差異,如果是這樣,當我喜歡通過git pull --rebase origin master拉到工作分支時,默認情況下應該選擇哪一個。

回答

3

這是一個很好的問題;該文件有點含糊不清,而且來源非常混亂(武力標誌的實際應用廣泛分散)。

一個答案很清楚。以下是the git push documentation說,用我的黑體字說:

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

           通常情況下, 「混帳推」 拒絕更新遠程裁判是不是當地裁判的祖先用來覆蓋它。

           此選項將覆蓋此限制如果遠程ref的電流值是預期的值。否則,「git push」會失敗。

           試想一下,你有什麼衍合你已經出版。您將不得不繞過「必須快進」規則,以便用最初發布的歷史記錄替換您最初發布的歷史記錄。如果其他人在你重組之後建立在原始歷史的基礎上,那麼遠程分支的頂端可能會隨着她的提交而前進,而盲目地用--force推動將失去她的工作。

           這個選項允許你說你希望你要更新的歷史是什麼,你重訂,並希望更換。如果遠程引用仍然指向你指定的提交,你可以確定沒有其他人對引用做任何事情。這就像在ref上「租賃」而不顯式鎖定它,只有當「租約」仍然有效時才更新遠程參考。

            --force-與租賃單,沒有指定的細節,將保護是要通過要求其電流值是相同的遠程更新所有遠程裁判跟蹤分支,我們爲他們。

            --force-與租賃= <refname>,沒有指定的預期值,將保護命名REF(單獨),如果它要通過要求進行更新,其當前值與我們對它的遠程跟蹤分支相同。

            --force-與租賃= <refname>:<預計>將保護命名REF(單獨),如果它要通過要求其當前值進行更新,與指定值相同(可以與我們針對refname所使用的遠程跟蹤分支不同,或者在使用此表單時,我們甚至不必擁有這樣的遠程跟蹤分支)。

           注意,所有形式的比--force-與租賃其他= <refname>:<預計>指定裁判的期望電流值明確仍然是實驗性的語義可以爲改變我們獲得了這項功能的經驗。

            「--no-力與租賃」 將取消以前所有的--force-與租賃在命令行上

因此,如果的比較並交換選項由傳輸支持,你寫--force-with-lease而不是--no-force-with-lease然後所有更新,強迫或沒有,使用租賃模式。

然而,--no-force-with-lease清除了存儲的push_cas_option結構,並且當這些存儲值應用於每個refspec時,它對我來說並不是顯而易見的。

使用明確的<refname>也明確保護只有一個引用,無論爲它設置任何強制標誌。

準確地說,底層傳輸缺乏對比較和交換支持的情況下發生的情況對我來說也不是很清楚。幸運的是GitHub的Git服務器支持它,如果你特別提到GitHub,這只是一個分心。


內部,GIT中源代碼使用宏CAS_OPT_NAME:的力與租賃的功能由現代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的高速緩衝存儲器已共用VS獨佔模式(例如,MESI或MOESI),我們可以使用「加載鏈接」或「加載鎖定」指令,然後使用「存儲條件」指令。只有當高速緩存行仍由當前CPU獨佔時,條件存儲才能成功。在這種情況下,我們必須重新初始化變量的鎖定負載,我們的循環看起來更像:label: ll r1,(r0); add 1,r1; sc (r0),r1; bne label。這用於PowerPC和MIPS架構。

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

+0

男人,這真的很深入這件事。不僅是問題本身,還有一些潛在的問題,但也是爲搜索引擎提供的東西。 – Veksi

3

這將應該的時候我想拉上班分支通過git pull --rebase origin master默認喜歡哪一種?

2013 for git 1.8.5, and March 2016 for git 2.8」報道,force-with-lease

我想說的...沒有。
一個pull --rebase做是爲了避免強行推動(有或無租賃)任何東西。

我簡單地設置(since git 2.6

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

,讓我不要做一些簡單git pull,然後是簡單的git push(不需要強制推送)

+0

好點,我忘了解決工作流程問題。使用'--force-with-lease'可以防止通過強制推送被故意刪除的「復活」提交,但是如果您的合作者首先不同意這種刪除,則不需要。因此,這種高級選項只有在你做一些不尋常的事情時才需要。 – torek

+0

投票獲取更多信息。實際上我有一種分心,因爲我並不總是藏起來,但我承諾,然後用先前的提交(假設我正在研究「相同的邏輯集合」)壓縮它,這首先導致了問題。我沒有想太多關於autostashing,但也許我應該。 – Veksi

+0

@Veksi是的,我甚至不考慮存儲或重新綁定:git爲我做,如果需要的話。 – VonC