Re: Storing permissions

On Sun, 17 Apr 2005, David A. Wheeler wrote:

Yes. I was actually thinking about having system config files in a git repository when I started it, since I noticed how nicely it would do exactly that.

However, since the mode bits also end up being part of the name of the tree object (ie they are most certainly part of the hash), it's really basically impossible to only care about one bit but writing out many bits: it's the same issue of having multiple "identical" blocks with different names.

It's ok if it happens occasionally (it _will_ happen at the point of a tree conversion to the new format, for example), but it's not ok if it happens all the time - which it would, since some people have umask 002 (and individual groups) and others have umask 022 (and shared groups), and I can imagine that some anal people have umask 0077 ("I don't want to play with others").

The trees would constantly bounce between a million different combinations (since _some_ files would be checked out with the "other" mode).

At least if you always honor umask or always totally ignore umask, you get a nice repetable thing. We tried the "always ignore" umask thing, and the problem with that is that while _git_ ended up always doing a "fchmod()" to reset the whole permission mask, anybody who created files any other way and then checked them in would end up using umask.

One solution is to tell git with a command line flag and/or config file entry that "for this repo, I want you to honor all bits". That should be easy enough to add at some point, and then you really get what you want.

That said, git won't be really good at doing system backup. I actually _do_ save a full 32-bit of "mode" (hey, you could have "immutable" bits etc set), but anybody who does anything fancy at all with mtime would be screwed, for example.

Also, right now we don't actually save any other type of file than regular/directory, so you'd have to come up with a good save-format for symlinks (easy, I guess - just make a "link" blob) and device nodes (that one probably should be saved in the "cache_entry" itself, possibly encoded where the sha1 hash normally is).

Also, I made a design decision that git only cares about non-dotfiles. Git literally never sees or looks at _anything_ that starts with a ".". I think that's absolutely the right thing to do for an SCM (if you hide your files, I really don't think you should expect the SCM to see it), but it's obviously not the right thing for a backup thing.

(It _might_ be the right thing for a system config file, though, eg tracking something like "/etc" with git might be ok, modulo the other issues).

			Linus