Re: tracking perms/ownership

From: Josh England <jjengla@sandia.gov>
Date: Aug 24, 2007, 18:15 UTC
Message-ID: <1187979317.6357.155.camel@beauty>
In-Reply-To: <alpine.LFD.0.999.0708241039250.25853@woody.linux-foundation.org>

On Fri, 2007-08-24 at 10:51 -0700, Linus Torvalds wrote:

Show 11 quoted lines

> 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.

Show 28 quoted lines

> 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.
> 
> > 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.
> 
> > > 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