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
Jakub Narebski <jnareb@gmail.com>
Date
May 31, 2008, 09:40 UTC
Message-ID
<m3lk1q24nb.fsf@localhost.localdomain>
In-Reply-To
<484087A7.2030107@gmail.com>
Lea Wiemann <lewiemann@gmail.com> writes:
Show 6 quoted lines
> Lea Wiemann wrote:
> > Subject: [PATCH] gitweb: use Git.pm, and use its parse_rev method
> >          for git_get_head_hash
> 
> For clarification, this is my first patch for refactoring Gitweb to
> use Git.pm's API.
Good.

I'm not sure however how much of gitweb engine should be moved to Git.pm. I think calling git commands could be moved from git_cmd() to command_output_pipe() or command_oneline(), replacing global variable $git_dir by global variable $repo. Perhaps gitweb's config file parsing should be added as an option to Git.pm. But I'm not sure for example about parsing subroutines.

> In the end, I'm hoping that all (or at least most) of Gitweb's
> accesses to the repositories will go through this API, which allows us
> to add caching to the Git.pm API (rather than Gitweb) pretty easily
> and cleanly.

IMVHO caching command output is bad idea. I'd rather have gitweb cache _parsed_ data (i.e. Perl structures).

For example projects list (but also summary page for a project) is composed as result of parsing output of _many_ git commands, in the case of projects list coming from many different repositories. Caching git command output (something like IPC::Cmd::Cached?) would only repeat bad I/O patterns of git commands.

Also I don't think it is a good idea to pollute Git.pm by caching command output. Perhaps in Git::Cached, but as a last resort...

P.S. Here it is what could go to Git.pm:
 * Eager config parsing, using e.g. $repo->parse_config() to prepare
   %config hash, and have $repo->config(VAR) etc. use %config hash.
   This means one git command and not one git command per variable,
   but it also means that we have to convert to bool or int, or color
   in Perl.
 * unquote() (which is not repository instance merhod, but utility
   subroutine) to unquote and unescape filenames.
 * generating rfc2822 and iso-8601 dates from timestamp plus timezone,
   i.e. from author/committer/tagger date; it would be useful for
   example in git-send-email.

I'm not sure about parse_* subroutines (some of which are not generic enough, I guess).

-- 
Jakub Narebski
Poland
ShadeHawk on #git
Previous: Lea WiemannNext: Lea Wiemann
Message 3 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.