Re: [RFC] gitweb wishlist and TODO list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/21/06, Jakub Narebski <jnareb@xxxxxxxxx> 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
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]