2014-08-27 138 views
4

我理解什麼不順心在下列情況下一個問題:Git的變基試圖更改應用到錯誤的文件

我有一個特性分支X的背後是development,所以我做這個特性分支的底墊當HEAD位於這個特性分支X上時,通過調用git rebase development。Git現在重播development上的我的特性分支的所有提交,並且它停止在具有衝突的提交上。我通過刪除一些不應該在那裏的文件來解決衝突,並將文件夾添加到我的.gitignore,然後繼續執行更改和git rebase --continue。 現在,rebase再次停止對先前刪除的某些文件進行更改的提交。但是,git試圖將更改應用於文件夾中的不同文件,而不是注意到此特定文件不再存在!

爲什麼這是默認行爲? (我運行git 2.0)

衝突文件的差異是這樣的:

++<<<<<<< HEAD:<path>/XML/fileA.xslt 
+ [...] 
+ 
++======= 
+ [....] 
+  
++>>>>>>> <commit message>:<path>/XML/fileB.html 
+0

你嘗試過'git rebase -i development'命令嗎?這將允許您控制rebase的每個步驟。 – 2014-08-28 09:06:03

+0

我實際上做了一次互動式底膠,但爲了清晰起見,我將其從等式中排除。 – 2014-08-28 13:30:38

回答

1

爲什麼這是默認行爲?

每次提交都會存儲一個文件樹,當您重新綁定(據我所知)時,它將從基本提交開始合併每個提交提交。

什麼,當你解決的發言權衝突目錄/XML/它本身存儲爲一棵樹刪除文件fileA.xslt情況是這樣的:

git ls-tree HEAD XML/ 
... blob ... fileA.xslt 
... blob ... fileB.html 

中取出後XML目錄樹看起來像這樣的:

git ls-tree HEAD XML/ 
... blob ... fileB.html 

現在,如果你嘗試與已刪除的文件存在於樹再次將其合併(提交它被修改):

git ls-tree HEAD XML/ 
... blob ... fileA.xslt 
... blob ... fileB.html 

所以我的猜測是,以配合它可能會嘗試將fileB.html轉換成fileA.xst,因爲它們是在不同版本的XML樹都的第一個文件或已被確定爲非常相似。


BTW:你可以做一個互動變基和編輯,跳過或重新安排提交,如果它是必要的。

+0

我通常總是互動地完成拼合,因爲它在修正提交時提供了很大的靈活性。然而,上面描述的情景一直在彈出,讓我撓了撓頭。我把互動部分留下了,因爲我認爲這可能會令人困惑,並且對手頭的問題沒有實際的影響。 感謝您的解釋,仍然認爲這不應該是默認的行爲,雖然...... – 2014-08-28 13:35:34

+0

你可以發佈'git ls-tree COMMIT_SHA XML /'輸出爲每次提交重新包括解決第一次衝突和衝突提交關於第二次衝突?這有助於確定'git'可能認爲哪裏有重命名和調試問題,因爲它看起來似乎不應該是默認行爲。 – 2014-08-28 13:58:18

0

因爲Git並不記錄所做的更改,只需快照,您的更改錯誤地檢測爲重命名.XML來。並用.html文件的內容替換其內容。我認爲可能會有一些開關爲git提供有關此事的提示,但我不確定。