3 ms·
No, it makes no difference. Git doesn't look at the full history when performing a merge, it just looks for similarity between the paths and files in the commit
by kruador 4y ago
No, it makes no difference. Git doesn't look at the full history when performing a merge, it just looks for similarity between the paths and files in the commits being merged, and the common base commit (which you can discover by running `git merge-base`). It doesn't keep any metadata about whether something was a move: as far as the actual data structures are concerned, you deleted file a/b/c and added file d/e/f, that have the same file content hash.
You can find more information on how Git now does it at https://blog.palantir.com/optimizing-gits-merge-machinery-1-127ceb0ef2a1 https://blog.palantir.com/optimizing-gits-merge-machinery-1-... . I think this first started to be released in v2.31.0, and completed in v2.33.0. v2.34.0 switched the default merge strategy to the new 'ort' strategy mentioned in that blog.
- avar 4y agoThe "git log" "follow renames" logic isn't the same as conceptually related merge logic. I think there are unfortunately still cases where what the GP is suggesting improves the UX, i.e. I think some shortcuts are taken when following a file if the content doesn't change. IIRC this matters particularly for very large renames, at some point during revision walking we'll give up trying to match your A.txt to B.txt, but if they're the same...