3

I have big merge which involve many inexact rename, but it fails with the below:

Performing inexact rename detection: 100% (169817200/169817200), done.
Performing inexact rename detection: 100% (2106881938/2106881938), done.
Performing inexact rename detection: 100% (120035958/120035958), done.
Segmentation fault

I tried to restart my VDI but it didn't help. Any idea how to solve it?

arielma
  • 1,308
  • 1
  • 11
  • 29

1 Answers1

4

From the discussion, this happens only during a complex merge involving renamed folder and many files.

That is a job for the new merge strategy ORT ("Ostensibly Recursive's Twin").
That merge strategy will become the default in 2.34, but in the meantime, with git 2.33.0.2:

git merge -s ort

The primary difference noticable here is that the updating of the working tree and index is not done simultaneously with the merge algorithm, but is a separate post-processing step.
The new API is designed so that one can do repeated merges (e.g. during a rebase or cherry-pick) and only update the index and working tree one time at the end instead of updating it with every intermediate result.

Also, one can perform a merge between two branches, neither of which match the index or the working tree, without clobbering the index or working tree.

The "ort" backend does the complete merge inmemory, and only updates the index and working copy as a post-processing step.

It does handle file conflicts and file/Folder renames much more efficiently than before (with the default "recursive" strategy).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Tnx a lot, it's clear. So how I can decide when to use this command or just simple 'git merge' command? – arielma Sep 09 '21 at 22:55
  • 1
    @arielma Starting with 2.34 (next release, Q4 2021), you won't have to decide. The ORT strategy will be the default one. A simple `git merge` will work, even in your case. – VonC Sep 10 '21 at 06:13
  • BTW, although the question was closed, I think it might solve it as well, right? https://stackoverflow.com/questions/69150777/git-mv-doesnt-work-as-expected-wrong-files-location – arielma Sep 12 '21 at 12:40
  • @arielma It would and I would have added the same merge -s ort answer. – VonC Sep 12 '21 at 14:43
  • what about history? I see that once I resolve conflict of file which wasn't exists and was created after the merge, all its history gone. Why git doesn't save it? – arielma Sep 12 '21 at 15:19
  • @arielma `git log --follow --cc` can help (https://stackoverflow.com/a/43960010/6309), even though it is not foolproof: https://stackoverflow.com/a/46492159/6309 – VonC Sep 12 '21 at 21:19
  • Not good :) doesn't show the real commit history of the file – arielma Sep 12 '21 at 21:36
  • @arielma Which is why https://stackoverflow.com/a/46492159/6309 mentions it is a hack. In case of a complex merge, getting back the full history is not a guarantee. – VonC Sep 12 '21 at 22:06
  • One more question :) I see the command in the solution knows how to handle new files and move them to right place, but that's not the case with folders. Is it known issue? – arielma Sep 14 '21 at 12:13
  • @arielma 2.33 should have taken care of folder renaming detection (as seen for instance in https://stackoverflow.com/a/52227201/6309). Hopefully, 2.34 will take care of all corner cases, but it is possible some remains. – VonC Sep 14 '21 at 12:17
  • I'm using git version 2.33.0.windows.2, but note it's not folder renaming, but new folder which was added after the merge – arielma Sep 14 '21 at 13:15
  • @arielma Interesting. Not sure this particular usecase is managed by ORT though. – VonC Sep 14 '21 at 13:29
  • I will sent mail to git@vger.kernel.org, hopefully to get clear answer for this case – arielma Sep 19 '21 at 21:05
  • 1
    @arielma Let me know of the URL of your question on the mailing list (https://public-inbox.org/git/): I will follow that thread. – VonC Sep 19 '21 at 21:08
  • https://public-inbox.org/git/CANgfOPtz9JqCs-7z1DJnOqxnsGiQS6BBPD6tKTWnTpC0K3qZ9Q@mail.gmail.com/T/#u – arielma Sep 19 '21 at 21:40
  • they replied on my ticket and I replied back. you can track it. other question, you wrote in the answer to use git 2.33.0.2, but in my organization the latest approved git version is 2.31.1. Can I use it as well? – arielma Sep 30 '21 at 11:36
  • @arielma 2.31 is a bit young for the new merge ORT: it is best to use the very latest, to benfit from all its features. – VonC Sep 30 '21 at 21:40
  • Ok, although I went thought the commits of 2.32 and 2.33, and couldn't find anything which related got OTT – arielma Oct 01 '21 at 08:17
  • 1
    @arielma OTT no, but ORT, most definitively yes: https://stackoverflow.com/a/66447468/6309 – VonC Oct 01 '21 at 08:29
  • You are right as always :). From Git 2.33 Release Notes: Repeated rename detections in a sequence of mergy operations have been optimized out for the 'ort' merge strategy. From Git 2.32 Release Notes: The test framework has been taught to optionally turn the default merge strategy to "ort" throughout the system where we use three-way merges internally, like cherry-pick, rebase etc., primarily to enhance its test coverage (the strategy has been available as an explicit "-s ort" choice). – arielma Oct 02 '21 at 18:07
  • Thread: https://public-inbox.org/git/CANgfOPtz9JqCs-7z1DJnOqxnsGiQS6BBPD6tKTWnTpC0K3qZ9Q@mail.gmail.com/T/#u – VonC Jul 09 '22 at 17:54