Jeff Garzik wrote:

quoted text
> 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.
> 
> It's a great idea, something I would like to do, and something I've 
> suggested before.  You could dig through the mailing list archives, if 
> you're motivated.
> 
> I actively use git to version, store and distribute an exim mail 
> configuration across six servers.  So far my solution has been a 'fix 
> perms' script, or using the file perm checking capabilities of cfengine.

Fix perms' script used on a checkout hook is a best idea I think.
 
quoted text
> But it would be a lot better if git natively cared about ownership and 
> permissions (presumably via an option).

There is currently no place for ownership and extended attributes in
the tree object; and even full POSIX permissions might be challenge
because for example currently unused 'is socket' permission bit is
used for experimental commit-in-tree submodule support. And given Linus
stance that git is "content tracker"...

In the loooong thread "VCS comparison table" there was some talk
about using git (or any SCM) to manage /etc. Check out:

 * Message-ID: <Pine.LNX.4.64.0610220926170.3962@g5.osdl.org>
   http://permalink.gmane.org/gmane.comp.version-control.git/29765
 * Message-ID: <20061023051932.GA8625@evofed.localdomain>
   http://marc.theaimsgroup.com/?i=<20061023051932.GA8625@evofed.localdomain>

(and other messages in this subthread).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


-
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