Alex Riesen <raa.lkml@xxxxxxxxx> writes: > Imagine a project which started using the attributes at some point of > time. And imagine developers whose repos suddenly start breaking > because of clueless integrator created a filter which does not work > anywere but his system (typical, really) and didn't tell anyone to > update their configuration (whereas .gitattribute files are in working > trees already). That's one of the reasons why only the filter names are assigned to paths using gitattributes mechanism and what action to take when a specific filter name is attached to a path is determined by the config. Missing filter driver definition in the config is not an error but makes the filter a no-op passthru. The content filtering is to massage the content into a shape that is more convenient for the platform/filesystem/the user to use. The keyword here is "more convenient" and not "usable"; in other words, it is "hanging yourself because we gave you a long rope" if your project tries to do something with the filtering mechanism to make your project unusable unless the checkout is done with specific filter in effect. So defaulting to passthru is meant to fall-back on the plain-old inconvenient checkout, which is not a bad thing. > How do you suggest to distribute filter configurations, BTW? The same project description message the participant learn about the project that says the public repository locations and such, and perhaps in-tree READ.ME file. The earlier example I gave would fit this pattern rather well. If somebody (me) cannot deal with UTF-8 encoded Japanese text very well, that user personally can mark such a file in $GIT_DIR/info/attributes as 'filter=utf8-japanese-text' and define the iconv based filtering driver in $GIT_DIR/config in the repository that he (me) uses for editing. In addition, I would most likely have another repository that does not have the filtering driver defined, and that would be where I would run the build tools for documentation part, since the project documentation is supposed to be in UTF-8. This is a "purely personal" setting that does not have to be known to the outside world. But the filter=utf8-japanese-text attribute could be shared in-tree if the project has more then one person with difficulty dealing with UTF-8 encoded Japanese text. I may personally edit the file after having iconv convert to EUC-JP and convert it back to UTF-8 when checking in, but the other person may use local encoding different from EUC-JP for editing. In such a case, only the definition in our config files are different, and in-tree Documentation/.gitattributes file would have git-lost-found.txt filter=utf8-japanese-text which is distributed project-wide. Repositories used by people who do not have trouble handling UTF-8 encoded Japanese text would not have any filtering driver defined for utf8-japanese-text in their $GIT_DIR/config, and their checkout would be in UTF-8, because of this passthru behaviour. > How about checkout performance impact? Measurement would be interesting; I haven't done it, and that is one of the smaller reasons I am not particularly keen on pushing the 'filter' attribute. Hawk-eyed people might have noticed that I swapped the order of the series in 'pu' to have 'ident' first and then 'filter'. - 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