Re: [PATCH] gitweb: use Git.pm, and use its parse_rev method for git_get_head_hash
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 2, 2008, 05:35 UTC
- Message-ID
- <7vbq2k9z65.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <200806020019.23858.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
Show 36 quoted lines
> On Sat, 31 May 2008, Lea Wiemann wrote: > ... >> So you end up with these layers: >> >> (Layer 0: Front-end [HTML] caching.) >> Layer 1: Application (Gitweb) >> Layer 2: Back-end caching >> Layer 3: Repository access (command parsing) >> Layer 4: Calls to the git binary >> >> Layer 3 and 4 are application-independent (i.e. not Gitweb specific), >> and since they form a usable API, they might as well be written as a >> separate API rather than lumped together with Gitweb. Git.pm is a start >> of such an API (it does layer 4 and a little bit of layer 3), so it >> seems natural for me to extend it. > > This assumes that command parsing used by gitweb are generic enough > to put them in Git.pm. But some IMVHO are very gitweb-specific, for > example the part in parse_commit_text() beginning with > # remove leading stuff of merges to make the interesting part visible > and the 'age_string*' keys there, parse_difftree_raw_line() which > currently does not support '-z' output, parse_from_to_diffinfo() which > is _very_ gitweb specific, git_get_heads_list() which is not generic > enough (it gets info which gitweb needs, but no more), etc. > >> Layer 2 is application-independent as well, so it can become an extra >> class in Git.pm or a separate module. (It should stay independent of >> layers 3 and 4). > > I think it would be better as separate module. Would it be Git::Cache > (or Git::Caching), Gitweb::Cache, or part of gitweb, that would have > to be decided. Besides, I'm not sure if it is really application- > -independent as you say: I think we would get better result if we > collate data first, which is application dependent. Also I think > there is no sense to cache everything: what to cache is again > application dependent.
Even though I (for some unknown reason) rarely agree with Jakub on this list, I agree 100% with the above paragraph. In fact I yesterday started to write exactly the same thing but I could not word it well enough, and I am glad Jakub said what I wanted to say in a form that is much clearer than I would have ;-).