On Sun, 17 Apr 2005, David A. Wheeler wrote:
>
> There's a minor reason to write out ALL the perm bit data, but
> only care about a few bits coming back in: Some people use
> SCM systems as a generalized backup system
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
