From: David Kastrup <hidden> Date: 2016-06-15 22:43:30
[copied to gmane after sending personal copy by accident, since mails
of me don't arrive on the list from my work account. Sorry for the
duplication.]
Linus Torvalds [off-list ref] writes:
[make install]
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.
But in this case you have a work directory and an installation
directory. And you have an installation procedure. No tracking is
involved at all.
So yes, you could have an insane piece of crap that actually tracks
file ownership in the filesystem, and requires people to be root.
In your example, neither installed files nor ownership are tracked in
the filesystem. Both are "tracked" in the Makefile. Or rather than
being tracked, they are explicitly catered for by the user.
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.
git is a content _tracker_. It tracks contents, also contents that
move around. If it can't track the permissions moving around as well,
it's sort of pointless to integrate this into git: if you have to
manage the stuff yourself, anyway, there is no point in creating the
illusion that it is done by git.
Your choice. But I know which one I'd choose.
That's fine. But you don't actually need git at all to implement your
choice, so this is orthogonal to whether having an option to do it
inside of git might be worth having.
--
David Kastrup
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.
But in this case you have a work directory and an installation
directory. And you have an installation procedure. No tracking is
involved at all.
I agree that the cases are different.
I also agree that a tool that is *specialized* to only do basically
backups (or, equivalently, "distributed installation") would potentially
be a different issue, and there "it will only run as root" is a reasonable
thing to do.
But git is, if anything, specialized the other way - which means that I
think it's perfectly fine to let it know about ownership, but it's *not* a
valid thing to do to then say "only root can do it".
Also, even with a distributed installer/backup thing, the fact is,
"ownership" and "permissions" is simply not well-defined at a filesystem
level. Are we talking just unix owner/group/mode here? That won't do for a
lot of filesystems that have ACL's or other extended user/permission
information.
In your example, neither installed files nor ownership are tracked in
the filesystem. Both are "tracked" in the Makefile. Or rather than
being tracked, they are explicitly catered for by the user.
And I seriously am saying that that is the only way to handle things
sanely in a distributed content tracker like git.
Because full permissions and ownership (think ACL's) simply aren't
"content" enough. The way to _reliably_ turn them into "content" that can
be tracked, is to make it some form of file content.
Because otherwise, you will always hit situations where you simply cannot
access it sanely. Even as an administrator you might need to do some
emergency fixup, but you may be on vacation, and the only thing you have
access to is some machine that you're not root on - and you'd like to send
a "git bundle" with the fix to your less-than-stellar stand-in that is
knee-deep in sh*t because he doesn't know the system, and you're on some
sunny tropical island.
Or just imagine the case where you have slightly different setups for
different people - some have ACL's, some have just basic permissions. But
you want to maintain an image that works for both cases. What do you do?
See? If you just accept the fact that ownership and permissions are
totally "separate content" that is tracked AS CONTENT, and not as the
filesystem thing, you solve all these problems.
git is a content _tracker_. It tracks contents, also contents that
move around. If it can't track the permissions moving around as well,
it's sort of pointless to integrate this into git: if you have to
manage the stuff yourself, anyway, there is no point in creating the
illusion that it is done by git.
Fair enough - I'll certainly agree with the notion that we don't
necessarily need any integration of permissions/ownership into git at
all, and you can always do it as a totally independent layer.
quoted
Your choice. But I know which one I'd choose.
That's fine. But you don't actually need git at all to implement your
choice, so this is orthogonal to whether having an option to do it
inside of git might be worth having.
But I care about git having a *sane*design*, whether I use all the
features or not. Because I simply care about my tools at a higher level
than most users do. Which means that it doesn't matter whether I'll use
permissions/ownership tracking or not - I still require that git do it
*sanely* from my standpoint of having a good content tracker.
And that means tracking those things *separately*, and not trying to mess
up the "tree" structure, for example.
Linus
From: Josh England <hidden> Date: 2016-06-15 22:43:30
On Fri, 2007-08-24 at 10:51 -0700, Linus Torvalds wrote:
Because full permissions and ownership (think ACL's) simply aren't
"content" enough. The way to _reliably_ turn them into "content" that can
be tracked, is to make it some form of file content.
Because otherwise, you will always hit situations where you simply cannot
access it sanely. Even as an administrator you might need to do some
emergency fixup, but you may be on vacation, and the only thing you have
access to is some machine that you're not root on - and you'd like to send
a "git bundle" with the fix to your less-than-stellar stand-in that is
knee-deep in sh*t because he doesn't know the system, and you're on some
sunny tropical island.
Using the .gitattributes approach essentially does turn perms/ownership
into trackable content. A non-root user could specify the ownership of
certain files just by editing the .gitattributes, much in the same way a
non-root user can create an initramfs filesystem.
Or just imagine the case where you have slightly different setups for
different people - some have ACL's, some have just basic permissions. But
you want to maintain an image that works for both cases. What do you do?
punt :) Simple unix ownership and perms are a good first cut. ACL's
could probably be handled in much the same way, but converting between
unix perms and ACLs might have to be a separate attribute/filter
entirely.
See? If you just accept the fact that ownership and permissions are
totally "separate content" that is tracked AS CONTENT, and not as the
filesystem thing, you solve all these problems.
quoted
git is a content _tracker_. It tracks contents, also contents that
move around. If it can't track the permissions moving around as well,
it's sort of pointless to integrate this into git: if you have to
manage the stuff yourself, anyway, there is no point in creating the
illusion that it is done by git.
Fair enough - I'll certainly agree with the notion that we don't
necessarily need any integration of permissions/ownership into git at
all, and you can always do it as a totally independent layer.
quoted
quoted
Your choice. But I know which one I'd choose.
That's fine. But you don't actually need git at all to implement your
choice, so this is orthogonal to whether having an option to do it
inside of git might be worth having.
But I care about git having a *sane*design*, whether I use all the
features or not. Because I simply care about my tools at a higher level
than most users do. Which means that it doesn't matter whether I'll use
permissions/ownership tracking or not - I still require that git do it
*sanely* from my standpoint of having a good content tracker.
And that means tracking those things *separately*, and not trying to mess
up the "tree" structure, for example.
Do you think its OK to cache this stuff in the index, though?
write-tree could then just dump the perms/ownership out as gitattributes
somewhere.
-JE
Do you think its OK to cache this stuff in the index, though?
write-tree could then just dump the perms/ownership out as gitattributes
somewhere.
I'd really prefer not.
The index state - very much by design - matches the filesystem "stat"
data, not the internal git data. So "ce_size" matches the checked-out
size, not the native git data size (ie with CRLF conversion, it matches
not the checked-in data, but the filesystem version).
And the same really goes for ce_uid/ce_gid: they have to match what's on
the filesystem, because they are used not to track user information, but
to verify that the inode data is valid!
Yeah, we could just ignore them for checking "is the inode the same", but
that would actually end up *defeating* the point of what you want to do:
at that point, we'd also obviously ignore it when ownership changes!
Linus
From: Josh England <hidden> Date: 2016-06-15 22:43:30
On Fri, 2007-08-24 at 11:23 -0700, Linus Torvalds wrote:
On Fri, 24 Aug 2007, Josh England wrote:
quoted
Do you think its OK to cache this stuff in the index, though?
write-tree could then just dump the perms/ownership out as gitattributes
somewhere.
I'd really prefer not.
The index state - very much by design - matches the filesystem "stat"
data, not the internal git data. So "ce_size" matches the checked-out
size, not the native git data size (ie with CRLF conversion, it matches
not the checked-in data, but the filesystem version).
That's exactly what I'm after, too: having a snapshot of all lstat data
in the index, because I don't want to have to do an extra stat
somewhere.
And the same really goes for ce_uid/ce_gid: they have to match what's on
the filesystem, because they are used not to track user information, but
to verify that the inode data is valid!
But the stat data (even uid/gid) is in there nonetheless, right? If
everything is in there already I wouldn't need to add a thing. I just
want to access the index cache rather than hitting the filesystem
directly.
Yeah, we could just ignore them for checking "is the inode the same", but
that would actually end up *defeating* the point of what you want to do:
at that point, we'd also obviously ignore it when ownership changes!
If we view the index as being a snapshot of the filesystem, and if
perm/ownership data is stored as .gitattributes in the actual repo,
then the perm/ownership engine just has to reconcile between the index
and the .gitattributes file for both the read and write case.
Differences in the write case would result in the .gitattributes being
updated. Differences in the read case would result in chown/chmod being
run in the working tree. Does this make sense?
-JE
From: Robin Rosenberg <hidden> Date: 2016-06-15 22:43:30
fredag 24 augusti 2007 skrev Josh England:
punt :) Simple unix ownership and perms are a good first cut. ACL's
could probably be handled in much the same way, but converting between
unix perms and ACLs might have to be a separate attribute/filter
entirely.
You cannot convert between traditional unix permissisons and ACL:s. Either you
manage ACL:s or not. The traditional form is fortunately just a special case of posix
ACL:s. Here is a getfacl example. Just feed it to setfacl to set permissions according
to the dump.
$ getfacl README
# file: README
# owner: me
# group: me
user::rw-
group::r--
group:apache:rwx
mask::rwx
other::r--
Windows ACL.s are different though.
-- robin