Dnia czwartek 15. kwietnia 2010 06:30, Christian Couder napisał:
I would really prefer if Pavan just *wrote* the text of his "Integrated
Web Client for git" proposal for GSoC 2010 in email, instead of providing
link to it; link that requires signing-in.
This proposal aims at creating a multi-purpose HTML based GUI client
for git. This client intends in reducing the work needed to be done
by a developer while working on a git repository. This is not another
gitweb or gitorious but it also contains their functionalities as
submodules.
The project goal is to try and implement a integrated multi-purpose
HTML based GUI client for git. It contains two parts which are
crucial while working on a git repository, Read and Write.
* Read means browse through the code and repository
* Write means working on the code and repository
Also, in the future others will be able to develop more functionalities
for this client with the help of the framework like structure of this
project.
It is not entirely sure what this "Web Client" is meant to do. Is it
mainly meant as web interface to managing repositories (webmin for git),
something that GitHub, Gitorious, InDefero, Girocco all include? This
could mean web interface to configuring gitosis / gitolite. Or is it
meant as web analogue of git-gui: a committool, with ability to create
new commits, perhaps to edit files (and add them, delete them, move them
around), a bit like ikiwiki with Git backend, or other Git based wikis
and blogs? Or is it something else?
It could be a waste to duplicate functionality that is already present
in gitweb, at least for GSoC (having yet another web interface for git,
this time in Python, could be a good thing... if the web interface would
be developed further).
As to integrating "Web Client for Git" with gitweb, there exists at least
a few possible ways to do this:
1. Keep "Web Client" separate for gitweb, and make use of gitweb
hooks/plugin system like $feature{'actions'}. This might require
adding new "hooks" to gitweb.
The advantage is that "Web Client" can be written in any language,
not necessary Perl. The disadvantage that if it is written in Perl,
some code might be duplicated. It might be hard to write generic
hooks - the "Web Client" could be not as well integrated with gitweb.
2. Write "Web Client" as a Perl module, like 'gitweb/cache.pm' in the
http://repo.or.cz/w/git/jnareb-git.git/log/refs/heads/gitweb/cache-kernel-pu
and 'require' this file as needed, guarded by global variable or
%feature.
The advantage is possible tighter integration. I am not sure about
being able to use code from gitweb in "Web Client". It also requires
using Perl, and might require using some contortions if the problem
would be naturally split into multiple modules: there can be multiple
modules, but it could be better to have them in one file.
3. Split Gitweb, add "Web Client" as one of modules. Might be best
from the purity point of view, but is practical only if it is
integrated in gitweb. That would require getting gitweb maintainer
out of GSoC. Also I am not sure how feaible this approach would be.
True, I don't think that e.g. git.kernel.org or repo.or.cz could install
Catalyst and Git::PurePerl and use Gitalist instead of gitweb...
P.S. If I remember correctly Gitalist was based out of last gitweb version
before it got bundled with git. I wonder if they caught up to the
modern gitweb features (snapshots, Atom/RSS feeds, basic submodule
support, handling images, incremental blame, grep and pickaxe search,
etc.).
--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
