Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)

From: Andreas Ericsson <ae@op5.se>
Date: Dec 11, 2006, 10:39 UTC
Message-ID: <457D3573.2010001@op5.se>
In-Reply-To: <19476830-E30A-42B7-AD9B-4C417D830C8E@mac.com>

Kyle Moffett wrote:

Show 13 quoted lines

> On Dec 10, 2006, at 13:26:32, Jakub Narebski wrote:
>> The idea is to not store /etc in git directly, but use import/export 
>> scripts, which for example saves permissions and ownership in some 
>> file also tracked by git on import, and restores correct permissions 
>> on export. That is what I remember from this discussion. This of 
>> course means that you would have to write your own porcelain...
>>
>> What about mentioned in other email IsiSetup?
> 
> The real problem I have with that is you literally have to duplicate all 
> sorts of functionality.  I want to run "foo-status" in /etc and get 
> something useful, but if /etc is not a git directory in and of itself 
> then you have to duplicate most of "git-status" anyways.

Make /etc/.git a symlink to where you store your repo and go to the other directory when you want to *restore* configuration. The only "own porcelain" you need to write is a simple program that understands "save" and "restore" (or some such) and tucks away the meta-data in a file somewhere inside the git tree. If you make it in the format

octal-mode path/to/file

you can even get decently human-readable permission diffs, which will most likely be prettier and easier to read than anything git currently has.

Show 7 quoted lines

> 
> GIT already has _some_ idea about file permissions, it just discards 
> most of the data before writing to disk.   Of course, adding POSIX ACLs
> and user-extended-attributes requires a new data format, but those are 
> very similar to filesystem permissions; they differ only in amount of 
> data stored, not in purpose.
>

The amount of data stored is the issue here. The current implementation (which works just fine and does The Right Thing(tm) for code-repos) only stores what it has to and uses the spare bits to do other things.

Show 8 quoted lines

> Import/export scripts literally require wrapping every single GIT 
> command with a script that changes directory a few times, reads from a 
> different checked-out tree, and permutes some extended-attribute data 
> slightly before storing it in the underlying GIT tree.  Even without 
> adding any new functionality whatsoever that doubles the amount of code 
> just for finding your repository and checking command-line arguments, 
> and that's a crazy trade-off to make in any situation.
>

GIT_DIR=/some/where/else/.git git log -p

Why would you want to read from a different checked-out tree? Non-committed data is "changes", committed data is "HEAD" (or commit-ish) and marked data is "index". I see no reason what so ever for a second checked-out tree.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se