{"thread":{"id":"15607","subject":"What's cooking in gitweb (20 Sep 2008)","startedAt":"2008-09-20T23:38:00Z","lastAt":"2008-09-22T16:51:22Z","messageCount":5,"participants":["Jakub Narebski","Junio C Hamano","Giuseppe Bilotta"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"91208","messageId":"200809210138.01874.jnareb@gmail.com","threadId":"15607","inReplyTo":null,"subject":"What's cooking in gitweb (20 Sep 2008)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-09-20T23:38:00Z","receivedAt":"2008-09-20T23:38:00Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"This is short summary of not-applied (and not ready to be applied)\ngitweb patches, in reverse chronological order, with most recent\nentries on top (first). Patches which probably should be resend, now\nthat we are after 1.6.0 release\n\nJunio, what about \"[PATCH] avoid gitweb uninitialized value warning\"\n(http://thread.gmane.org/gmane.comp.version-control.git/95028)? This\nis pure bugfix (well, warning fix, and failrly rare one, but warning\nwhich goes to web server logs).\n\n$gmane=thread.gmane.org/gmane.comp.version-control.git\n\n\n1. \"gitweb pathinfo improvements\" by Giuseppe Bilotta\n   Message-ID: <1220435839-29360-1-git-send-email-giuseppe.bilotta@gmail.com>\n   http://$gmane/94779\n\n   Table of contents:\n   ==================\n    * [PATCH 1/5] gitweb: action in path with use_pathinfo\n    * [PATCH 2/5] gitweb: use_pathinfo filenames start with /\n    * [PATCH 3/5] gitweb: parse parent..current syntax from pathinfo\n    * [PATCH 4/5] gitweb: use_pathinfo creates parent..current paths\n    * [PATCH 5/5] gitweb: remove PATH_INFO from $my_url and $my_uri\n\n   Need some refinement, especially with respect to _generating_\n   path_info URLs inside gitweb.  Some patches (2 and 5) does not\n   need correction, and probably should be sent as separate series.\n   Author promised to resend series, if I remember correctly.\n\n\n2. \"[PATCH] gitweb: shortlog now also obeys $hash_parent\" by Giuseppe Bilotta\n   Message-ID: <1218204731-9931-1-git-send-email-giuseppe.bilotta@gmail.com>\n   http://$gmane/91666\n\n   Very good idea, but for the following two caveats.  The name\n   '$commit_hash' is a bit strange to mean also revision range; passing\n   \"a..b\" to parse_commits()... well, it is a good solution, but for me it\n   feels a bit hacky.  But this is not something serious.\n\n   More importnat fact is that I'd very much like for _all_ log-like views\n   (perhaps with exception of feeds: Atom and RSS) to implement this\n   feature.  This could be done by either doing it all in the same commit,\n   doing commit series changing 'shortlog', 'log' and 'history' separately,\n   or what I would prefer actually, to refactor generation of log-like views\n   to use single worker/engine subroutine.\n\n\n3. \"[PATCH 1/1] Add \"git\" link to the end of project line on the\n   project_list page.\" by John 'Warthog9' Hawley\n   Message-ID: <1217815217-11329-2-git-send-email-warthog19@eaglescrag.net>\n   http://$gmane/91305\n   See also: http://$gmane/90778\n\n   As it was said in the commit message (which should be line-wrapped by\n   the way) it makes the assumption that each repository is available from\n   unique location.  Both per-repo cloneurl and gitweb.url, and per\n   instllation @git_base_url_list allow for multiple repository URLs.\n\n   The problem of course is _which_ of those to choose for the targer of\n   'git' links on projects list page.  And I don't think adding yet another\n   prefix to generate $project URL is a good dolution; better to simply\n   use first of URLs, and mention it both in comments in gitweb, and in\n   gitweb/README.  Perhaps simply use first entry in @git_base_url_list.\n\n   Commit message could be improved too.\n\n\n3. \"Re: [PATCH 0/3] Git::Repo API and gitweb caching\" by Lea Wiemann\n   Message-ID: <48A9CEC0.2020100@gmail.com>\n   http://$gmane/92726\n   Demo: http://odin3.kernel.org/git-lewiemann/\n\n   Result of \"gitweb caching\" Google Summer of Code 2008 project.\n   This is second resend of gitweb patch; the patches adding Mechanize\n   test of gitweb output, and Git::Repo api had more revisions (reviews)\n   on git mailing list.\n\n   Quote (perhaps it is simply not possible...):\n   > I unfortunately didn't end up being able to split up the third patch\n   > (use Perl API in Gitweb, and add caching layer), since the two changes\n   > are too intricately linked to be properly separated (I actually tried\n   > splitting it two times, two different ways, and it just didn't work).\n\n   Those patches, in particular the gitweb one, needs some review I think,\n   as they affect quite a bit of code.\n\n\n4. \"[PATCH 0/2] gitweb use sections\" by Gustavo Sverzut Barbieri\n   Message-ID: <1217298868-16513-1-git-send-email-barbieri@profusion.mobi>\n   http://$gmane/90553\n   Demo: http://staff.get-e.org/\n\n   Patches overview:\n   ==================\n   * [PATCH 1/2] gitweb: sort projects by path.\n   * [PATCH 2/2] gitweb: add section support to gitweb project listing.\n\n   What I'd like to have for first patch is at least estimating\n   performance hit (if there is any), and an example where original old\n   code sorts paths wrongly.\n\n   Nevetheless I think it is a good idea to have.  I didn't reviewed the\n   code though...\n\n\n-- \nJakub Narebski\nPoland\n"},{"id":"91213","messageId":"7vhc8a14lo.fsf@gitster.siamese.dyndns.org","threadId":"15607","inReplyTo":"200809210138.01874.jnareb@gmail.com","subject":"Re: What's cooking in gitweb (20 Sep 2008)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-21T04:54:11Z","receivedAt":"2008-09-21T04:54:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Junio, what about \"[PATCH] avoid gitweb uninitialized value warning\"\n> (http://thread.gmane.org/gmane.comp.version-control.git/95028)? This\n> is pure bugfix (well, warning fix, and failrly rare one, but warning\n> which goes to web server logs).\n\nThanks for a summary.  I think I've applied this one a few days ago to\n'maint' and merged the result up.\n"},{"id":"91257","messageId":"cb7bb73a0809211322q5aa6d8ex88651aa33a6c2688@mail.gmail.com","threadId":"15607","inReplyTo":"200809210138.01874.jnareb@gmail.com","subject":"Re: What's cooking in gitweb (20 Sep 2008)","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-09-21T20:22:55Z","receivedAt":"2008-09-21T20:22:55Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"Hi Jakub, hi all,\n\nsorry for the late reply, I was out of town and connectionless for two\nweeks and I'm getting back on track now.\n\n> 1. \"gitweb pathinfo improvements\" by Giuseppe Bilotta\n>   Message-ID: <1220435839-29360-1-git-send-email-giuseppe.bilotta@gmail.com>\n>   http://$gmane/94779\n>\n>   Table of contents:\n>   ==================\n>    * [PATCH 1/5] gitweb: action in path with use_pathinfo\n>    * [PATCH 2/5] gitweb: use_pathinfo filenames start with /\n>    * [PATCH 3/5] gitweb: parse parent..current syntax from pathinfo\n>    * [PATCH 4/5] gitweb: use_pathinfo creates parent..current paths\n>    * [PATCH 5/5] gitweb: remove PATH_INFO from $my_url and $my_uri\n>\n>   Need some refinement, especially with respect to _generating_\n>   path_info URLs inside gitweb.  Some patches (2 and 5) does not\n>   need correction, and probably should be sent as separate series.\n>   Author promised to resend series, if I remember correctly.\n\nI'll resend the whole series (plus an additional patch to fix an\naesthetical issue I found recently) as soon as I fix the url\ngeneration for the dotted filename corner case (which by re-reading\nthe past emails seemed to be the only significant issue, correct?).\nShould be shortly\n\n> 2. \"[PATCH] gitweb: shortlog now also obeys $hash_parent\" by Giuseppe Bilotta\n>   Message-ID: <1218204731-9931-1-git-send-email-giuseppe.bilotta@gmail.com>\n>   http://$gmane/91666\n>\n>   Very good idea, but for the following two caveats.  The name\n>   '$commit_hash' is a bit strange to mean also revision range; passing\n>   \"a..b\" to parse_commits()... well, it is a good solution, but for me it\n>   feels a bit hacky.  But this is not something serious.\n>\n>   More importnat fact is that I'd very much like for _all_ log-like views\n>   (perhaps with exception of feeds: Atom and RSS) to implement this\n>   feature.  This could be done by either doing it all in the same commit,\n>   doing commit series changing 'shortlog', 'log' and 'history' separately,\n>   or what I would prefer actually, to refactor generation of log-like views\n>   to use single worker/engine subroutine.\n\nI agree that refactoring is probably the best idea. It will also take\nme some more time ;)\n\nBTW, I haven't heard from Lea, so can I just assume that my patches\ndon't touch any of her caching improvements?\n\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"91308","messageId":"200809221443.38689.jnareb@gmail.com","threadId":"15607","inReplyTo":"cb7bb73a0809211322q5aa6d8ex88651aa33a6c2688@mail.gmail.com","subject":"Re: What's cooking in gitweb (20 Sep 2008)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-09-22T12:43:37Z","receivedAt":"2008-09-22T12:43:37Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Giuseppe Bilotta wrote:\n\n> > 1. \"gitweb pathinfo improvements\" by Giuseppe Bilotta\n[...]\n> >   Need some refinement, especially with respect to _generating_\n> >   path_info URLs inside gitweb.  Some patches (2 and 5) does not\n> >   need correction, and probably should be sent as separate series.\n> >   Author promised to resend series, if I remember correctly.\n> \n> I'll resend the whole series (plus an additional patch to fix an\n> aesthetical issue I found recently) as soon as I fix the url\n> generation for the dotted filename corner case (which by re-reading\n> the past emails seemed to be the only significant issue, correct?).\n\nI think it was the only significant issue (besides the fact that\ntwo mentioned patches could be in separate series).  To be more\nexact the issue was with generating gitweb URLs for sets of\nparameters which cannot be represented as path_info URL.  One\nexample was filename with '..' in it, which cannot be used in\nthe following path_info form:\n  $hash_parent_base:$file_parent..$hash_base:$filename\nbut it can be used in 'no name change' form\n  $hash_parent_base..$hash_base:$filename\nThis requires fallback to 'query' form URL.\n\nOther example was branch name with the same name as one of gitweb\nactions, which require action to be stated explicitly even if it\nis default action and otherwise could be omitted.\n\n> Should be shortly.\n\nI see that it is now. Thanks.\n\n> > 2. \"[PATCH] gitweb: shortlog now also obeys $hash_parent\"\n> > by Giuseppe Bilotta \n[...]\n> > More important fact is that I'd very much like for _all_ log-like\n> > views (perhaps with exception of feeds: Atom and RSS) to implement\n> > this feature.  This could be done by either doing it all in the same\n> > commit, doing commit series changing 'shortlog', 'log' and 'history'\n> > separately, or what I would prefer actually, to refactor generation\n> > of log-like views to use single worker/engine subroutine.\n> \n> I agree that refactoring is probably the best idea. It will also take\n> me some more time ;)\n\nBut it has the advantage of making it easier to add more log-like\nviews, like 'log' like view for the 'history' view, i.e. --pretty=full\nlike view with path limiting.\n\nI have thought about doing the refactoring (it is/was on my long-term\nTODO list for gitweb), but I haven't even found good way to code it,\nto be flexible but not too generalized.  Callbacks, perhaps?\n \n> BTW, I haven't heard from Lea, so can I just assume that my patches\n> don't touch any of her caching improvements?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"91327","messageId":"cb7bb73a0809220951p5c19d19g2d79ecba0ef7e394@mail.gmail.com","threadId":"15607","inReplyTo":"200809221443.38689.jnareb@gmail.com","subject":"Re: What's cooking in gitweb (20 Sep 2008)","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-09-22T16:51:22Z","receivedAt":"2008-09-22T16:51:22Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Mon, Sep 22, 2008 at 2:43 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n> Giuseppe Bilotta wrote:\n>>\n>> I'll resend the whole series (plus an additional patch to fix an\n>> aesthetical issue I found recently) as soon as I fix the url\n>> generation for the dotted filename corner case (which by re-reading\n>> the past emails seemed to be the only significant issue, correct?).\n>\n> I think it was the only significant issue (besides the fact that\n> two mentioned patches could be in separate series).  To be more\n> exact the issue was with generating gitweb URLs for sets of\n> parameters which cannot be represented as path_info URL.  One\n> example was filename with '..' in it, which cannot be used in\n> the following path_info form:\n>  $hash_parent_base:$file_parent..$hash_base:$filename\n> but it can be used in 'no name change' form\n>  $hash_parent_base..$hash_base:$filename\n> This requires fallback to 'query' form URL.\n\nThis is fixed in the resend.\n\n> Other example was branch name with the same name as one of gitweb\n> actions, which require action to be stated explicitly even if it\n> is default action and otherwise could be omitted.\n\nGenerated urls now _always_ contain the action\n\n>> > 2. \"[PATCH] gitweb: shortlog now also obeys $hash_parent\"\n>> > by Giuseppe Bilotta\n> [...]\n>> > More important fact is that I'd very much like for _all_ log-like\n>> > views (perhaps with exception of feeds: Atom and RSS) to implement\n>> > this feature.  This could be done by either doing it all in the same\n>> > commit, doing commit series changing 'shortlog', 'log' and 'history'\n>> > separately, or what I would prefer actually, to refactor generation\n>> > of log-like views to use single worker/engine subroutine.\n>>\n>> I agree that refactoring is probably the best idea. It will also take\n>> me some more time ;)\n>\n> But it has the advantage of making it easier to add more log-like\n> views, like 'log' like view for the 'history' view, i.e. --pretty=full\n> like view with path limiting.\n>\n> I have thought about doing the refactoring (it is/was on my long-term\n> TODO list for gitweb), but I haven't even found good way to code it,\n> to be flexible but not too generalized.  Callbacks, perhaps?\n\nActually, the only reason I mentioned it would take time was to\nexplain why _that_ patch wouldn't be resent 'shortly' by me. I need to\nstudy the log/shortlog/history code better to get an idea of what\nmight be a good refactoring strategy :)\n\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"}]}