Using clean/smudge scripts from repository

Using clean/smudge scripts from repository

[Bob Bell]

I'm setting up a clean/smudge filter for a repository.  In local testing 
it seemed to work well.  To allow for the clean/smudge scripts to be 
updated as the source changes, I put the clean/smudge scripts into the 
repository, and configured the filter in my ~/.gitconfig file to be 
simply "./filter --clean" and "./filter --smudge".

However, when cloning a fresh repository instance, that's breaking 
because a file with the filter set by .gitattributes is getting created 
BEFORE the filter script itself exists.

Playing around with things, I realized that alphabetically the filter 
script came after the filename being filtered.  So I renamed the filter 
to __filter, and that appears to have changed to order in which contents 
are created during "git clone".

Is this a proper solution, or did I just "luck out"?  Am I perhaps doing 
something foolish?

Thanks,
Bob

Re: Using clean/smudge scripts from repository

[Junio C Hamano]

Bob Bell <b_git@thebellsplace.com> writes:

> Is this a proper solution, or did I just "luck out"?  Am I perhaps
> doing something foolish?

Yes, we happen to run checkout in the index order, but that is not
something we guarantee, so you can call yourself lucky.  You are
being doubly lucky that nobody in your project is committing a
malicious script in the repository.  It may also count as foolish,
depending on how important the security is for you and how
trustworthy your collaborators are.

Re: Using clean/smudge scripts from repository

[Bob Bell]

On Wed, Jun 10, 2015 at 08:22:18AM -0700, Junio C Hamano wrote:
> Bob Bell <b_git@thebellsplace.com> writes:
> > Is this a proper solution, or did I just "luck out"?  Am I perhaps
> > doing something foolish?
> 
> Yes, we happen to run checkout in the index order, but that is not
> something we guarantee, so you can call yourself lucky.  You are
> being doubly lucky that nobody in your project is committing a
> malicious script in the repository.  It may also count as foolish,
> depending on how important the security is for you and how
> trustworthy your collaborators are.

Hrm, that's unfortunate.  So I gather it'll work, consistently, but
there's no guarantee that future versions of git won't break the
ordering assumption?  Is there anything available I can leverage here?
git has to at least assure that .gitattributes is checked out before the
files to which it could refer, right?

This is development in a corporate environment, and the collaborators
are trustworthy.  The alternative is to place the files on some network
share, where the same collaborators could edit it, etc.  But I was
hoping for a more self-contained solution, without such dependencies.

Thanks,
Bob