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

Re: [PATCH] Avoid errors from git-rev-parse in gitweb blame

From
Jakub Narebski <jnareb@gmail.com>
Date
Jun 8, 2008, 20:28 UTC
Message-ID
<200806082228.55495.jnareb@gmail.com>
In-Reply-To
<484C22BF.7040700@gmail.com>
On Sun, 8 Jun 2008, Lea Wiemann wrote:
Show 11 quoted lines
> On Wed, 04 Jun 2008, Lea Wiemann wrote:
>>
>> Blame first calculates the whole blame and then dumps it out in
>> zero-time [so] there's no performance difference in getting all  blame
>> output and then dumping it out vs. reading and outputting it line-by-line.
> 
> I haven't been following the recent discussion in detail, but here's 
> another thought: If you want to look up the parents, it's usually faster 
> (at least when caching is enabled) to get them all in a single call. 
> IOW, don't look up the parent for each hash as it appears, but collect 
> all hashes and then get a list of all parents with a single call.

If caching is enabled, then parent info can be retrieved from cache. If caching is disabled, or cache expired (cache miss) you would have to get whole blame output to get all revisions to get parents for. This means for a short while twice amount of memory (whole blame in git-blame, because thats how non-incremental blame works, and whole blame in gitweb, till reading last byte of blame when git-blame ends); and that is not good when memory-based cache (be it memcache, mmap, or other solution) is on the same machine (sometimes you just don't have a farm of servers...).

Junio's patches adding "previous" header to git blame result in no worse output (result) than current code. I have proposed improvements, but I'm not sure they can be implemented cheaply (fairly sure that they cannot, and I'm not sure if improvements are worth the cost). I'd like to know what happens in Junio code when evil merge is blamed; I don't know code enough (and I am a bit lazy here) to get this from code itself.

-- 
Jakub Narebski
Poland
Previous: Lea WiemannNext: Luben Tuikov
Message 36 of 40 in “Avoid errors from git-rev-parse in gitweb blame”
  1. Avoid errors from git-rev-parse in gitweb blameRafael Garcia-Suarez, Jun 3, 2008
  2. Lea WiemannJun 3, 2008
  3. Jakub NarebskiJun 3, 2008
  4. Rafael Garcia-SuarezJun 3, 2008
  5. Jakub NarebskiJun 3, 2008
  6. Rafael Garcia-SuarezJun 3, 2008
  7. Jakub NarebskiJun 3, 2008
  8. Rafael Garcia-SuarezJun 3, 2008
  9. Jakub NarebskiJun 3, 2008
  10. Rafael Garcia-SuarezJun 3, 2008
  11. Jakub NarebskiJun 3, 2008
  12. Rafael Garcia-SuarezJun 3, 2008
  13. Jakub NarebskiJun 3, 2008
  14. Luben TuikovJun 3, 2008
  15. Luben TuikovJun 3, 2008
  16. Luben TuikovJun 3, 2008
  17. Jakub NarebskiJun 3, 2008
  18. Junio C HamanoJun 4, 2008
  19. Jakub NarebskiJun 4, 2008
  20. Junio C HamanoJun 5, 2008
  21. 1/2 git-blame: refactor code to emit "porcelain format" outputJunio C Hamano, Jun 5, 2008
  22. Jakub NarebskiJun 6, 2008
  23. 2/2 blame: show "previous" information in --porcelain/--incremental formatJunio C Hamano, Jun 5, 2008
  24. Jakub NarebskiJun 6, 2008
  25. Junio C HamanoJun 6, 2008
  26. Jakub NarebskiJun 6, 2008
  27. Jakub NarebskiJun 6, 2008
  28. Luben TuikovJun 4, 2008
  29. Lea WiemannJun 3, 2008
  30. Jakub NarebskiJun 3, 2008
  31. Lea WiemannJun 3, 2008
  32. Jakub NarebskiJun 4, 2008
  33. Lea WiemannJun 4, 2008
  34. Jakub NarebskiJun 4, 2008
  35. Lea WiemannJun 8, 2008
  36. Jakub NarebskiJun 8, 2008
  37. Luben TuikovJun 3, 2008
  38. Jakub NarebskiJun 3, 2008
  39. Luben TuikovJun 3, 2008
  40. Jakub NarebskiJun 3, 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.