Re: Tracking file metadata in git -- fix metastore or enhance git?

From: Chris Webb <chris@arachsys.com>
Date: Apr 9, 2011, 08:11 UTC
Message-ID: <20110409081108.GE13750@arachsys.com>
In-Reply-To: <BANLkTi=3LPRzohnZStAogddpL5ZLehb97Q@mail.gmail.com>

Richard Hartmann <richih.mailinglist@gmail.com> writes:

Show 15 quoted lines

> * In most cases I can think of, it would be preferable to track
> changes in metadata along with the actual files.
> 
> * It should be possible for other repositories to ignore this metadata.
> 
> * I am not sure if notes are suitable for this. Using notes.displayRef
> to hide those notes is an option, but it would force everyone to set
> this up locally. Else, it would be very spammy.
> 
> * .gitattributes is too important to fill with potentially thousands
> of lines, imo. Using it to define what metadata should be stored would
> make sense, though.
> 
> * would a .gitmetadata make sense for storage? Alternatively, a
> .git/objects/??/*.metadata per object could make sense.

One other possibility which occurs: would it be possible to store permissions, attributes and so on in a header line (or header lines) in the blob itself, which are stripped from the file and applied to the filesystem by a smudge filter, and added back by a clean filter?

If it works sensibly, this is roughly equivalent to adding a .gitmetadata file as you suggest above, except that the permissions and attribute data are stored with each file, so the resulting diffs will be nicer and merges should always be trivial without any special handling.

(Disclaimer: I've never tried using smudge filters; maybe they can't be used in the way I describe!)

Cheers,

Chris.