On 6/25/07, Nanako Shiraishi <nanako3@xxxxxxxxxxxxxx> wrote:
>> Marco Costalba <mcostalba@xxxxxxxxx> wrote: > > - filtering, ie selecting with the mouse some lines and getting a > subset of the file history that modified at least one of that lines is > not possible. I often use "git blame -L'/regexp/,/regexp/'" (you can use line numbers there, too). Is this different from what you talk above?
Yes it. Suppose you have selected file lines from 20 to 23 in revision A. Revision history it's the following, in cronological order: A (oldest) -> B - > C (newest) Say that in revision B the patch removed 5 lines from 5 to 10 and added 2 new lines instead. Now when you jump from A to revision C you may want to see selected the lines (-5 + 2 = -3) from 17 to 20 and no more the lines from 20 to 23 that will point to a different content. In a general case jumping from a revision A to a revision N you have to: - get the list of intermediate revision - for each revision calculate deleted/ added content that is before the selected lines range. - for each revision calculate deleted/ added content that CROSSES the selected range, so that if in our example revision B adds also 2 new lines in position 21 the selection in C will not be 17 to 20 but 17 to 22! The same logic in case of deleted lines in selected range. So to keep a "consistent" mouse selection when jumping to different file revisions you really need to know all the annotate history in between. Marco - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
