threads / discuss / 39578

Using clean/smudge scripts from repository

Subject: Using clean/smudge scripts from repository

## tl;dr

3 messages between Jun 10, 2015 and Jun 10, 2015.

replies: 2people: 2as markdown or json

Bob Bell· Jun 10, 2015, 01:53 UTC · lore

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

Junio C Hamano· Jun 10, 2015, 15:22 UTC · re: Bob Bell · lore

Re: Using clean/smudge scripts from repository

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.

Bob Bell· Jun 10, 2015, 20:55 UTC · re: Junio C Hamano · lore

Re: Using clean/smudge scripts from repository

On Wed, Jun 10, 2015 at 08:22:18AM -0700, Junio C Hamano wrote:

Show 10 quoted lines

> 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