的Git，在兩個分支重新命名時，不會被檢測爲重命名

許多問題，其中問的Git未檢測含量的變化後重新命名。我有一個不同的問題：在共同的祖先有文件f_rename.txt。在一個分支（發散）重新命名（只，而不是內容的變化），以f_rename_1.txt 在其他分支僅重命名爲f_rename_2.txt的Git，在兩個分支重新命名時，不會被檢測爲重命名

當合並兩個分支，我得到的衝突：

我無法理解這種行爲，即使我認爲Git不會檢測重命名操作，並假定f_rename_1是一個新的文件，那麼爲什麼它標誌着衝突？與什麼衝突？

望着階段的文件，很顯然，這裏沒有修改過的文件（同SHA1）：我期待重新命名

/重命名爲Git conflict (rename/rename)

我不問如何解決衝突！，但爲什麼Git的行爲如此。我使用Git「2.13.3.windows.1」

感謝波阿斯

來源

2017-10-18 Boaz Nahum

如果它不檢測重命名，則不會觸發衝突。但由於git知道發生了兩次重命名，顯然彼此衝突，所以會產生衝突。你爲什麼認爲這兩個重命名不衝突？他們用兩種不可能的方式來處理同一個文件。這是一個衝突。 –

@Nils_M我明白我的錯誤，感謝託雷克答案，我只是仍然無法在衆多的衝突時瞭解一個人如何可以分析和理解，這是重命名/重命名 –

你在你的問題包括圖像具有git status輸出。

的CONFLICT (rename/rename):你期望由git merge命令打印。

該跟蹤，這留在索引，你現在看到的是，該索引有一個階段1條目的原始名稱（沒有階段2或階段3條目），一個（沒有階段1或階段3條目）的一個階段2條目，以及另一個新名稱（沒有階段1或階段2條目）的一個階段3條目。 git status命令將打印該類型跟蹤的輸出。

看看您的linked question的接受答案，它顯示相同的git status輸出。 both deleted行只是稍後，因爲輸出按文件名排序，而will-be-deleted以w開頭，後面會出現。

來源

2017-10-18 18:20:38 torek

所以@torek，萬一比幾衝突，開發人員應該分析和檢測這些衝突的三倍，並瞭解它是重命名/重命名？有沒有一種方法可以緩解這種分析？ –

如果您保存'git merge'命令的'CONFLICT ...'錯誤消息輸出，您將獲得必要的信息。在我看來，Git真的*應該*寫這個索引，使其可以檢索自動化和更好的'Git狀態'輸出，因爲有不同種類的我稱之爲「高級別」合併衝突，難以區分沒有這些數據。（請參閱https://stackoverflow.com/a/44360581/1256452） – torek

的Git，在兩個分支重新命名時，不會被檢測爲重命名

回答

相關問題