爲什麼「git rebase」會在舞臺和工作副本中留下相反的修改集合？

我使用git-svn作爲svn客戶端。我不時遇到以下問題。爲什麼「git rebase」會在舞臺和工作副本中留下相反的修改集合？

我開始在我的本地git分支提交幾個提交，一個空的階段和一個乾淨的工作副本。
我輸入窗口的命令行「混帳SVN變基」獲取球隊的修改，並把我的承諾後，他們保持一個線性的歷史（這是需要使用混帳SVN）
一切順利，團隊的內容被提取和我的承諾後重新分配，但...

我最終在工作副本中修改，並在舞臺上修改文件，工作副本的修改是確切的反例在舞臺上的修改。

我通常圍繞此只是unstaging一切的舞臺，而歸還的工作拷貝，這是很好的修改，但我真的想了解這裏發生了什麼。

問題：這是一個錯誤，還是我用git rebase不理解的東西？

注意：我以後在使用「git svn fetch」和「git rebase」時遇到了問題。

注意：我在帶有大型svn存儲庫（10000+個文件，150000+修訂版）的windows上使用git，並且我也使用git-extensions。 編輯：我使用它只探索存儲庫並提交。我從Windows命令行執行其他任何操作。

編輯：根據其中一條評論的要求，這裏有兩個截圖幫助理解問題。第一個是工作副本的內容，第二個是舞臺的內容。你可以很容易地看到兩者是完全相同oposite：

工作拷貝： enter image description here

階段（恢復工作副本的修改，很直觀：相同的圖像，紅色和綠色被交換）： enter image description here

編輯：我只是在一個非常簡單的情況下重現了這個問題：我的提交只修改一個文件，在「git svn rebase」期間提取的提交很少，並且它們都不影響修改後的文件。我查過「gitk --all」。它與git-extensions和「git status」完全相同。這裏是gitk的輸出。我們從底部到頂部看到：

最後3行是3次提交當綁定時提取。他們都沒有觸及我的文件。
第三行顯示我在rebase之後的提交：它很好，它添加了它應該添加的內容，並刪除了它應該刪除的內容。
第二行顯示的索引的內容：包含修飾恢復我的承諾
第1行顯示的工作副本內容：它包含了我的承諾做同樣的修改，IE恢復索引中的修改。

enter image description here

編輯：這裏的內容我一個「混帳SVN變基」問題出在哪裏發生後.git DIR：

17/02/2012 04:57     0 ArmuazEm5Z 
05/04/2012 02:28     0 BeMzRLwWcu 
06/11/2012 14:37    90 COMMIT_EDITMSG 
01/11/2012 15:42    628 config 
15/02/2012 04:21    73 description 
16/02/2012 13:22     0 fuMhUevkYu 
05/11/2012 15:53   1 703 279 gitk.cache 
05/07/2012 03:49     0 gJfUbdRuG9 
06/11/2012 14:42    23 HEAD 
11/07/2012 03:14 <DIR>   hooks 
21/02/2012 03:22     0 II5HPacSJd 
06/11/2012 14:42   5 439 960 index 
15/10/2012 13:18 <DIR>   info 
16/02/2012 08:16     0 jerS1GtBYS 
17/02/2012 04:57     0 Kg64sq9pzS 
15/02/2012 23:36     0 lbe0yALJYy 
15/10/2012 13:17 <DIR>   logs 
19/10/2012 16:58 <DIR>   objects 
06/11/2012 14:42    41 ORIG_HEAD 
25/10/2012 11:02    2 795 packed-refs 
05/07/2012 03:49     0 PpxYa5z0Hc 
02/11/2012 10:00 <DIR>   refs 
15/02/2012 23:36     0 sm6ociDGGF 
06/11/2012 14:42 <DIR>   svn 
21/02/2012 03:22     0 vEqtL0Yiqd 
05/04/2012 02:28     0 VFwn3laTEV 
16/02/2012 13:22     0 XYoiLqY5BM 
16/02/2012 08:16     0 z9vL8lRT7t 
       22 File(s)  7 146 889 bytes 
       6 Dir(s) 54 105 219 072 bytes free

編輯：如果你有興趣在跟蹤這個問題時，我在主題中報告了[email protected]郵件列表上的一個bug，其中「[git-svn] [bug report] git svn rebase之後的奇怪狀態索引」。

來源

2012-11-01 Samuel Rossille

聽起來像一場噩夢。無論如何擺脫SVN？ –

@AdamDymitruk這是一家500多人公司的漫長過程......我在等待更改時使用git-svn。我對此非常滿意：快速創建分支，快速分支交換，多個工作副本，出色的合併功能......有時只有幾個問題。 –

你可以發佈gitk的截圖，說明發生了什麼？與分支和差異和敏感的東西消滅等我懷疑你的工作樹是不乾淨甚至在rebase之前（你可以通過'git status'檢查） – prusswan

這似乎是一個錯誤。如果您的工作目錄和索引在重新綁定之前是乾淨的，那麼在重新綁定之後它們應該是乾淨的;或者你應該得到一個合併衝突並有機會清理它並繼續進行rebase。

它看起來像是由於某種原因，你的索引在應用你的本地修改後仍然是陳舊的。

基本上，存儲庫的當前狀態有三個主要視圖。有HEAD提交，它是上次提交時的存儲庫狀態，以及您的下一個提交將作爲子進程的內容。在您的重新設置期間這個更新正確。 HEAD現在是您的本地提交，根據您從上游存儲庫獲得的內容重新進行升級。

還有一個索引，它應該包含您下一次提交的狀態的視圖。這似乎是問題所在。在從乾淨的樹中成功重新綁定之後，索引應該看起來與作爲HEAD的存儲庫具有相同的視圖，但似乎獲得了上游存儲庫包含的內容的陳舊視圖。看起來它在上游存儲庫頂部應用本地修補程序後未更新。

還有你的工作副本;磁盤上的實際文件。出於某種原因，當你進行rebase時，head commit被正確更新，並且工作樹正在被正確更新（或者被單獨留下），但是索引被保留在一個指向源提交的狀態你正在重新投入。這意味着如果您將索引與您的重定向提交進行比較，則看起來您已經恢復了您的更改，並且如果您將工作副本與索引進行比較，則看起來您已將其重新添加回。

有幾件事情要檢查：

你能告訴我們你的.git目錄的內容，這樣有問題的重訂後？只有.git頂級文件的列表會很有幫助。實際上，完整列表包括文件名，修改日期和權限可能會提供更多信息。
你是通過任何一種網絡文件系統或其他奇怪的東西來使用它嗎？網絡文件系統有時會存在文件過時的問題;我想知道這是否發生在你身上。
你使用的是什麼版本的Git？

來源

2012-11-05 21:21:22

非常感謝您的關注。 *** 1 ***我會在下次發現問題時發帖。 *** 2 ***我的git存儲庫位於C：\上一個很好的舊NTFS文件系統上，但我的用戶的主目錄包含.gitconfig位於網絡驅動器（公司計算機配置）上*** 3 *** git --version輸出「git version 1.7.10.msysgit.1」我從git-extensions站點安裝了一個包含git-extension和git的bundle。我不知道他們打包了自己的git版本。我剛剛意識到，一邊檢查版本。我會嘗試安裝一個常規版本的git，看看我是否仍然有這個問題。 –

@SamuelRossille Git擴展只是打包標準的Git for Windows（msysgit），所以它與一個相同，你可以手動安裝。 – poke

我編輯了問題，在發生問題時添加.git目錄的內容。我開始認真地認爲這是一個錯誤，但我無法在git郵件列表中找到存檔。我想我會報告它。 –

爲什麼「git rebase」會在舞臺和工作副本中留下相反的修改集合？

回答

相關問題