Re: tracking perms/ownership

["Josh England" <jjengla@sandia.gov>]

On Fri, 2007-08-24 at 11:23 -0700, Linus Torvalds wrote:
> 
> 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