On Thu, 2007-08-23 at 15:08 -0700, Junio C Hamano wrote: > "Josh England" <jjengla@xxxxxxxxxx> 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 - 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
