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