Wincent Colaiuta wrote: > So yes, this is discarding information -- in a sense it is actually > removing *correct* configuration from the server side to work around > undesired behaviour on the client side -- but it gave the behaviour I > wanted. So I think this patch is actually a good idea, because the > behaviour (the user experience) is more important than adhering to a > standard just because its a standard. Modifying gitweb to work around not configured web browser and mime.types not written for gitweb like in this RFC patch is one way of solving this. Is it good way? That is why it is an RFC... well that and details of sanitization. Another would be to use mime.types crafted specially for gitweb, and use it for $mimetypes_file (gitweb falls back to /etc/mime.types if it is not defined or not present). This might be better solution. QUESTION: Currently gitweb checks if $mimetypes_file is relative path (using nonportable m!^/! instead of File::Spec::file_name_is_absolute), and if it is then it is used as relative to project. Does anyone use this feature to provide per-project mimetypes? Would perhaps using relative path as-is (i.e. relative to gitweb script) be better solution, and checking for gitweb.mimetypes repo configuration variable for per-repo relative to project if relative? -- Jakub Narebski Poland - 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
