Re: Storing permissions

From: David A. Wheeler <dwheeler@dwheeler.com>
Date: 2005-04-18 02:21:47
Linus Torvalds wrote:
> 
> 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.
...
> 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.

Yes, I thought of that too.  And I agree, that should do the job.

My real concern is I'm looking at the early design of the
storage format so that it's POSSIBLE to extend git in obvious ways.
As long as it's possible later, then that's a great thing.

...
> 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.

Again, a command line flag or config file entry could change that
in the future, if desired.  So this is a decision that could be
changed later... the best kind of decision :-).

--- David A. Wheeler
-
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
Received on Mon Apr 18 02:20:09 2005

This archive was generated by hypermail 2.1.8 : 2005-04-18 02:20:09 EST