This is short summary of not-applied (and not ready to be applied) gitweb patches, in reverse chronological order, with most recent entries on top (first). Patches which probably should be resend, now that we are after 1.6.0 release Junio, what about "[PATCH] avoid gitweb uninitialized value warning" (http://thread.gmane.org/gmane.comp.version-control.git/95028)? This is pure bugfix (well, warning fix, and failrly rare one, but warning which goes to web server logs). $gmane=thread.gmane.org/gmane.comp.version-control.git 1. "gitweb pathinfo improvements" by Giuseppe Bilotta Message-ID: <1220435839-29360-1-git-send-email-giuseppe.bilotta@xxxxxxxxx> http://$gmane/94779 Table of contents: ================== * [PATCH 1/5] gitweb: action in path with use_pathinfo * [PATCH 2/5] gitweb: use_pathinfo filenames start with / * [PATCH 3/5] gitweb: parse parent..current syntax from pathinfo * [PATCH 4/5] gitweb: use_pathinfo creates parent..current paths * [PATCH 5/5] gitweb: remove PATH_INFO from $my_url and $my_uri Need some refinement, especially with respect to _generating_ path_info URLs inside gitweb. Some patches (2 and 5) does not need correction, and probably should be sent as separate series. Author promised to resend series, if I remember correctly. 2. "[PATCH] gitweb: shortlog now also obeys $hash_parent" by Giuseppe Bilotta Message-ID: <1218204731-9931-1-git-send-email-giuseppe.bilotta@xxxxxxxxx> http://$gmane/91666 Very good idea, but for the following two caveats. The name '$commit_hash' is a bit strange to mean also revision range; passing "a..b" to parse_commits()... well, it is a good solution, but for me it feels a bit hacky. But this is not something serious. More importnat fact is that I'd very much like for _all_ log-like views (perhaps with exception of feeds: Atom and RSS) to implement this feature. This could be done by either doing it all in the same commit, doing commit series changing 'shortlog', 'log' and 'history' separately, or what I would prefer actually, to refactor generation of log-like views to use single worker/engine subroutine. 3. "[PATCH 1/1] Add "git" link to the end of project line on the project_list page." by John 'Warthog9' Hawley Message-ID: <1217815217-11329-2-git-send-email-warthog19@xxxxxxxxxxxxxx> http://$gmane/91305 See also: http://$gmane/90778 As it was said in the commit message (which should be line-wrapped by the way) it makes the assumption that each repository is available from unique location. Both per-repo cloneurl and gitweb.url, and per instllation @git_base_url_list allow for multiple repository URLs. The problem of course is _which_ of those to choose for the targer of 'git' links on projects list page. And I don't think adding yet another prefix to generate $project URL is a good dolution; better to simply use first of URLs, and mention it both in comments in gitweb, and in gitweb/README. Perhaps simply use first entry in @git_base_url_list. Commit message could be improved too. 3. "Re: [PATCH 0/3] Git::Repo API and gitweb caching" by Lea Wiemann Message-ID: <48A9CEC0.2020100@xxxxxxxxx> http://$gmane/92726 Demo: http://odin3.kernel.org/git-lewiemann/ Result of "gitweb caching" Google Summer of Code 2008 project. This is second resend of gitweb patch; the patches adding Mechanize test of gitweb output, and Git::Repo api had more revisions (reviews) on git mailing list. Quote (perhaps it is simply not possible...): > I unfortunately didn't end up being able to split up the third patch > (use Perl API in Gitweb, and add caching layer), since the two changes > are too intricately linked to be properly separated (I actually tried > splitting it two times, two different ways, and it just didn't work). Those patches, in particular the gitweb one, needs some review I think, as they affect quite a bit of code. 4. "[PATCH 0/2] gitweb use sections" by Gustavo Sverzut Barbieri Message-ID: <1217298868-16513-1-git-send-email-barbieri@xxxxxxxxxxxxxx> http://$gmane/90553 Demo: http://staff.get-e.org/ Patches overview: ================== * [PATCH 1/2] gitweb: sort projects by path. * [PATCH 2/2] gitweb: add section support to gitweb project listing. What I'd like to have for first patch is at least estimating performance hit (if there is any), and an example where original old code sorts paths wrongly. Nevetheless I think it is a good idea to have. I didn't reviewed the code though... -- Jakub Narebski Poland -- To unsubscribe from this list: 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
