David Lang <david.lang@digitalinsight.com> wrote:
quoted text
> 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.
 
quoted text
> >>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.

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

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

quoted text
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html