From: David A. Wheeler Date: Sun, 17 Apr 2005 06:22:10 GMT Subject: Re: Storing permissions Message-ID: <42620092.9040402@dwheeler.com> In-Reply-To: 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