Re: The future of gitweb - part 2: JavaScript

[Jakub Narebski <jnareb@gmail.com>]

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