Re: tracking perms/ownership

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Aug 24, 2007, 17:51 UTC
Message-ID: <alpine.LFD.0.999.0708241039250.25853@woody.linux-foundation.org>
In-Reply-To: <86mywhfk17.fsf@lola.quinscape.zz>

On Fri, 24 Aug 2007, David Kastrup wrote:

Show 8 quoted lines

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

Show 5 quoted lines

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

Show 5 quoted lines

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