On 2024-11-26 at 19:40:32, Peter B. wrote: > Hi everyone :) > > I'm evaluating and testing extended attributes (xattrs) for professional > archival collection use. > I couldn't find any proper documentation/information on how (well) git > supports including xattrs in version control. > > I assume behavior may be similar to any other property-change of > files/folders? > Would it be possible to have bit-proof preservation of all xattrs? (even > larger ones). As others have mentioned, Git doesn't store this. There are a couple ways that one could store this information, depending on what you want to store. One way is to store the metadata in the `.gitattributes` file if you're storing one or two well-known xattrs and the values are well stored as text in the file. You can then use `git ls-attr` and a `post-checkout` hook[0] to set those attributes appropriately. Another way is to store the data as part of an mtree(1) file in the repository. mtree is a file format that comes from the BSDs that can contain a wide variety of data, including file type, uid and gid, text user and group, permissions, size, mtime, cryptographic hashes, and a wide variety of other data. mtree utilities can usually generate a manifest based on the state of the file system, validate that files match a manifest, and usually update existing files such that they match a manifest. There's a Go-based version[1] which does support storing xattrs. Again, you can use a `post-checkout` hook here. Since mtree is a key-value format, you can also extend the value with other data. I use a similar format in my dotfiles to specify install location, for instance, so I recommend this as a good way to store this data. [0] Git LFS uses post-checkout hooks to adjust the read-only bit for files which are lockable but not locked, so this is generally a robust method. [1] https://github.com/vbatts/go-mtree -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
