On Fri, Oct 22, 2010 at 11:28:44AM -0700, Joshua Juran wrote: > >What's wrong with .gitattributes for this use case? I would think a > >clean/smudge filter would produce very good behavior from most git > >commands. > > I wrote a Mac<->UTF-8 converter in C++ and set it as the clean/smudge > filter for .r (Rez) files. Checkouts were noticeably slower (on a > real machine, not one of my antiques). This would be much worse if I > also applied it to C and C++ source files (most, but not all, of > which are ASCII anyway). Not surprising, as you were probably running your filter a lot. Clean and smudge could perhaps benefit from the same notes-caching layer that textconv uses (caching the "smudged" version of each clean file). But that would only impact checkout. Most other operations use the "clean" representation already, so they should be full-speed. You could also cache the other way (mapping smudged sha1's into clean sha1's). But I doubt that would do you any good. We generally see those when updating the index with "git add", which means either the stat information is clean (and we don't have the clean the file) or it isn't (in which case you probably have new content that has not been seen before, which means a cache miss). And of course it doesn't help the other clean/smudge inconveniences you ran into. -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