On Tue, 2 Oct 2007, David Härdeman wrote:
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).
You need more than that. You need to be able to log, blame etc on the
attributes. One of the big annoyances of Subversion properties is being
unable to find out when or why a property value was changed.
I still don't see why the attributes need to be stored in git directly -
particularly if you are going to use an external program to actually apply
any settings - why not store the attributes as normal file (or files) of
some sort tracked by git? You could use any number of methods - e.g. use
an sqlite database stored in the root of your tree, or a .<name>.props
file alongside each path that you have properties for. You could even
write a system that uses such a method and was then SCM agnostic, allowing
you to keep your attribute tracking system if/when something better than
git comes along - or simply share it with less-fortunate souls stuck in an
inferior system.
--
Julian
---
A strong conviction that something must be done is the parent of many
bad measures.
-- Daniel Webster
