git merge忽略合並分支上存在的已刪除文件（重命名文件）

Question

我有分支feature1和master 。
然后在feature1我將文件dir/file.txt重命名為dir2/file2.txt 。
之后我改變了master的文件，一周之后也改變了feature1的文件。

我在整個項目中改變了40個文件。
當我嘗試將master合並到feature1我使用的是低重命名閾值。 大多數文件都是正確自動合並的。 提供了一些文件用於手動解決沖突。

但是一些具體文件在merge響應中既不會出現自動合並，
也沒有正確合並 。 在適當的情況下，我期待我可以解決的兩個結果之一：
1.它不會檢測重命名，只需將另一個dir/file.txt添加到feature1分支中。
它會檢測重命名並讓我手動解決沖突。

我查看時有很多變化
git difftool master:dir/file.txt feature1:dir2/file2.txt

因此我假設git識別重命名並決定保留我的版本而不通知我發生了什么。 我該如何解決/調試呢？

這是我使用的命令

git config merge.renameLimit 9999999999
git merge --no-ff -Xrename-threshold=20 -Xignore-space-change master

Upd1

在使用feature1分支時，我刪除了dir/file.txt 。
也許git假設這個文件應該刪除，因此忽略它在master的存在。
重命名檢測失敗，盡管文件的相似性保持不變（levenshtein距離小於內容長度的2％）
另一個討論建議“手動合並”將文件從分支復制到分支。

UPD2

其他一些文件已正確解析
CONFLICT (rename/delete): images/ab.gif deleted in master and renamed in HEAD. Version HEAD of cdn/img/ab.gif left in tree.
在master中刪除並合並到feature1已正確解析。 合並時無法識別feature1中刪除（或移動）的文件。
建議嗎？

Upd3

目前我正試圖合並另一種方式。 將feature1合並到master ，查看正在添加和刪除的文件。 這樣我就會將git fail列出的文件列表識別為重命名並采用手動合並。

Answer 1

如果您要從您的repo中刪除文件 - git正在跟蹤此刪除，並且在確定要執行的操作時合並正在考慮此問題。

這可能不是你所做的全部，但它是它的一部分。 你可以嘗試git再次添加它們。

Answer 2

因此我假設git識別重命名並決定保留我的版本而不通知我發生了什么。

Git 2.13（2017年第二季度）實際上會告訴你更多關於發生了什么的事情：

當“ git merge ”檢測到在一個歷史記錄中重命名的路徑而另一個歷史記錄被刪除（或修改）它時， 它現在報告兩條路徑以幫助用戶了解正在合並的兩個歷史記錄中發生了什么 。

見Matt McCutchen（ mattmccutchen ） 提交b26d87f （2017年1月28日） 。
^{（由Junio C gitster合並- gitster - in commit 74aabf4 ，2017年2月27日）}

merge-recursive：make“CONFLICT（rename / delete）”消息顯示兩個路徑

由“ git merge-recursive ”為重命名/刪除沖突打印的當前消息如下所示：

CONFLICT (rename/delete): 
new-path deleted in HEAD and renamed in other-branch. 
Version other-branch of new-path left in tree.

為了更有幫助，該消息應顯示重命名的兩個路徑，並指出刪除發生在舊路徑，而不是新路徑。 因此，將消息更改為以下格式：

CONFLICT (rename/delete): 
old-path deleted in HEAD and renamed to  new-path in other-branch.  
Version other-branch of new-path left in tree.

由於這會使handle_change_delete（修改與重命名）中的個案數量翻倍，因此通過合並o-> branch1具有更改的情況並且o-> branch2具有刪除的情況，重構代碼以將案例數量再次減半。是另一種方式。