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

Re: [PATCH] Add git-annotate - a tool for annotating files with the revision and person that created each line in the file.

From
Junio C Hamano <junkio@cox.net>
Date
Feb 8, 2006, 21:45 UTC
Message-ID
<7vlkwlo788.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<20060208210756.GA9490@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
Show 5 quoted lines
>> It's been a while since I looked at it the last time so it may
>> not even work with the current git, but here it is..
>
> I'll take a look through this in greater detail later, hopefully your
> approach can be applied.  Diff-analyzing is apparently tricky.

Reading diff is tricky but I was lazy to match up the lines by hand, which is also a real work ;-).

There are a few things I should add to that ancient code:
 - It wants old ls-tree behaviour.  The command line used in the
   "sub find_file" needs to be updated to something like this:
    open $fh, '-|', 'git-ls-tree', '-z', '-r', $commit->{TREE}, $path
	or die "cannot read git-ls-tree $commit->{TREE}";
 - It only cares about the line numbers and its output is meant
   to be postprocessed with the contents from the latest blob.
 - It predates the recent rev-list that skips commits that do
   not change the specified paths, and it literally follows each
   parent and optimizes not to diff with uninteresting parents
   by hand.

I suspect if you go with the diff-reading approach, it might be easy to convert it to C (or even write the initial version in C) using the machinery similar to what is in combine-diff.c.

The algorithm combine-diff.c uses keeps the lines discarded from each parent in lline structure linked to the sline structure (which keeps track of the lines in the final version), but for your annotate purposes what you care about is only what the child adds to the parent (IOW, we do not care about the lines that do not appear in the final version), so the logic and the data structure could be greatly simplified. You only need to keep "flag" element in the sline structure, and maybe bol and len that point at the contents of the resulting line from the final version. In addition, you would need to store "the current suspect commit" (starts from the final revision and updated as you pass the blame along) and another bool that says if "the current suspect" is known to be the guilty party or if the true culprit is one of its ancestors (capital vs lowercase difference in that explanatory note).

Previous: Ryan AndersonNext: Ryan Anderson
Message 18 of 19 in “Add git-annotate - a tool for annotating files with the revision and person that created each line in the file.”
  1. Add git-annotate - a tool for annotating files with the revision and person that created each line in the file.Ryan Anderson, Feb 8, 2006
  2. Peter EriksenFeb 8, 2006
  3. Johannes SchindelinFeb 8, 2006
  4. Franck Bui-HuuFeb 8, 2006
  5. Johannes SchindelinFeb 8, 2006
  6. Junio C HamanoFeb 8, 2006
  7. Ralf BaechleFeb 10, 2006
  8. Andreas EricssonFeb 10, 2006
  9. Fredrik KuivinenFeb 14, 2006
  10. Randal L. SchwartzFeb 8, 2006
  11. Andreas EricssonFeb 9, 2006
  12. Junio C HamanoFeb 9, 2006
  13. Franck Bui-HuuFeb 9, 2006
  14. Andreas EricssonFeb 9, 2006
  15. Linus TorvaldsFeb 8, 2006
  16. Junio C HamanoFeb 8, 2006
  17. Ryan AndersonFeb 8, 2006
  18. Junio C HamanoFeb 8, 2006
  19. Ryan AndersonFeb 10, 2006

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.