On Sun, 10 Dec 2006, Kyle Moffett wrote: > I've recently become somewhat interested in the idea of using GIT to store the > contents of various folders in /etc. However after a bit of playing with > this, I discovered that GIT doesn't actually preserve all permission bits > since that would cause problems with the more traditional software development > model. I'm curious if anyone has done this before; and if so, how they went > about handling the permissions and ownership issues. > > I spent a little time looking over how GIT stores and compares permission > bits; trying to figure out if it's possible to patch in a new configuration > variable or two; say "preserve_all_perms" and "preserve_owner", or maybe even > "save_acls". It looks like standard permission preservation is fairly basic; > you would just need to patch a few routines which alter the permissions read > in from disk or compare them with ones from the database. On the other hand, > it would appear that preserving ownership or full POSIX ACLs might be a bit of > a challenge. The first thing you'd want to do is correct the fact that the index doesn't keep full permissions. We decided long ago that we don't want to track more than 0100, but we're discarding the rest between the filesystem and the index, rather than between the index and the tree. (This is weird of us, since we keep gid and uid in the index, as changedness heuristics, but don't keep permissions; of course, we'd have to apply umask to the index when we check it out to sync what we expect to be there with what has actually been created.) I think that would be the only change needed to the index and index/working directory connection, although it might be necessary to support longer values for uid/gid/etc, since they'd be important data now. Note that git only stores content, not incidental information. But a lot of information which is incidental in a source tree is content in /etc. This implies that /etc and working/linux-2.6 are fundamentally different sorts of things, because different aspects of them are content. I'd suggest a new object type for a directory with permissions, ACLs, and so forth. It should probably use symbolic owner and group, too. My guess is that you'll want to use "commit"s, the new object type, and "blob"s. Everything that uses trees would need to have a version that uses the new type. But I think that you generally want different behavior anyway, so that's not a major issue. -Daniel *This .sig left intentionally blank* - 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