Re: tracking perms/ownership

On Fri, 24 Aug 2007, David Kastrup wrote:

quoted

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