On Sun, Apr 18, Petr Baudis wrote:
> On Sun, Apr 18, 2010 at 02:46:16AM +0200, Jakub Narebski wrote:
> > 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?
>
> Yes. Though it is probably supposed to be real Git frontend with Git
> semantics, not something more abstract with Git under the hood.
Hmmm... doesn't look so easy. What to do about simultaneous access
(what webmin does?), and working directory (what ikiwiki does?)?
> > 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.
>
> I think (2) is only infinitesimally better than (1) if you can't call
> all the gitweb methods from your module anyway. For me, the main worry
> is maintaining some consistent UI for the user (graphical and URI-wise)
> and (2) can accomplish this really only in a limited way unless you go
> much further with the modularization first.
Well, you can always add some of "Web Client" functionality directly
to gitweb (for example dispatch must be, I think, in gitweb). Or you
can (ab)use "do $gitwebgui_pm;" instead of "require $gitwebgui_pm;",
like in http://repo.or.cz/w/git/jnareb-git.git/commitdiff/261b99e3#patch3
(second chunk).
OTOH we can always make gitweb "use Git;" and move some of its routines,
to it after generalization (e.g. config management using single run of
"git config -l -z", unquoting paths, parsing commit/tag/ls-tree/difftree
etc., date parsing and conversion).
BTW. the major thing that prevented me from using Git.pm was the few
places that gitweb uses pipeline, or needs to redirect STDERR to
/dev/null. Also t9700-perl-git.sh test doesn't test command_output_pipe
and the like.
> > 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.
>
> Would it be really required to get gitweb maintainer out of GSoC in
> order to go this way? Why?
Well, at least someone who would be able to manage integrating split
gitweb. I think that splitting gitweb, and doing it well, is quite
outside this GSoC 2010 proposal: it would be too much.
--
Jakub Narebski
Poland
--
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