So there's an additional config management overhead to rolling that out to everyone in a machine. One complication with using a custom merge driver, as discussed by, is that they need to be configured inside the `.git/config` of the repo, which itself is not version controlled.

This never went anywhere near production, but it was very easy to put together something basic. Here's a proof of concept python merge driver I bashed together at the time to auto-merge JSON objects:

I investigated the option of using a custom git merge driver for a project where we were planning to version control a bunch of data files using git. And it will also make the source control system a lot more complicated than it would otherwise be, in return for a largely theoretical payoff.īut if we want to delegate the work of generating diffs off to other people, so that Git can allow for syntax or semantics-aware diffing without having to personally wade into that quagmire (and perhaps also allowing language communities to support multiple source control systems, a bit like how it works with LSP), that might be an interesting thing to experiment with. That will inevitably make the source control system less compatible with the various kinds of things you might want to put into source control. So I think that we really don't want the source control system itself trying to get too smart about the contents of files. Some languages (such as Fortran and Racket) have variable syntax. In some files, such as makefiles, the difference between tabs and spaces is semantically significant. Not every programming language's grammar maps to an abstract syntax tree. Not every file in source control is source code. That seems to me to be an idea that lives on a misconception of the 'things programmers believe about names' variety. I would maybe be interested in Git allowing you to plug in your own diff generators for different file types.īut I would not want Git itself trying to understand the contents of files.

Winmerge vs beyond compare