Thread (6 messages) flat view 6 messages, 4 authors, 2016-06-15

Re: tracking perms/ownership

From: Josh England <hidden>
Date: 2016-06-15 22:43:30

On Fri, 2007-08-24 at 10:51 -0700, Linus Torvalds wrote:
Because full permissions and ownership (think ACL's) simply aren't 
"content" enough. The way to _reliably_ turn them into "content" that can 
be tracked, is to make it some form of file content.

Because otherwise, you will always hit situations where you simply cannot 
access it sanely. Even as an administrator you might need to do some 
emergency fixup, but you may be on vacation, and the only thing you have 
access to is some machine that you're not root on - and you'd like to send 
a "git bundle" with the fix to your less-than-stellar stand-in that is 
knee-deep in sh*t because he doesn't know the system, and you're on some 
sunny tropical island.
Using the .gitattributes approach essentially does turn perms/ownership
into trackable content.  A non-root user could specify the ownership of
certain files just by editing the .gitattributes, much in the same way a
non-root user can create an initramfs filesystem.
Or just imagine the case where you have slightly different setups for 
different people - some have ACL's, some have just basic permissions. But 
you want to maintain an image that works for both cases. What do you do?
punt  :)   Simple unix ownership and perms are a good first cut.  ACL's
could probably be handled in much the same way, but converting between
unix perms and ACLs might have to be a separate attribute/filter
entirely.
See? If you just accept the fact that ownership and permissions are 
totally "separate content" that is tracked AS CONTENT, and not as the 
filesystem thing, you solve all these problems.
quoted
git is a content _tracker_.  It tracks contents, also contents that
move around.  If it can't track the permissions moving around as well,
it's sort of pointless to integrate this into git: if you have to
manage the stuff yourself, anyway, there is no point in creating the
illusion that it is done by git.
Fair enough - I'll certainly agree with the notion that we don't 
necessarily need any integration of permissions/ownership into git at 
all, and you can always do it as a totally independent layer.
quoted
quoted
Your choice. But I know which one I'd choose.
That's fine.  But you don't actually need git at all to implement your
choice, so this is orthogonal to whether having an option to do it
inside of git might be worth having.
But I care about git having a *sane*design*, whether I use all the 
features or not. Because I simply care about my tools at a higher level 
than most users do. Which means that it doesn't matter whether I'll use 
permissions/ownership tracking or not - I still require that git do it 
*sanely* from my standpoint of having a good content tracker.

And that means tracking those things *separately*, and not trying to mess 
up the "tree" structure, for example.
Do you think its OK to cache this stuff in the index, though?
write-tree could then just dump the perms/ownership out as gitattributes
somewhere.

-JE
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help