[RFC] gitweb wishlist and TODO list

[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

[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

[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

[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

[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

[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

[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

[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

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

[Dennis Stosberg]

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

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

[Dennis Stosberg]

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

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

[Dennis Stosberg]

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

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: [PATCH 3/3] gitweb: Use --git-dir parameter instead of setting $ENV{'GIT_DIR'}

[Timo Hirvonen]

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/

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

[Jakub Narebski]

Timo Hirvonen wrote:

> 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

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]

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

[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

[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

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

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

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