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