[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

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

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

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

[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

[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

[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

[RFC] gitweb wishlist and TODO list

[Jakub Narebski]

This is yet another series of planned gitweb features. It expands more
on tasks improving gitweb; new features are mentioned only in general
view.

Which tasks / features are most requested?  Which tasks should be done
first?  All comments appreciated.


1. Cleanup

* HTML: use classes for styling elements.

  There are still some places where we use presentational HTML elements
  like <i>. I'd rather have it replaced by adding class to appropriate
  element, and adding proper rule to CSS. This would make changing the
  style easier, but it would make generated a bit longer page larger.

  Other issue with above is with web browsers which do not implement CSS,
  so it would be good to retain presentational elements, perhaps adding
  styling to those elements.

  On the other hand we use class element when sometimes id attribute would
  be better, and sometimes (in the tables) it would be better served to
  add <col> and <colgroup> elements, and use header attribute and select
  CSS style by this attribute value.

* CSS: remove repetitions, use more elaborate selectors.

  Use descendant selectors more, and use other selectors like parent or
  grandchild, instead of relying on class iself.  The goal is to remove
  some of repetition in CSS file.  For example we could state that all
  "second level" divs, perhaps with some exceptions, should have 8px
  padding.

  This would make adding similar elements easier (for example README for a
  project had for a while no padding), and most probably would make CSS
  style smaller, but at the cost of CSS being more complicated (more
  complicated selectors, knowledge of cascading (priority) sequence).

  Perhaps we should reorder CSS file, and add some comments, to make it's
  maintenance easier, and make it easier to add style for new elements.

* Code: make code more readable.

  Some time passed by since renaming subroutines to better reflect what
  they do, and moving them to group similar subroutines together.  But
  since then gitweb gathered more subroutines, other subroutines were
  modified.  It would be nice if somebody with fresh view examined the
  code and, if it is needed, proposed subroutines renaming, changes in
  subroutines calling conventions, and move code around to have similar
  subroutines together.

* Code refactoring: separate code dealing with similar things.

  Gathering together code dealing with various log-like views, i.e. code
  dealing with 'log', 'shortlog', 'history' and 'rss'/'atom' actions (and
  perhaps also 'search' action for searching commit messages) would allow
  for improvements to "log" code to apply to all those views.  It would
  make also easier to add another log-like views, for example 'raw' or
  'plain' or 'mbox' view, or more delatiled search results (e.g. with
  context) for searching commit message.

  Another bit of code that could be put into separate subroutine is code
  dealing with "item" views, i.e. links for each tag in a list of tags,
  links for each entry in a 'tree' view, links for each commit in a
  'shortlog' or 'log' view, etc.  Yet another, code displaying single
  structured object, like 'tag' and 'commit' view.

  This would also make it easier to change the style used by gitweb
  everywhere simultaneously, without worrying that we forgot some place.

* Code: list form of open pipeline (?)

  Gitweb uses list form of open to run git commands, avoiding (negligible)
  cost of forking shell, and (non negligigle) trouble with shell-quoting
  command arguments.  But when output must be passed to other command,
  gitweb falls back to "shell" form of open.  Currently this happens only
  for snapshot formats using external compresor, now that pickaxe search
  got rewritten to use git-log, instead of git-rev-list fed to
  git-diff-tree.

  But if gitweb is to get syntax highlighting using some external tool, it
  would be better to have some kind of "list form of open" to open
  pipelines.

* Code: deal with utf8 when reading data (?)

  Currently gitweb converts from utf8 to Perl internal form using
  (misnamed) to_utf8() subroutine when writing out (printing out) via
  esc_html(), or by calling to_utf8() explicitely.  It would be less
  error-prone to force conversion to Perl internal form when reading data
  from external sources, and always store data in variables in Perl
  internal form.

* Code: input reading and validation refactoring.

  Currently gitweb reads values of CGI parameters into global variables,
  performing in the meantime basic validation of parameters.  It is done
  independently if current action access all the [possible] parameters.

  Perhaps this should be separated into subroutine.  This should help
  to have better FastCGI and probably also "native" mod_perl support.
  It would also show which actions use (and require) which parameters.


2. Performance etc.

* Better 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.

* Gitweb caching

  Add caching to gitweb, either caching of output, or caching of
  intermediate Perl structures.  Support proper replies to HTTP cache
  (in)validation requests.

  This is one of GSoC 2008 projects.

  Bundled together is using "infinite" (or at least large: currently we
  use +1d) Expires: and/or Cache-Control: max-age (if HTTP/1.1) for
  unchanging pages. Although those pages are usually rarely accessed...

* Reduce size of project list page

  Now that gitweb is used for installations spanning thousands of
  repositories, showing all projects (repositories) in the front page is
  hard on server (this can be migitated by caching), but also hard on
  browser which has to render huge table / huge page.

  One solution would be to divide projects list page into pages; this
  would have the advantage that for sorting by project name (default),
  or by project owner gitweb would have to get data (owner, last change)
  only for the projects shown.  Alternate solution, if categories support
  would got implemented, would be to show only list of categories.  Yet
  another would be to put projects search form as homepage (front page).

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


3. New features

* 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

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

-- 
Jakub Narebski
Poland

[RFC] gitweb wishlist and TODO list

[Jakub Narebski]

There is a new part of gitweb TODO list and wishlist; planned features and
features it would be nice to have. If you have new ideas, if you want some
features to be implemented first, if you use some web interface to some SCM
you like, please do contribute.

I've tried to divide this TODO/wishlist into categories.


1. Cleanups and refactoring

 * HTML and CSS cleanup. All (or almost all) styling should be done using
   CSS, and not embedded style or presentation elements. All HTML elements
   except perhaps a few should have either class attribute (if such
   element can be multiple times on page) or id attribute (if there can be
   only one such element). Perhaps some class attributes should be changed
   to id attributes. Gitweb has much improved from the incorporation in
   this area.

 * CSS refactoring. Try to avoid repeating the same styling, using
   combination of descendant and _child_ selectors, perhaps also
   adjacent sibling selector and attribute/attribute value selector.
   Perhaps large reorganization patch (moving contents within CSS and adding
   comments) is to be done...

 * Code refactoring. Separate/refactor common parts and put them into
   separate subrotines OR collapse similar subrotines into one subroutine
   with an argument selecting the case. For example git_blob and
   git_blob_plain could be collapsed; git_shortlog, git_tags/git_heads,
   git_log, git_history do similar work. When the new
   --grep/--author/--commiter options to git-rev-list hits released version,
   perhaps also git_search could be put together with the previous set.
   git_rss does similar work as a git_summary.

 * Refactor printing related links (like "blame | history | raw" for blob
   entries in tree view) into separate subroutine. The list depends both on
   the kind of object pointed, and on the current action/view.

 * Perhaps refactor reading and validation of parameters, except the ones
   used for dispatch i.e. project and action parameters, into separate
   subroutine
 
        my ($hash, $hash_base) = gitweb_params('hash', 'hash_base');    

   I'm not sure if it is/would be usefull.


2. Git.pm-ish (subroutines which in generalized version are/could be
   in Git.pm)
 
 * Refactor calling a git command and reading it's output into separate
   subroutine git_command/git_pipe, so for example if someone _has_ to use
   gitweb with ancient Perl version which does not understand list version
   of magic "-|" open could do it changing only one subroutine. Well, we can
   use Git.pm when it hits main release.

 * Add subroutine/subroutines, which given a full name of ref, returns
   either another ref if input ref was symlink/symref, or hash of the
   pointed object, and which work not only with ordinary loose refs, but
   also with symlinks, symrefs (up to some level of recursion) and packed
   refs. All without calling any git command. But I guess that currently
   it is not needed at all.

 * Add simplified git config file parser, which would _read_ only gitweb
   entries (and convert them to bool/int if necessary). With this we could
   move description, category, export_ok, .hide, cloneurl to config file,
   instead of cluttering $GIT_DIR. Or just make it an option (read file
   first, if it doesn't exist try config file).

 * Parsing of remotes/ files _and_ equivalent config entries, for adding
   information (tooltip?) about tracking branches in heads view, and for
   adding information about given subdirectory in refs/remotes/ (see below).


3. Optimizing gitweb

 * Use git-for-each-ref (when it hits released version) to speed up of
   generation of summary, heads and tags views. It would also enable the
   option of having most recent commit date in projects list view, and not
   most recent commit in current branch (in HEAD).
 
 * Add better support for mod_perl, e.g. $r->path_info(), via checking for
   MOD_PERL enviromental variable.

 * Better support for mod_perl/FastCGI, perhaps wrapping the changeable part
   into gitweb_handler subroutine, and calling it.


4. New features

 * Add support for other directories in $refs/ besides "heads" and
   "tags" directories, for example refs/remotes/ generated when cloning with
   --use-separate-remote option. On short TODO list.

 * Add categories support a la gitweb-xmms2 to the projects list view (and
   perhaps also OPML); perhaps with option to use first part of path to
   repository as category.

 * Code highlighting (or generic filter) support in blob view, perhaps as
   a feature. Proposed tools for generating syntax highlighting include
   Highlight (http://www.andre-simon.de) and GNU Source Highlight
   (http://www.gnu.org/software/src-highlite) a la gitweb-xmms2.
   Gitweb-xmms2 uses Highlight, and due to the tags support uses temporary
   files. I think that CSS for code highlighting should be in separate file,
   and that selecting syntax to use should be done using mime.types like
   file rather than gitweb-xmms2 internal configuration (hash of
   extensions).

 * Committags support from gitweb-xmms2 in commit, commitdiff, log views and
   in the top commit summary/title link on most pages. There was preliminary
   patch on git mailing list for committags support (more general than
   the support in gitweb-xmms2), with current commitsha link (now in
   format_log_line_html) implemented as committag. Junio had quite
   a good idea how to avoid having to do committags _after_ HTML escaping,
   and how to stack committags. I'm not sure if it wouldn't be better to try
   to do all committags in one go, instead of stacking. Perhaps also commit
   message "syntax highlighting" (i.e. highlighting signoff lines) and empty
   lines simplification should be done using committags.

 * Crossreferencing in blob view. Gitweb-xmms2 uses if I remember correctly
   etags to generate anchors and to generate hyperlinks to definition of
   function. GNU Highlight can use encumberant-tags IIRC. Both need I think
   temporary files for index. Perhaps this should be done rather as a part
   of gitweb/git integration with LXR Cross Referencer. 

   Do you know other projects that could be used instead of etags here?

   I'm not sure if it is worth to pursue implementing it now.

 * Improve blame view, making use of --porcelain option to git-blame (for
   later). Perhaps change blame view from table based one to div based one.
   Use different colors for different commits (graph coloring problem).

 * Perhaps add some kind of finding closest preceding/following tag. and on
   which branch we are on. Tempered of course by the concerns of
   performance. What is possible for locally run history browser like gitk
   or qgit, might be not feasible on server run web interface.

 * Add information from remotes/ to heads view, for example the following
     tracks branch 'master' of git://git.kernel.org/pub/scm/git/git (origin)
   as a tooltip for 'origin' branch. But what if one branch tracks more than
   one remote? Needs to use also config file.

 * Support for tracking renames in history view. Simple rename tracking
   I think could be done directly in gitweb; more advanced would need
   --follow option (i.e. core git improvement).

 * log/shortlog should be a format, so we could have log-like history, tags,
   heads views.

 * add summary of number of lines changed for each file (a la darcsview)
   in the difftree part of commit and *diff* views, e.g.

        blame.c   +1 -0  diff | history | blame

   or something like that.

 * add extended header to the commitdiff and perhaps blobdiff views,
   hyperlinked. _This_ would add some patches to commitdiff view, which are
   now IIRC visible only in difftree part now.

 * enable sorting tags/heads view by name instead of sorting it by date.


5. New views

 * Reflog view (most probably limited to heads only). I'm not sure if it is
   worth time spend on calling git commands to mark unreachable commits for
   example using strikethrough, and hyperlink reachable. Any ideas how such
   a view should look like?

 * ViewVC-like tree-blame view. There was RFC patch adding tree_blame view
   some time ago here, on git mailing list. The main problem of course is
   performance. We could implement tree_blame purely in gitweb as it was
   done in mentioned patch (having --stdin option to git-ls-tree would
   help), or add new core command/extend git-blame for directories. There is
   also a question if we want to find blame for tree entries, or not.

 * "List of the files in given directory, touched by given commit"

 * Perhaps ad Atom feed support as an alternative to RSS, and XOXO as an
   alternative to OPML.

 * Graph of number of changed files in given branch; probably should be
   cached.


X. Proposed improvements to core git commands
 * add --stdin option to git-ls-tree, a la --stdin option to git-diff-tree.
 * add --follow option to git-rev-list, allow to provide path limiter via
   stdin (with --stdin option) in git-diff-tree
 * add --numstat option to git-diff; currently only git-apply has it.


Thoughts? Comments?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Luben Tuikov]

--- Jakub Narebski <jnareb@gmail.com> wrote:
>  * Improve blame view, making use of --porcelain option to git-blame (for
>    later). Perhaps change blame view from table based one to div based one.

>    Use different colors for different commits (graph coloring problem).

Oh, no please no.

Why do you think I left the color list as a list?  I did try to use
more colors when I wrote it, and it was ugly as h3ll and very distracting
when doing real work.  So I ended up with the two color (shades) we have
now and this is what I submitted.

Also, any kind of "graph coloring problem" would make blame slow.

In any way, if you/someone does implement this "coloring" can you please
make it an option, because I'll never turn it on.  Thanks!

     Luben

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Luben Tuikov wrote:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
> >  * Improve blame view, making use of --porcelain option to git-blame (for
> >    later). Perhaps change blame view from table based one to div based one.
> 
> >    Use different colors for different commits (graph coloring problem).
> 
> Oh, no please no.
> 
> Why do you think I left the color list as a list?  I did try to use
> more colors when I wrote it, and it was ugly as h3ll and very distracting
> when doing real work.  So I ended up with the two color (shades) we have
> now and this is what I submitted.
> 
> Also, any kind of "graph coloring problem" would make blame slow.

One of ideas (without having some nice _mathematical_ solution, i.e. not
having for to try and check different coloring but calculating coloring, 
of a blame graph coloring problem[*1*]) was to use few colors, 3, 6, 8
based on some hash of sha1 of commit (for example first character) plus
alternating "darkness" of those colors to ensure that neighbours would
have different colors. Another was to use first 6 characters of sha1 as
a color, then flatten the color to suitable for background (perhaps also
with some kind of ensuring that neigbour blames would have different color). 

Junio idea of basing color/brighness (of some part of blame output at
least) on the _age_ of region (perhaps using two altrenating _colors_)
has also it's merit.

Nevertheless, such change would be preceded by an RFC, and discussion.

> In any way, if you/someone does implement this "coloring" can you please
> make it an option, because I'll never turn it on.  Thanks!

Not a problem to make blame coloring a feature.


Footnotes:
[*1*] Blame graph coloring problem: 1) regions blamed on the same commit
should have the same color 2) neighbour blame regions should have different
colors.
-- 
Jakub Narebski
Poland

Re: [RFC] gitweb wishlist and TODO list

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> 1. Cleanups and refactoring
>
>  * HTML and CSS cleanup. All (or almost all) styling should be done using
>    CSS, and not embedded style or presentation elements. All HTML elements
>    except perhaps a few should have either class attribute (if such
>    element can be multiple times on page) or id attribute (if there can be
>    only one such element). Perhaps some class attributes should be changed
>    to id attributes. Gitweb has much improved from the incorporation in
>    this area.

It scares me when somebody says "all X should do Y".  Aiming for
consistency and cleanliness is good but taking it to extreme and
becoming dogmatic about it isn't.  Let's not repeat the crusade
against redundant links.

>    ... When the new
>    --grep/--author/--commiter options to git-rev-list hits released version,
>    perhaps also git_search could be put together with the previous set.

Sounds like a good idea, but I think people can (and should)
start preparing for it in "next"; after all that is what "next"
is for.

>  * Refactor calling a git command and reading it's output into separate
>    subroutine git_command/git_pipe, so for example if someone _has_ to use
>    gitweb with ancient Perl version which does not understand list version
>    of magic "-|" open could do it changing only one subroutine. Well, we can
>    use Git.pm when it hits main release.

I agree this is a good thing to do while refactoring.  There are
too many similar looking code sprinkled all over.  Git.pm is
already in the "master" and there is nothing cooking in "next".

>  * Add simplified git config file parser, which would _read_ only gitweb
>    entries (and convert them to bool/int if necessary). With this we could
>    move description, category, export_ok, .hide, cloneurl to config file,
>    instead of cluttering $GIT_DIR. Or just make it an option (read file
>    first, if it doesn't exist try config file).

I do not see why you would need anything "simplified"; I think
writing a .git/config parser purely in Perl is much easier than
waiting for libified interface that talks .xs and would run just
as efficient -- after all Perl is the ideal tool for text file
processing like this.  And I do not particularly worry about
issues that could arise from two different configuration parsers
having different set of bugs.  The file format is simple enough.
It would be a very good addition to Git.pm suite.

>  * Add categories support a la gitweb-xmms2 to the projects list view (and
>    perhaps also OPML); perhaps with option to use first part of path to
>    repository as category.

Perhaps; hosting site would want this.

>  * Code highlighting (or generic filter) support in blob view, perhaps as
>    a feature.

Not particularly interested myself but as long as it would not
add huge load on the server I would not much object either.

>  * Crossreferencing in blob view.

Lxr is certainly interesting, but I would rather use local "git grep".

>  * add summary of number of lines changed for each file (a la darcsview)
>    in the difftree part of commit and *diff* views, e.g.
>
>         blame.c   +1 -0  diff | history | blame
>
>    or something like that.

I'll place "diff --numstat" to the stack of "things to do on the
core side".  Should be trivial.

>  * Reflog view (most probably limited to heads only). I'm not sure if it is
>    worth time spend on calling git commands to mark unreachable commits for
>    example using strikethrough, and hyperlink reachable. Any ideas how such
>    a view should look like?

If the feature is useful, do not be afraid to add core side
support for it.  As long as the proposed core side support is
reasonable and not too specific to a niche task, that is.

>  * "List of the files in given directory, touched by given commit"

Have no idea what you mean.  "diff-tree -r --name-only $commit"?

> X. Proposed improvements to core git commands
>  * add --stdin option to git-ls-tree, a la --stdin option to git-diff-tree.

Not particularly interested, as it is unclear how the output
boundary should be marked, but should be trivial to add once we
know what the output should look like.

>  * add --follow option to git-rev-list, allow to provide path limiter via
>    stdin (with --stdin option) in git-diff-tree

The "path limiter via stdin" part is murky.  I would not object
to "rev-list --follow=$this_path_at_the_tip $start_at_this_commit"
which I can see clear semantics for. 

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> 1. Cleanups and refactoring
>>
>>  * HTML and CSS cleanup. All (or almost all) styling should be done using
>>    CSS, and not embedded style or presentation elements. All HTML elements
>>    except perhaps a few should have either class attribute (if such
>>    element can be multiple times on page) or id attribute (if there can be
>>    only one such element). Perhaps some class attributes should be changed
>>    to id attributes. Gitweb has much improved from the incorporation in
>>    this area.
> 
> It scares me when somebody says "all X should do Y".  Aiming for
> consistency and cleanliness is good but taking it to extreme and
> becoming dogmatic about it isn't.  Let's not repeat the crusade
> against redundant links.

Well, after writing this part I have checked that we don't use
"style" attribute in gitweb anymore. But we still do use presentational
elements, like <i>. IMHO we should use CSS for styling.

>>    ... When the new
>>    --grep/--author/--commiter options to git-rev-list hits released version,
>>    perhaps also git_search could be put together with the previous set.
> 
> Sounds like a good idea, but I think people can (and should)
> start preparing for it in "next"; after all that is what "next"
> is for.

Using --grep/--author/--commiter would have the advantage of to be
easily able to paginate "log search" in gitweb.

I forgot to add splitting git_search into "log search" and "pickaxe search",
and perhaps adding "file search" aka. "grep search" to gitweb.
 
>>  * Refactor calling a git command and reading it's output into separate
>>    subroutine git_command/git_pipe, so for example if someone _has_ to use
>>    gitweb with ancient Perl version which does not understand list version
>>    of magic "-|" open could do it changing only one subroutine. Well, we can
>>    use Git.pm when it hits main release.
> 
> I agree this is a good thing to do while refactoring.  There are
> too many similar looking code sprinkled all over.  Git.pm is
> already in the "master" and there is nothing cooking in "next".

I'm not sure if I would like to use Git.pm repository abstraction.
But converting gitweb to use Git.pm would be a good idea, I agree.
Although I'd rather have any gitweb patches which need _unreleased_
features to be in 'next'.
 
BTW. the Git.pm-ish ideas (config parser, remotes parser, symrefs and
packed refs parser) should perhaps be added (at least in 'next')
via Git.pm.

>>  * Add simplified git config file parser, which would _read_ only gitweb
>>    entries (and convert them to bool/int if necessary). With this we could
>>    move description, category, export_ok, .hide, cloneurl to config file,
>>    instead of cluttering $GIT_DIR. Or just make it an option (read file
>>    first, if it doesn't exist try config file).
> 
> I do not see why you would need anything "simplified"; I think
> writing a .git/config parser purely in Perl is much easier than
> waiting for libified interface that talks .xs and would run just
> as efficient -- after all Perl is the ideal tool for text file
> processing like this.  And I do not particularly worry about
> issues that could arise from two different configuration parsers
> having different set of bugs.  The file format is simple enough.
> It would be a very good addition to Git.pm suite.

There are many INI file parsers in CPAN, but I guess that Git adds
it's own config file syntax (e.g. branch and remote config:
  [branch "quoted branch name with funny characters]
which is not yet documented if I remember correctly) that we want our
own parser; this would also reduce dependencies.

"Simplified" because of not implementing "extended syntax" mentioned
above, and because implementing only reading config file. It is harder
to make it write config file, preserving comments etc.
 
By the way, would it be better to use CGI like syntax of 
$repo->config("gitweb.$key"), or tie hash?

>>  * Code highlighting (or generic filter) support in blob view, perhaps as
>>    a feature.
> 
> Not particularly interested myself but as long as it would not
> add huge load on the server I would not much object either.

It should be: as a feature, not perhaps as a feature. Perhaps
make highlighting configurable (program to use, filename to mode
mapping, etc.)
 
>>  * Crossreferencing in blob view.
> 
> LXR is certainly interesting, but I would rather use local "git grep".

This is far, far in the queue at least for me. And I'm not sure
if crossreferencing can be done without creating temporary files,
something we tried to avoid (e.g. creating diffs on-the-fly now).
 
>>  * add summary of number of lines changed for each file (a la darcsview)
>>    in the difftree part of commit and *diff* views, e.g.
>>
>>         blame.c   +1 -0  diff | history | blame
>>
>>    or something like that.
> 
> I'll place "diff --numstat" to the stack of "things to do on the
> core side".  Should be trivial.

Thanks. I did wonder why git-apply (!) has "--numstat" but git-diff
has not... 

>>  * "List of the files in given directory, touched by given commit"
> 
> Have no idea what you mean.  "diff-tree -r --name-only $commit"?

I'm repeating verbatim someone idea. IIRC it meant adding list
of affected files (like difftre part of "commit" and "commitdiff"
views) to the "log" and "search" views...
 
>> X. Proposed improvements to core git commands
>>  * add --stdin option to git-ls-tree, a la --stdin option to git-diff-tree.
> 
> Not particularly interested, as it is unclear how the output
> boundary should be marked, but should be trivial to add once we
> know what the output should look like.

The output format for git-ls-tree is
	<mode> SP <type> SP <object> TAB <file>
It is fairly easy to distinguish such line from the
	<sha1 of tree-ish>
line. 

The idea was that 
	echo "tree-ish 1" "tree-ish 2" | git ls-tree --stdin
output would be
	<sha1 of tree-ish 1>
	<mode> SP <type> SP <object> TAB <file>
	...
	<mode> SP <type> SP <object> TAB <file>
	<sha1 of tree-ish 2>
	<mode> SP <type> SP <object> TAB <file>
	...
	<mode> SP <type> SP <object> TAB <file>

We could add some records (trees) seperating, for example by NUL
character like in git-rev-list --headers.
 
>>  * add --follow option to git-rev-list, allow to provide path limiter via
>>    stdin (with --stdin option) in git-diff-tree
> 
> The "path limiter via stdin" part is murky.  I would not object
> to "rev-list --follow=$this_path_at_the_tip $start_at_this_commit"
> which I can see clear semantics for. 
 
You can provide <tree-ish> or pair of <tree-ish> from stdin for
git-diff-tree --stdin. You can provide path limiter _only_ as an
argument to git-diff-tree. Proposed extension is to be able to
use
	<tree-ish> [<tree-ish>] [<path>...]
from stdin, perhaps _forcing_ to use
	 <tree-ish> [<tree-ish>] ['--' <path>...]
syntax.

Alternatively, change semantics of path limiter if path limiter
match _exactly_ --follow argument.
-- 
Jakub Narebski
Poland

Re: [RFC] gitweb wishlist and TODO list

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Jakub Narebski <jnareb@gmail.com> writes:
>
>>  * add summary of number of lines changed for each file (a la darcsview)
>>    in the difftree part of commit and *diff* views, e.g.
>>
>>         blame.c   +1 -0  diff | history | blame
>>
>>    or something like that.
>
> I'll place "diff --numstat" to the stack of "things to do on the
> core side".  Should be trivial.

This is only lightly tested. I haven't done test suite nor
documentation, which the list should be able to take care of,
now my git day for this week is over ;-).

-- >8 --
[PATCH] diff --numstat

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 combine-diff.c |    9 ++++++---
 diff.c         |   29 +++++++++++++++++++++++++++--
 diff.h         |   15 ++++++++-------
 3 files changed, 41 insertions(+), 12 deletions(-)

diff --git a/combine-diff.c b/combine-diff.c
index 46d9121..65c7868 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -856,8 +856,10 @@ void diff_tree_combined(const unsigned c
 		/* show stat against the first parent even
 		 * when doing combined diff.
 		 */
-		if (i == 0 && opt->output_format & DIFF_FORMAT_DIFFSTAT)
-			diffopts.output_format = DIFF_FORMAT_DIFFSTAT;
+		int stat_opt = (opt->output_format &
+				(DIFF_FORMAT_NUMSTAT|DIFF_FORMAT_DIFFSTAT));
+		if (i == 0 && stat_opt)
+			diffopts.output_format = stat_opt;
 		else
 			diffopts.output_format = DIFF_FORMAT_NO_OUTPUT;
 		diff_tree_sha1(parent[i], sha1, "", &diffopts);
@@ -887,7 +889,8 @@ void diff_tree_combined(const unsigned c
 			}
 			needsep = 1;
 		}
-		else if (opt->output_format & DIFF_FORMAT_DIFFSTAT)
+		else if (opt->output_format &
+			 (DIFF_FORMAT_NUMSTAT|DIFF_FORMAT_DIFFSTAT))
 			needsep = 1;
 		if (opt->output_format & DIFF_FORMAT_PATCH) {
 			if (needsep)
diff --git a/diff.c b/diff.c
index fb82432..2dcad19 100644
--- a/diff.c
+++ b/diff.c
@@ -795,6 +795,23 @@ static void show_stats(struct diffstat_t
 	       set, total_files, adds, dels, reset);
 }
 
+static void show_numstat(struct diffstat_t* data, struct diff_options *options)
+{
+	int i;
+
+	for (i = 0; i < data->nr; i++) {
+		struct diffstat_file *file = data->files[i];
+
+		printf("%d\t%d\t", file->added, file->deleted);
+		if (options->line_termination &&
+		    quote_c_style(file->name, NULL, NULL, 0))
+			quote_c_style(file->name, NULL, stdout, 0);
+		else
+			fputs(file->name, stdout);
+		putchar(options->line_termination);
+	}
+}
+
 struct checkdiff_t {
 	struct xdiff_emit_state xm;
 	const char *filename;
@@ -1731,6 +1748,7 @@ int diff_setup_done(struct diff_options 
 				      DIFF_FORMAT_CHECKDIFF |
 				      DIFF_FORMAT_NO_OUTPUT))
 		options->output_format &= ~(DIFF_FORMAT_RAW |
+					    DIFF_FORMAT_NUMSTAT |
 					    DIFF_FORMAT_DIFFSTAT |
 					    DIFF_FORMAT_SUMMARY |
 					    DIFF_FORMAT_PATCH);
@@ -1740,6 +1758,7 @@ int diff_setup_done(struct diff_options 
 	 * recursive bits for other formats here.
 	 */
 	if (options->output_format & (DIFF_FORMAT_PATCH |
+				      DIFF_FORMAT_NUMSTAT |
 				      DIFF_FORMAT_DIFFSTAT |
 				      DIFF_FORMAT_CHECKDIFF))
 		options->recursive = 1;
@@ -1828,6 +1847,9 @@ int diff_opt_parse(struct diff_options *
 	else if (!strcmp(arg, "--patch-with-raw")) {
 		options->output_format |= DIFF_FORMAT_PATCH | DIFF_FORMAT_RAW;
 	}
+	else if (!strcmp(arg, "--numstat")) {
+		options->output_format |= DIFF_FORMAT_NUMSTAT;
+	}
 	else if (!strncmp(arg, "--stat", 6)) {
 		char *end;
 		int width = options->stat_width;
@@ -2602,7 +2624,7 @@ void diff_flush(struct diff_options *opt
 		separator++;
 	}
 
-	if (output_format & DIFF_FORMAT_DIFFSTAT) {
+	if (output_format & (DIFF_FORMAT_DIFFSTAT|DIFF_FORMAT_NUMSTAT)) {
 		struct diffstat_t diffstat;
 
 		memset(&diffstat, 0, sizeof(struct diffstat_t));
@@ -2612,7 +2634,10 @@ void diff_flush(struct diff_options *opt
 			if (check_pair_status(p))
 				diff_flush_stat(p, options, &diffstat);
 		}
-		show_stats(&diffstat, options);
+		if (output_format & DIFF_FORMAT_NUMSTAT)
+			show_numstat(&diffstat, options);
+		if (output_format & DIFF_FORMAT_DIFFSTAT)
+			show_stats(&diffstat, options);
 		separator++;
 	}
 
diff --git a/diff.h b/diff.h
index b48c991..435c70c 100644
--- a/diff.h
+++ b/diff.h
@@ -26,20 +26,21 @@ typedef void (*diff_format_fn_t)(struct 
 
 #define DIFF_FORMAT_RAW		0x0001
 #define DIFF_FORMAT_DIFFSTAT	0x0002
-#define DIFF_FORMAT_SUMMARY	0x0004
-#define DIFF_FORMAT_PATCH	0x0008
+#define DIFF_FORMAT_NUMSTAT	0x0004
+#define DIFF_FORMAT_SUMMARY	0x0008
+#define DIFF_FORMAT_PATCH	0x0010
 
 /* These override all above */
-#define DIFF_FORMAT_NAME	0x0010
-#define DIFF_FORMAT_NAME_STATUS	0x0020
-#define DIFF_FORMAT_CHECKDIFF	0x0040
+#define DIFF_FORMAT_NAME	0x0100
+#define DIFF_FORMAT_NAME_STATUS	0x0200
+#define DIFF_FORMAT_CHECKDIFF	0x0400
 
 /* Same as output_format = 0 but we know that -s flag was given
  * and we should not give default value to output_format.
  */
-#define DIFF_FORMAT_NO_OUTPUT	0x0080
+#define DIFF_FORMAT_NO_OUTPUT	0x0800
 
-#define DIFF_FORMAT_CALLBACK	0x0100
+#define DIFF_FORMAT_CALLBACK	0x1000
 
 struct diff_options {
 	const char *filter;
-- 
1.4.3.rc2.gdce3

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Junio C Hamano wrote:
> This is only lightly tested. I haven't done test suite nor
> documentation, which the list should be able to take care of,
> now my git day for this week is over ;-).
> 
> -- >8 --
> [PATCH] diff --numstat

Does for example

	git diff-tree --numstat --patch-with-stat <tree-ish>

or

	git diff-tree --numstat -p <tree-ish>

work as expected, i.e. prepend diffstat in machine friendly (numstat)
format? What happens if one uses both --stat and --numstat?

-- >8 --
Documenting diff --numstat

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Is it enough documentation? Should we provide also numstat format
description in Documentation/diff-format.txt?

 Documentation/diff-options.txt |    5 +++++
 diff.h                         |    1 +
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 7b7b9e8..e112172 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -16,6 +16,11 @@
 	The width of the filename part can be controlled by
 	giving another width to it separated by a comma.
 
+--numstat::
+	Similar to \--stat, but shows number of added and
+	deleted lines in decimal notation and pathname without
+	abbreviation, to make it more machine friendly.
+
 --summary::
 	Output a condensed summary of extended header information
 	such as creations, renames and mode changes.
diff --git a/diff.h b/diff.h
index 435c70c..ce3058e 100644
--- a/diff.h
+++ b/diff.h
@@ -171,6 +171,7 @@ #define COMMON_DIFF_OPTIONS_HELP \
 "  --patch-with-raw\n" \
 "                output both a patch and the diff-raw format.\n" \
 "  --stat        show diffstat instead of patch.\n" \
+"  --numstat     show numeric diffstat instead of patch.\n" \
 "  --patch-with-stat\n" \
 "                output a patch and prepend its diffstat.\n" \
 "  --name-only   show only names of changed files.\n" \

-- 
Jakub Narebski
Poland

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Jakub Narebski wrote:

>  * Graph of number of changed files in given branch; probably should be
>    cached.

See for example StatCVS and FishEye
  http://www-128.ibm.com/developerworks/java/library/j-statcvs/
  http://statcvs.sourceforge.net/statcvs-stats/

  http://fisheye.codehaus.org/browse/activecluster
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

4. New features

 * Better support for symlinks in the "tree" view, perhaps in the
   "_filename_ -> _target_" form instead of simply "_filename_"
   if the symlink is relative, and the target is inside repository
   (not checking if it exists), "_filename_ -> target" otherwise.
   Needs some normalizing (removing of '/./' and '/../') of the symlink
   target.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Marco Costalba wrote:

> On 9/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Marco Costalba wrote:
>>
>>> On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
>>>>
>>>> By the way, do the diff between arbitrary revisions (say, between two
>>>> branches/two refs) and between arbitrary versions of the same file
>>>> would be useful to have in gitweb?
>>>>
>>>
>>> A nice tool, lot of ideas to steal ;-)
>>>
>>>http://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1
>>
>> FishEye? I haven't took the full tour, but the tool seems somewhat
>> CVS centric, i.e. per file history, file description,...
>>
>> But for example "breadcrumbs" idea for the file path (each segment
>> of path being link to given (sub)directory) is a nice one. Although 
>> if I remember correctly the pathname (for files only) is currently
>> hack to have somewhere link to "head" version of current file in
>> plain format. 
> 
> Also the UI for diff between arbitrary revisions could be interesting.

There is problem with git encouraging multiple branches and nonlinear
history. While it would be fairly easy either to add Wiki-like (e.g.
http://git.or.cz/gitwiki/ or http://en.wikipedia.org) radio-boxes to mark
revisions to compare, or add pull down menu to select revision (useless
with longer history) of a given file (we have diff-to-current in file
history, by the way), the true power of selecting revisions to compare
would be when we would have graphical history visualizer built in, similar
to gitk and qgit. 

By the way, do you known any common Perl modules for generating PNG
(graphs)?

P.S. This message seems to hit VGER BOGOfilter... ehhh...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git



-- 
VGER BF report: S 0.999997

Re: [RFC] gitweb wishlist and TODO list

[Marco Costalba]

>
> By the way, do you known any common Perl modules for generating PNG
> (graphs)?
>

No, I don't. sorry. Anyway, from my experience with qgit I can say
that one thing is to produce a revision graph, another thing is to
produce a _fast_ and (perhaps more important) no memory hogger
revision graph.

Both qgit and gitk implement heavy optimizations and a lot of tricks
to make that happen. IMHO this is almost mandatory with long and
complex histories like Linux tree. I'm not sure a generic graph
builder is up to the task.

More, gitweb is designed to be used by many people at the same time,
while qgit and gitk are for personal use only, and this adds burden
from the performance/resources  point of view.


  Marco

-- 
VGER BF report: U 0.807973

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Marco Costalba wrote:

>>
>> By the way, do you known any common Perl modules for generating PNG
>> (graphs)?
>>
> 
> No, I don't. sorry. Anyway, from my experience with qgit I can say
> that one thing is to produce a revision graph, another thing is to
> produce a _fast_ and (perhaps more important) no memory hogger
> revision graph.
> 
> Both qgit and gitk implement heavy optimizations and a lot of tricks
> to make that happen. IMHO this is almost mandatory with long and
> complex histories like Linux tree. I'm not sure a generic graph
> builder is up to the task.
> 
> More, gitweb is designed to be used by many people at the same time,
> while qgit and gitk are for personal use only, and this adds burden
> from the performance/resources  point of view.

Well, I guess even if/when gitweb acquires history graph support, it would
be paged like history/shortlog is, i.e. at most 100 commits to graph.

P.S. To those wondering why thread got broken, and why the parent post is
lost: vger bogofilter.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git



-- 
VGER BF report: S 0.992982

[RFC] gitweb wishlist and TODO list

[Jakub Narebski]

This is second series of planned gitweb features. Still ideas for many 
of them come from xmms2's gitweb version, which can you see in work at
  http://git.xmms.se/?p=gitweb-xmms2.git;a=summary
Some of gitweb features like snapshot support and clone/fetch URL were 
implemented, some of cleanup like refactoring navbar generation or 
putting CSS into separate style file too.

I have put the list here for three reasons. First to get input which 
features are most wanted, and to receive perhaps ideas for new 
features. Second, to have TODO list, and receive input if somebody is 
doing implementing some of the features to avoid duplicate work. Third, 
and most important, some of features needs discussion about _how_ to 
implement them.

Copy sent to Sham Chukoury, owner of gitweb-xmms2.


Cleanup, tidying, refactoring:
* HTML code still needs cleanup. All elements should have be either
  assigned class, or given unique id. Presentational elements like <i>
  or <b> should be replaced by styling using CSS. Page should be divided
  into block elements; avoid overuse of <br/>.

* CSS cleanup. Names of classes should reflect intent, not be
  replacement for presentational elements, or be incomprehensive:
  e.g. classes age0, age1, age2, dark, light. padding: 8px; repeats many
  times, perhaps it could be replaced by setting margin in encompassing
  element, or via inheritance or additional class.

* Separate generating link and related links to object 
  (e.g. "blob | blame | history | raw" for blob in "tree" view)
  into subroutine, similarly to refactoring navbar. The problem is that
  the set of links depends not only on the type of object, but also on
  the action/view we are in, for example links to commit object might
  be either "commit | commitdiff", or "log | shortlog" if the commit is
  considered ref. DISCUSSION needed.

* Collapse similar subroutines into one, e.g. git_blob and
  git_blob_plain, and use parameter to set format. Perhaps instead of
  having
	sub git_commitdiff_plain {
		git_commitdiff('plain');
	}
  we can simply use
	my %actions = (
		# ...
		"commitdiff_plain" => sub { git_commitdiff('plain'); }
		# ...
	);
  Which of this options is more readable, which one is faster?

* Refactoring formatsnav similarly to commit/hashbase related main
  navbar (upper part of navbar now). For blob it would be "html",
  "plain", "blame", "head" (or "base"), optionally "HEAD", "history",
  perhaps later "highlight". For tree it would be "tree", "blame" and
  "history". For commit it would be "html", "plain", and "combined" 
  if applicable.

* Perhaps some of the views should be made into format, e.g. 'shortlog'
  and 'log' (and perhaps 'rss') for log views (this includes
  "log"/"shortlog" and "history" views), or 'html', 'opml' and
  'plain'/'index' for "project_list". DISCUSSION encouraged.

* Things like description or cloneurls (repourls) and further category
  should be perhaps available to set in repository config, not only from
  additional files in repository.


Gitweb speed:
* Ensure that gitweb is compatibile with mod_perl not only in
  Apache::Registry/ModPerl::Registry CGI script compatibility mode,
  but also as native mod_perl handler/script. Make it easy to use
  FastCGI instead of CGI (perhaps via CGI::Fast).

  This could be ensured by creating 'handler'/'main' method which
  does parameter reading, validation and dispatching action. Perhaps
  we should add gitweb_params subroutine, which given the names
  of parameters returns values of needed parameters (either as list of
  parameter names and returning list of parameters in order set by
  subroutine argument, or as hash with keys and undefined values and
  returning hash or hashref with values filled). The exception being
  project and action parameters, which must be accessed before
  dispatching action.

  We could make script options parameters my() again, and leave our()
  only for global variables which changes from invocation to invocation,
  like $project, $action, $git_dir etc.  

* Add new CORE GIT command, git-show-refs, which returns for given
  by glob set of refs required fields (specified by --format option),
  sorted by given field (specified by --sort option). This would speed
  up "tags" and "summary" views considerably.

  See Junio post in "[PATCH/RFC] gitweb: Great subroutines renaming"
  thread for proposed git-show-refs options.
    http://permalink.gmane.org/gmane.comp.version-control.git/25055
    Message-Id: <7vejvsyum8.fsf@assigned-by-dhcp.cox.net>

* Try to avoid unnecessary calls to git commands, try do do things
  using one command. For example instead of getting list of revisions
  from git-rev-list, then parsing commit after commit use one 
  git-rev-list invocation to get and parse list of revisions.

  It would be easier if some CORE GIT commands, for example git-ls-tree,
  acquired --stdin option, similarly to git-diff-tree (and output
  revision before output for that revison, like git-diff-tree).

* In the future, use Git.pm


Improvements of existing views and features:
* Make pickaxe search a feature (as it is expensive), and document
  existing search operators. Perhaps refactor git_search as well.

* Make history follow renames. This could I think be done without CORE
  GIT support, but it would be better with it. The proposition is to add
  --follow option to git-rev-list (or -C, -M, -B options), which would
  make if follow renames in files in path limit; I think following
  renames with pathspec being glob is out, unless we expand glob to
  individual file names and then follow those, and that following
  directory renames would be very hard if not impossible.

  Additionally make git-rev-list output current path limit, in format
  suitable as argument for other git commands like git-diff-tree, i.e.
  	<hash> -- <path limit>
  instead of current
  	<hash>
  Make git-diff-tree at least accept and understand this kind of input
  also on stdin with --stdin option.

* Perhaps add number of changed lines to the short information about
  blob (perhaps via title to patch/diff link?), and diffstat to
  "commitdiff_plain" view.

* Parse $GIT_DIR/remotes/ to mark tracking branches in "heads" view,
  e.g. as a popup.


New features:
* Categories support (from gitweb-xmms2), although I'm not sure about
  adding yet another file "category" to git repository. Perhaps first
  part of dirname could serve as category name, or we could use
  gitweb.category configuration variable.

* Code highlighting in blob view (from gitweb-xmms2), or to generalize
  to allow for generalized filter. The higlighter should have support
  for HTML support, it should always close elements before end of line,
  it would be better if it used CSS for styling, and it should accept
  file to highlight on standard input. gitweb-xmms2 uses Highlight
    http://www.andre-simon.de/
  but GNU Highlight (src-hilite) could be used instead
    http://www.gnu.org/software/src-highlite/

* Committags support, i.e. extend hyperlinking commit sha1 to commit
  view to hyperlinking bug #nn/BUG(nn) to the proper bugtracker, in both
  commit message view and (harder to do properly) in commit
  title/subject line which is hyperlink itself. The problem is how to do
  this general enough...

  I have thought about structure somewhat similar to %feature hash, i.e.
  something like %commitfilter hash, with 'enabled', 'override', 'name',
  'options' or something like that and of course 'sub' (as we probably
  would use $cgi->a(...) to construct hyperlink, and not simple regexp
  replacement.

  DISCUSSION needed.

* Etags/Ctags/LXR based anchors in the blob view. In gitweb-xmms2 they
  use temporary file to avoid race condition for both etags and
  highlighting. Is it worth doing? GNU Highlight has ctags
  (encumberant-ctags) support built in, I don't know about Highlight.


New views:
* Reflog support: show history of branch. I'm not sure if it is worth
  doing, as of now reflogs are local matter, and doesn't get copied on
  push even to bare repository.

* ViewVC-like "tree_blame" view. It probably would need CORE GIT support
  to have acceptable speed, although version using git-ls-tree wasn't
  that slow. Or at least git-ls-tree with --stdin support.

* gitk-ish (qgit-ish) view, with graph showing branches forking and
  merging. Not that easy, but probably possible.


In the future:
* AJAX-ize parts of gitweb.


Comments? Other ideas? <wishful thinking>Code?</wishful thinking>
-- 
Jakub Narebski
ShadeHawk on #git
Poland

-- 
VGER BF report: H 0

Re: [RFC] gitweb wishlist and TODO list

[Marco Costalba]

>
> * Code highlighting in blob view (from gitweb-xmms2), or to generalize
>   to allow for generalized filter. The higlighter should have support
>   for HTML support, it should always close elements before end of line,
>   it would be better if it used CSS for styling, and it should accept
>   file to highlight on standard input. gitweb-xmms2 uses Highlight
>     http://www.andre-simon.de/
>   but GNU Highlight (src-hilite) could be used instead
>     http://www.gnu.org/software/src-highlite/
>

Current HEAD of qgit  (I plan to release the new version very shortly)
uses GNU Highlight. I can say this tool is easy to use yet very
flexible and configurable and, last but not the least, the developer
is very responsive.

My two cents.

  Marco

-- 
VGER BF report: U 0.500001

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

By the way, do the diff between arbitrary revisions (say, between two
branches/two refs) and between arbitrary versions of the same file would be
useful to have in gitweb?

-- 
Jakub Narębski
Poland


-- 
VGER BF report: U 0.5

Re: [RFC] gitweb wishlist and TODO list

[Marco Costalba]

On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
> By the way, do the diff between arbitrary revisions (say, between two
> branches/two refs) and between arbitrary versions of the same file would be
> useful to have in gitweb?
>

A nice tool, lot of ideas to steal ;-)

http://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1

-- 
VGER BF report: U 0.510515

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Marco Costalba wrote:

> On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
>>
>> By the way, do the diff between arbitrary revisions (say, between two
>> branches/two refs) and between arbitrary versions of the same file would be
>> useful to have in gitweb?
>>
> 
> A nice tool, lot of ideas to steal ;-)
> 
> http://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1

FishEye? I haven't took the full tour, but the tool seems somewhat
CVS centric, i.e. per file history, file description,...

But for example "breadcrumbs" idea for the file path (each segment of path
being link to given (sub)directory) is a nice one. Although if I remember
correctly the pathname (for files only) is currently hack to have somewhere
link to "head" version of current file in plain format.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git



-- 
VGER BF report: U 0.910123

Re: [RFC] gitweb wishlist and TODO list

[Marco Costalba]

On 9/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> > On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
> >>
> >> By the way, do the diff between arbitrary revisions (say, between two
> >> branches/two refs) and between arbitrary versions of the same file would be
> >> useful to have in gitweb?
> >>
> >
> > A nice tool, lot of ideas to steal ;-)
> >
> > http://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1
>
> FishEye? I haven't took the full tour, but the tool seems somewhat
> CVS centric, i.e. per file history, file description,...
>
> But for example "breadcrumbs" idea for the file path (each segment of path
> being link to given (sub)directory) is a nice one. Although if I remember
> correctly the pathname (for files only) is currently hack to have somewhere
> link to "head" version of current file in plain format.
> --

Also the UI for diff between arbitrary revisions could be interesting.

-- 
VGER BF report: U 0.791104

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Marco Costalba wrote:

> On 9/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Marco Costalba wrote:
>>
>>> On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
>>>>
>>>> By the way, do the diff between arbitrary revisions (say, between two
>>>> branches/two refs) and between arbitrary versions of the same file
>>>> would be useful to have in gitweb?
>>>>
>>>
>>> A nice tool, lot of ideas to steal ;-)
>>>
>>>http://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1
>>
>> FishEye? I haven't took the full tour, but the tool seems somewhat
>> CVS centric, i.e. per file history, file description,...
>>
>> But for example "breadcrumbs" idea for the file path (each segment
>> of path being link to given (sub)directory) is a nice one. Although 
>> if I remember correctly the pathname (for files only) is currently
>> hack to have somewhere link to "head" version of current file in
>> plain format. 
> 
> Also the UI for diff between arbitrary revisions could be interesting.

There is problem with git encouraging multiple branches and nonlinear
history. While it would be fairly easy either to add Wiki-like (e.g.
http://git.or.cz/gitwiki/ or http://en.wikipedia.org) radio-boxes to mark
revisions to compare, or add pull down menu to select revision (useless
with longer history) of a given file (we have diff-to-current in file
history, by the way), the true power of selecting revisions to compare
would be when we would have graphical history visualizer built in, similar
to gitk and qgit. 

By the way, do you known any common Perl modules for generating PNG
(graphs)?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git



-- 
VGER BF report: S 0.995678

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Jakub Narebski wrote:

> * Committags support, i.e. extend hyperlinking commit sha1 to commit
>   view to hyperlinking bug #nn/BUG(nn) to the proper bugtracker, in both
>   commit message view and (harder to do properly) in commit
>   title/subject line which is hyperlink itself. The problem is how to do
>   this general enough...
> 
>   I have thought about structure somewhat similar to %feature hash, i.e.
>   something like %commitfilter hash, with 'enabled', 'override', 'name',
>   'options' or something like that and of course 'sub' (as we probably
>   would use $cgi->a(...) to construct hyperlink, and not simple regexp
>   replacement.

I have very preliminary work, where gitweb uses @enabled_committags as list
of committags to use, and %committags_info for actual committags info.
Examples of committags includes current linking of commit sha1,
gitweb-xmms2 linking of BUG(n) and FEATURE(n) to site-wide based URL
(Mantis), and RELEASE x.y.z to site-wide based URL (Wiki); perhaps "bug n"
to site-wide/project-wide URL (Bugzilla)... any other ideas?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> I have very preliminary work, where gitweb uses @enabled_committags as list
> of committags to use, and %committags_info for actual committags info.
> Examples of committags includes current linking of commit sha1,
> gitweb-xmms2 linking of BUG(n) and FEATURE(n) to site-wide based URL
> (Mantis), and RELEASE x.y.z to site-wide based URL (Wiki); perhaps "bug n"
> to site-wide/project-wide URL (Bugzilla)... any other ideas?

Use a regexp as %committags key and its value to be whatever
that takes the matched string and munge it into a URL form
perhaps?  A site that does not have commit tags do not have any
element in that hash.

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> I have very preliminary work, where gitweb uses @enabled_committags as list
>> of committags to use, and %committags_info for actual committags info.
>> Examples of committags includes current linking of commit sha1,
>> gitweb-xmms2 linking of BUG(n) and FEATURE(n) to site-wide based URL
>> (Mantis), and RELEASE x.y.z to site-wide based URL (Wiki); perhaps "bug n"
>> to site-wide/project-wide URL (Bugzilla)... any other ideas?
> 
> Use a regexp as %committags key and its value to be whatever
> that takes the matched string and munge it into a URL form
> perhaps?  A site that does not have commit tags do not have any
> element in that hash.

The problem is when you have a bunch of projects, all server by the same 
gitweb, but otherwise unrelated, so needing different committags (e.g. one 
project uses Mantis and needs "BUG(n)" and "FEATURE(n)", another uses 
Bugzilla and needs "bug nn", yet another doesn't use any bugtracker).
And for committag you would want also information if to use it in summary
(title) in shortlog, head, history etc. views.

But this might be a good idea.

We loop over all enabled (active) committags.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

[RFC] gitweb wishlist and TODO list

[Jakub Narebski]

I am planning on copying features from xmms2's gitweb version 
to git's gitweb, and introducing new ones.

My gitweb can be seen at http://front.fuw.edu.pl/cgi-bin/jnareb/gitweb.cgi
Fetch from http://front.fuw.edu.pl/jnareb/scm/git.git/ (not checked!)


* HTML cleanup - ongoing process of replacing embedded style information
  with CSS styling, adding classes and ids to elements. This is independent 
  on other changes. On top of 'next', as it needs style in separate CSS
  file gitweb.css.

* Storing site-wide gitweb configuration in separate gitweb.conf file.
  Needs GIT_CONFIG patch. Not implemented yet.

  Bootstrapping: gitweb would need location of configuration file.
  Has to be changed in gitweb.cgi itself. Additionally gitexecdir or
  git in PATH is needed to be able to run git-repo-config to read config;
  the solution might be home-grown "parser" to find gitexecdir only.

  Both could be set from Makefile at install stage.

* Add git fetch URL to the project page from gitweb-xmms2. Needs site-wide
  base_url, which need not to be set as there is sane default: use base 
  of gitweb URL.

  Is it useful to allow repository configuration to override it?

* Support for categories from gitweb-xmms2. We can alternatively use
  directory structure of git projects displayed by gitweb as categories.
  Needs I think some site-wide configuration.

  Question: where store categories? .git/category, like .git/description?
  Use gitweb.category key? If yes, do convert description to repository key,
  or perhaps use gitweb.descriptionfile? What should be priority of those
  options if both are set: use repo-config for short (in project listing 
  and in page footer), and from file for long description on project page?
  What if they don't match?

* Refactor dispatch from if...elsif...else construction 
  to using 'name' => \&sub hash.

* Refactor generation of navigation bar. There are at least two
  implementations of that. With hash dispatch it would be easy to
  list all possibilities.

* Add (of course optional, like blame support) snapshot support. There are
  at least two different implementations. I'd prefer to do without second
  CGI script, but perhaps this is better from the performance point of view.
  gitweb-xmms2 has snapshot.cgi in Python: should it be rewritten in Perl?

* Code highlighting for plain view for blobs. gitweb-xmms2 did that using
  GNU highlight program and some embedded configuration (filename regexp to
  syntax used). More generic: run some post-processing. Configurable
  globally (perhaps separate "syntax type" filename or file magic mapping),
  and enabled per repository (default off).

* gitweb-xmms2 has something called committags support: it means that
  'BUG(n)', 'FEATURE(n)' and 'RELEASE: xx' in commit message are turned into
  bugtracker (Mantis for xmms2) or wiki links. It is extension of turning
  sha1-ids into references. Probably needs some extra configuration file,
  and some per repository configuration. Of course we want to support not
  only Mantis, but also e.g. Bugzilla (e.g. Linux kernel) and conventions
  for marking bugs therein.

* gitweb-xmms2 has also etags based anchors to mark function definitions 
  in blob view. I'm not sure it would be that usefull. LXR equivalent,
  perhaps...


Which of those should be implemented first?

Any further ideas for other useful features?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

On Tue, 20 Jun 2006 18:51:18 +0200, Jakub Narebski wrote:
>
> Any further ideas for other useful features?
>

Since you asked...

From the first time I saw gitweb the feature I wanted was to put
more useful information in the path of the URL rather than in the
query string.

One possible organization might be:

/<project>/<commitish>/<path>[/<more_path> ...]

I'd really like to be able to publish nice clean URLs (without any
query component) for getting at particular branches within projects,
for example.

The above might not be entirely feasible in the face of hierachical
project names containing '/' characters as they might then conflict
with branch names.

Another general feature I'd like is for URLs to be as interchangeable
as possible between gitweb and command-line git tools. My goal is to
be able to push out a new branch and then send an email announcing the
branch with a single URL something like:

	http://git.somewhere.org/project/branch

where this would obviously work if fed to a web browser, but ideally
would also be possible to feed to git-fetch or even git-clone perhaps
without requiring any user knowledge on how to mangle it first.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Carl Worth wrote:

> On Tue, 20 Jun 2006 18:51:18 +0200, Jakub Narebski wrote:
>>
>> Any further ideas for other useful features?
>>
> 
> Since you asked...
> 
> From the first time I saw gitweb the feature I wanted was to put
> more useful information in the path of the URL rather than in the
> query string.
> 
> One possible organization might be:
> 
> /<project>/<commitish>/<path>[/<more_path> ...]
> 
> I'd really like to be able to publish nice clean URLs (without any
> query component) for getting at particular branches within projects,
> for example.
> 
> The above might not be entirely feasible in the face of hierachical
> project names containing '/' characters as they might then conflict
> with branch names.

And in the face of topic branches with names like 'js/lsfix' or
'gitweb/config'.

Add to that the fact that above needs some support from web server
(e.g. Apache's mod_rewrite) and web server configuration, while gitweb tries
to be server agnostic...

One of the part of HTML cleanup would be changing order of URL query string,
so that the human readable part is first.


P.S. I have forgot about:
* Check how gitweb.cgi behaves with mod_perl, and correct/add modifications
  to support this mode better (and perhaps also FastCGI if it adds
  anything).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Petr Baudis]

Dear diary, on Tue, Jun 20, 2006 at 07:46:11PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Add to that the fact that above needs some support from web server
> (e.g. Apache's mod_rewrite) and web server configuration, while gitweb tries
> to be server agnostic...

Nope, you get the stuff in $PATH_INFO. And having at least just the
project name in the path part would be quite nice, it's my common gripe
with cvsweb as I frequently get to mangle with the query part manually
(can be much faster than clicking around) and I have to carefully evade
the project name part, which is something I would really expect to be in
the "static" part of the URL.

When we are talking about URLs, it would be quite nice if the query
parameter names would be actually meaningful instead of some cryptic
'h', 'pg' and whatnot.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Petr Baudis wrote:

> Dear diary, on Tue, Jun 20, 2006 at 07:46:11PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Add to that the fact that above needs some support from web server
>> (e.g. Apache's mod_rewrite) and web server configuration, while gitweb tries
>> to be server agnostic...
> 
> Nope, you get the stuff in $PATH_INFO. And having at least just the
> project name in the path part would be quite nice, it's my common gripe
> with cvsweb as I frequently get to mangle with the query part manually
> (can be much faster than clicking around) and I have to carefully evade
> the project name part, which is something I would really expect to be in
> the "static" part of the URL.

But without web server support I think you would need one copy/symbolic link
per repository served.

> When we are talking about URLs, it would be quite nice if the query
> parameter names would be actually meaningful instead of some cryptic
> 'h', 'pg' and whatnot.

I guess that is because hash values are somewhat long (40 characters wide),
so one letter parameter names were chosen to shorten URL.

Dictionary:
 'a'  - action (e.g. summary, log, commitdiff, blob, tree)
 'o'  - order by (for sorting tables)
 'p'  - project (might include category/directory: cogito/cogito.git, 
        git/git.git, git/gitk.git)
 'f'  - filename (I plan to move it before hash-valued parameters, 
        perhaps except hb which usually is symbolic) 
 'pg' - page
 's'  - searchtext (shouldn't it be 'q', from querystring?)
 'h'  - hash
 'hp' - hash parent (not used yet I think)
 'hb' - hash base (i.e. head or tag; underused I think)

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Petr Baudis]

Dear diary, on Tue, Jun 20, 2006 at 08:34:38PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
> 
> > Nope, you get the stuff in $PATH_INFO. And having at least just the
> > project name in the path part would be quite nice, it's my common gripe
> > with cvsweb as I frequently get to mangle with the query part manually
> > (can be much faster than clicking around) and I have to carefully evade
> > the project name part, which is something I would really expect to be in
> > the "static" part of the URL.
> 
> But without web server support I think you would need one copy/symbolic link
> per repository served.

Nope. As I said, the webserver stops in the path at the point it hits
the CGI and the rest is in $PATH_INFO.

> > When we are talking about URLs, it would be quite nice if the query
> > parameter names would be actually meaningful instead of some cryptic
> > 'h', 'pg' and whatnot.
> 
> I guess that is because hash values are somewhat long (40 characters wide),
> so one letter parameter names were chosen to shorten URL.

I might argue that since the hash values are so long, few extra bytes
for having the names make some sense aren't going to hurt.

Thanks for the dictionary, though. :)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Petr Baudis wrote:

> Nope, you get the stuff in $PATH_INFO. And having at least just the
> project name in the path part would be quite nice, it's my common gripe
> with cvsweb as I frequently get to mangle with the query part manually
> (can be much faster than clicking around) and I have to carefully evade
> the project name part, which is something I would really expect to be in
> the "static" part of the URL.

What about the patch I just sent:  "[PATCH] gitweb: Make use of $PATH_INFO
for project parameter" (<11509012742493-git-send-email-jnareb@gmail.com>)?

It doesn't as of yet make use of that.

I wonder if this solution would work for mod_perl, or one would need some
Apache-specific package...

P.S. I meant to sent the patch as reply to this mail. Oops.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Martin Langhoff]

On 6/21/06, Jakub Narebski <jnareb@gmail.com> wrote:
> I am planning on copying features from xmms2's gitweb version
> to git's gitweb, and introducing new ones.

Cool!

> * Storing site-wide gitweb configuration in separate gitweb.conf file.
>   Needs GIT_CONFIG patch. Not implemented yet.
>
>   Bootstrapping: gitweb would need location of configuration file.
>   Has to be changed in gitweb.cgi itself. Additionally gitexecdir or
>   git in PATH is needed to be able to run git-repo-config to read config;
>   the solution might be home-grown "parser" to find gitexecdir only.
>
>   Both could be set from Makefile at install stage.

There's been some discussion about reading GIT_CONFIG from %ENV (but
defaulting to the repo config). If GIT_CONFIG is set, I think we can
trick git-repo-config to parse it for us.

Now, I suspect we'll want to read _both_ the per-repo config and
GIT_CONFIG, which is likely to be /etc/gitweb.conf or similar.

> * Add git fetch URL to the project page from gitweb-xmms2. Needs site-wide
>   base_url, which need not to be set as there is sane default: use base
>   of gitweb URL.
>
>   Is it useful to allow repository configuration to override it?

I think so, as mentioned above.

> * Add (of course optional, like blame support) snapshot support. There are
>   at least two different implementations. I'd prefer to do without second
>   CGI script, but perhaps this is better from the performance point of view.
>   gitweb-xmms2 has snapshot.cgi in Python: should it be rewritten in Perl?

I intend to post a patch that adds snapshot support in Perl, in the
main code. Just need to make it optional ;-)

> * Code highlighting for plain view for blobs. gitweb-xmms2 did that using
>   GNU highlight program and some embedded configuration (filename regexp to
>   syntax used). More generic: run some post-processing. Configurable
>   globally (perhaps separate "syntax type" filename or file magic mapping),
>   and enabled per repository (default off).

Yep, probably a generic filter facility is better...

> * gitweb-xmms2 has something called committags support: it means that
>   'BUG(n)', 'FEATURE(n)' and 'RELEASE: xx' in commit message are turned into
>   bugtracker (Mantis for xmms2) or wiki links. It is extension of turning
>   sha1-ids into references. Probably needs some extra configuration file,
>   and some per repository configuration. Of course we want to support not
>   only Mantis, but also e.g. Bugzilla (e.g. Linux kernel) and conventions
>   for marking bugs therein.

That would be great.

...

> Which of those should be implemented first?

I like the order the list has... but it's up to you.

> Any further ideas for other useful features?

Now what I think would rock too is something similar to gitk's "nearby
tags" feature. When reading a commit, it lists the heads and tags that
this commit is part of. It's very useful. Now I'll have to read up on
how gitk does it.

And, as you mention in your other post, mod_perl support. And a bit of
speed. Gitweb rght now is really really slow.

cheers,



martin

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Martin Langhoff wrote:

> On 6/21/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> 
>> * Add (of course optional, like blame support) snapshot support. There are
>>   at least two different implementations. I'd prefer to do without second
>>   CGI script, but perhaps this is better from the performance point of view.
>>   gitweb-xmms2 has snapshot.cgi in Python: should it be rewritten in Perl?
> 
> I intend to post a patch that adds snapshot support in Perl, in the
> main code. Just need to make it optional ;-)

Check http://marc.theaimsgroup.com/?l=git&m=111909432415478&w=2 for 
in the main code snapshot implementation.

http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=summary
http://www.liacs.nl/~sverdool/gitweb.git

Would separate snapshot CGI script make it work faster?

>> Any further ideas for other useful features?
> 
> Now what I think would rock too is something similar to gitk's "nearby
> tags" feature. When reading a commit, it lists the heads and tags that
> this commit is part of. It's very useful. Now I'll have to read up on
> how gitk does it.

If I remember correctly, it was done in the background, and it was done 
at least partially _in_ gitk (Tcl/Tk).
 
> And, as you mention in your other post, mod_perl support. And a bit of
> speed. Gitweb right now is really really slow.

Perhaps mod_cache would help. Especially if cache can be configured to 
look only at the hash part, plus formatting (normal, plain/raw, blame,
search match highlighting).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Martin Langhoff]

On 6/21/06, Jakub Narebski <jnareb@gmail.com> wrote:
> > I intend to post a patch that adds snapshot support in Perl, in the
> > main code. Just need to make it optional ;-)
>
> Check http://marc.theaimsgroup.com/?l=git&m=111909432415478&w=2 for
> in the main code snapshot implementation.
>
> http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=summary
> http://www.liacs.nl/~sverdool/gitweb.git
>
> Would separate snapshot CGI script make it work faster?

I was thinking about that same one, we found (and fixed) a bug or two
on top of that so my plan is to rebase it on top of the gitweb on next
;-)

> >> Any further ideas for other useful features?
> >
> > Now what I think would rock too is something similar to gitk's "nearby
> > tags" feature. When reading a commit, it lists the heads and tags that
> > this commit is part of. It's very useful. Now I'll have to read up on
> > how gitk does it.
>
> If I remember correctly, it was done in the background, and it was done
> at least partially _in_ gitk (Tcl/Tk).

I suspect it is doing a whole lot of git-merge-base invocations, which
are rather costly. I don't know of any cheaper way to ask that
question.

> > And, as you mention in your other post, mod_perl support. And a bit of
> > speed. Gitweb right now is really really slow.
>
> Perhaps mod_cache would help. Especially if cache can be configured to
> look only at the hash part, plus formatting (normal, plain/raw, blame,
> search match highlighting).

Right, some URLs are guaranteed to be static (those blob views), so it
can just cache on the full URL, for ever and ever. The other ones...
well, we just make sure we don't do anything too expensive there ;-)



martin

Re: [RFC] gitweb wishlist and TODO list

[Paul Mackerras]

Martin Langhoff writes:

> > If I remember correctly, it was done in the background, and it was done
> > at least partially _in_ gitk (Tcl/Tk).
> 
> I suspect it is doing a whole lot of git-merge-base invocations, which
> are rather costly. I don't know of any cheaper way to ask that
> question.

There's no git-merge-base involved.  Gitk does a

git-rev-list --all --topo-order --parents

and reads the output of that, and then traverses the entire graph
forwards and backwards (in Tcl).  (This is after gitk has read the
output of git ls-remote $GIT_DIR, so it knows which commits have
tags.)

Paul.

Re: [RFC] gitweb wishlist and TODO list

[Dennis Stosberg]

Martin Langhoff wrote:

> And, as you mention in your other post, mod_perl support. And a bit of
> speed. Gitweb rght now is really really slow.

A few days ago I have tried to run gitweb under mod_perl and these
are my results.  All of this hasn't got any real testing, so this is
more a request for comment.  I had to make two changes to gitweb to
get it running as a Registry script with mod_perl:

(1) With mod_perl you cannot access variables which were defined
    with "my" on file scope from subroutines.  Unless gitweb becomes
    split in separate packages the easiest solution is probably to
    use "our" to declare them.

(2) Setting %ENV has no effect on spawned processes under mod_perl,
    so the git commands would never find the project directories.
    My first thought was to set $GIT_DIR on the commands' command
    lines like in open($fh, '$GIT_DIR=blah git-rev-list ...') but it
    would lead to an extra shell being spawned on every invocation
    of a git command.

    So I added the possibility to set/override the path to the
    repository with a command line parameter.  For simplicity I
    handled that parameter in git.c.  The drawbacks are that it has
    to be given before the command name and that it won't work when
    commands are invoked as "git-command".

The gains vary hugely.  Inexpensive views like the title page, blob
and commit view are sped up by a factor of 5 to 8 for successive
requests.  The project summary in contrast issues quite a number of
calls to git, so the speedup is only a few percent for it.

Regards,
Dennis

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Dennis Stosberg wrote:

> (2) Setting %ENV has no effect on spawned processes under mod_perl,
>     so the git commands would never find the project directories.
>     My first thought was to set $GIT_DIR on the commands' command
>     lines like in open($fh, '$GIT_DIR=blah git-rev-list ...') but it
>     would lead to an extra shell being spawned on every invocation
>     of a git command.
> 
>     So I added the possibility to set/override the path to the
>     repository with a command line parameter.  For simplicity I
>     handled that parameter in git.c.  The drawbacks are that it has
>     to be given before the command name and that it won't work when
>     commands are invoked as "git-command".

So now you have extra git redirector being spawned, instead of extra shell
being spawned. I wonder if using 'env' wouldn't be simplier, and how
portable 'env' is.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Dennis Stosberg]

Jakub Narebski wrote:

> So now you have extra git redirector being spawned, instead of extra shell
> being spawned. 

Most of the commands that Gitweb uses are built-ins, so there
shouldn't be any extra overhead by calling "git command" instead of
"git-command".  If I haven't missed one, git-annotate is the only one
which is not a built-in.

Regards,
Dennis

Re: [RFC] gitweb wishlist and TODO list

[Ryan Anderson]

On Thu, Jun 22, 2006 at 12:00:25PM +0200, Dennis Stosberg wrote:
> Jakub Narebski wrote:
> 
> > So now you have extra git redirector being spawned, instead of extra shell
> > being spawned. 
> 
> Most of the commands that Gitweb uses are built-ins, so there
> shouldn't be any extra overhead by calling "git command" instead of
> "git-command".  If I haven't missed one, git-annotate is the only one
> which is not a built-in.

git-annotate is a Perl script anyway, so it's not unreasonable to
consider making it a .pm module and just using it directly in gitweb.


-- 

Ryan Anderson
  sometimes Pug Majere

Re: [RFC] gitweb wishlist and TODO list

[Ryan Anderson]

On Wed, Jun 21, 2006 at 03:05:35PM +0200, Dennis Stosberg wrote:
> (2) Setting %ENV has no effect on spawned processes under mod_perl,
>     so the git commands would never find the project directories.
>     My first thought was to set $GIT_DIR on the commands' command
>     lines like in open($fh, '$GIT_DIR=blah git-rev-list ...') but it
>     would lead to an extra shell being spawned on every invocation
>     of a git command.


I haven't looked at gitweb much, but why can't you solve this by doing
manual pipe,fork,exec combinations?  That should give you complete
control over the environment, right?

(IIRC, the last time I played with mod_perl and spawning processes, I
recall it doing something very confusing with the pipes I had open.)


-- 

Ryan Anderson
  sometimes Pug Majere

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Ryan Anderson wrote:

> On Wed, Jun 21, 2006 at 03:05:35PM +0200, Dennis Stosberg wrote:
>> (2) Setting %ENV has no effect on spawned processes under mod_perl,
>>     so the git commands would never find the project directories.
>>     My first thought was to set $GIT_DIR on the commands' command
>>     lines like in open($fh, '$GIT_DIR=blah git-rev-list ...') but it
>>     would lead to an extra shell being spawned on every invocation
>>     of a git command.
> 
> I haven't looked at gitweb much, but why can't you solve this by doing
> manual pipe,fork,exec combinations?  That should give you complete
> control over the environment, right?

In gitweb.cgi we now use magic open "-|" invocation, e.g.:

        open my $fd, "-|", "$gitbin/git-cat-file -t $hash" or return;

in git-rerere we still fork magically, but exec explicitely

        my $pid = open($in, '-|');
        die "$!" unless defined $pid;
        if (!$pid) {
                exec(qw(git ls-files -z -u)) or die "$!: ls-files";
        }

The same is done in git-annotate (via open_pipe sub which takes care of
ActiveState Perl implementation); git-archimport, git-cvsexportcommit 
(via safe_pipe_capture); git-send-email (without encapsulating in 
a subroutine; it also uses backticks)  

git-svn uses fork + redirecting output + exec and waitpid for quiet_run
subroutine and system call.

git-cvsimport uses system call, backticks, straight pipe open, i.e. using
"git-command |", and magic open "-|" like gitweb.cgi. git-cvsserver has
safe_pipe_capture, but sometimes uses backticks. git-fmt-merge-message uses
backticks only. git-mv uses backticks and pipe. git-svnimport uses system
call and pipe.

What a mess. We really need Git.pm module...


And to answer your question, AFAICT exec cannot modify environment, not like
execve (or execle wrapper). POE (POE::Wheel::Run) or IPC::Run modules
perhaps...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> I am planning on copying features from xmms2's gitweb version 
> to git's gitweb, and introducing new ones.
>
> Which of those should be implemented first?

Clean-ups and obvious fixes without introducing new features
first please.

> * Add (of course optional, like blame support) snapshot support. There are
>   at least two different implementations. I'd prefer to do without second
>   CGI script, but perhaps this is better from the performance point of view.
>   gitweb-xmms2 has snapshot.cgi in Python: should it be rewritten in Perl?

Isn't it just the matter of spawning git-tar-tree?

> * gitweb-xmms2 has something called committags support: it means that
>   'BUG(n)', 'FEATURE(n)' and 'RELEASE: xx' in commit message are turned into
>   bugtracker (Mantis for xmms2) or wiki links. It is extension of turning
>   sha1-ids into references. Probably needs some extra configuration file,
>   and some per repository configuration. Of course we want to support not
>   only Mantis, but also e.g. Bugzilla (e.g. Linux kernel) and conventions
>   for marking bugs therein.

Yes, I found this quite nice.

BTW, are you in touch with xmms2 folks?

Re: [RFC] gitweb wishlist and TODO list

[Petr Baudis]

Dear diary, on Tue, Jun 20, 2006 at 06:51:18PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> * Add git fetch URL to the project page from gitweb-xmms2. Needs site-wide
>   base_url, which need not to be set as there is sane default: use base 
>   of gitweb URL.
> 
>   Is it useful to allow repository configuration to override it?

Certainly. E.g. http://pasky.or.cz/gitweb.cgi hosts some random projects
but generally they are to be fetched from totally different locations.

> * Refactor dispatch from if...elsif...else construction 
>   to using 'name' => \&sub hash.

In other words, you say the result of the IRC discussion we had about
symbol lookups and evals turned out really scary? ;-)

> * gitweb-xmms2 has something called committags support: it means that
>   'BUG(n)', 'FEATURE(n)' and 'RELEASE: xx' in commit message are turned into
>   bugtracker (Mantis for xmms2) or wiki links. It is extension of turning
>   sha1-ids into references. Probably needs some extra configuration file,
>   and some per repository configuration. Of course we want to support not
>   only Mantis, but also e.g. Bugzilla (e.g. Linux kernel) and conventions
>   for marking bugs therein.

For Bugzilla, just /\bbug (\d+)/i is frequently used so many people are
probably used to it while it feels natural and doesn't make you tumble
over it when reading the message.

For these things it's simplest to give the user ability to specify some
regexp substitutions to be applied on commit messages.

About sha1 turned to references, I don't think that's practical until
you will have some way of finding out whether a given sha1 is a valid
object reference without Theta(n) forks.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Petr Baudis wrote:

> Dear diary, on Tue, Jun 20, 2006 at 06:51:18PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...

>> * Refactor dispatch from if...elsif...else construction 
>>   to using 'name' => \&sub hash.
> 
> In other words, you say the result of the IRC discussion we had about
> symbol lookups and evals turned out really scary? ;-)

First, we need arrays (ordering!) of sets of possible actions for navbar,
so we will have list of all possible actions.

Besides, simple test

        [...]
        sub dispatch {
          dispatch_ifelse(@_);
          #dispatch_hash(@_);
          #dispatch_callname(@_);
          #dispatch_anonsub(@_);
        }
        
        sub test_dispatch_all {
          dispatch(undef);
        
          dispatch("summary");
          [...]
          dispatch("tag");
                
          dispatch("unknown");
          dispatch("tag();injected();");
        }
        
        test_dispatch_all() foreach (1..10000);

run with '$ time ./test.pl > /dev/null' has shown that (suprise, suprise!)
that hash is fastest, then if...elsif...else variant, then 
  my $sub = \&{"git_$action"}; eval { &$sub() };
and last, much much worse is eval "..." version.

Of course test leaves something to be desired...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Petr Baudis]

> Any further ideas for other useful features?

By the way, it would definitely make me feel better about gitweb
security-wise if it would run with taints checks on - they are very good
idea.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: [RFC] gitweb wishlist and TODO list

[Thomas Glanzmann]

Hello,

> Any further ideas for other useful features?

a friend of mine was yesterday complained to me about not be able to see
which file was last touched in a given directory like it is possible
with viewcvs[1]. I told him that he should just call 'git whatchanged
-p'. And he answered back 'downloading 128Mbytes' for a few bytes
of history? I told him to address this list with his feature request, but
he didn't do so far. So I use this opportunity. Maybe something else
would be much more handier: Use gitweb to request the log and shortlog
of a directory tree, like git-whatchanged arch/i386 does for example.
Maybe it is already possible and I missed it?

        Thomas

[1] viewcvs prints the last touch of a a file in a directory and you can
tell it to sort after the date criteria:

http://faumachine.informatik.uni-erlangen.de/cgi-bin/viewcvs.cgi/mutt/?sortby=date#dirlist

Re: [RFC] gitweb wishlist and TODO list

[Josef Weidendorfer]

On Tuesday 20 June 2006 23:53, you wrote:
> he didn't do so far. So I use this opportunity. Maybe something else
> would be much more handier: Use gitweb to request the log and shortlog
> of a directory tree, like git-whatchanged arch/i386 does for example.
> Maybe it is already possible and I missed it?

There aren't any links, but:
On the bottom of a commit, you can click on "history" for blobs.
Changing the URL afterwards (the f= arg) can give you the history of
a directory.

I just tried, and in fact it works. But "Diff to current" does not
work for directories.

It would be nice to have a list of the files in the directory
touched by the given commits.

Josef

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Josef Weidendorfer wrote:

> It would be nice to have a list of the files in the directory
> touched by the given commits.

'commit' view gives at the bottom list of all files affected by given
commit. Is that what you wanted, or did you want 'blame' for directories
(trees)?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Josef Weidendorfer]

On Wednesday 21 June 2006 11:15, you wrote:
> Josef Weidendorfer wrote:
> 
> > It would be nice to have a list of the files in the directory
> > touched by the given commits.
> 
> 'commit' view gives at the bottom list of all files affected by given
> commit.

Yup, but when you are interested in the history of changes to files in
a given directory, you also want to see the name of the changed files on
the same page, and not have to click on every commit to get the file names.
Besides, the "commit" view shows all changed files, and not only the ones
which are in the directory.

> Is that what you wanted, or did you want 'blame' for directories 
> (trees)?

Could be interesting; but everytime I look at such a page in ViewCVS,
I want to have it sorted by time...

Josef

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Josef Weidendorfer wrote:

> On Wednesday 21 June 2006 11:15, Jakub Narebski wrote:
>> Josef Weidendorfer wrote:
>> 
>>> It would be nice to have a list of the files in the directory
>>> touched by the given commits.
>> 
>> 'commit' view gives at the bottom list of all files affected by given
>> commit.
> 
> Yup, but when you are interested in the history of changes to files in
> a given directory, you also want to see the name of the changed files on
> the same page, and not have to click on every commit to get the file
> names. Besides, the "commit" view shows all changed files, and not only 
> the ones which are in the directory.

Could you please create a mockup how you imagine the page to look like
(in ascii-art)? At least list the columns...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Josef Weidendorfer wrote:
> On Wednesday 21 June 2006 15:53, Jakub Narebski wrote:
>>> Yup, but when you are interested in the history of changes to files in
>>> a given directory, you also want to see the name of the changed files on
>>> the same page, and not have to click on every commit to get the file
>>> names. Besides, the "commit" view shows all changed files, and not only 
>>> the ones which are in the directory.
>> 
>> Could you please create a mockup how you imagine the page to look like
>> (in ascii-art)? At least list the columns...
> 
> Let's see. A think a mixture between current history and log...
> Currently, it looks like this
> 
>  http://git.kernel.org/git/?p=git/git.git;a=history;f=Documentation
> 
> gives you the history of subdirectory Documentation/ of git
> (unfortunately only reachable via changing the URL...).
> 
> And it could look as attached (I did a little copy/paste of
> HTML). I only modified 2 commits of the list...

It probably didn't get to mailing list (at least to archives) due 
to having attachement.

I thought you wanted to enhance tree view, e.g. adding to the view like in

  http://git.kernel.org/git/?p=git/git.git;a=tree;f=Documentation

columns 'Changed by' or 'Author', 'Age' or 'Last changed', 'Commit' 
(i.e. abbreviated sha1 id of a commit), and perhaps shortened commit
message (short description of changes, a la shortlog but shorther).
In other words 'blame'/'annotate' for directory. Which would need new git
command I think.

Adding filtered list of files modified by commit in log and history views 
should be fairly easy...
-- 
Jakub Narebski
Poland

Re: [RFC] gitweb wishlist and TODO list

[Josef Weidendorfer]

On Wednesday 21 June 2006 18:38, you wrote:
> Josef Weidendorfer wrote:
> > Let's see. A think a mixture between current history and log...
> > Currently, it looks like this
> > 
> >  http://git.kernel.org/git/?p=git/git.git;a=history;f=Documentation
> > 
> > gives you the history of subdirectory Documentation/ of git
> > (unfortunately only reachable via changing the URL...).
> > 
> > And it could look as attached (I did a little copy/paste of
> > HTML). I only modified 2 commits of the list...
> 
> It probably didn't get to mailing list (at least to archives) due 
> to having attachement.

Yes; the mailing list regarded as spam because of the attachment.

> I thought you wanted to enhance tree view,

That wasn't me ;-)

> e.g. adding to the view like in 
> 
>   http://git.kernel.org/git/?p=git/git.git;a=tree;f=Documentation
> 
> columns 'Changed by' or 'Author', 'Age' or 'Last changed', 'Commit' 
> (i.e. abbreviated sha1 id of a commit), and perhaps shortened commit
> message (short description of changes, a la shortlog but shorther).

Yes, sometimes this could be interesting. However, as said above,
I find myself often looking for date sorting with such views.

> In other words 'blame'/'annotate' for directory. Which would need new git
> command I think.

Hmmm... wouldn't "git-log --summary", and building up a map from files names
to commits be enough? You would probably need to parse the full history before
sending any output, so it is potentially heavy. 

> Adding filtered list of files modified by commit in log and history views 
> should be fairly easy...

Yes. If I get some time, I'll send a patch.

Josef

Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski]

Jakub Narebski wrote:

> I am planning on copying features from xmms2's gitweb version 
> to git's gitweb, and introducing new ones.

> * Refactor generation of navigation bar. There are at least two
>   implementations of that. With hash dispatch it would be easy to
>   list all possibilities.

Actually I think that whole gitweb.cgi needs refactoring, badly. Generation
of navigation bar is only one, admittedly worst, example of code
duplication.


Another gitweb feature I can think of:

* Add information about from which repository and which branch in the
  remote repository given branch (head) came from. Should support both
  $GIT_DIR/branches and $GIT_DIR/remotes format, and be easy extendable
  to support branch/repo/remotes configuration in config.

  I think it would be best to show this info (as it is variable long length,
  and optional) as the last column of heads listing. Or would be better to
  just add link with the remote name as text?

  Is git://host.xz/path/to/repo.git#branch correct branch URI?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [RFC] gitweb wishlist and TODO list

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Jakub Narebski wrote:
>
>> I am planning on copying features from xmms2's gitweb version 
>> to git's gitweb, and introducing new ones.
>
>> * Refactor generation of navigation bar. There are at least two
>>   implementations of that. With hash dispatch it would be easy to
>>   list all possibilities.
>
> Actually I think that whole gitweb.cgi needs refactoring, badly. Generation
> of navigation bar is only one, admittedly worst, example of code
> duplication.

Yes.  I liked what xmms2 folks did to the navbar exactly for
that reason.  We would be better off to first clean up what we
currently have before starting to build too much on it.