If you can losslessly convert between the two models, then it seems like you could make git's conflict resolution smarter without changing the underlying data model.
If you can losslessly convert between the two models, then it seems like you could make git's conflict resolution smarter without changing the underlying data model.
> If you can losslessly convert between the two models, then it seems like you could make git's conflict resolution smarter without changing the underlying data model.
No, this will turn into a performance nightmare.
The keyword is efficiently. A patch based data model is a requirement to efficiently do the kind of deduction on patch commutativity and other properties that Pijul does. Converting back and forth on the fly using snapshots (which are a list of filenames and blob hashes) would not work outside of toy examples.
And this is what eventually "killed" Darcs (an earlier patch based system), its data model had some exponential corner cases that could not be resolved.
The main thing that makes it all work is the extreme performance of its storage backend, which allows to manipulate a graph datastructure directly on disk, and avoid as many IO operations as possible while doing that. This works well, as all operations in Pijul (with some caveats) work in a time logarithmic in the size of history. And yet, it is slower than Git for some operations.
Therefore, what you're suggesting is linear in the size of history (importing), i.e. exponentially slower than Pijul, for every single merge!