Dotting the I's and Crossing the T's.
The theme since Release 1.4.1 has been making sure that Kinetic Merge performs at least as well as core Git merge on some obscure corner cases:
- Report merging of a file completely deleted on one branch with its modification on the other branch as a straight conflict in the index for that file.
- Report merging of a file renamed on one branch with its deletion on the other branch is a straight conflict in the index for the renamed file.
- Report colliding renames from different files on both branches as a content conflict for the renamed file; but only if the content disagrees - otherwise just merge it.
- Report a rename on one branch that collides with the modification of a file added on the other as a content conflict; but only if the content disagrees - otherwise just merge it.
These are specifically not the power features that already distinguish Kinetic Merge from core Git merge, i.e. those involving code motion and change migration that is either intra-file or inter-file; the goal here is to make sure nobody loses out in making the transition to Kinetic Merge.
Features:
#4 Duplicate the behaviour of Git merge for simple renaming / movement of files with minor editing on one branch and outright deletion on the other.
#137 How should a deletion versus modification conflict be handled? - Redux.
Notes:
Kinetic Merge handles the renaming with more generality than core Git merge - so it can cope with files being split into multiple renamed fragments, as well as the condensation of fragments together into one single renamed file. It also handles 'off-cut' files and condensation into existing files.
Whenever entire-file renaming is detected (even when there are no conflicts), Kinetic Merge issues a diagnostic for the file rename in addition to the move destinations report.
Like core Git merge, Kinetic Merge uses heuristics to declare a file as being renamed - so moving small sections of content out of a file and into another would not be considered a rename. That would still be treated as code motion though, so would benefit from change migration if applicable.
If a file is added without any renaming on both branches, then this is treated as a straight addition versus addition conflict, but only if the content doesn't merge smoothly.