On 4/23/07, Junio C Hamano <junkio@xxxxxxx> wrote:
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.
Fragile. What if content is useless without filter? How does the user know about the fact so he can work the problem around? What if you have multiple filters matching the same path? (does not seem to be possible. Someone will ask you why)
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
how can "not usable" be "more convenient"?
> 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.
But there seem to be no way to notice that the READ.ME should be reread by project participants downstream.
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.
which will be a PITA to setup in each and every clone of the repository, unless it is cloned with the repo. - 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