You're face to face with man who sold the world, Jakub! 2011/04/16 23:17:55 +0200 Jakub Narebski <jnareb@xxxxxxxxx> => To Peter Vereshagin : JN> > JN> No, fetching and pushing using HTTP transport, be it "smart" or "dumb" JN> > JN> Gitweb is web interface for _viewing and browsing_ repositories using JN> You can configure web server in such way that you can use the same JN> URL for fetching with git as for browsing repository with web browser There are more disadvantages of such an approach: - for CGI, the process is being executed on every request. On some systems, e. g., Windows, launching a process is very expensive, sometimes more than compiling of perl source itself. - for development, some different parts of the code for the same purpose do exist, e. g., client and storage i/o. The more it is being developed, the more features it satisfies, the more such a code. For example, I suppose git-http-backend will have 'get a particular commitdiff quickly without fetching all the repo' feature one day to be used in web clients' scripts, e. g. will serve the same way for git cli as a file system. This will make it have the same feature like 'commitdiff' feature of a gitweb but implemented differently. - the routing of the request, the deciding what to do with the particular HTTP request, becomes more obfuscated. First, web server decides what CGI should approve it. Plus two more decision makers are those 2 CGI, all different. It's just why I never supposed git to have 2 different native web interfaces, especially in sight of plumbing vs porcelain contrast in cli, sorry for confusion. 73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627) -- http://vereshagin.org -- 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