4 ms·
They mention using git to version Unison code, and point out how there'll practically never be any version conflicts because of the immutable / append-only natu
by WillDaSilva 5y ago
They mention using git to version Unison code, and point out how there'll practically never be any version conflicts because of the immutable / append-only nature of the language.
Doesn't that mean that the git repository will only ever grow, and that old code will stick around forever? I hope I'm misunderstanding because that would be unfortunate if true.
- JoshTriplett 5y agoSeems like an intended design feature. That doesn't mean you have to keep all those old versions in every copy of the repository; you could always fetch only versions you need, for instance.
- teraflop 5y agoIsn't that true of any Git repository? The internal object store keeps every version of every file that has ever existed (unless you rewrite history). In practice, Git's content-addressable storage and delta compression make it work fairly well for all but the largest repositories.
- dthul 5y agoWhat I don't understand is what they do when merging two branches. If both branches introduce a function with the same name a merge conflict is inevitable, no? Or do they not support the distributed version control approach and every developer has to submit their changes to the current version of the database?
- refried_ 5y agoIt produces a name conflict, but (unlike git merge conflicts) these don't prevent any previously written code from running normally. A name conflict only needs to be resolved as a convenience to the next person to try calling the function by that name, and even that next person might not have trouble if the two new functions with the same name have different types. The person just calls the one they mean, and the type-checker uses the one with the type that fits.