Re: Storing permissions

["David A. Wheeler" <dwheeler@dwheeler.com>]

Linus Torvalds wrote:
> 
> On Sat, 16 Apr 2005, Paul Jackson wrote:
> 
>>Morten wrote:
>>
>>>It makes some sense in principle, but without storing what they mean
>>>(i.e., group==?) it certainly makes no sense. 
>>
>>There's no "they" there.
>>
>>I think Martin's proposal, to which I agreed, was to store a _single_
>>bit.  If any of the execute permissions of the incoming file are set,
>>then the bit is stored ON, else it is stored OFF.  On 'checkout', if the
>>bit is ON, then the file permission is set mode 0777 (modulo umask),
>>else it is set mode 0666 (modulo umask).
> 
> 
> I think I agree.
> 
> Anybody willing to send me a patch? One issue is that if done the obvious
> way it's an incompatible change, and old tree objects won't be valid any
> more. It might be ok to just change the "compare cache" check to only care
> about a few bits, though: S_IXUSR and S_IFDIR.

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, so you can back up
your system to an arbitrary known state in the past
(e.g., "Change my /etc files to the state I was at
just before I installed that &*#@ program!").
For more on this, see:
  http://www.onlamp.com/pub/a/onlamp/2005/01/06/svn_homedir.html

If you store all the bits, then you CAN restore things
more exactly the way they were.  This is imperfect, since
it doesn't cover more exotic permission
values from SELinux, xattrs, whatever.  For some, that's enough.

Yeah, I know, not the main purpose of git.  But what the heck,
I _like_ flexible infrastructures.

--- David A. Wheeler