From the VCS point of view, redefining a from from a sequentce of
Putting “mere patch management scripts” such as Git to shame… So merging is the great VCS challenge, due to conflicts and more importantly the uncertainty of which of a number of conflict resolution strategies is required to resolve any particular merge conflict. lines, to a directed graph of lines, allows for endless automated merging, with preservation of the resultant graphs, for possible presentation to a user at some future time for "conflict resolution". This sounds simple, but that's really only because it's so intuitive, yet has now been put into a logically coherent mathematical paper with fancy names which apparently establishes “a sound theory of patches” - which is a very good thing indeed for VCS boffins. And the reason that a digle, file => sequence of lines digle => directed graph of lines , is particularly useful, is that for one, merges can be done automatically even in the case of conflicts, and simplified presentation of conflicts and conflict resolution UIs is possible - witness the various diff (and merge) "heuristics" which are too often spoken of in Git land - which heuristics although very welcome, and entirely suprerior to the VCS's of yore, are by virtue of being heuristics and not "closed set" type functions, are naggingly and annoyingly unrobust, at least mathematically/ logically, which is doubly nagging due to Git's content-addressed data model design breakthrough - surely we can have it all? Well yes grasshopper, that's where your intuition is right, yes you can, in the world of Version Control Systemes, have it all: Teh paper: http://arxiv.org/abs/1311.3903 Teh model: https://pijul.org/model/#why-care-about-patch-theory Teh easy description: https://jneem.github.io/merging/ Easy, part 2: https://jneem.github.io/pijul/ A VCS being built on teh theory: https://pijul.org/ Coming soon to a "mere patch management script" near you :)