From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:30
"Josh England" [off-list ref] 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.
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. 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.
Of course, you would need to worry about resolving merge
conflicts of gitattributes file, too.
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.
Well, the nice thing is that even non-root can actually resolve merge
conflicts and generally use the archive, even if non-root obviously cannot
then actually set the files to those users/groups!
So handling ownership outside of the actual filesystem, in a separate file
that git tracks, actually allows you to do things that you couldn't
otherwise sanely do.
It obviously does have downsides:
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.
This is a direct consequence of allowing non-root to actually work with
such a repository: the git-tracked ownership information simply is
separate, and "git update-index" and friends will never do anything about
it, since they just can't rely on the *filesystem* user/group information
anyway (because normal users would never be allowed to set it, anyway).
Linus
From: Josh England <hidden> Date: 2016-06-15 22:43:30
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
From: Josh England <hidden> Date: 2016-06-15 22:43:30
On Thu, 2007-08-23 at 15:08 -0700, Junio C Hamano wrote:
Of course, you would need to worry about resolving merge
conflicts of gitattributes file, too.
I'm still confused on things. So, with all perms/ownership stored
as .gitattributes, would mucking around with the index still be
necessary? I'm not too sure what to do about merge conflicts.
-JE
From: Josh England <hidden> Date: 2016-06-15 22:43:30
On Fri, 2007-08-24 at 10:11 -0600, Josh England wrote:
On Thu, 2007-08-23 at 15:08 -0700, Junio C Hamano wrote:
quoted
Of course, you would need to worry about resolving merge
conflicts of gitattributes file, too.
I'm still confused on things. So, with all perms/ownership stored
as .gitattributes, would mucking around with the index still be
necessary? I'm not too sure what to do about merge conflicts.
OK, let me know if this is completely off-base. perms/ownership can be
stored in the index at update-index time and restored maybe at
checkout-index time. Calls to write-tree and read-tree can
store/retrieve the perms/ownership data from a .gitattributes file
somewhere; and something sane needs to be done about merging. Does this
sound reasonable enough for a first cut?
-JE