Kyle Moffett wrote:
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.
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.
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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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