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?
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).