On Sun, 10 Dec 2006, Kyle Moffett wrote:

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html