On Tue, Oct 02, 2007 at 10:04:56PM +0200, David Kastrup wrote:
David Härdeman <david@xxxxxxxxxxx> writes:
On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:
also sprach David Härdeman <david@xxxxxxxxxxx> [2007.09.19.2016 +0100]:
But I agree, if any changes were made to git, I'd advocate adding
arbitrary attributes to files (much like xattrs) in name=value
pairs, then any extended metadata could be stored in those
attributes and external scripts/tools could use them in some way
that makes sense...and also make sure to only update them when it
makes sense.
So where would those metdata be stored in your opinion?
I'm not sufficiently versed in the internals of git to have an
informed opinion :)
I think we have something like a length count for file names in index
and/or tree. We could just put the (sorted) attributes after a NUL
byte in the file name and include them in the count. It would also
make those artificially longer file names work more or less when
sorting them for deltification.
Or perhaps the index format could be extended to include a new field for
value=name pairs instead of overloading the name field.
But as I said, I have no idea how feasible it would be to change git to
support another arbitrary length field in the index/tree file.
However, this requires implementing _policies_: it must be possible to
specify per repository exactly what will and what won't get tracked,
or one will get conflicts that are not necessary or appropriate.
I think the opposite approach would be better. Let git provide
set/get/delete attribute operations and leave it at that. Then external
programs can do what they want with that data and add/remove/modify tags
as necessary (and also include the smarts to not, e.g. remove the
permissions on all files if the git repo is checked out to a FAT fs).
--
David Härdeman
-
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
