Re: tracking perms/ownership

From: Josh England <jjengla@sandia.gov>
Date: Aug 24, 2007, 18:56 UTC
Message-ID: <1187981803.6357.173.camel@beauty>
In-Reply-To: <alpine.LFD.0.999.0708241119140.25853@woody.linux-foundation.org>

On Fri, 2007-08-24 at 11:23 -0700, Linus Torvalds wrote:

Show 13 quoted lines

> 
> On Fri, 24 Aug 2007, Josh England wrote:
> > 
> > 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