A Categorical Theory of Patches

Created on 2024-02-12T06:09:05-06:00

Return to the Index

This card pertains to a resource available on the internet.

This card can also be read via Gemini.

Authors: Samuel Mimram, Cinzia Di Giusto

Paper seems needlessly difficult to read--as though the authors were being paid by perplexity.

Store the changes to files themselves in the form of patches. A patch applies to another artifact and changes it in some way. Two patches may be incompatible with one another--forming a merge conflict. This conflict can be stored within the system (though rendering it might result in nonsense.)

Repositories become graphs of changes which point to the outcome of previous stages.

Merge conflicts point to a hypothetical invalid state created by two incoming patches, determine the final output, and then "patch" that invalid state by pointing the new outcome to the broken node.

This is basically how Pijul can store the resolution to a merge conflict and replay it even if you were to go back in history and change other code. The resolution to the conflict is itself stored--not just that the file had been changed, as with Git.