Re: tracking perms/ownership

From: Josh England <jjengla@sandia.gov>
Date: Aug 24, 2007, 07:38 UTC
Message-ID: <1187941133.6357.75.camel@beauty>
In-Reply-To: <alpine.LFD.0.999.0708232327100.25853@woody.linux-foundation.org>

On Thu, 2007-08-23 at 23:37 -0700, Linus Torvalds wrote:

Show 30 quoted lines

> 
> On Fri, 24 Aug 2007, David Kastrup wrote:
> > >
> > > So handling ownership outside of the actual filesystem, in a
> > > separate file that git tracks, actually allows you to do things that
> > > you couldn't otherwise sanely do.
> > 
> > Well, about that "sane" bit: I don't see an application for tracking
> > unrestorable ownership values.
> 
> Umm. Like an RPM spec file?
> 
> The thing you "don't see an application" for is exactly the kind of things 
> that people very much ALREADY DO. 
> 
> There are tons of different setups for setting up user and group ownership 
> (and things like permission) in almost any project. And I can pretty much 
> *guarantee* you that none of them depend on actually having ownership on 
> the files themselves.
> 
> In git, just for fun, do
> 
> 	git grep defattr
> 
> or even just look into the Makefile, and think about what lines like that
> 
> 	$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(bindir_SQ)'
> 
> thing means, and why it has a "755" there, and why other Makefiles quite 
> often have things like "-o bin" etc on such lines!

Yes. Permission bits are useful. I wouldn't want a umask clobbering some /bin directory to 0644 or some such.

> See? Those ownership things are restorable *as*root*, but that doesn't 
> mean that everybody should do development as root. In fact, I'd argue
>  that any system that is set up so that you have to develop and merge
>  things while being root is pretty damn broken.

If your repository is a full system image (my extreme case), developing as root (installing packages, altering configs) is *required* if you expect the image to boot/behave properly. Squashing ownership in this case would undoubtedly break many things.

Show 6 quoted lines

> Which means that any such environment *has* to encode the owndership 
> *separately* from the actual filesystem ownership. Because doing it in the 
> filesystem simply isn't sane.
> 
> So yes, you could have an insane piece of crap that actually tracks file 
> ownership in the filesystem, and requires people to be root.

This is what I've done with SVN. The mechanisms to save/restore perms/ownership can be run as hooks before checkin and after checkout. The performance is pretty depressing even without running those hooks every time. I'm just hoping that using .gitattribues will perform reasonably well.

> Or you could use a ".gitattributes" file or similar _external_ tracking 
> method that allows even people who cannot actually set ownership to work 
> with it.

Yes, although it would be nice if a clone or a pull tells me (running as a user) that the ownership being set doesn't match the uid/gid in the attribute file. Element of least surprise. For those actually requesting the behavior, a little extra verbosity seems pretty acceptable.

-JE