Hi folks, I just came across a situation where the ort merge strategy chooses a "worse" rename mapping than the recursive strategy - worse in the sense of having a lower similarity score, worse in the sense of having been a change in another commit (but I guess this is just a limitation of git merge? It doesn't look for renames "iteratively" through history when merging?), and finally worse in the sense of causing a merge conflict that, given the previous two points, is unnecessary and does not occur with recursive. I've prepared a reproduction script, attached. It's probably a little convoluted because I didn't know exactly what to look out for. This is an extreme simplification of a real-life incident: One file (folder1/firstfile.txt) is deleted independently in two branches, and another somewhat-similar file (folder2/secondfile.txt) is renamed (to folder2/secondfile_renamed.txt) and slightly modified in one of them (in another commit). When the branch with the rename gets merged in to the branch that just had the delete, "ort" sees the rename as having been of "folder1/firstfile.txt" to "folder2/secondfile_renamed.txt", despite this being of a lower similarity than the real rename that happened, and a conflict ensues. Is ort supposed to choose the "best" rename choice, for a given set of trees, and failing to do so here? Or is this a case of recursive *accidentally* doing a better thing? Thanks, Tao
git init git config commit.gpgsign false git config user.name Tao git config user.email tao@xxxxxxxxxx touch firstfile git add firstfile git commit -m "First commit" mkdir folder1 mkdir folder2 cat >> folder1/firstfile.txt << "EOF" FirstLine Second Line Line Number 3 Fourth Line There can Always be more Lines That was an Empty Line Some Unique Stuff But Not too Much EOF cat >> folder2/secondfile.txt << "EOF" FirstLine Second Line Line Number 3 There can Always be more Lines But not too many! That was an Empty Line Otherwise Unique Stuff But Not too Much EOF git add . git commit -m "Starting State" git checkout -b featurebranch touch newworkingfile git add newworkingfile git commit -m "New working file" git rm folder1/firstfile.txt git add . git commit -m "Deleted in working branch" touch anothernewworkingfile git add anothernewworkingfile git commit -m "More regular history" git checkout master rm folder1/firstfile.txt git add . git commit -m "also deleted here" rm folder2/secondfile.txt cat >> folder2/secondfile_renamed.txt << "EOF" FirstLine Second Line Line Number 3 There can Always be more Lines But not too many! That was an Empty Line Otherwise Almost Unique Stuff But Not too Much EOF git add . git commit -m "a high-percentage rename" touch amasterfile git add amasterfile git commit -m "More regular history in master" git checkout -b regularmerge featurebranch git merge master -s recursive git checkout -b ortmerge featurebranch git merge master -s ort
