Re: tracking perms/ownership

["Josh England" <jjengla@sandia.gov>]

On Thu, 2007-08-23 at 15:08 -0700, Junio C Hamano wrote: 
> "Josh England" <jjengla@sandia.gov> writes:
> 
> > Looking at the index struct, it already has fields in it for file mode
> > uid and gid (woohoo!).
> 
> I can see that storing textual names in gitattributes and having
> the root user run git so that it can chown(), would work.
> 
> But this is only about checkout.  After you chown a file in the
> work tree and run update-index, next write-tree would not record
> it, as there is no place in tree objects to record uid/gid.
> You would need to arrange so that a matching change is made in
> the gitattributes file if you go that route.

That's ok.  Any place to store the data is fine by me.  I'm just
concerned about some comments I saw in attrs.c <line13>:
/*
The basic design decision here is that we are not going to have insanely
large number of attributes.
This is a randomly chosen prime.
*/
#define HASHSIZE 257

Using a brute force perm/ownership attribute set for every file,
assuming a modestly populated linux distribution image having upwards of
150,000 files/directories in it, thats sticking over 100,000 attributes
into some .gitattributes file somewhere.  Do you think the gitattributes
system can handle this kind of abuse?

> If you had:
> 
> 	etc/*		owner=root
>         etc/frotz	owner=nobody
> 
> in gitattributes, and you did a checkout.  You chown etc/nitfol
> with "chown printer etc/nitfol".  Somebody needs to add a line
> 
> 	etc/nitfol	owner=printer
> 
> to gitattributes before you make the commit.

Unless this 'somebody' is an automated process that will never fly. I
want git to do it for me when the right config/attr is set (maybe at
update_index time).  Thats where my concern about the gitattributes
system comes from.  What's going to happen when I stick 150,000 (est)
attributes in there?

> Maybe the chown
> was not about etc/nitfol but about making etc/frotz owned by
> root.  Then you would, instead of adding the etc/nitfol line,
> remove existing etc/frotz line so that earlier glob would
> capture and express the idea of making everything owned by
> root.  I suspect this would get rather tricky quickly.

Maybe doable though.  Starting from the root of the tree, traverse
downwards and only add new attributes when a file or dir's ownership
has changed from the parent, maybe.  This could optimize away many of
the attributes needed.  I think a good place might be right in
index_path() because the lstat data is fresh and accessible.  Writing
attrs out to file if necessary should hopefully not add too much overhead.

-JE