Re: More precise tag following
- From
Junio C Hamano <junkio@cox.net>
- Date
- Jan 28, 2007, 20:01 UTC
- Message-ID
- <7vhcuaex9k.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <Pine.LNX.4.64.0701281143190.25027@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 27 quoted lines
> But for the actual viewer parts, which don't need internal git knowledge,
> let's just document the blame format, so that others can do it:
>
> The new format is fairly easy to parse: each blame entry is always
>
> - starts with a line of
>
> <40-byte hex sha1> <sourceline> <resultline> <num_lines>
>
> - the first time that commit shows up in the stream, it has various
> other information about it printed out with a one-word tag at the
> beginning of each line about that "extended commit info" (author,
> email, committer, dates, summary etc)
>
> - each entry is _always_ finished by a
>
> "filename" <whitespace-quoted-filename-goes-here>
>
> and thus it's really quite easy to parse for some line- and word-oriented
> parser (which should be quite natural for most scripting languages).
>
> NOTE! For people who do parsing: to make it more robust, just ignore any
> lines in between the first and last one ("<sha1>" and "filename" lines)
> where you don't recognize the tag-words (or care about that particular
> one) at the beginning of the "extended information" lines. That way, if
> there is ever added information (like the commit encoding or extended
> commit commentary), a blame viewer won't ever care.Thanks for these notes, which I should have written. I would also caution them to ignore if there is anything they do not understand between "filename" and <sha1>.
A sample code to parse it in Perl was just posted by me ;-).