All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Peter B." <pb@das-werkstatt.com>
Cc: git@vger.kernel.org
Subject: Re: git support for "xattrs" (extended filesystem attributes)?
Date: Wed, 27 Nov 2024 01:29:49 +0000	[thread overview]
Message-ID: <Z0Z2DVuR2PiN-oxy@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <5b4c09a9-64bb-e672-e604-120563fc1ad6@das-werkstatt.com>

[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  parent reply	other threads:[~2024-11-27  1:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-26 19:40 git support for "xattrs" (extended filesystem attributes)? Peter B.
2024-11-26 19:47 ` Junio C Hamano
2024-11-26 22:41 ` Jeff King
2024-11-27  0:00   ` Junio C Hamano
2024-11-27  1:29 ` brian m. carlson [this message]
2024-11-27  7:59   ` Peter B.
2024-11-27 20:52   ` Peter B.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z0Z2DVuR2PiN-oxy@tapette.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=pb@das-werkstatt.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.