git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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 ;-).

Previous: Jakub NarebskiNext: Petr Baudis
Message 6 of 23 in “gitweb: use Git.pm, and use its parse_rev method for git_get_head_hash”
  1. gitweb: use Git.pm, and use its parse_rev method for git_get_head_hashLea Wiemann, May 30, 2008
  2. Lea WiemannMay 30, 2008
  3. Jakub NarebskiMay 31, 2008
  4. Lea WiemannMay 31, 2008
  5. Jakub NarebskiJun 1, 2008
  6. Junio C HamanoJun 2, 2008
  7. Petr BaudisJun 2, 2008
  8. Jakub NarebskiJun 2, 2008
  9. Lea WiemannJun 2, 2008
  10. Petr BaudisMay 31, 2008
  11. gitweb: use Git.pm, and use its parse_rev method for git_get_head_hashLea Wiemann, May 31, 2008
  12. Lea WiemannMay 31, 2008
  13. Junio C HamanoJun 1, 2008
  14. Lea WiemannJun 1, 2008
  15. Junio C HamanoJun 1, 2008
  16. test-lib.sh: set PERL5LIB instead of GITPERLLIBLea Wiemann, Jun 1, 2008
  17. Junio C HamanoJun 2, 2008
  18. Lea WiemannJun 2, 2008
  19. test-lib.sh: set PERL5LIB instead of GITPERLLIBLea Wiemann, Jun 2, 2008
  20. Junio C HamanoJun 2, 2008
  21. Lea WiemannJun 2, 2008
  22. Lea WiemannJun 3, 2008
  23. Lea WiemannJun 1, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.