On Mon, Oct 27, 2008 at 02:46:41PM -0400, Leo Razoumov wrote: > There is a little catch-22 problem here. .gitattributes are stored > in-tree and git clone does not know about these files existence until > it checks the tree out, by that time it is already too late to apply > filters. Yes, this has been brought up on the list before. > Of course, there could be several obvious workarounds: > > (1) git clone can redo checkout when it finds files affected by gitattributes > > (2) before doing checkout "git clone" inspects tree-object and looks > for .gitattributes files. If found it checks them out first before all > other files. Now it can apply the attributes found as the checkout > process progresses. I think (2) is closer to the right solution. Though instead of changing checkout order, I think .gitattributes should simply be able to look in an auxiliary tree (and checkout would feed the to-be-checked-out tree to the attribute machinery). One concern, though, is how to handle conflicts between the tree we're moving _to_ and what's already in the working tree. I would think that the tree we're moving to would take precedence. I feel like Junio may have mentioned some of these issues in a mail the last time this subject came up, but maybe I'm mis-remembering. Try searching the archive. -Peff -- 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
