Any two commits that conflict in a semantic sense (either change individually is okay, but both together don't work), but don't conflict in a syntactic sense (t

Any two commits that conflict in a semantic sense (either change individually is okay, but both together don't work), but don't conflict in a syntactic sense (the changes are not textually near enough to each other to cause git to consider them conflicts, so an automatic merge can & will still happen; alternatively, they make the exact same change, and so don't conflict). We see this often with lockfiles (someone updates a dep, someone else adds a new dependency; the merge is a new dependency to a version of the dependency that no longer exists), or version numbers that get incremented (each author increments once; the second merge, git will consider it the same add on both sides, and not a conflict, so the result it original_version+1, when it should be original_version+2).