git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Unexpected conflict with ort merge strategy?

From
Tao Klerks <tao@klerks.biz>
Date
Oct 19, 2021, 22:40 UTC
Message-ID
<CAPMMpojsNQuHe9iSUGyu_q2M4VObjDPj4c0QrFPsHdYypQ3aog@mail.gmail.com>
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@klerks.biz 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

Next: Elijah Newren
Message 1 of 5 in “Unexpected conflict with ort merge strategy?”
  1. Tao KlerksOct 19, 2021
  2. Elijah NewrenNov 11, 2021
  3. Junio C HamanoNov 11, 2021
  4. Tao KlerksApr 20, 2022
  5. Elijah NewrenApr 21, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.