{"thread":{"id":"39578","subject":"Using clean/smudge scripts from repository","startedAt":"2015-06-10T01:53:50Z","lastAt":"2015-06-10T20:55:43Z","messageCount":3,"participants":["Bob Bell","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"263429","messageId":"20150610015349.GA5417@robin.thebellsplace.net","threadId":"39578","inReplyTo":null,"subject":"Using clean/smudge scripts from repository","fromName":"Bob Bell","fromEmail":"b_git@thebellsplace.com","sentAt":"2015-06-10T01:53:50Z","receivedAt":"2015-06-10T01:53:50Z","isPatch":false,"sender":{"key":"b_git@thebellsplace.com","avatar":null},"body":"I'm setting up a clean/smudge filter for a repository.  In local testing \nit seemed to work well.  To allow for the clean/smudge scripts to be \nupdated as the source changes, I put the clean/smudge scripts into the \nrepository, and configured the filter in my ~/.gitconfig file to be \nsimply \"./filter --clean\" and \"./filter --smudge\".\n\nHowever, when cloning a fresh repository instance, that's breaking \nbecause a file with the filter set by .gitattributes is getting created \nBEFORE the filter script itself exists.\n\nPlaying around with things, I realized that alphabetically the filter \nscript came after the filename being filtered.  So I renamed the filter \nto __filter, and that appears to have changed to order in which contents \nare created during \"git clone\".\n\nIs this a proper solution, or did I just \"luck out\"?  Am I perhaps doing \nsomething foolish?\n\nThanks,\nBob\n"},{"id":"263480","messageId":"xmqq1thjoafp.fsf@gitster.dls.corp.google.com","threadId":"39578","inReplyTo":"20150610015349.GA5417@robin.thebellsplace.net","subject":"Re: Using clean/smudge scripts from repository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-06-10T15:22:18Z","receivedAt":"2015-06-10T15:22:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bob Bell <b_git@thebellsplace.com> writes:\n\n> Is this a proper solution, or did I just \"luck out\"?  Am I perhaps\n> doing something foolish?\n\nYes, we happen to run checkout in the index order, but that is not\nsomething we guarantee, so you can call yourself lucky.  You are\nbeing doubly lucky that nobody in your project is committing a\nmalicious script in the repository.  It may also count as foolish,\ndepending on how important the security is for you and how\ntrustworthy your collaborators are.\n"},{"id":"263528","messageId":"20150610205542.GB5417@robin.thebellsplace.net","threadId":"39578","inReplyTo":"xmqq1thjoafp.fsf@gitster.dls.corp.google.com","subject":"Re: Using clean/smudge scripts from repository","fromName":"Bob Bell","fromEmail":"b_git@thebellsplace.com","sentAt":"2015-06-10T20:55:43Z","receivedAt":"2015-06-10T20:55:43Z","isPatch":false,"sender":{"key":"b_git@thebellsplace.com","avatar":null},"body":"On Wed, Jun 10, 2015 at 08:22:18AM -0700, Junio C Hamano wrote:\n> Bob Bell <b_git@thebellsplace.com> writes:\n> > Is this a proper solution, or did I just \"luck out\"?  Am I perhaps\n> > doing something foolish?\n> \n> Yes, we happen to run checkout in the index order, but that is not\n> something we guarantee, so you can call yourself lucky.  You are\n> being doubly lucky that nobody in your project is committing a\n> malicious script in the repository.  It may also count as foolish,\n> depending on how important the security is for you and how\n> trustworthy your collaborators are.\n\nHrm, that's unfortunate.  So I gather it'll work, consistently, but\nthere's no guarantee that future versions of git won't break the\nordering assumption?  Is there anything available I can leverage here?\ngit has to at least assure that .gitattributes is checked out before the\nfiles to which it could refer, right?\n\nThis is development in a corporate environment, and the collaborators\nare trustworthy.  The alternative is to place the files on some network\nshare, where the same collaborators could edit it, etc.  But I was\nhoping for a more self-contained solution, without such dependencies.\n\nThanks,\nBob\n"}]}