2015-04-25 101 views
-1

所以我有非常大的svn回購,做遷移到Git和答對回購不同的哈希在SVN同步後同樣提交

git svn clone path_to_svn 

後,我做了

git svn fetch 
git svn rebase 

同步它第一次工作,但第二次嘗試失敗,無法確定上游SVN信息從工作樹歷史,雖然我在同步分支,這是'完全沒有改變,我們只是同步它,然後把它與主人合併。 我決定做新的克隆,並嘗試在我的項目上設置遠程併合並這個新的分支,並克隆它後,我發現相同的提交有不同的哈希值,但我100%確定它們是相同的。相同的差異,作者等等。

爲什麼我會看到不同的散列表示相同的提交?

+0

如果他們有不同的(提交者或作者或兩者)時間戳,你的提交將有不同的散列。 – Jubobs

+0

這是完全相同的提交,它已同步到git兩次。但對不同的存儲庫。所以基本上git svn克隆影響哈希計數或爲什麼? – lummycoder

+0

@lummycoder,我不是'git-svn'專家,但是在Git世界中,如果你創建了兩次「相同」的提交,它將會有不同的哈希值(通常是因爲時間戳不同)。如果你已經同步了同樣的Subversion提交給Git兩次,這可能是發生了什麼事情。 – Chris

回答

1

通常,git-svn將在您再次克隆存儲庫時創建相同的Git對象。它將使用Subversion版本庫的作者姓名和簽入日期來設置提交作者和提交者,它將根據Subversion中的簽入消息設置提交消息,並且它會正確地創建內容。所以你應該結束了相同的提交對象(我剛剛證實,這是我自己的情況)。

但是,只適用於兩個克隆的條件相同的情況。這意味着例如您指定了相同的分支佈局,並且服務器返回適當的時間戳(我可以看到DST更改存在一些問題)。由於它被嵌入到Git提交消息中,因此Subversion URL仍然是相同的,這一點也很重要。

我建議你做一個git cat-file -p <hash>兩個提交應該是相同的每個克隆。這樣,您可以嘗試找出克隆之間可能存在的差異。您也可以爲每個存儲庫並行打開gitk以完成提交併嘗試找出哪些歷史記錄可能發生了變化。

+0

好吧,我會試試。我知道,svn repo在下一個克隆期間有新的提交,但老版本完全一樣。因此,下一個克隆進程比之前包含更多修訂版。謝謝您的回答! – lummycoder