[RFC] gitweb wishlist and TODO list

[RFC] gitweb wishlist and TODO list

[Jakub Narebski]

This is yet another series of planned gitweb features. It expands more
on new user-visible features than on improving gitweb code (therefore
for example using Git.pm/Git::Repo, gitweb caching, and list form of
open for pipelines are not mentioned here).

Which tasks / features are most requested?  Which tasks should be done
first?  What do you have on your gitweb TODO list? 

All comments appreciated. Thanks in advance.


* Support for FastCGI (via CGI::Fast or FCGI).

  Unfortunately I don't use FastCGI.  This has to be done in a very
  un-intruisive way, and without performance penalties for "ordinary"
  CGI and mod_perl.

  Suggested: input reading and validation refactoring.

* Optional information about load stats

  Add an option to display information about how much time it took to
  generate page, how many git commands were called, and possibly other
  metric; if page was cached, write when it was generated, and how much
  time till timeout.  This probably would require additional perl
  modules, and it should be conditional on those modules.

* AJAX sorting of tables

  Implement sorting tables (projects list, fork list, heads, tags) in
  browser using JavaScript, like tables in Wikipedia (if possible). 
  This would reduce server load, too.  Of course there would be fallback
  to server-side sorting.

* Committags support

  Support expansion of "tags" in commit messages, like gitweb now does for
  (shortened) SHA-1, converting them to 'object' view link.  It should be
  done in a way to make it easy configurable, preferebly having to
  configure only variable part, and not having to write whole replacement
  rule.

  Possible committags include: _BUG(n)_, bug _#n_, _FEATURE(n),
  Message-Id, plain text URL e.g. _http://repo.or.cz_, spam protecting of
  email addresses, "rich text formatting" like *bold* and _underline_,
  syntax highlighting of signoff lines.

* Project categories support; and/or support for tags, tag clouds,
  removing tags, grouping tags, tags suggestions; and/or support for Trove
  categories (like on Freshmeat, or SourceForge, or Savane/GForge).

* Syntax highlighting for "blob" view
  (in general: blob output filter)

* New log views (formats)

  New log-like views could include: 'log' view with path limiter,
  'whatchanged' like view with list of changed files, 'mbox' format (aka
  'plain' format) to be used by git-am, etc.

  This would I think require changes to log showing infrastructure.

* Enable showing blob size in 'tree' view (optional)

* Graphical log (like gitk, qgit, tig, or git-browser)
  perhaps also graphical view of forks like in GitHub

* Enable transparent compression for HTTP output
  (for performance reasons it makes sense to do it only for cached output)

* Side by side diff (like Wikipedia/MediaWiki), and/or side by side
  comparison (see e.g. Codestriker web review tool).

* Tree blame (when, at what commit and by whom current version of file or
  directory was generated).  This view can be seen in tree/directory view
  of such SCM web interfaces as ViewVC, or GitHub.

* Searching for projects, optionally with paginating projects list page

* Graphical diffstat/dirstat in 'commit' view for merge commits.

* Enhancing gitweb output with RDFa and/or microformats, to make it
  easier to parse unambiguously by machine, for example find fetch
  URL, find push URL, find homepage, parse dates, etc.

* Support for other outline format (XOXO perhaps), and other outlines,
  perhaps also in OPML.

* Etags based anchors to function definitions, i.e. something like
  version-aware source code browser like LXR Cross Referencer (in
  Perl), cscope, Bonsai Project or OpenGrok (unfortunately CDDL
  licensed, and in Java). Should we use Exuberant Ctags
  (http://ctags.sourceforge.net)?

* Optional support for remotes and remote-tracking branches;
  and perhaps support for showing alternates (see forks support)

* Support for patch management interfaces (StGit, Guilt, TopGit), like
  gitk and QGit now have; option to show unapplied patches stack etc.

* AJAX incremental blame, if cached version does not exist

* Better snapshot names, for example <project>-<tag> for tag
  snapshots, perhaps <project>-<branch>-<date> for branch tip
  snapshots, etc.  Ensure that <filename>.<suffix> expands to
  <filename> (see also snapshots of subtrees).

* ...

-- 
Jakub Narebski
Poland

Re: [RFC] gitweb wishlist and TODO list

[Pedro Melo]

Hi,

On Sep 25, 2008, at 11:30 AM, Jakub Narebski wrote:

> * Support for FastCGI (via CGI::Fast or FCGI).
>
>  Unfortunately I don't use FastCGI.  This has to be done in a very
>  un-intruisive way, and without performance penalties for "ordinary"
>  CGI and mod_perl.
>
>  Suggested: input reading and validation refactoring.

Is it ok to require CPAN modules? If yes, then using HTTP::Engine as a  
base could be helpful here.

It supports standalone deployments as well as FastCGI, CGI, mod_perl,  
POE and others.

And it acks as a very simpe HTTP-layer, without any "framework" logic.


> * Committags support
>
>  Support expansion of "tags" in commit messages, like gitweb now  
> does for
>  (shortened) SHA-1, converting them to 'object' view link.  It  
> should be
>  done in a way to make it easy configurable, preferebly having to
>  configure only variable part, and not having to write whole  
> replacement
>  rule.
>
>  Possible committags include: _BUG(n)_, bug _#n_, _FEATURE(n),
>  Message-Id, plain text URL e.g. _http://repo.or.cz_, spam  
> protecting of
>  email addresses, "rich text formatting" like *bold* and _underline_,
>  syntax highlighting of signoff lines.

If this part is modular, we can even use a full blown text markup  
tool, like Markdown or Textile, to generate the HTML version of the  
commits.

Best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Pedro Melo wrote:
> On Sep 25, 2008, at 11:30 AM, Jakub Narebski wrote:
> 
> > * Support for FastCGI (via CGI::Fast or FCGI).
> >
> >  Unfortunately I don't use FastCGI.  This has to be done in a very
> >  un-intruisive way, and without performance penalties for "ordinary"
> >  CGI and mod_perl.
> >
> >  Suggested: input reading and validation refactoring.
> 
> Is it ok to require CPAN modules? If yes, then using HTTP::Engine as a  
> base could be helpful here.

No, it is not.  Some gitweb installations (kernel.org, IIRC) are on
tightly managed machines, where installation is severely restricted.
If it is distributed together with Perl package it is best, if it can
be found in distribution packages it is good, if it can be found in
distribution extras it is quite good, if it can be found in trusted
package repository, it is manageable.  Installing untested packages
from CPAN is usually out of the question.

That said...
 
> It supports standalone deployments as well as FastCGI, CGI, mod_perl,  
> POE and others.
> 
> And it acts as a very simple HTTP-layer, without any "framework"
> logic. 

...if we could make it conditional on HTTP::Engine being installed,
and fallback on current code easily, it could be done, I think, without
problems.

Thanks for the pointer. 

> > * Committags support
> >
> >   Support expansion of "tags" in commit messages, like gitweb now
> >   does for (shortened) SHA-1, converting them to 'object' view link.
> >   It should be done in a way to make it easy configurable,
> >   preferebly having to configure only variable part, and not having
> >   to write whole replacement rule.
> >
> >   Possible committags include: _BUG(n)_, bug _#n_, _FEATURE(n),
> >   Message-Id, plain text URL e.g. _http://repo.or.cz_, spam  
> >   protecting of  email addresses, "rich text formatting" like *bold*
> >   and _underline_, syntax highlighting of signoff lines.
> 
> If this part is modular, we can even use a full blown text markup  
> tool, like Markdown or Textile, to generate the HTML version of the  
> commits.

I don't think it is a good idea.  The main target of git commit
messages is command line, so fixed width format is expected.  Commit
mesages are also shown in commit tools and history viewers (git-gui,
gitk, QGit) and in intergration with IDE/editors (KDevelop, Eclipse,
Emacs, Vim).  Unless unprocessed code doesn't loose anything, I think
that advanced markup is a bad, bad idea.

-- 
Jakub Narebski
Poland

Re: [RFC] gitweb wishlist and TODO list

[Wincent Colaiuta]

El 25/9/2008, a las 12:30, Jakub Narebski escribió:

> This is yet another series of planned gitweb features. It expands more
> on new user-visible features than on improving gitweb code (therefore
> for example using Git.pm/Git::Repo, gitweb caching, and list form of
> open for pipelines are not mentioned here).
>
> Which tasks / features are most requested?  Which tasks should be done
> first?  What do you have on your gitweb TODO list?

One which I'm looking at doing is supporting reading the "README.html"  
from the tree indicated by the current HEAD instead of reading it from  
a file in the .git directory.

This should make tracking and updating such READMEs a little easier as  
all that'll be required is a "push" to advance the HEAD and the new  
README goes live.

Obviously, will have to make this optional and configurable. I'm  
thinking of providing a means of specifying the filename to look for  
(no filename, the default, means don't look), and also a setting to  
indicate the content type of the file (either plain text, which would  
be wrapped in a <pre></pre> block with HTML entities used where  
appropriate, or HTML which would be included verbatim).

Cheers,
Wincent

Re: [RFC] gitweb wishlist and TODO list

[Petr Baudis]

On Thu, Sep 25, 2008 at 03:19:09PM +0200, Wincent Colaiuta wrote:
> One which I'm looking at doing is supporting reading the "README.html" from 
> the tree indicated by the current HEAD instead of reading it from a file in 
> the .git directory.
>
> This should make tracking and updating such READMEs a little easier as all 
> that'll be required is a "push" to advance the HEAD and the new README goes 
> live.
>
> Obviously, will have to make this optional and configurable. I'm thinking 
> of providing a means of specifying the filename to look for (no filename, 
> the default, means don't look), and also a setting to indicate the content 
> type of the file (either plain text, which would be wrapped in a 
> <pre></pre> block with HTML entities used where appropriate, or HTML which 
> would be included verbatim).

In my queue and something I will hopefully get to submit tomorrow or at
the beginning of next week is actually support for full-blown templating
of gitweb pages (customization of the summary page, even adding extra
project actions) based on gitconfig-style specification within the
project HEAD. In its simplest variant, this could be used for including
a README from the HEAD tree as well, I think. But it's in the same class
as the git-gui support for the 'publish' dialog, something potentially
useful for others, but not *universally* useful and in this case,
unfortunately somewhat invasive.

-- 
				Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.

Re: [RFC] gitweb wishlist and TODO list

[Pedro Melo]

Hi,

On Sep 25, 2008, at 1:23 PM, Jakub Narebski wrote:

> Pedro Melo wrote:
>> On Sep 25, 2008, at 11:30 AM, Jakub Narebski wrote:
>>
>>> * Support for FastCGI (via CGI::Fast or FCGI).
>>>
>>> Unfortunately I don't use FastCGI.  This has to be done in a very
>>> un-intruisive way, and without performance penalties for "ordinary"
>>> CGI and mod_perl.
>>>
>>> Suggested: input reading and validation refactoring.
>>
>> Is it ok to require CPAN modules? If yes, then using HTTP::Engine  
>> as a
>> base could be helpful here.
>
> No, it is not.  Some gitweb installations (kernel.org, IIRC) are on
> tightly managed machines, where installation is severely restricted.
> If it is distributed together with Perl package it is best, if it can
> be found in distribution packages it is good, if it can be found in
> distribution extras it is quite good, if it can be found in trusted
> package repository, it is manageable.  Installing untested packages
> from CPAN is usually out of the question.

> That said...
>
>> It supports standalone deployments as well as FastCGI, CGI, mod_perl,
>> POE and others.
>>
>> And it acts as a very simple HTTP-layer, without any "framework"
>> logic.
>
> ...if we could make it conditional on HTTP::Engine being installed,
> and fallback on current code easily, it could be done, I think,  
> without
> problems.
>
> Thanks for the pointer.

While researching HTTP::Engine (I use Catalyst and they where talking  
about moving to it), I also came across a new HTTP layer, called  
Mango. Also on CPAN, so same conditional code applies.

Right now, I'm not sure what the Cat team is thinking, HTTP::Engine or  
Mango, or other, but I suggest the use of the stack then end up  
choosing. The Cat team has a very good test-driven way-of-doing  
things, and the modules they use tend to stabilize very quickly.

Best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

On Thu, 25 Sep 2008, Wincent Colaiuta wrote:
> El 25/9/2008, a las 12:30, Jakub Narebski escribió:
> 
> > This is yet another series of planned gitweb features. It expands more
> > on new user-visible features than on improving gitweb code (therefore
> > for example using Git.pm/Git::Repo, gitweb caching, and list form of
> > open for pipelines are not mentioned here).
> >
> > Which tasks / features are most requested?  Which tasks should be done
> > first?  What do you have on your gitweb TODO list?
> 
> One which I'm looking at doing is supporting reading the "README.html"  
> from the tree indicated by the current HEAD instead of reading it from  
> a file in the .git directory.

One problem is with the concept of using "current HEAD" for that.

I have nothing against for example showing README or README.html (in
some order of preference), or initial fragment of it with link to full
version ('blob' view), either below or above 'tree' view, like
GitHub and Gitorious does.  When you are on 'tree' view you are on
some branch, even implicitly[1].  But for 'summary' view, which is
currently the only view that shows $GIT_DIR/README.html, you are not.

It might happen that you push to git hosting site while on some side
unrelated branch like 'todo', 'html' or 'man' pages in git.git, or
are on branch spawned off subtree-merged subproject like git-gui;
or your gitweb shows state of live non-bare repo and you happen to be
on such branch.  What then?  Repository description vanishing by
accident is not a good solution...


[1] And you can have different READMEs shown for different subprojects,
like there is README, and gitweb/README, and contrib/README, etc.
 
> This should make tracking and updating such READMEs a little easier as  
> all that'll be required is a "push" to advance the HEAD and the new  
> README goes live.
> 
> Obviously, will have to make this optional and configurable. I'm  
> thinking of providing a means of specifying the filename to look for  
> (no filename, the default, means don't look), and also a setting to  
> indicate the content type of the file (either plain text, which would  
> be wrapped in a <pre></pre> block with HTML entities used where  
> appropriate, or HTML which would be included verbatim).

Well, $GIT_DIR/README.html was meant as extension of simple project
description ($GIT_DIR/description or gitweb.description in config).
One paragraph of concise short description; something like projects
description on software hosting site like SourceForge or Savannah,
or software metric site like Ohloh, or software catalog/directory
like Freshmeat.  It is meant as short introduction to project, or
to be more exact to given repository (see below).

In-tree README has different purpose.  Besides describing project
in detail, it usually has some instructions on how to install it
(even if it is referring to INSTALL file), how to configure it,
how to use it; should have all the things required by GNU Coding
Standards and/or Gnits Standards.  It is usually therefore much
longer than $GIT_DIR/README.html (and usually does not use HTML,
but [almost] plain text); so I think gitweb should display around
some given number of lines, ending at break between paragraph if
possible.

Besides $GIT_DIR/README.html can describe specific _repository_,
either some fork of a project (like who created it, what is purpose
of this fork, even if in-tree README remains the same; an example
would be git.git repository forks for git GSoC projects), or
specific mirror (for example describing difference between git.git
and alt-git.git on repo.or.cz).


But I would be not against having in-tree (with the mentioned caveat
of using top-tree HEAD version) README or README.html as fallback
if $GIT_DIR/README.html does not exists, taking into account some
order of preference among README* files if there exists more than one
such file, and displaying it not in full if in-tree README is large.

Alternate solution would be add some kind of _gitweb-admin_ script,
which would allow to set parameters of gitweb or of repository
displayed in gitweb on-line, which would include one-line plain-text
description of a project, and short README.html.  Although I'm
not sure if it should be not left for higher level of hosting site
(Gitorious, repo/Girocco, GitHub, Savane-clean, GForge,...).

-- 
Jakub Narebski
Poland

Re: [RFC] gitweb wishlist and TODO list (templating)

[Jakub Narebski]

Petr Baudis wrote:
> On Thu, Sep 25, 2008 at 03:19:09PM +0200, Wincent Colaiuta wrote:
> >
> > One which I'm looking at doing is supporting reading the "README.html" from 
> > the tree indicated by the current HEAD instead of reading it from a file in 
> > the .git directory.
[...]
> > Obviously, will have to make this optional and configurable. I'm thinking 
> > of providing a means of specifying the filename to look for (no filename, 
> > the default, means don't look), and also a setting to indicate the content 
> > type of the file (either plain text, which would be wrapped in a 
> > <pre></pre> block with HTML entities used where appropriate, or HTML which 
> > would be included verbatim).
> 
> In my queue and something I will hopefully get to submit tomorrow or at
> the beginning of next week is actually support for full-blown templating
> of gitweb pages (customization of the summary page, even adding extra
> project actions) based on gitconfig-style specification within the
> project HEAD. In its simplest variant, this could be used for including
> a README from the HEAD tree as well, I think. But it's in the same class
> as the git-gui support for the 'publish' dialog, something potentially
> useful for others, but not *universally* useful and in this case,
> unfortunately somewhat invasive.

I think that making gitweb use something like Gitweb::Template, where
action appearance is governed by templates, be it something like
git-for-each-ref --format or StGit *.tmpl files, or XSLT / XSL,
could be a good idea.  But I think _that_ would require almost writing
from scratch, certainly making it long-term gitweb fork, perhaps even
with different name (and not residing inside git.git repository).

We can discuss this idea here in this subthread.  For example: do
create Gitweb::Template like HTML::Template or use Template Toolkit;
which parts put in template and which in "gitweb" driver, etc.

-- 
Jakub Narebski
Poland

Re: [RFC] gitweb wishlist and TODO list (templating)

[Petr Baudis]

On Thu, Sep 25, 2008 at 06:52:22PM +0200, Jakub Narebski wrote:
> I think that making gitweb use something like Gitweb::Template, where
> action appearance is governed by templates, be it something like
> git-for-each-ref --format or StGit *.tmpl files, or XSLT / XSL,
> could be a good idea.  But I think _that_ would require almost writing
> from scratch, certainly making it long-term gitweb fork, perhaps even
> with different name (and not residing inside git.git repository).
> 
> We can discuss this idea here in this subthread.  For example: do
> create Gitweb::Template like HTML::Template or use Template Toolkit;
> which parts put in template and which in "gitweb" driver, etc.

Actually, my implementation works quite differently - the idea of the
templates is that you just specify data from which files to show and
whether to take them right away or tabulate them in some way - so it is
something very abstract, and agnostic to _presentation_ layer, which is
still provided by gitweb. An example of made-up template configuration
file would look something like:

[action "summary"]
	sections = metadata overview README shortlog forks

[section "overview"]
	type = csv
	row = Project Title,(info.txt:title)
	row = Project Authors,(info.txt:authors)
	row = Bussiness Impact,(info.txt:bizimpact)
	row = Base Equation,[formula.png]

[section "README"]
	type = html
	content = (README.html)

(where info.txt is another gitconfig-ish file in tree root, one that
the user actually touches).

When I post the patch, I will probably apply it to repo.or.cz too so
that I can show-case this in practice.

-- 
				Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Pedro Melo wrote:

> While researching HTTP::Engine (I use Catalyst and they where talking  
> about moving to it), I also came across a new HTTP layer, called  
> Mango. Also on CPAN, so same conditional code applies.
> 
> Right now, I'm not sure what the Cat team is thinking, HTTP::Engine or  
> Mango, or other, but I suggest the use of the stack then end up  
> choosing. The Cat team has a very good test-driven way-of-doing  
> things, and the modules they use tend to stabilize very quickly.

I think I'll wait for results of your/Catalyst research then... ;-)

-- 
Jakub Narebski
Poland

Re: [RFC] gitweb wishlist and TODO list (templating)

[Jakub Narebski]

Dnia czwartek 25. września 2008 19:10, Petr Baudis napisał:
> On Thu, Sep 25, 2008 at 06:52:22PM +0200, Jakub Narebski wrote:
> >
> > I think that making gitweb use something like Gitweb::Template, where
> > action appearance is governed by templates, be it something like
> > git-for-each-ref --format or StGit *.tmpl files, or XSLT / XSL,
> > could be a good idea.  But I think _that_ would require almost writing
> > from scratch, certainly making it long-term gitweb fork, perhaps even
> > with different name (and not residing inside git.git repository).
> > 
> > We can discuss this idea here in this subthread.  For example: do
> > create Gitweb::Template like HTML::Template or use Template Toolkit;
> > which parts put in template and which in "gitweb" driver, etc.
> 
> Actually, my implementation works quite differently - the idea of the
> templates is that you just specify data from which files to show and
> whether to take them right away or tabulate them in some way - so it is
> something very abstract, and agnostic to _presentation_ layer, which is
> still provided by gitweb. An example of made-up template configuration
> file would look something like:
> 
> [action "summary"]
> 	sections = metadata overview README shortlog forks
> 
> [section "overview"]
> 	type = csv
> 	row = Project Title,(info.txt:title)
> 	row = Project Authors,(info.txt:authors)
> 	row = Bussiness Impact,(info.txt:bizimpact)
> 	row = Base Equation,[formula.png]
> 
> [section "README"]
> 	type = html
> 	content = (README.html)

Gaaaah. I think this is heavy abuse of _configuration_ mini-language
git uses (extended ini-like syntax); it can be done, but it is IMVHO
on par of writing A.I. (Artificial Intelligence) in COBOL:
  http://ars.userfriendly.org/cartoons/?id=20001018

-- 
Jakub Narebski
Poland

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

On Thu, 25 Sep 2008, Jakub Narebski wrote:

> This is yet another series of planned gitweb features. It expands more
> on new user-visible features than on improving gitweb code (therefore
> for example using Git.pm/Git::Repo, gitweb caching, and list form of
> open for pipelines are not mentioned here).

Below there are a few more features which were missing from the list:

* Support for invoking gitweb.cgi (the compiled version) from command
  line to easy generate projects list in format used by gitweb,
  perhaps also to generate web feeds (RSS, Atom, OPML). It would
  probably require adding support for CLI parameters.

* gitweb-admin or gitwebmin; I guess best as separate script.
  
  Allow to set gitweb configuration, gitweb-related per-repository
  configuration (visibility, access, description, README, URLs,...).
  Perhaps also allow to set access permissions, delete/create
  branches, change denyFastForward, rename project, set alternates,
  etc.

* Make gitweb use less dependent on understanding git terminology, like
  'tree' -> 'browse' etc. (proposed by Pieter de Bie (Pieter) on #git,
  as "simplified interface", 2008-09-27T14:56+0200).

  'tree' -> 'browse', 'blob' -> 'file' or 'show', 
  'snapshot' -> 'archive' or 'download', 'heads' -> 'branches'
  'commit | commitdiff | tree | snapshot' -> 'show | browse' for heads
  
  Unfortunately there is no consensus on how such simpler terminology
  should look like...

* Support for generating bundles, and not only snapshots, either
  depth=1 bundles, or diff bundles (snapshot for diff is bundle).

* Support for i18n (translating gitweb), best using 'gettext' which
  the rest of git (gitk and git-gui) uses (use Locale::TextDomain,
  or Locale::Maketext?).

* Possibly: fallback to "user.name <user.email>" for repository owner

-- 
Jakub Narebski
Poland

Re: [RFC] gitweb wishlist and TODO list

[Petr Baudis]

On Sun, Sep 28, 2008 at 12:01:03PM +0200, Jakub Narebski wrote:
> On Thu, 25 Sep 2008, Jakub Narebski wrote:
> 
> > This is yet another series of planned gitweb features. It expands more
> > on new user-visible features than on improving gitweb code (therefore
> > for example using Git.pm/Git::Repo, gitweb caching, and list form of
> > open for pipelines are not mentioned here).
> 
> Below there are a few more features which were missing from the list:
> 
> * Support for invoking gitweb.cgi (the compiled version) from command
>   line to easy generate projects list in format used by gitweb,
>   perhaps also to generate web feeds (RSS, Atom, OPML). It would
>   probably require adding support for CLI parameters.

Or, for starters, just document the existing one. ;-)

	REQUEST_METHOD=GET QUERY_STRING=a=opml gitweb/gitweb.cgi

> * gitweb-admin or gitwebmin; I guess best as separate script.
>   
>   Allow to set gitweb configuration, gitweb-related per-repository
>   configuration (visibility, access, description, README, URLs,...).
>   Perhaps also allow to set access permissions, delete/create
>   branches, change denyFastForward, rename project, set alternates,
>   etc.

I don't see this very useful for gitweb administrator, but more for
owners of particular projects shown by gitweb. That would be very
useful, yes!

> * Make gitweb use less dependent on understanding git terminology, like
>   'tree' -> 'browse' etc. (proposed by Pieter de Bie (Pieter) on #git,
>   as "simplified interface", 2008-09-27T14:56+0200).
> 
>   'tree' -> 'browse', 'blob' -> 'file' or 'show', 
>   'snapshot' -> 'archive' or 'download', 'heads' -> 'branches'
>   'commit | commitdiff | tree | snapshot' -> 'show | browse' for heads
>   
>   Unfortunately there is no consensus on how such simpler terminology
>   should look like...

Yes, I would be very careful here. I personally agree with 'snapshot' ->
'archive' and 'heads' -> 'branches', but I'm not comfortable with the
others at all.

> * Possibly: fallback to "user.name <user.email>" for repository owner

That would be good.

-- 
				Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.

Re: [RFC] gitweb wishlist and TODO list (templating)

[Jakub Narebski]

On Thu, 25 Sep 2008, Petr Baudis wrote:
> On Thu, Sep 25, 2008 at 06:52:22PM +0200, Jakub Narebski wrote:

> > I think that making gitweb use something like Gitweb::Template, where
> > action appearance is governed by templates, be it something like
> > git-for-each-ref --format or StGit *.tmpl files, or XSLT / XSL,
> > could be a good idea.  But I think _that_ would require almost writing
> > from scratch, certainly making it long-term gitweb fork, perhaps even
> > with different name (and not residing inside git.git repository).
> > 
> > We can discuss this idea here in this subthread.  For example: do
> > create Gitweb::Template like HTML::Template or use Template Toolkit;
> > which parts put in template and which in "gitweb" driver, etc.
> 
> Actually, my implementation works quite differently - the idea of the
> templates is that you just specify data from which files to show and
> whether to take them right away or tabulate them in some way - so it is
> something very abstract, and agnostic to _presentation_ layer, which is
> still provided by gitweb. An example of made-up template configuration
> file would look something like:
> 
> [action "summary"]
> 	sections = metadata overview README shortlog forks
> 
> [section "overview"]
> 	type = csv
> 	row = Project Title,(info.txt:title)
> 	row = Project Authors,(info.txt:authors)
> 	row = Bussiness Impact,(info.txt:bizimpact)
> 	row = Base Equation,[formula.png]
> 
> [section "README"]
> 	type = html
> 	content = (README.html)
> 
> (where info.txt is another gitconfig-ish file in tree root, one that
> the user actually touches).
> 
> When I post the patch, I will probably apply it to repo.or.cz too so
> that I can show-case this in practice.

After reading above I'm not sure if what you think about as templating
system for gitweb is the same as I am talking about when thinking about
something like Gitweb::Template.

It looks like you are thinking about having templating system inside
gitweb, with templates describing page layout and view.  Reusing git
ini-like config syntax as (from what I understand) a kind of declarative
layout language (like for example Metafont and MetaPost used in TeX)
would be not that bad idea then; it certainly would avoid adding extra
dependencies on additional Perl modules, and reduce a bit size of code
to be added to deal with templating... if only git config syntax was
not such _limited_ language.  Git ini-like syntax is domain-specific
language meant for storing 2-level and 3+-level hierarchical
configuration; abusing it for templating system would be like writing
A.I. in COBOL.  Also to write all this constraint declarative part
of templating language would be lot of work, I'm not sure if more
work than implementing simple templating system from scratch.

I am thinking about something which would be rather alternate to
gitweb, rather than expanding it.  Gitweb started as simple single-file
CGI script to view and browse git repositories on the web; it is not
modular, and not much embeddable.  But it is easy to install; somewhat
harder than when it was single file (now there is script itself, CSS
and images), but in some parts easier (you don't have to edit file by
hand to make it find repositories and git binary, and to configure it).
Nevertheless easy installation is one of its advantages 
(see also git-instaweb).

Currently (after a bit of research and asking on #perl) I am thinking
about having it either as Template Toolkit[1] plugin (Template::Git or
Template::Plugin::Git) for getting data from git repositories, used
in place of usual DBI/database access module, and as Template Toolkit
filter (Template::Plugin::Gitweb or something like that) for massaging
output, like for example relative/absolute date formats and such,
or as plugin for Catalyst[2] MVC framework.  (Well TT (Template Toolkit)
can be used by Catalyst, so if it is TT module it can be used in
Catalyst).

But this won't be gitweb; more like GitHub.


For example if there was 'gitweb' Template Toolkit the 'shortlog' view
could look like this:

  [% USE Git(projectroot,project) %]
  [% INCLUDE header project=project %]
  ...
  [% FOREACH commit IN repo.log %]
  ...
  [% END %]

Note: I do not know TT, so there might be glaring errors there


References:
===========
[1] http://template-toolkit.org
[2] http://www.catalystframework.org/

P.S. Do anybody know any declarative (constraints based) templating
engine (templating system)? Preferably in Perl...
-- 
Jakub Narebski
Poland

Re: [RFC] gitweb wishlist and TODO list

[Ask Bjørn Hansen]

On Sep 25, 2008, at 3:30, Jakub Narebski wrote:

> * Optional information about load stats
>
>  Add an option to display information about how much time it took to  
> generate page, how many git commands were called, and possibly other  
> metric; if page was cached, write when it was generated, and how  
> much time till timeout.  This probably would require additional perl  
> modules, and it should be conditional on those modules.

Before spending too much time on this, be sure to have a look a  
Devel::NYTProf.

http://search.cpan.org/~timb/Devel-NYTProf-2.03/lib/Devel/NYTProf.pm

http://blog.timbunce.org/2008/07/15/nytprof-v2-a-major-advance-in-perl-profilers/

-- 
http://develooper.com/ - http://askask.com/

Re: [RFC] gitweb wishlist and TODO list (profiling gitweb)

[Jakub Narebski]

On Wed, 1 Oct 2008, Ask Bjørn Hansen wrote:
> On Sep 25, 2008, at 3:30, Jakub Narebski wrote:
> 
> > * Optional information about load stats
> >
> >  Add an option to display information about how much time it took to  
> > generate page, how many git commands were called, and possibly other  
> > metric; if page was cached, write when it was generated, and how  
> > much time till timeout.  This probably would require additional perl  
> > modules, and it should be conditional on those modules.
> 
> Before spending too much time on this, be sure to have a look a  
> Devel::NYTProf.
> 
> http://search.cpan.org/~timb/Devel-NYTProf-2.03/lib/Devel/NYTProf.pm
> 
> http://blog.timbunce.org/2008/07/15/nytprof-v2-a-major-advance-in-perl-profilers/

Thank you very much for the pointers.

However I'm not sure how much help would that be, as according to J.H.
(kernel.org admin) and Petr Baudis (repo.or.cz admin), gitweb
performance in real life settings is bound by I/O, not by CPU usage.

-- 
Jakub Narebski
Poland