git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: GSoC 2010: "Integrated Web Client for git" proposal

From
Jakub Narebski <jnareb@gmail.com>
Date
Apr 18, 2010, 17:50 UTC
Message-ID
<201004181950.19610.jnareb@gmail.com>
In-Reply-To
<20100418021223.GP10939@machine.or.cz>
On Sun, Apr 18, 2010, Petr Baudis wrote:
> On Sun, Apr 18, 2010 at 03:24:53AM +0200, Jakub Narebski wrote:
>> On Sun, Apr 18, Petr Baudis wrote:
>>> On Sun, Apr 18, 2010 at 02:46:16AM +0200, Jakub Narebski wrote:
Show 15 quoted lines
>>>> 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?)?
> 
>   I would expect it to work the same as if you work in single working
> copy from multiple shells. If multiple people want to collaborate, each
> should have their own clone to begin with.
So it is intended, I guess, more like git-instaweb or webmin, not like
administrative parts of Girocco (or repo.or.cz), GitHub, Gitorious or
InDefero.  Probably authentication and authorization would not be needed
then, if it is to be run as web interface but locally...
 
Show 6 quoted lines
>> Well, you can always add some of "Web Client" functionality directly
>> to gitweb (for example dispatch must be, I think, in gitweb).
> 
> But I don't think you can reasonably separate a major portion of web
> client that would not depend on gitweb functions like href(), format*()
> etc. all over the map.
Well, there is also copy'n'paste of code as a last resort.  

I guess that git-gui and gitk duplicate some of their functionality (and only git-gui is split; gitk is monolitic single file, even larger than gitweb: 320KB vs 220KB).

Show 7 quoted lines
>> 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).
> 
> This already occured to me, yes. It's tempting to have this as the
> emergency way out, shall other things fail. But .
                                              ^^^^^^^^^^-- ???
But what?

Yes, it is not as elegant as "require", and you have to catch errors in "do"-ed file yourself (as described at the end of `perldoc -f do`).

Show 7 quoted lines
>> 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).
> 
> Yes, but not things like href(), git_header_html() and other absolutely
> essential routines.
True.
Show 18 quoted lines
>>>> 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. 
> 
> This was my hesitation at the beginning, but I'm not really sure if
> it's really so hard, _if_ we resist the temptation to snowball unrelated
> cleanups on top of it. Conceptually, it isn't really hard to do, is it?
> The only tricky thing would be making sure instaweb still works and
> installation is still easy, but I don't see anything really difficult in
> this area either...?

Currently to install gitweb you have to copy *one* script, and a few static files (2 x image, CSS, JavaScript). You can configure it using "make gitweb" with appropriate options, you can simply edit gitweb script, or you can leave this to the gitweb config file.

There are quite a few requirements that gitweb should fulfill:
* It must be able to install without admin rights, and requirng to
  install Perl modules system wide.  We can rely on core Perl modules,
  on git core and possibly on perl-Git being installed.
* It must be able to install without editing web server config file,
  nor setting environment variables for the user account that is used
  by the web server (e.g. 'apache', or 'web', or 'nobody').
* Possibly also it should be easy to install gitweb "by hand", without
  requirng to use build system.
* Any automatic installation target must take into account that gitweb
  must run on many web servers (Apache as CGI, Apache as mod_perl, nginx,
  lighttpd, IIS, Moongose, Webrick,...) and on many distributions and
  operating systems (where location of server, and server configuration
  might differ).  But I guess we can borrow some code from git-instaweb.sh

Also there is a question _how_ to split gitweb into modules, e.g. whether to follow SVN::Web example on how gitweb (Git::Web?) should be split. But I guess any splitting would suffice; we need to provide a way to build and install split gitweb.

Split can be as simple as:
  Makefile, or Makefile.PL, or Build.PL
  gitweb.perl
  static/git-logo.png
  static/git-favicon.png
  static/gitweb.css
  static/gitweb.js
  lib/Gitweb/Utils.pm   (Gitweb::Utils)
  lib/Gitweb/Editor.pm  (Gitweb::Editor, for GSoC2010, if it gets accepted)
-- 
Jakub Narebski
Poland
Previous: Petr BaudisNext: Petr Baudis
Message 20 of 39 in “GSoC 2010: "Integrated Web Client for git" proposal”
  1. Christian CouderApr 15, 2010
  2. Jakub NarebskiApr 18, 2010
  3. Petr BaudisApr 18, 2010
  4. Jakub NarebskiApr 18, 2010
  5. Petr BaudisApr 18, 2010
  6. Pavan Kumar SunkaraApr 18, 2010
  7. Jakub NarebskiApr 18, 2010
  8. Petr BaudisApr 18, 2010
  9. Pavan Kumar SunkaraApr 19, 2010
  10. Matthieu MoyApr 19, 2010
  11. Junio C HamanoApr 19, 2010
  12. Pavan Kumar SunkaraApr 19, 2010
  13. Petr BaudisApr 19, 2010
  14. Matthieu MoyApr 19, 2010
  15. Pavan Kumar SunkaraApr 19, 2010
  16. Matthieu MoyApr 19, 2010
  17. Petr BaudisApr 19, 2010
  18. Pavan Kumar SunkaraApr 19, 2010
  19. Petr BaudisApr 20, 2010
  20. Jakub NarebskiApr 18, 2010
  21. Petr BaudisApr 18, 2010
  22. Jakub NarebskiApr 19, 2010
  23. Petr BaudisApr 19, 2010
  24. Pavan Kumar SunkaraApr 19, 2010
  25. Petr BaudisApr 20, 2010
  26. Jakub NarebskiApr 20, 2010
  27. Pavan Kumar SunkaraApr 21, 2010
  28. Petr BaudisApr 22, 2010
  29. Junio C HamanoApr 22, 2010
  30. Petr BaudisApr 23, 2010
  31. Junio C HamanoApr 23, 2010
  32. Pavan Kumar SunkaraApr 22, 2010
  33. Christian CouderApr 23, 2010
  34. Pavan Kumar SunkaraApr 23, 2010
  35. Pavan Kumar SunkaraApr 19, 2010
  36. Jakub NarebskiApr 19, 2010
  37. Pavan Kumar SunkaraApr 19, 2010
  38. Jakub NarebskiApr 19, 2010
  39. Pavan Kumar SunkaraApr 20, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.