# Merge ORT (Elijah) - Git has multiple merge backends - default was "recursive", now "merge-ort" - When merge-ort was written, it was intended to be a replacement - Would people be okay removing the old merge-recursive code? ORT was meant as a drop-in replacement, but it does have some differences in behavior - If it is okay, what's the timeline? - (Taylor): gradual guarded by config might be a good approach (e.g., "merge.recursiveIsORT") - (Johannes): describing the differences in behavior - Merge-ort rename detection is always on, but merge-recursive is opt-in - ORT uses histogram diffs (arguably more correct, matching unique lines in diffs). Leads to (sometimes) merge conflicts where merge-recursive didn't find it, but ort did. Still probably more correct, though. Much more rarely, it's the opposite - recursive found a conflict, ORT did not - Conclusion: wait 2 major versions to deprecate - (Taylor): maybe we should add "turn off rename detection" option - (Johannes): should we even give users that option in the first place? If they don't have it, they won't be as upset when we get rid of it ;) - (Peff) how long has ort been the default? 2 versions. Now people have recursive as a escape hatch. But we don't know if/when people use if. Also recursive with find-renames is an escape hatch. - (Emily): we know how often people are using escape hatches (at Google), could take the same approach with this option - (jrn): do we have other signals for how often this escape hatch is used? Stack Overflow posts? - No one's named it as a solution on the mailing list, though, so we don't know from that medium - Agree with Johannes, might be best to not give the option to users because this way we have more chance of getting signal. - (Peff): the mailing list isn't representative of the larger Git community, so people bringing it up to the mailing list might not be indicative of usage - Leaving the hatch doesn't seem like it'd incur a huge maintenance burden - (Terry): some distros might have significant propagation delay, should probably bake in extra time because of slow adoption - (Ævar): I'm happy to follow your decision - Some behavior difference, but it's working -better- - At some point, we should be willing to say "if you need an old feature, use an old version" - Some observed differences might be libgit2 recursive vs. ORT, unclear which ones though - (Johannes): We can bake in a deprecation notice, like: if you see something wrong, now is the time to bring it up! We'd rather fix it now - (Jeff): most users won't be bothered - they'll see a conflict and resolve it, without thinking about which algorithm generated the conflict - (jrn): for most usage, this is a completely safe change. The discussion comes up because of the fear that some user might have some use of merge they regularly do that hangs, that kind of thing, rather than the subtle merge resolution changes that we've discussed. I think we're safe. :) - (brian): observing something like Debian or other LTS versions of projects - if there isn't a lot of screaming after a couple months, it's probably safe. Even if you wait a decade, though, there'll always be one or two who suddenly encounter issues with the new feature after the old is long deprecated. - (Ævar): haven't seen any huge warning in the merge docs saying we've changed something, but with how many users are already using it, it's likely very few people will ever notice
