Re: git support for "xattrs" (extended filesystem attributes)?

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Nov 27, 2024, 01:29 UTC
Message-ID: <Z0Z2DVuR2PiN-oxy@tapette.crustytoothpaste.net>
In-Reply-To: <5b4c09a9-64bb-e672-e604-120563fc1ad6@das-werkstatt.com>

On 2024-11-26 at 19:40:32, Peter B. wrote:

Show 11 quoted lines

> 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