2017-04-18 60 views
1

我用git fetch <remote> --depth=<N>避開超時問題添加遠程到我的本地存儲庫。嘗試git fetch <remote>沒有指定深度會超時。所以我嘗試了git fetch <remote> --depth=10,然後反覆多次,每次都穩步增加深度,直到我終於能夠獲得整個事物(即增加深度檢索零對象)。之後我跑git fetch <remote> --unshallow其中is supposed to convert the remote back to a non-shallow remote copy與每個提取後更改遠程分支git問題

這是我的問題。完成所有這些之後,我不確定我的本地存儲庫是否處於相同/相同狀態,如果我剛開始時完成了git fetch <remote>,並且沒有超時。每次我git fetch <remote>它不斷報告相同的「新」和「更新」分支。

發生了什麼,我該如何糾正?

我唯一能想到的嘗試就是我沒有真正嘗試過,就是刪除遠程並重新添加它。我害怕不得不重新開始。這是一個非常大的存儲庫,需要很長時間才能達到這一點。如果我在此期間避免了git gc,將刪除並重新添加遠程分支,而無需再次下載所有提交?

以下是我所做的和結果。

每次我git fetch <remote>現在,不管我怎麼努力,我得到這樣的輸出:

Fetching <remote> 
From ssh://<url> 
+ 3603285...775e0fe Feature/A -> <remote>/Feature/A (forced update) 
+ 6303337...de89a23 Feature/B -> <remote>/Feature/B (forced update) 
* [new branch]  feature/C -> <remote>/feature/C 
* [new branch]  feature/D -> <remote>/feature/D 
* [new branch]  feature/E -> <remote>/feature/E 
* [new branch]  feature/F -> <remote>/feature/F 
* [new branch]  feature/G -> <remote>/feature/G 
* [new branch]  feature/H -> <remote>/feature/H 

同樣的輸出每次。其他遙控器並不像這樣。它只出現在這個遠程,分支指針實際上從來沒有實際進展,每個fetch試圖再次推進它們。輸出中永遠不會有任何實際的錯誤。

我已經驗證這些分支都存在於遠程服務器中,並且不會在那裏刪除。但是,檢查遠程回購的分支Feature/A的整個提交歷史記錄,它根本不包含提交3603285

輸出的

git config --get remote.<remote>.fetch

+refs/heads/*:refs/remotes/<remote>/* 

部分輸出的git remote show <remote>

Remote branches: 
    feature/X      tracked 
    feature/Y      tracked 
    feature/A      tracked 
    feature/B      tracked 
    refs/remotes/<remote>feature/C stale (use 'git remote prune' to remove) 
    refs/remotes/<remote>feature/D stale (use 'git remote prune' to remove) 
    refs/remotes/<remote>feature/E stale (use 'git remote prune' to remove) 
    refs/remotes/<remote>feature/F stale (use 'git remote prune' to remove) 
    refs/remotes/<remote>feature/G stale (use 'git remote prune' to remove) 
    refs/remotes/<remote>feature/H stale (use 'git remote prune' to remove) 

事情我已經試過這沒有糾正這一點,

  • git fsck(未報告任何問題)
  • git fetch <remote> --unshallow(報告資料庫已經完成)
  • git gc(沒有錯誤報告,運行兩次產生相同的輸出)
  • git remote prune <remote>(刪除分支CH,但他們加了回去未來fetch
  • git fetch --all --prune

git fetch --all --prune輸出是有點不同(也每一次,不管我怎麼努力):

Fetching <remote> 
From ssh://<url> 
x [deleted]   (none)  -> <remote>/Feature/C 
x [deleted]   (none)  -> <remote>/Feature/D 
x [deleted]   (none)  -> <remote>/Feature/E 
x [deleted]   (none)  -> <remote>/Feature/F 
x [deleted]   (none)  -> <remote>/Feature/G 
x [deleted]   (none)  -> <remote>/Feature/H 
+ 3603285...775e0fe Feature/A -> <remote>/Feature/A (forced update) 
+ 6303337...de89a23 Feature/B -> <remote>/Feature/B (forced update) 
* [new branch]  feature/C -> <remote>/feature/C 
* [new branch]  feature/D -> <remote>/feature/D 
* [new branch]  feature/E -> <remote>/feature/E 
* [new branch]  feature/F -> <remote>/feature/F 
* [new branch]  feature/G -> <remote>/feature/G 
* [new branch]  feature/H -> <remote>/feature/H 

如果我退房分支<remote>/Feature/A我得到承諾3603285775e0fe,即使在遠程服務器上,Feature/A775e0fe3603285是無處在它的歷史。我也可以通過提交字符串直接檢查出775e0fe,沒有問題。命令該序列產生令我感到奇怪的輸出(也每一次,不管我怎麼努力):

$ git checkout <remote>/Feature/A 
HEAD is now at 3603285 
$ git checkout -b Feature/A 
$ git merge 775e0fe 
Already up-to-date. 
+0

我以前在使用案例摺疊的系統上看到過這種行爲。我看到你在這裏有'feature/'和'Feature/',這裏有小寫字母和大寫字母F.如果這是同樣的問題,就是這樣。你的Git認爲它必須銷燬錯誤的分支並創建正確的分支,但是你仍然有錯誤的名稱,因爲你的操作系統會摺疊大小寫並將所有內容寫入現有的其他大小寫目錄。解決方案是使用不折疊大小寫的OS(或文件系統),或者修復上游以使用單個大小寫。 – torek

+0

@torek這是完全正確的。遠程回購包含具有不同提交的'Feature/A'和'Feature/B'的大小寫版本。並且所有'[刪除的]'分支都被修剪爲'特徵/ ...',然後以小寫形式添加回'特徵/ ...'。添加您的解決方案並作爲答案,我會接受它。 – wberry

回答

0

這是一個文件系統的情況下摺疊的問題,所以它無關,與淺部(其是好消息/壞消息)。

我看你有沒有這兩個feature/<name>Feature/<name>這裏,用小寫和大寫F.你的Git版本庫中設置了這些,但一旦它創建一個目錄有一個情況下,與其他情況下的分支名稱在同去目錄。然後你的Git認爲這是錯誤的:它必須銷燬錯誤的分支並創建正確的分支,但是你仍然有錯誤的名字,因爲你的操作系統再次摺疊大小寫並且寫入所有內容到現有的其他案例目錄。

通常的解決方案是使用不折疊大小寫的操作系統(或文件系統),或修復上游以使用單個大小寫。

如果這是不可能的,我有一個想法,我從來沒有測試過,但應該工作:你可以分裂你的fetch網址。這有很多缺點,主要是你必須偶爾手動運行git ls-remote並檢查是否需要更新URL映射。 (使用其中一種更常用的解決方案要好得多。)

+0

賓果!我正在使用Windows,遠程服務器幾乎可以肯定是Linux,然後進入'.git'文件夾,我可以準確地看到您描述的內容。此外,遙控器確實有兩個分支:「特徵/ A」和「特徵/ A」等。所以這幾乎肯定是正確的解釋。現在我知道我的本地回購沒有損壞,在我的情況下,我可以放心地忽略這些分支,所以我會將分割取回解決方案的嘗試留給其他人。 – wberry