{"thread":{"id":"22576","subject":"blame -L questions","startedAt":"2010-02-09T03:03:37Z","lastAt":"2010-02-09T03:32:50Z","messageCount":2,"participants":["Jay Soffian","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"133984","messageId":"76718491002081903s2e37875bs85eeb55779167ce7@mail.gmail.com","threadId":"22576","inReplyTo":null,"subject":"blame -L questions","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-02-09T03:03:37Z","receivedAt":"2010-02-09T03:03:37Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"Junio,\n\nI'd like git blame to be able to emit multiple blocks when using it\nwith -L /start/,/end/.\n\nMy use case is emitting blocks that are wrapped in\n\n#if defined(WHATEVER)\n....\n#endif\n\nI was going to use the syntax -L /start/../end/ for this.\n\nI naively thought I might just be able to setup multiple blame_entry's\nlinked through the next/prev pointers at the start, but that clearly\ndoes not work.\n\nSo I was wondering if you could give me any tips about how the\nscoreboard, blame_entry, and origin all fit together before I injure\nmyself. :-)\n\nThanks,\n\nj.\n"},{"id":"133985","messageId":"7vtytrulr1.fsf@alter.siamese.dyndns.org","threadId":"22576","inReplyTo":"76718491002081903s2e37875bs85eeb55779167ce7@mail.gmail.com","subject":"Re: blame -L questions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-09T03:32:50Z","receivedAt":"2010-02-09T03:32:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian <jaysoffian@gmail.com> writes:\n\n> My use case is emitting blocks that are wrapped in\n>\n> #if defined(WHATEVER)\n> ....\n> #endif\n>\n> I was going to use the syntax -L /start/../end/ for this.\n>\n> I naively thought I might just be able to setup multiple blame_entry's\n> linked through the next/prev pointers at the start, but that clearly\n> does not work.\n\nThe current -L parser is prepared to take only one range, but the\nunderlying data structure should be able to support what you want to do.\n\nThe scoreboard holds one final image (final_buf, final_buf_size) that is\nthe whole blob in the revision being annotated.  Without -L, we start with\none blame entry in ent that covers the whole lines in this image.  With a\nsingle -L (i.e. the current implementation), this single ent covers a bit\nnarrower range of lines than the whole file.\n\n    A blame_entry records a range of lines (lno, num_lines) and which path\n    from what commit is the current suspect.  We iteratively compare this\n    with parents of the suspect to see if we can pass blame for some lines\n    in the given range to some parents.  When we can pass blame for the\n    whole range, we just update the \"suspect\" to parent; when we can pass\n    blame for some but not for other lines in the range, we break the\n    blame_entry into pieces, pass blame to parents for lines that came\n    from those parents and declare the current suspect for lines that did\n    not appear in any of the parents.\n\n    But this part does not concern you very much.  The only thing you need\n    to know for what you want to do is how an ent must be initialized.\n\nYou should be able to start with more than one blame entry queued in ent\nmember of the scoreboard, each representing one range given by an -L\noption, and as long as you prime these blame entries correctly, everything\nshould work just fine.  sb->ent is supposed to be sorted by line number\nand not have overlap, but I don't think they have to be contiguous.\n"}]}