Linus Torvalds [off-list ref] writes:
On Thu, 23 Aug 2007, Junio C Hamano wrote:
quoted
"Josh England" [off-list ref] writes:
quoted
Looking at the index struct, it already has fields in it for file mode
uid and gid (woohoo!).
I can see that storing textual names in gitattributes and having
the root user run git so that it can chown(), would work.
Well, the nice thing is that even non-root can actually resolve
merge conflicts and generally use the archive, even if non-root
obviously cannot then actually set the files to those users/groups!
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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
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
On Thu, 2007-08-23 at 23:37 -0700, Linus Torvalds wrote:
On Fri, 24 Aug 2007, David Kastrup wrote:
quoted
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!
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.
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