Re: tracking perms/ownership

On Thu, 2007-08-23 at 15:08 -0700, Junio C Hamano wrote: 

"Josh England" [off-list ref] writes:

quoted

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