On Tue, 2 Oct 2007, David H=E4rdeman wrote:

quoted text
> On Tue, Oct 02, 2007 at 10:04:56PM +0200, David Kastrup wrote:
>> David H=E4rdeman <david@hardeman.nu> writes:
>>=20
>> >  On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:
>> > > also sprach David H=E4rdeman <david@hardeman.nu> [2007.09.19.2016 +0=
100]:
quoted text
>> > > >  But I agree, if any changes were made to git, I'd advocate adding
>> > > >  arbitrary attributes to files (much like xattrs) in name=3Dvalue
>> > > >  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.
>> > >=20
>> > > So where would those metdata be stored in your opinion?
>> >=20
>> >  I'm not sufficiently versed in the internals of git to have an
>> >  informed opinion :)
>>=20
>> 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=
=20
quoted text
> value=3Dname pairs instead of overloading the name field.
>
> But as I said, I have no idea how feasible it would be to change git to=
=20
quoted text
> 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/de=
lete=20
quoted text
> attribute operations and leave it at that. Then external programs can do =
what=20
quoted text
> they want with that data and add/remove/modify tags as necessary (and als=
o=20
quoted text
> include the smarts to not, e.g. remove the permissions on all files if th=
e=20
quoted text
> 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=20
attributes.  One of the big annoyances of Subversion properties is being=20
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 -=20
particularly if you are going to use an external program to actually apply=
=20
any settings - why not store the attributes as normal file (or files) of=20
some sort tracked by git?  You could use any number of methods - e.g. use=
=20
an sqlite database stored in the root of your tree, or a .<name>.props=20
file alongside each path that you have properties for.  You could even=20
write a system that uses such a method and was then SCM agnostic, allowing=
=20
you to keep your attribute tracking system if/when something better than=20
git comes along - or simply share it with less-fortunate souls stuck in an=
=20
inferior system.

--=20
Julian

  ---
A strong conviction that something must be done is the parent of many
bad measures.
 =09=09-- Daniel Webster