threads / rfc / 4592

[RFC] gitweb wishlist and TODO list

Subject: [RFC] gitweb wishlist and TODO list

## tl;dr

35 messages between Jun 20, 2006 and Jul 1, 2006.

replies: 34people: 11as markdown or json

Jakub Narebski· Jun 20, 2006, 16:51 UTC · lore

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
Carl Worth· Jun 20, 2006, 17:33 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

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
Jakub Narebski· Jun 20, 2006, 17:46 UTC · re: Carl Worth · lore

Re: [RFC] gitweb wishlist and TODO list

Carl Worth wrote:
Show 22 quoted lines
> 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
Petr Baudis· Jun 20, 2006, 17:55 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

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.
Jakub Narebski· Jun 20, 2006, 18:34 UTC · re: Petr Baudis · lore

Re: [RFC] gitweb wishlist and TODO list

Petr Baudis wrote:
Show 12 quoted lines
> 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
Petr Baudis· Jun 20, 2006, 18:40 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

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

Show 11 quoted lines
> 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.

Show 6 quoted lines
> > 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.
Jakub Narebski· Jun 21, 2006, 14:52 UTC · re: Petr Baudis · lore

Re: [RFC] gitweb wishlist and TODO list

Petr Baudis wrote:
Show 6 quoted lines
> 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
Martin Langhoff· Jun 20, 2006, 19:33 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

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!
Show 9 quoted lines
> * 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.

Show 5 quoted lines
> * 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 ;-)

Show 5 quoted lines
> * 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...
Show 7 quoted lines
> * 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
Jakub Narebski· Jun 20, 2006, 19:56 UTC · re: Martin Langhoff · lore

Re: [RFC] gitweb wishlist and TODO list

Martin Langhoff wrote:
Show 9 quoted lines
> 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?
Show 6 quoted lines
>> 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
Martin Langhoff· Jun 20, 2006, 21:17 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

On 6/21/06, Jakub Narebski <jnareb@gmail.com> wrote:
Show 10 quoted lines
> > 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 ;-)

Show 9 quoted lines
> >> 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.

Show 6 quoted lines
> > 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
Paul Mackerras· Jul 1, 2006, 10:35 UTC · re: Martin Langhoff · lore

Re: [RFC] gitweb wishlist and TODO list

Martin Langhoff writes:
Show 6 quoted lines
> > 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.
Dennis Stosberg· Jun 21, 2006, 13:05 UTC · re: Martin Langhoff · lore

Re: [RFC] gitweb wishlist and TODO list

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

Dennis Stosberg· Jun 21, 2006, 13:07 UTC · re: Dennis Stosberg · lore

[PATCH 1/3] gitweb: Declare global variables with "our"

Variables declared with "my" in the file scope cannot be accessed from
subroutines with mod_perl.
---
 gitweb/gitweb.cgi |   55 ++++++++++++++++++++++++++---------------------------
 1 files changed, 27 insertions(+), 28 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index ef7fcbd..8f19fdb 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -16,21 +16,21 @@ use Encode;
 use Fcntl ':mode';
 binmode STDOUT, ':utf8';
 
-my $cgi = new CGI;
-my $version = "267";
-my $my_url = $cgi->url();
-my $my_uri = $cgi->url(-absolute => 1);
-my $rss_link = "";
+our $cgi = new CGI;
+our $version = "267";
+our $my_url = $cgi->url();
+our $my_uri = $cgi->url(-absolute => 1);
+our $rss_link = "";
 
 # location of the git-core binaries
-my $gitbin = "/usr/bin";
+our $gitbin = "/usr/bin";
 
 # absolute fs-path which will be prepended to the project path
-#my $projectroot = "/pub/scm";
-my $projectroot = "/home/kay/public_html/pub/scm";
+#our $projectroot = "/pub/scm";
+our $projectroot = "/home/kay/public_html/pub/scm";
 
 # version of the git-core binaries
-my $git_version = qx($gitbin/git --version);
+our $git_version = qx($gitbin/git --version);
 if ($git_version =~ m/git version (.*)$/) {
 	$git_version = $1;
 } else {
@@ -38,32 +38,31 @@ if ($git_version =~ m/git version (.*)$/
 }
 
 # location for temporary files needed for diffs
-my $git_temp = "/tmp/gitweb";
+our $git_temp = "/tmp/gitweb";
 
 # target of the home link on top of all pages
-my $home_link = $my_uri;
+our $home_link = $my_uri;
 
 # html text to include at home page
-my $home_text = "indextext.html";
+our $home_text = "indextext.html";
 
 # URI of default stylesheet
-my $stylesheet = "gitweb.css";
+our $stylesheet = "gitweb.css";
 
 # source of projects list
-#my $projects_list = $projectroot;
-my $projects_list = "index/index.aux";
+#our $projects_list = $projectroot;
+our $projects_list = "index/index.aux";
 
 # default blob_plain mimetype and default charset for text/plain blob
-my $default_blob_plain_mimetype = 'text/plain';
-my $default_text_plain_charset  = undef;
+our $default_blob_plain_mimetype = 'text/plain';
+our $default_text_plain_charset  = undef;
 
 # file to use for guessing MIME types before trying /etc/mime.types
 # (relative to the current git repository)
-my $mimetypes_file = undef;
-
+our $mimetypes_file = undef;
 
 # input validation and dispatch
-my $action = $cgi->param('a');
+our $action = $cgi->param('a');
 if (defined $action) {
 	if ($action =~ m/[^0-9a-zA-Z\.\-_]/) {
 		undef $action;
@@ -78,7 +77,7 @@ if (defined $action) {
 	}
 }
 
-my $order = $cgi->param('o');
+our $order = $cgi->param('o');
 if (defined $order) {
 	if ($order =~ m/[^0-9a-zA-Z_]/) {
 		undef $order;
@@ -86,7 +85,7 @@ if (defined $order) {
 	}
 }
 
-my $project = $cgi->param('p');
+our $project = $cgi->param('p');
 if (defined $project) {
 	$project = validate_input($project);
 	if (!defined($project)) {
@@ -108,7 +107,7 @@ if (defined $project) {
 	exit;
 }
 
-my $file_name = $cgi->param('f');
+our $file_name = $cgi->param('f');
 if (defined $file_name) {
 	$file_name = validate_input($file_name);
 	if (!defined($file_name)) {
@@ -116,7 +115,7 @@ if (defined $file_name) {
 	}
 }
 
-my $hash = $cgi->param('h');
+our $hash = $cgi->param('h');
 if (defined $hash) {
 	$hash = validate_input($hash);
 	if (!defined($hash)) {
@@ -124,7 +123,7 @@ if (defined $hash) {
 	}
 }
 
-my $hash_parent = $cgi->param('hp');
+our $hash_parent = $cgi->param('hp');
 if (defined $hash_parent) {
 	$hash_parent = validate_input($hash_parent);
 	if (!defined($hash_parent)) {
@@ -132,7 +131,7 @@ if (defined $hash_parent) {
 	}
 }
 
-my $hash_base = $cgi->param('hb');
+our $hash_base = $cgi->param('hb');
 if (defined $hash_base) {
 	$hash_base = validate_input($hash_base);
 	if (!defined($hash_base)) {
@@ -140,7 +139,7 @@ if (defined $hash_base) {
 	}
 }
 
-my $page = $cgi->param('pg');
+our $page = $cgi->param('pg');
 if (defined $page) {
 	if ($page =~ m/[^0-9]$/) {
 		undef $page;
@@ -148,7 +147,7 @@ if (defined $page) {
 	}
 }
 
-my $searchtext = $cgi->param('s');
+our $searchtext = $cgi->param('s');
 if (defined $searchtext) {
 	if ($searchtext =~ m/[^a-zA-Z0-9_\.\/\-\+\:\@ ]/) {
 		undef $searchtext;
-- 
1.4.0
Dennis Stosberg· Jun 21, 2006, 13:08 UTC · re: Dennis Stosberg · lore

[PATCH 2/3] Add a parameter to specify the repository path

---
 builtin-help.c |    2 +-
 git.c          |    6 ++++++
 2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/builtin-help.c b/builtin-help.c
index 7470faa..db233eb 100644
--- a/builtin-help.c
+++ b/builtin-help.c
@@ -10,7 +10,7 @@ #include "exec_cmd.h"
 #include "common-cmds.h"
 
 static const char git_usage[] =
-	"Usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--help] COMMAND [ ARGS ]";
+	"Usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--git-dir=GIT_DIR] [--help] COMMAND [ ARGS ]";
 
 /* most gui terms set COLUMNS (although some don't export it) */
 static int term_columns(void)
diff --git a/git.c b/git.c
index 94e9a4a..d49f626 100644
--- a/git.c
+++ b/git.c
@@ -277,6 +277,12 @@ int main(int argc, const char **argv, ch
 			puts(git_exec_path());
 			exit(0);
 		}
+
+		if (!strncmp(cmd, "git-dir=", 8)) {
+			setenv("GIT_DIR", cmd + 8, 1);
+			continue;
+		}
+
 		cmd_usage(0, NULL, NULL);
 	}
 	argv[0] = cmd;
-- 
1.4.0
Dennis Stosberg· Jun 21, 2006, 13:09 UTC · re: Dennis Stosberg · lore

[PATCH 3/3] gitweb: Use --git-dir parameter instead of setting $ENV{'GIT_DIR'}

---
 gitweb/gitweb.cgi |   67 +++++++++++++++++++++++++++--------------------------
 1 files changed, 34 insertions(+), 33 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 8f19fdb..57ac3a3 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -61,6 +61,9 @@ # file to use for guessing MIME types be
 # (relative to the current git repository)
 our $mimetypes_file = undef;
 
+# path to the project's repository
+our $git_dir = undef;
+
 # input validation and dispatch
 our $action = $cgi->param('a');
 if (defined $action) {
@@ -101,7 +104,7 @@ if (defined $project) {
 	}
 	$rss_link = "<link rel=\"alternate\" title=\"" . esc_param($project) . " log\" href=\"" .
 		    "$my_uri?" . esc_param("p=$project;a=rss") . "\" type=\"application/rss+xml\"/>";
-	$ENV{'GIT_DIR'} = "$projectroot/$project";
+	$git_dir = "$projectroot/$project";
 } else {
 	git_project_list();
 	exit;
@@ -372,7 +375,7 @@ sub die_error {
 sub git_get_type {
 	my $hash = shift;
 
-	open my $fd, "-|", "$gitbin/git-cat-file -t $hash" or return;
+	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir cat-file -t $hash" or return;
 	my $type = <$fd>;
 	close $fd or return;
 	chomp $type;
@@ -381,19 +384,15 @@ sub git_get_type {
 
 sub git_read_head {
 	my $project = shift;
-	my $oENV = $ENV{'GIT_DIR'};
 	my $retval = undef;
-	$ENV{'GIT_DIR'} = "$projectroot/$project";
-	if (open my $fd, "-|", "$gitbin/git-rev-parse", "--verify", "HEAD") {
+
+	if (open my $fd, "-|", "$gitbin/git", "--git-dir=$projectroot/$project", "rev-parse", "--verify", "HEAD") {
 		my $head = <$fd>;
 		close $fd;
 		if (defined $head && $head =~ /^([0-9a-fA-F]{40})$/) {
 			$retval = $1;
 		}
 	}
-	if (defined $oENV) {
-		$ENV{'GIT_DIR'} = $oENV;
-	}
 	return $retval;
 }
 
@@ -424,7 +423,7 @@ sub git_read_tag {
 	my %tag;
 	my @comment;
 
-	open my $fd, "-|", "$gitbin/git-cat-file tag $tag_id" or return;
+	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir cat-file tag $tag_id" or return;
 	$tag{'id'} = $tag_id;
 	while (my $line = <$fd>) {
 		chomp $line;
@@ -496,7 +495,7 @@ sub git_read_commit {
 		@commit_lines = @$commit_text;
 	} else {
 		$/ = "\0";
-		open my $fd, "-|", "$gitbin/git-rev-list --header --parents --max-count=1 $commit_id" or return;
+		open my $fd, "-|", "$gitbin/git  --git-dir=$git_dir rev-list --header --parents --max-count=1 $commit_id" or return;
 		@commit_lines = split '\n', <$fd>;
 		close $fd or return;
 		$/ = "\n";
@@ -594,7 +593,7 @@ sub git_diff_print {
 	if (defined $from) {
 		$from_tmp = "$git_temp/gitweb_" . $$ . "_from";
 		open my $fd2, "> $from_tmp";
-		open my $fd, "-|", "$gitbin/git-cat-file blob $from";
+		open my $fd, "-|", "$gitbin/git --git-dir=$git_dir cat-file blob $from";
 		my @file = <$fd>;
 		print $fd2 @file;
 		close $fd2;
@@ -605,7 +604,7 @@ sub git_diff_print {
 	if (defined $to) {
 		$to_tmp = "$git_temp/gitweb_" . $$ . "_to";
 		open my $fd2, "> $to_tmp";
-		open my $fd, "-|", "$gitbin/git-cat-file blob $to";
+		open my $fd, "-|", "$gitbin/git --git-dir=$git_dir cat-file blob $to";
 		my @file = <$fd>;
 		print $fd2 @file;
 		close $fd2;
@@ -844,10 +843,12 @@ sub git_project_list {
 	}
 	foreach my $pr (@list) {
 		my $head = git_read_head($pr->{'path'});
+		print STDERR $head;
+
 		if (!defined $head) {
 			next;
 		}
-		$ENV{'GIT_DIR'} = "$projectroot/$pr->{'path'}";
+		$git_dir = "$projectroot/$pr->{'path'}";
 		my %co = git_read_commit($head);
 		if (!%co) {
 			next;
@@ -1046,7 +1047,7 @@ sub git_summary {
 	      "<tr><td>owner</td><td>$owner</td></tr>\n" .
 	      "<tr><td>last change</td><td>$cd{'rfc2822'}</td></tr>\n" .
 	      "</table>\n";
-	open my $fd, "-|", "$gitbin/git-rev-list --max-count=17 " . git_read_head($project) or die_error(undef, "Open failed.");
+	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir rev-list --max-count=17 " . git_read_head($project) or die_error(undef, "Open failed.");
 	my (@revlist) = map { chomp; $_ } <$fd>;
 	close $fd;
 	print "<div>\n" .
@@ -1224,7 +1225,7 @@ sub git_tag {
 
 sub git_blame {
 	my $fd;
-	die_error('403 Permission denied', "Permission denied.") if (!git_get_project_config_bool ('blame'));
+	#die_error('403 Permission denied', "Permission denied.") if (!git_get_project_config_bool ('blame'));
 	die_error('404 Not Found', "What file will it be, master?") if (!$file_name);
 	$hash_base ||= git_read_head($project);
 	die_error(undef, "Reading commit failed.") unless ($hash_base);
@@ -1234,7 +1235,7 @@ sub git_blame {
 		$hash = git_get_hash_by_path($hash_base, $file_name, "blob")
 			or die_error(undef, "Error lookup file.");
 	}
-	open ($fd, "-|", "$gitbin/git-annotate", '-l', '-t', '-r', $file_name, $hash_base)
+	open ($fd, "-|", "$gitbin/git", "--git-dir=$git_dir", "annotate", '-l', '-t', '-r', $file_name, $hash_base)
 		or die_error(undef, "Open failed.");
 	git_header_html();
 	print "<div class=\"page_nav\">\n" .
@@ -1429,7 +1430,7 @@ sub git_get_hash_by_path {
 	my $tree = $base;
 	my @parts = split '/', $path;
 	while (my $part = shift @parts) {
-		open my $fd, "-|", "$gitbin/git-ls-tree $tree" or die_error(undef, "Open git-ls-tree failed.");
+		open my $fd, "-|", "$gitbin/git --git-dir=$git_dir ls-tree $tree" or die_error(undef, "Open git-ls-tree failed.");
 		my (@entries) = map { chomp; $_ } <$fd>;
 		close $fd or return undef;
 		foreach my $line (@entries) {
@@ -1457,8 +1458,8 @@ sub git_blob {
 		my $base = $hash_base || git_read_head($project);
 		$hash = git_get_hash_by_path($base, $file_name, "blob") || die_error(undef, "Error lookup file.");
 	}
-	my $have_blame = git_get_project_config_bool ('blame');
-	open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or die_error(undef, "Open failed.");
+	my $have_blame = 1; #git_get_project_config_bool ('blame');
+	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir cat-file blob $hash" or die_error(undef, "Open failed.");
 	git_header_html();
 	if (defined $hash_base && (my %co = git_read_commit($hash_base))) {
 		print "<div class=\"page_nav\">\n" .
@@ -1570,7 +1571,7 @@ sub git_blob_plain_mimetype {
 }
 
 sub git_blob_plain {
-	open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or return;
+	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir cat-file blob $hash" or return;
 	my $type = git_blob_plain_mimetype($fd, $file_name);
 
 	# save as filename, even when no $file_name is given
@@ -1602,7 +1603,7 @@ sub git_tree {
 		}
 	}
 	$/ = "\0";
-	open my $fd, "-|", "$gitbin/git-ls-tree -z $hash" or die_error(undef, "Open git-ls-tree failed.");
+	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir ls-tree -z $hash" or die_error(undef, "Open git-ls-tree failed.");
 	chomp (my (@entries) = <$fd>);
 	close $fd or die_error(undef, "Reading tree failed.");
 	$/ = "\n";
@@ -1683,7 +1684,7 @@ #			      " | " . $cgi->a({-href => "$my
 
 sub git_rss {
 	# http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
-	open my $fd, "-|", "$gitbin/git-rev-list --max-count=150 " . git_read_head($project) or die_error(undef, "Open failed.");
+	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir rev-list --max-count=150 " . git_read_head($project) or die_error(undef, "Open failed.");
 	my (@revlist) = map { chomp; $_ } <$fd>;
 	close $fd or die_error(undef, "Reading rev-list failed.");
 	print $cgi->header(-type => 'text/xml', -charset => 'utf-8');
@@ -1703,7 +1704,7 @@ sub git_rss {
 			last;
 		}
 		my %cd = date_str($co{'committer_epoch'});
-		open $fd, "-|", "$gitbin/git-diff-tree -r $co{'parent'} $co{'id'}" or next;
+		open $fd, "-|", "$gitbin/git --git-dir=$git_dir diff-tree -r $co{'parent'} $co{'id'}" or next;
 		my @difftree = map { chomp; $_ } <$fd>;
 		close $fd or next;
 		print "<item>\n" .
@@ -1756,7 +1757,7 @@ sub git_opml {
 		if (!defined $head) {
 			next;
 		}
-		$ENV{'GIT_DIR'} = "$projectroot/$proj{'path'}";
+		$git_dir = "$projectroot/$proj{'path'}";
 		my %co = git_read_commit($head);
 		if (!%co) {
 			next;
@@ -1791,7 +1792,7 @@ sub git_log {
 	      " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tree;h=$hash;hb=$hash")}, "tree") . "<br/>\n";
 
 	my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
-	open my $fd, "-|", "$gitbin/git-rev-list $limit $hash" or die_error(undef, "Open failed.");
+	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir rev-list $limit $hash" or die_error(undef, "Open failed.");
 	my (@revlist) = map { chomp; $_ } <$fd>;
 	close $fd;
 
@@ -1882,7 +1883,7 @@ sub git_commit {
 		$root = " --root";
 		$parent = "";
 	}
-	open my $fd, "-|", "$gitbin/git-diff-tree -r -M $root $parent $hash" or die_error(undef, "Open failed.");
+	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir diff-tree -r -M $root $parent $hash" or die_error(undef, "Open failed.");
 	@difftree = map { chomp; $_ } <$fd>;
 	close $fd or die_error(undef, "Reading diff-tree failed.");
 
@@ -2124,7 +2125,7 @@ sub git_commitdiff {
 	if (!defined $hash_parent) {
 		$hash_parent = $co{'parent'};
 	}
-	open my $fd, "-|", "$gitbin/git-diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
+	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
 	my (@difftree) = map { chomp; $_ } <$fd>;
 	close $fd or die_error(undef, "Reading diff-tree failed.");
 
@@ -2214,14 +2215,14 @@ sub git_commitdiff {
 
 sub git_commitdiff_plain {
 	mkdir($git_temp, 0700);
-	open my $fd, "-|", "$gitbin/git-diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
+	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
 	my (@difftree) = map { chomp; $_ } <$fd>;
 	close $fd or die_error(undef, "Reading diff-tree failed.");
 
 	# try to figure out the next tag after this commit
 	my $tagname;
 	my $refs = read_info_ref("tags");
-	open $fd, "-|", "$gitbin/git-rev-list HEAD";
+	open $fd, "-|", "$gitbin/git --git-dir=$git_dir rev-list HEAD";
 	chomp (my (@commits) = <$fd>);
 	close $fd;
 	foreach my $commit (@commits) {
@@ -2291,7 +2292,7 @@ sub git_history {
 	      "</div>\n";
 	print "<div class=\"page_path\"><b>/" . esc_html($file_name) . "</b><br/></div>\n";
 
-	open my $fd, "-|", "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin -- \'$file_name\'";
+	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir rev-list $hash | $gitbin/git --git-dir=$git_dir diff-tree -r --stdin -- \'$file_name\'";
 	my $commit;
 	print "<table cellspacing=\"0\">\n";
 	my $alternate = 0;
@@ -2383,7 +2384,7 @@ sub git_search {
 	my $alternate = 0;
 	if ($commit_search) {
 		$/ = "\0";
-		open my $fd, "-|", "$gitbin/git-rev-list --header --parents $hash" or next;
+		open my $fd, "-|", "$gitbin/git --git-dir=$git_dir rev-list --header --parents $hash" or next;
 		while (my $commit_text = <$fd>) {
 			if (!grep m/$searchtext/i, $commit_text) {
 				next;
@@ -2433,7 +2434,7 @@ sub git_search {
 
 	if ($pickaxe_search) {
 		$/ = "\n";
-		open my $fd, "-|", "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin -S\'$searchtext\'";
+		open my $fd, "-|", "$gitbin/git --git-dir=$git_dir rev-list $hash | $gitbin/git --git-dir=$git_dir diff-tree -r --stdin -S\'$searchtext\'";
 		undef %co;
 		my @files;
 		while (my $line = <$fd>) {
@@ -2504,7 +2505,7 @@ sub git_shortlog {
 	      " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tree;h=$hash;hb=$hash")}, "tree") . "<br/>\n";
 
 	my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
-	open my $fd, "-|", "$gitbin/git-rev-list $limit $hash" or die_error(undef, "Open failed.");
+	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir rev-list $limit $hash" or die_error(undef, "Open failed.");
 	my (@revlist) = map { chomp; $_ } <$fd>;
 	close $fd;
 
-- 
1.4.0
Timo Hirvonen· Jun 21, 2006, 13:33 UTC · re: Dennis Stosberg · lore

Re: [PATCH 3/3] gitweb: Use --git-dir parameter instead of setting $ENV{'GIT_DIR'}

Dennis Stosberg <dennis@stosberg.net> wrote:
> -	open my $fd, "-|", "$gitbin/git-cat-file -t $hash" or return;
> +	open my $fd, "-|", "$gitbin/git --git-dir=$git_dir cat-file -t $hash" or return;
How about adding a function to simplify calling the git commands?

Something like git("cat-file -t $hash") which would return "$gitbin/git --git-dir=$git_dir cat-file -t $hash" string.

I'm not Perl programmer so I don't know what would be the best way to do this.

-- 
http://onion.dynserv.net/~timo/
Jakub Narebski· Jun 21, 2006, 13:42 UTC · re: Timo Hirvonen · lore

Re: [PATCH 3/3] gitweb: Use --git-dir parameter instead of setting $ENV{'GIT_DIR'}

Timo Hirvonen wrote:
Show 9 quoted lines
> Dennis Stosberg <dennis@stosberg.net> wrote:
> 
>> -    open my $fd, "-|", "$gitbin/git-cat-file -t $hash" or return;
>> +    open my $fd, "-|", "$gitbin/git --git-dir=$git_dir cat-file -t $hash" or return;
> 
> How about adding a function to simplify calling the git commands?
> 
> Something like git("cat-file -t $hash") which would return
> "$gitbin/git --git-dir=$git_dir cat-file -t $hash" string.

Or rather add a function(s) to call git commands, either returning git command output, or filehandle to read from, e.g.

  my $fd = git_open("cat-file", "-t $hash") or return; 
i.e. each parameter separately, just in case.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Jakub Narebski· Jun 21, 2006, 13:30 UTC · re: Dennis Stosberg · lore

Re: [RFC] gitweb wishlist and TODO list

Dennis Stosberg wrote:
Show 12 quoted lines
> (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
Dennis Stosberg· Jun 22, 2006, 10:00 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

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

Ryan Anderson· Jun 22, 2006, 14:47 UTC · re: Dennis Stosberg · lore

Re: [RFC] gitweb wishlist and TODO list

On Thu, Jun 22, 2006 at 12:00:25PM +0200, Dennis Stosberg wrote:
Show 9 quoted lines
> 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
Ryan Anderson· Jun 21, 2006, 16:45 UTC · re: Dennis Stosberg · lore

Re: [RFC] gitweb wishlist and TODO list

On Wed, Jun 21, 2006 at 03:05:35PM +0200, Dennis Stosberg wrote:
Show 6 quoted lines
> (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
Jakub Narebski· Jun 21, 2006, 17:36 UTC · re: Ryan Anderson · lore

Re: [RFC] gitweb wishlist and TODO list

Ryan Anderson wrote:
Show 11 quoted lines
> 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
Junio C Hamano· Jun 20, 2006, 19:46 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

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?
Show 7 quoted lines
> * 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?
Petr Baudis· Jun 20, 2006, 20:10 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

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

Show 5 quoted lines
> * 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? ;-)

Show 7 quoted lines
> * 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.
Jakub Narebski· Jun 20, 2006, 20:59 UTC · re: Petr Baudis · lore

Re: [RFC] gitweb wishlist and TODO list

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...
Show 5 quoted lines
>> * 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
Petr Baudis· Jun 20, 2006, 21:25 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

> 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.
Thomas Glanzmann· Jun 20, 2006, 21:53 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

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
Josef Weidendorfer· Jun 21, 2006, 08:56 UTC · re: Thomas Glanzmann · lore

Re: [RFC] gitweb wishlist and TODO list

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
Jakub Narebski· Jun 21, 2006, 09:15 UTC · re: Josef Weidendorfer · lore

Re: [RFC] gitweb wishlist and TODO list

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
Josef Weidendorfer· Jun 21, 2006, 09:57 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

On Wednesday 21 June 2006 11:15, you wrote:
Show 7 quoted lines
> 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
Jakub Narebski· Jun 21, 2006, 13:53 UTC · re: Josef Weidendorfer · lore

Re: [RFC] gitweb wishlist and TODO list

Josef Weidendorfer wrote:
Show 14 quoted lines
> 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
Jakub Narebski· Jun 22, 2006, 09:01 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

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
Junio C Hamano· Jun 22, 2006, 09:14 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

Jakub Narebski <jnareb@gmail.com> writes:
Show 12 quoted lines
> 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.

Jakub Narebski· Jun 21, 2006, 16:38 UTC · lore

Re: [RFC] gitweb wishlist and TODO list

Josef Weidendorfer wrote:
Show 20 quoted lines
> 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
Josef Weidendorfer· Jun 21, 2006, 20:35 UTC · re: Jakub Narebski · lore

Re: [RFC] gitweb wishlist and TODO list

On Wednesday 21 June 2006 18:38, you wrote:
Show 14 quoted lines
> 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 ;-)
Show 7 quoted lines
> 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

← back to recent threads