On Fri, Jan 2, 2009 at 3:21 AM, Devin Doucette <devin@xxxxxxxxxxx> wrote: > On Thu, Jan 1, 2009 at 5:46 PM, Giuseppe Bilotta > <giuseppe.bilotta@xxxxxxxxx> wrote: >> Actually, the early bailout was sort of intentional. The problem is >> the ambiguity: does git.example.com/opml refer to the opml project, or >> does it refer to the opml action? > > Good point. Though my patch does not break any existing functionality, > it does not fix the case where a project matches the action. > >> HOWEVER, href() *does* create the opml action as git.example.com/opml, >> so gitweb is currently broken in the sense that ti doesn't correctly >> parse its own pathinfo output. So the question is: shall we go with >> this patch, preventing pathinfo from working for projects named like a >> no-project gitweb action, or should we fix href() to not generate >> pathinfo unless project is defined? > > A variation of the latter approach is to modify href() to use pathinfo > if there is a project or there is no project matching the name of the > action. The only downside to this approach is that a URI that refers to > an action when first generated could resolve to a project in the future, > if a project of the same name were added. And don't forget the case of a new action being introduced which is named like an existing project. I suspect we'd be much better off by not using pathinfo at all for global actions. Other possible solutions would be to have something like an ADDITIONAL prefix to the path (like project/projectname vs action/actionname, so we would have git.example.com/action/opml or git.example.com/project/example-project) but this is WAY too verbose. At most, we could add a suffix to global actions to reduce the chance of name conflict, such as using git.example.com/opml.xml or git.example.com/project_index.txt but I don't like these solution either: I'd rather have these be provided as filenames in the response header. Incoming patch to not make use of path_info without project. -- Giuseppe "Oblomov" Bilotta -- 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
