Re: [PATCH] git-pickaxe: blame rewritten.

From: Junio C Hamano <junkio@cox.net>
Date: Oct 13, 2006, 00:06 UTC
Message-ID: <7vzmc1jcz0.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20061012193107.44651.qmail@web31805.mail.mud.yahoo.com>

Luben Tuikov <ltuikov@yahoo.com> writes:

> Renames are naturally supported?

Didn't I say you can see it yourself by doing this and that?

A short answer is yes. I'll do a re-write-up of algorithm overview and directions to enhance it in a separate message when I have time.

One interesting difference is that it can do partial file (line range). With the "parameter order" fix Linus asked, I can do:

$ git-pickaxe -L 551,554 master commit.c

which would run a lot faster than:

$ git-pickaxe -L 551,560 master commit.c

This is a made-up example, but you would get the idea. In short, it does not have to dig deeper outside the range originally you specified.

> ---cut---
> The porcelain format is as follows:
>
> <SHA-1> <orig line> <line> [<num lines>

This is misleading. <num lines> is always shown for the group head, even if there was another group earlier from the same commit (otherwise the Porcelain has to buffer the chunk, which you did not like). Second and subsequent lines in the same group do not have <num lines>.

Show 16 quoted lines

> author <name>
> author-mail <email format>
>...
> committer-tz <TZ>
> filename <string>
> summary <string>]
> <TAB><line data>
>
> Where
>   <SHA-1> is the SHA-1 of the commit which introduces this line.
>   <orig line> it the line number where this line is introduced.
>   <line> is the line number of the final file (at SHA-1 commit)
>
> Then, if <SHA-1> is different from the previous line's SHA-1 (if no
> previous then always different), a header follows.  It starts by the
> number of lines that this <SHA-1> commit introduces,...

So this description is wrong; <num lines> is not part of the "extra".

>...
> ---cut----
>
> This kind of makes it slightly clearer.

I deliberately left it vague so that we can add things later to the header. Porcelains should ignore the fields that they do not understand, and should not expect these fields listed above come in the order the above list shows.

Also I deliberately left it vague so that Porcelains can get the header for the same SHA-1 more than once. This is needed when we add "ciff" to pick more than one paths from the same commit. In such a case, most likely we are better off not to repeat header fields from author...committer-tz and summary but we would need filename. The expectation to the Porcelains is:

   Read one line, which begins with commit object name and two
   or three numbers; if it has three numbers, it is the
   beginning of a group.  Any such "object name" line can be
   followed by a header.  Read subsequent lines until you get a
   line that begins with a <TAB>.

   - do not get upset if you see a header field that you do not
     understand; you are reading from newer version of blame.

   - do not get upset if you see a header for the commit you
     have already seen.  Some of the header fields can be
     updated from the one you have seen the last time, so use
     the updated value from the new header.

   Lines that begin with a <TAB> is data from the file being
   annotated.  The object name and headers you saw before this
   line annotate it.

So Porcelains need to keep one set of these header fields per commit object.