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