Re: tracking perms/ownership

On Fri, 24 Aug 2007, David Kastrup wrote:

quoted

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