Re: The future of gitweb - part 2: JavaScript

On Sat, 16 Apr 2011, Peter Vereshagin wrote:

You're face to face with man who sold the world, Jakub!
2011/04/16 23:17:55 +0200 Jakub Narebski [off-list ref] => 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>
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.

You can run gitweb as a persistent web app, using it either as FastCGI
script, or via mod_perl + ModPerl::Registry.

git-http-backend is written in C, not Perl.

- 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.

Gitweb is written in Perl.  This language is good for prototyping, for
fast development, and for easy writing of a web app.  Gitweb works on
porcelain level - it is an user interface (a web one).

C is good for performance.  git-http-backend is only an example
implementation.  The "smart" HTTP protocol works on porcelain level.

  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.

Unix philosophy which Git tries to follow is "do one thing and do it
well".

I don't believe git-http-backend would ever talk to web browsers, and
it is quite unlikely for git to acquire non-distributed client-server
mode.

And if it does acquire such feature, then gitweb will be simply modified
to use it...

- 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.

Those are not two _web interfaces_.  Gitweb is one of web interfaces
to git repositories; more at
  https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Web_Interfaces

Fetching and pushing via HTTP is not web interface, is HTTP _transport_.
For one you use web browser, for other you use git itself.


But this discussion got very off-topic...
-- 
Jakub Narebski
Poland