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

So, I've been making little repositories for appropriately related
stuff.  For example, I have a repository for my ~/.bashrc,
~/.bash_profile, ~/.bash_completions/*, and such.

I recall Linus's post in the "VCS Comparison Table" thread, and after
thinking about it, I decided the best thing to do would be to have a
couple extra files tracked in the repository, alongside other data.

I use a backup shell script to copy things from my system to the
repository, and then I run getfacl on it all to write out all the
details to a 'facl' file in my repository.  Then I can make a commit.

Then there's a restore shell script to copy things back to my system,
and restore ownership and permissions with setfacl.

I store the backup and restore scripts in the repository.  Paths are
currently hard-coded.  I'm sure there's a more flexible way to do
this, though I'd need some means of representing the correspondence
between content in the repository and files in my filesystem.


On 12/13/06, Daniel Barkalow [off-list ref] wrote:

On Tue, 12 Dec 2006, Kyle Moffett wrote:

quoted

Hmm, ok.  It would seem to be a reasonable requirement that if you want to
change any of the "preserve_*_attributes" config options you need to blow

away

quoted

and recreate your index, no?  I would probably change the underlying index
format pretty completely and stick a new version tag inside it.

You should be able to promote an insufficient-version index to a
new-version index that's needs to be refreshed for every entry. (And then
update-index would take care of the necessary rewrite-everything in the
normal way). But I suspect that the right thing is to require that the
repository be created with a "commits-include-directories-not-trees" flag,
and this means that you always use the extra-detailed index, and the
options only affect what information is filtered out in transit between
the directory object and the index. Having more information in the index
is merely a potential waste of space, not a correctness issue (we have
extra information for trees in the index now, remember); it just means
that there are more things that will cause git to reread the file, rather
than declaring it unchanged with a stat().

For that matter, it may be best for the directory objects to record what
information in them is real, and keep the "what's content" mask in the
index as well. If it changes over the history of a repository, you want to
correctly interpret the historical commits.

quoted

Ok, seems straightforward enough.  One other thing that crossed my mind

was

quoted

figuring out how to handle hardlinks.  The simplest solution would be to

add

quoted

an extra layer of indirection between the "file inode" and the "file

data".

quoted

Instead of your directory pointing to a "file-data" blob and

"file-attributes"

quoted

object, it would point to an "file-inode" object with embedded attribute

data

quoted

and a pointer to the file contents blob.

I remember reading some discussions from the early days of GIT about how

that

quoted

was considered and discarded because the extra overhead wouldn't give any

real

quoted

tangible benefit.  On the other hand for something like /etc the added
benefits of tracking extended attributes and hardlinks might outweigh the

cost

quoted

of a bunch of extra objects in the database.  A bit of care with the
construction of the index file should make it sufficiently efficient for
day-to-day usage.

I was thinking this could be internal to the directory object, but you
probably want to support hardlinks shared between dentries in different
directory objects, so you're probably right that this makes sense.

Alternatively, you could use a single "directory" object for the whole
state (including subdirectories), making hardlinks out of the object
clearly impossible, or you could use some scheme for sharing
sub-"directory" objects that would imply that hardlinks are within an
object (the hard part here is finding things when their locations aren't
predictable by name).

	-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

-- 
epistemological humility