Re: blame -L questions

[Junio C Hamano <gitster@pobox.com>]

Jay Soffian <jaysoffian@gmail.com> writes:

> My use case is emitting blocks that are wrapped in
>
> #if defined(WHATEVER)
> ....
> #endif
>
> I was going to use the syntax -L /start/../end/ for this.
>
> I naively thought I might just be able to setup multiple blame_entry's
> linked through the next/prev pointers at the start, but that clearly
> does not work.

The current -L parser is prepared to take only one range, but the
underlying data structure should be able to support what you want to do.

The scoreboard holds one final image (final_buf, final_buf_size) that is
the whole blob in the revision being annotated.  Without -L, we start with
one blame entry in ent that covers the whole lines in this image.  With a
single -L (i.e. the current implementation), this single ent covers a bit
narrower range of lines than the whole file.

    A blame_entry records a range of lines (lno, num_lines) and which path
    from what commit is the current suspect.  We iteratively compare this
    with parents of the suspect to see if we can pass blame for some lines
    in the given range to some parents.  When we can pass blame for the
    whole range, we just update the "suspect" to parent; when we can pass
    blame for some but not for other lines in the range, we break the
    blame_entry into pieces, pass blame to parents for lines that came
    from those parents and declare the current suspect for lines that did
    not appear in any of the parents.

    But this part does not concern you very much.  The only thing you need
    to know for what you want to do is how an ent must be initialized.

You should be able to start with more than one blame entry queued in ent
member of the scoreboard, each representing one range given by an -L
option, and as long as you prime these blame entries correctly, everything
should work just fine.  sb->ent is supposed to be sorted by line number
and not have overlap, but I don't think they have to be contiguous.