Re: tracking perms/ownership

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Aug 24, 2007, 06:37 UTC
Message-ID: <alpine.LFD.0.999.0708232327100.25853@woody.linux-foundation.org>
In-Reply-To: <85ir75h2zb.fsf@lola.goethe.zz>

On Fri, 24 Aug 2007, David Kastrup wrote:

Show 7 quoted lines

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

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.

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.

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.

Your choice. But I know which one I'd choose.

			Linus