Hi, Something I'm currently working on at work reminded me of an idea I had a while ago, which I thought may be useful to the Git project. The idea is simply that diffs and merges can be viewed as special cases of generalized N-way diffs. This N-way diff function takes an arbitrary number of inputs and returns a list of matching and non-matching hunks, where the non-matching hunks have the same number of parts as there were number of inputs. To get a diff, you pass in two inputs and interpret the first part of non-matching hunks as the "before" side and the second part as "after" (assuming that's the order you passed them in, of course). Similarly, to get a normal 3-way merge, you pass in three inputs (base, left, and right) and interpret the parts of the non-matching hunks accordingly. See the tests in [1] for some examples. One advantage of doing it this way is that the merge algorithm becomes consistent with the diff algorithm, so the user won't see conflicts where the conflicting hunks are in different places than they would appear in diff output. This is probably not much of a problem in practice. Another advantage that I'm not sure matters in the Git project is that the generalization can help render conflicts from octopus merges. Sorry if this is an old idea. The fact that there's `git diff --histogram` but no `git merge --histogram` made me think it's not. Or maybe there are simply good reasons to not do the generalization? [1] https://github.com/martinvonz/jj/commit/987aecc749f82c55cb3481f79680552040f7cf13