Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)

["Shawn O. Pearce" <spearce@spearce.org>]

David Lang <david.lang@digitalinsight.com> wrote:
> On Tue, 9 Jan 2007, Shawn O. Pearce wrote:
> >If the stat data is current it will leave it as-is.  You can force
> >the index to refresh with `git update-index --refresh` or by running
> >git status.
> 
> I was looking at checkout, not checkin so I'm not understanding how the 
> index is involved here.

During checkout we use the index to help us decide if a file needs
to be updated with new content or can be left as-is.  Its a cache of
what version each file is at, and its based on the file stat data
(dev, inode, modification date, etc.) to tell us if the file has
been modified or was last created by Git.  If Git was the one that
last modified the file and the version stored in the index matches
the version needed during the checkout, the file is left alone.
But if anything differs then the file gets overwritten.
 
> >>does this answer change if there is a trigger on checkout (to change
> >>permissions or otherwise manipulate the file)?
> >
> >Only if the trigger does something in addition, like force overwrite
> >files.  But we don't have a checkout trigger.  So there's no trigger.
> 
> we don't have a checkout trigger?

No.

> I thought that what Linus had suggested 
> for permissions was to have a script triggered on checkin that stored the 
> permissions of the files, and a script triggered on checkout that set the 
> permissions from the stored file.

Yes.  It is what he suggested.

> if there isn't a checkout trigger how would the permissions ever get set?

Someone needs to implement support for a post-checkout trigger.  _Then_
a checkout trigger could perform this action.

> in my particular case I'd like to have the checkin run a script that 
> produces a 'generic' version of each file,

You may be able to do that in the pre-commit hook by updating the index

-- 
Shawn.