[TOPIC 3/8] Merge ORT timeline

[Taylor Blau <me@ttaylorr.com>]

# 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