Re: The future of gitweb - part 2: JavaScript

[Peter Vereshagin <peter@vereshagin.org>]

You're face to face with man who sold the world, Jakub!
2011/04/16 23:17:55 +0200 Jakub Narebski <jnareb@gmail.com> => 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