Re: Storing permissions

From: David A. Wheeler <dwheeler@dwheeler.com>
Date: Apr 17, 2005, 16:21 UTC
Message-ID: <42628D1B.3000207@dwheeler.com>
In-Reply-To: <Pine.LNX.4.58.0504170857580.7211@ppc970.osdl.org>

Linus Torvalds wrote:

Show 16 quoted lines

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

...

Show 5 quoted lines

> 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