On 6/12/06, Florian Forster <octo@xxxxxxxxxxxx> wrote:
On Mon, Jun 12, 2006 at 10:02:05AM +1200, Martin Langhoff wrote:
> good! git-blame/git-annotate are quite expensive to run. Do you think
> it would make sense making it conditional on a git-repo-config option
> (gitweb.blame=1)?
sure, that it's a big change and if it helps the kernel.org folks ;)
I'll follow-up with a patch for this in a second..
That'd be great. I am looking into integrating other feature patches
too (like tarball downloads) that are useful but costly, making them
conditional too...
Would it help to cache `git-annotate's output, e.g. using one of the
I think we can rely on proxies doing good caching -- a busy host like
kernel.org will have big reverse proxies in front. A git-blame for a
given file+commitsha doesn't change, so we can give it a long cache
time, like... forever ;-)
I have two more points regarding gitweb's configuration:
- IMHO it would make sense to move the general gitweb-configuration
(where are the repositories, where are the binaries, etc) out of the
script. As far as I know the Debian maintainer of the `gitweb'
package has asked for this before but was refused for some reason..
Sounds like a reasonable request. I would make it rely on env vars,
$ENV{GITWEB_CONFIG} can generally point to /etc/gitweb.conf, and that
would override the config values we have.
This is trivial, and it means we buy a lot of flexibility from
apache's httpd.conf being able to point to different config files
depending on arbitrarty conditions.
BTW, I haven't seen the debian maintainer's request, was that on the list?
- If `GIT_DIR/description' is only used by gitweb it may be more
consistent to use the git-repo-config option `gitweb.description' in
the future.
Not sure how git-repo configurations deal with long entries. Right now
the description may contain html for instance.
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