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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Richard Hartmann <richih.mailinglist@xxxxxxxxx> writes:

> * 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]