Am 29.06.20 um 16:51 schrieb James Cook: >> There is also more than just hunks. What about file renames? A file >> rename commutes with a hunk that changes the file, and in darcs this >> changes the hunk patch to refer to the renamed file. You need to change >> the internal representation to refer to files using UUIDs to get around >> that. And as soon as you do that you get the same problems with global >> uniqueness invariants that you previously had for patches. There is a >> reason why git cannot track file renames: they store just trees and >> identify them by their content hash. This is secure and quite efficient, >> but properly tracking file renames is not possible in such a model. >> AFAIK Pijul suffers from a similar limitation and for the same reason >> i.e. there is no primitive "rename" patch, only file-remove and file-add. > > I think Pijul does handle renames intelligently. (I just tested: > merging a rename "f -> g" with an edit to f results in editing g.)
Okay, thanks. I just remembered (vaguely) that at one point they didn't have a move command, the rest was just guessing. > A while ago I poked at Pijul's patch representation and inferred that > it indeed gives each file a unique ID, and that ID is based on the ID > of the patch that created it. I think it does something similar to > assign identities to individual lines in files. I imagine it does the > same thing for directories. Don't quote me on this, though. Hmm. If they base the UUID on the creating patch's ID, then this might be safe, assuming the latter is (based on) a content hash. So I guess I was wrong to claim that you necessarily get the same "global uniqueness" problems as Darcs has. Cheers Ben _______________________________________________ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
