{"thread":{"id":"16063","subject":"problems with clone and .gitattributes","startedAt":"2008-10-27T18:46:41Z","lastAt":"2008-10-28T05:50:59Z","messageCount":2,"participants":["Leo Razoumov","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"94065","messageId":"ee2a733e0810271146r5b21213eg989045e4bf42d99a@mail.gmail.com","threadId":"16063","inReplyTo":null,"subject":"problems with clone and .gitattributes","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2008-10-27T18:46:41Z","receivedAt":"2008-10-27T18:46:41Z","isPatch":false,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"Hi Everyone,\nI am using .gitattributes with clean/smudge filters to optimize\nstorage of OpenOffice binary files (zip compressed). So far it works\nfine except for clone operation.\nApparently, \"git clone\" does not call smudge filter when checking out a branch.\nI have to manually remove openoffice files and then do \"git co -f\" to\nre-checkout them  again, this time smudge filter gets applied.\n\nThere is a little catch-22 problem here. .gitattributes are stored\nin-tree and git clone does not know about these files existence until\nit checks the tree out, by that time it is already too late to apply\nfilters.\n\nOf course, there could be several obvious workarounds:\n\n(1) git clone can redo checkout when it finds files affected by gitattributes\n\n(2) before doing checkout \"git clone\" inspects tree-object and looks\nfor .gitattributes files. If found it checks them out first before all\nother files. Now it can apply the attributes found as the checkout\nprocess progresses.\n\nIMHO, both workarounds are somewhat clumsy.\nIs there anything cleaner that can be done to solve the problem?\n\n--Leo--\n"},{"id":"94093","messageId":"20081028055058.GB23195@sigill.intra.peff.net","threadId":"16063","inReplyTo":"ee2a733e0810271146r5b21213eg989045e4bf42d99a@mail.gmail.com","subject":"Re: problems with clone and .gitattributes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-28T05:50:59Z","receivedAt":"2008-10-28T05:50:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 27, 2008 at 02:46:41PM -0400, Leo Razoumov wrote:\n\n> There is a little catch-22 problem here. .gitattributes are stored\n> in-tree and git clone does not know about these files existence until\n> it checks the tree out, by that time it is already too late to apply\n> filters.\n\nYes, this has been brought up on the list before.\n\n> Of course, there could be several obvious workarounds:\n> \n> (1) git clone can redo checkout when it finds files affected by gitattributes\n> \n> (2) before doing checkout \"git clone\" inspects tree-object and looks\n> for .gitattributes files. If found it checks them out first before all\n> other files. Now it can apply the attributes found as the checkout\n> process progresses.\n\nI think (2) is closer to the right solution. Though instead of changing\ncheckout order, I think .gitattributes should simply be able to look in\nan auxiliary tree (and checkout would feed the to-be-checked-out tree to\nthe attribute machinery). One concern, though, is how to handle\nconflicts between the tree we're moving _to_ and what's already in the\nworking tree. I would think that the tree we're moving to would take\nprecedence.\n\nI feel like Junio may have mentioned some of these issues in a mail the\nlast time this subject came up, but maybe I'm mis-remembering. Try\nsearching the archive.\n\n-Peff\n"}]}