{"thread":{"id":"34368","subject":"[PATCH/RFC] blame: accept multiple -L ranges","startedAt":"2013-07-07T08:45:06Z","lastAt":"2013-07-22T21:34:34Z","messageCount":22,"participants":["Eric Sunshine","Junio C Hamano","Thomas Rast","Jonathan Nieder","Michael Haggerty"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"222726","messageId":"1373186706-19284-1-git-send-email-sunshine@sunshineco.com","threadId":"34368","inReplyTo":null,"subject":"[PATCH/RFC] blame: accept multiple -L ranges","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-07-07T08:45:06Z","receivedAt":"2013-07-07T08:45:06Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"git-blame accepts only zero or one -L option. Clients requiring blame\ninformation for multiple disjoint ranges are therefore forced either to\ninvoke git-blame multiple times, once for each range, or only once with\nno -L option to cover the entire file, which can be costly. Teach\ngit-blame to accept multiple -L ranges.\n\nOverlapping and out-of-order ranges are accepted and handled gracefully.\nFor example:\n\n git blame -L 3,+4 -L 91,+7 -L 2,3 -L 89,100 source.c\n\nemits blame information for lines 2-6 and 89-100.\n\nSigned-off-by: Eric Sunshine \n---\n\nThis is RFC because it lacks documentation and test updates, and because\nI want to make sure the approach is sound and not abusive of the blame\nmachinery.\n\nRather than sorting and coalescing input -L ranges manually, existing\nadd_blame_range() and coalesce() are (ab)used to normalize the input.\nThis requires a small change to coalesce() to deal with potentially\noverlapping ranges since it never otherwise encounters overlap during\nnormal blame operation.\n\nThis patch is somewhat less scary when whitespace changes are ignored.\n\n\n builtin/blame.c | 70 +++++++++++++++++++++++++++++----------------------------\n 1 file changed, 36 insertions(+), 34 deletions(-)\n\ndiff --git a/builtin/blame.c b/builtin/blame.c\nindex 079dcd3..f26ff44 100644\n--- a/builtin/blame.c\n+++ b/builtin/blame.c\n@@ -278,8 +278,11 @@ static void coalesce(struct scoreboard *sb)\n \tfor (ent = sb->ent; ent && (next = ent->next); ent = next) {\n \t\tif (same_suspect(ent->suspect, next->suspect) &&\n \t\t ent->guilty == next->guilty &&\n-\t\t ent->s_lno + ent->num_lines == next->s_lno) {\n-\t\t\tent->num_lines += next->num_lines;\n+\t\t ent->s_lno + ent->num_lines >= next->s_lno) {\n+\t\t\tint ent_top = ent->lno + ent->num_lines;\n+\t\t\tint next_top = next->lno + next->num_lines;\n+\t\t\tif (ent_top < next_top)\n+\t\t\t\tent->num_lines = next_top - ent->s_lno;\n \t\t\tent->next = next->next;\n \t\t\tif (ent->next)\n \t\t\t\tent->next->prev = ent;\n@@ -2245,17 +2248,6 @@ static int blame_move_callback(const struct option *option, const char *arg, int\n \treturn 0;\n }\n \n-static int blame_bottomtop_callback(const struct option *option, const char *arg, int unset)\n-{\n-\tconst char **bottomtop = option->value;\n-\tif (!arg)\n-\t\treturn -1;\n-\tif (*bottomtop)\n-\t\tdie(\"More than one '-L n,m' option given\");\n-\t*bottomtop = arg;\n-\treturn 0;\n-}\n-\n int cmd_blame(int argc, const char **argv, const char *prefix)\n {\n \tstruct rev_info revs;\n@@ -2263,11 +2255,11 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n \tstruct scoreboard sb;\n \tstruct origin *o;\n \tstruct blame_entry *ent;\n-\tlong dashdash_pos, bottom, top, lno;\n+\tlong dashdash_pos, lno;\n \tconst char *final_commit_name = NULL;\n \tenum object_type type;\n \n-\tstatic const char *bottomtop = NULL;\n+\tstatic struct string_list ranges;\n \tstatic int output_option = 0, opt = 0;\n \tstatic int show_stats = 0;\n \tstatic const char *revs_file = NULL;\n@@ -2293,13 +2285,14 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n \t\tOPT_STRING(0, \"contents\", &contents_from, N_(\"file\"), N_(\"Use 's contents as the final image\")),\n \t\t{ OPTION_CALLBACK, 'C', NULL, &opt, N_(\"score\"), N_(\"Find line copies within and across files\"), PARSE_OPT_OPTARG, blame_copy_callback },\n \t\t{ OPTION_CALLBACK, 'M', NULL, &opt, N_(\"score\"), N_(\"Find line movements within and across files\"), PARSE_OPT_OPTARG, blame_move_callback },\n-\t\tOPT_CALLBACK('L', NULL, &bottomtop, N_(\"n,m\"), N_(\"Process only line range n,m, counting from 1\"), blame_bottomtop_callback),\n+\t\tOPT_STRING_LIST('L', NULL, &ranges, N_(\"n,m\"), N_(\"Process only line range n,m, counting from 1\")),\n \t\tOPT__ABBREV(&abbrev),\n \t\tOPT_END()\n \t};\n \n \tstruct parse_opt_ctx_t ctx;\n \tint cmd_is_annotate = !strcmp(argv[0], \"annotate\");\n+\tunsigned int range_i;\n \n \tgit_config(git_blame_config, NULL);\n \tinit_revisions(&revs, NULL);\n@@ -2492,24 +2485,33 @@ parse_done:\n \tnum_read_blob++;\n \tlno = prepare_lines(&sb);\n \n-\tbottom = top = 0;\n-\tif (bottomtop)\n-\t\tprepare_blame_range(&sb, bottomtop, lno, &bottom, &top);\n-\tif (bottom < 1)\n-\t\tbottom = 1;\n-\tif (top < 1)\n-\t\ttop = lno;\n-\tbottom--;\n-\tif (lno < top || lno < bottom)\n-\t\tdie(\"file %s has only %lu lines\", path, lno);\n-\n-\tent = xcalloc(1, sizeof(*ent));\n-\tent->lno = bottom;\n-\tent->num_lines = top - bottom;\n-\tent->suspect = o;\n-\tent->s_lno = bottom;\n-\n-\tsb.ent = ent;\n+\tif (!ranges.nr)\n+\t\tstring_list_append(&ranges, xstrdup(\"0,0\"));\n+\n+\tfor (range_i = 0; range_i < ranges.nr; ++range_i) {\n+\t\tlong bottom, top;\n+\t\tprepare_blame_range(&sb, ranges.items[range_i].string,\n+\t\t\t\t lno, &bottom, &top);\n+\t\tif (bottom < 1)\n+\t\t\tbottom = 1;\n+\t\tif (top < 1)\n+\t\t\ttop = lno;\n+\t\tbottom--;\n+\t\tif (lno < top || lno < bottom)\n+\t\t\tdie(\"file %s has only %lu lines\", path, lno);\n+\n+\t\tent = xcalloc(1, sizeof(*ent));\n+\t\tent->lno = bottom;\n+\t\tent->num_lines = top - bottom;\n+\t\tent->suspect = o;\n+\t\tent->s_lno = bottom;\n+\t\tadd_blame_entry(&sb, ent);\n+\t}\n+\tcoalesce(&sb);\n+\n+\torigin_decref(o);\n+\tstring_list_clear(&ranges, 0);\n+\n \tsb.path = path;\n \n \tread_mailmap(&mailmap, NULL);\n-- \n1.8.3.2\n"},{"id":"222731","messageId":"7vk3l26695.fsf@alter.siamese.dyndns.org","threadId":"34368","inReplyTo":"1373186706-19284-1-git-send-email-sunshine@sunshineco.com","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-07T09:58:46Z","receivedAt":"2013-07-07T09:58:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> git-blame accepts only zero or one -L option. Clients requiring blame\n> information for multiple disjoint ranges are therefore forced either to\n> invoke git-blame multiple times, once for each range, or only once with\n> no -L option to cover the entire file, which can be costly. Teach\n> git-blame to accept multiple -L ranges.\n>\n> Overlapping and out-of-order ranges are accepted and handled gracefully.\n> For example:\n>\n> git blame -L 3,+4 -L 91,+7 -L 2,3 -L 89,100 source.c\n>\n> emits blame information for lines 2-6 and 89-100.\n>\n> Signed-off-by: Eric Sunshine \n> ---\n>\n> This is RFC because it lacks documentation and test updates, and because\n> I want to make sure the approach is sound and not abusive of the blame\n> machinery.\n\nThanks. Procrastination (and being down sick) pays off.\n\nA few commments (without reading too deep in the patch, so do not\ntake any of these as complaint---if you did it the way I said \"I'd\nprefer\", take it as a praise ;-).\n\n - The general concept to start from not just one but multiple blame\n entries that share the same source (and initial suspect) is the\n right way to implement multiple ranges.\n\n - I'd prefer to see the command parser for multiple -L options to\n ensure that they are in strictly increasing order without\n overlap. Error out with a message if the input ranges are out of\n order or with overlap. Doing it that way, it would be easier to\n explain to the users how \"blame -L /A/,/B/ -L /C/,/D/\" should\n work. It would find the first line that matches C _after_ the\n end of the first range. This is in line with the way we find the\n end of the range (e.g. the line that matches B) starting from the\n last line previously specified (e.g. the line that matches A).\n\n - I'd be somewhat unhappy to see coalesce() butchered to blindly\n accept overlapping ranges (if anything, I'd rather see it\n tightened to detect such input as a programming error), but this\n is a minor point.\n"},{"id":"222928","messageId":"CAPig+cQ9sfV+PRqn5vrL0=xOZrKDDmsKdAPiB4PsCFb=jnk4kQ@mail.gmail.com","threadId":"34368","inReplyTo":"7vk3l26695.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-07-09T15:04:55Z","receivedAt":"2013-07-09T15:04:55Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"[Added Cc:Thomas Rast]\n\nOn Sun, Jul 7, 2013 at 5:58 AM, Junio C Hamano wrote:\n> Eric Sunshine writes:\n>\n>> git-blame accepts only zero or one -L option. Clients requiring blame\n>> information for multiple disjoint ranges are therefore forced either to\n>> invoke git-blame multiple times, once for each range, or only once with\n>> no -L option to cover the entire file, which can be costly. Teach\n>> git-blame to accept multiple -L ranges.\n>>\n>> Overlapping and out-of-order ranges are accepted and handled gracefully.\n>> For example:\n>>\n>> git blame -L 3,+4 -L 91,+7 -L 2,3 -L 89,100 source.c\n>>\n>> emits blame information for lines 2-6 and 89-100.\n>> ---\n>>\n>> This is RFC because it lacks documentation and test updates, and because\n>> I want to make sure the approach is sound and not abusive of the blame\n>> machinery.\n>\n> A few commments (without reading too deep in the patch, so do not\n> take any of these as complaint---if you did it the way I said \"I'd\n> prefer\", take it as a praise ;-).\n>\n> - I'd prefer to see the command parser for multiple -L options to\n> ensure that they are in strictly increasing order without\n> overlap. Error out with a message if the input ranges are out of\n> order or with overlap. Doing it that way, it would be easier to\n> explain to the users how \"blame -L /A/,/B/ -L /C/,/D/\" should\n> work. It would find the first line that matches C _after_ the\n> end of the first range. This is in line with the way we find the\n> end of the range (e.g. the line that matches B) starting from the\n> last line previously specified (e.g. the line that matches A).\n\nAs implemented by this patch, the behavior of git-blame with multiple\n-L's is consistent with that of git-log with multiple -L's. The\nimplemented behavior feels intuitive to me, but I can see how the\nbehavior you suggest could feel intuitive to others.\n\nIf I re-do the patch to work the way you describe above, how should we\ndeal with the inconsistent behaviors between the two commands?\n\n> - I'd be somewhat unhappy to see coalesce() butchered to blindly\n> accept overlapping ranges (if anything, I'd rather see it\n> tightened to detect such input as a programming error), but this\n> is a minor point.\n\nLoosening the behavior bothered enough that I mentioned it centrally\nin the patch commentary. I can re-implement without (ab)using\ncoalesce().\n\n(In fact, I already have an implementation which re-uses the machinery\nemployed by git-log -L.)\n\n-- ES\n"},{"id":"222935","messageId":"7v38rnwuvb.fsf@alter.siamese.dyndns.org","threadId":"34368","inReplyTo":"CAPig+cQ9sfV+PRqn5vrL0=xOZrKDDmsKdAPiB4PsCFb=jnk4kQ@mail.gmail.com","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-09T16:39:20Z","receivedAt":"2013-07-09T16:39:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> As implemented by this patch, the behavior of git-blame with multiple\n> -L's is consistent with that of git-log with multiple -L's. The\n> implemented behavior feels intuitive to me, but I can see how the\n> behavior you suggest could feel intuitive to others.\n>\n> If I re-do the patch to work the way you describe above, how should we\n> deal with the inconsistent behaviors between the two commands?\n\nTo be extremely honest, I do not care too deeply about what log -L\ndoes today, because it is still in \"may have rough edges but is an\ninteresting toy to play with\" state in my mind ;-)\n\nThe suggestion to error out was more about \"start simple, strict and\nobvious to make it easy to explain\" and nothing else. If we start\nwith a simple and strict version, we can later loosen it without\nmaking an input that was valid earlier invalid. If we start with\ntoo loose, on the other hand, it would be hard to tighten it later.\n\nBut the only two things I care deeply about are, in a file whose\ncontents is:\n\n\tC\n B\n A\n B\n C\n D\n\n (1) The range \"-L /A/,/B/\" finds the first A from the beginning,\n and then chooses B that comes _after_ it, making it equivalent\n to -L3,4 (not -L3,2 or -L2,3).\n\n (2) In the ranges \"-L ,/B/ -L /C/,\", the\n beginning of the second range is found by choosing C that comes\n _after_ the end of the previous range (/B/ may choose either\n the second or the 4th line, and the only C that comes after\n either of them is the 5th line and that is where the second\n range should begin, not at the beginning of the file). The\n same for \"-L 1,3 -L /C/\" (only C that comes after 3 is eligible\n to be the beginning of the second range).\n\nI view it as a nice addition to coalesce two overlapping ranges\ngiven exactly by numbers, e.g. \"-L 100,200 -L 50,102\". I do not\nhave a strong objection to it, as long as it does not interfere\nnegatively with ranges specified by patterns.\n\nThanks.\n"},{"id":"222939","messageId":"CAPig+cSxiSWwZ6QANWtTt7ioAewD0tk62V=pkdiT9JLw3Fzb9g@mail.gmail.com","threadId":"34368","inReplyTo":"7v38rnwuvb.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-07-09T17:17:18Z","receivedAt":"2013-07-09T17:17:18Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Jul 9, 2013 at 12:39 PM, Junio C Hamano wrote:\n> Eric Sunshine writes:\n>\n>> As implemented by this patch, the behavior of git-blame with multiple\n>> -L's is consistent with that of git-log with multiple -L's. The\n>> implemented behavior feels intuitive to me, but I can see how the\n>> behavior you suggest could feel intuitive to others.\n>>\n>> If I re-do the patch to work the way you describe above, how should we\n>> deal with the inconsistent behaviors between the two commands?\n>\n> The suggestion to error out was more about \"start simple, strict and\n> obvious to make it easy to explain\" and nothing else. If we start\n> with a simple and strict version, we can later loosen it without\n> making an input that was valid earlier invalid. If we start with\n> too loose, on the other hand, it would be hard to tighten it later.\n\nMakes sense.\n\n> But the only two things I care deeply about are, in a file whose\n> contents is:\n>\n> C\n> B\n> A\n> B\n> C\n> D\n>\n> (1) The range \"-L /A/,/B/\" finds the first A from the beginning,\n> and then chooses B that comes _after_ it, making it equivalent\n> to -L3,4 (not -L3,2 or -L2,3).\n>\n> (2) In the ranges \"-L ,/B/ -L /C/,\", the\n> beginning of the second range is found by choosing C that comes\n> _after_ the end of the previous range (/B/ may choose either\n> the second or the 4th line, and the only C that comes after\n> either of them is the 5th line and that is where the second\n> range should begin, not at the beginning of the file). The\n> same for \"-L 1,3 -L /C/\" (only C that comes after 3 is eligible\n> to be the beginning of the second range).\n\nThinking aloud: Thus, for \"-L 1,5 -L /C/\", no C would be found.\n\n> I view it as a nice addition to coalesce two overlapping ranges\n> given exactly by numbers, e.g. \"-L 100,200 -L 50,102\". I do not\n> have a strong objection to it, as long as it does not interfere\n> negatively with ranges specified by patterns.\n\nOkay, I will base my rewrite upon the above constraints, along with\nother observations from your initial response.\n\n-- ES\n"},{"id":"222942","messageId":"87ehb7d3za.fsf@hexa.v.cablecom.net","threadId":"34368","inReplyTo":"7v38rnwuvb.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-07-09T17:42:49Z","receivedAt":"2013-07-09T17:42:49Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano writes:\n\n> (2) In the ranges \"-L ,/B/ -L /C/,\", the\n> beginning of the second range is found by choosing C that comes\n> _after_ the end of the previous range (/B/ may choose either\n> the second or the 4th line, and the only C that comes after\n> either of them is the 5th line and that is where the second\n> range should begin, not at the beginning of the file). The\n> same for \"-L 1,3 -L /C/\" (only C that comes after 3 is eligible\n> to be the beginning of the second range).\n\nSo passing several -L arguments does not blame the union of what each\nargument would blame individually? Doesn't that make it rather harder\nto explain?\n\nIn any case, if you define it like that for blame, log -L should be\nchanged to match.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"222943","messageId":"CAPig+cT9U7L-03Fe5YLft=WS2EZY1B_BhLzkM_sT_3wQQ1g1MQ@mail.gmail.com","threadId":"34368","inReplyTo":"87ehb7d3za.fsf@hexa.v.cablecom.net","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-07-09T18:23:55Z","receivedAt":"2013-07-09T18:23:55Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast wrote:\n> Junio C Hamano writes:\n>\n>> (2) In the ranges \"-L ,/B/ -L /C/,\", the\n>> beginning of the second range is found by choosing C that comes\n>> _after_ the end of the previous range (/B/ may choose either\n>> the second or the 4th line, and the only C that comes after\n>> either of them is the 5th line and that is where the second\n>> range should begin, not at the beginning of the file). The\n>> same for \"-L 1,3 -L /C/\" (only C that comes after 3 is eligible\n>> to be the beginning of the second range).\n>\n> So passing several -L arguments does not blame the union of what each\n> argument would blame individually? Doesn't that make it rather harder\n> to explain?\n\nI don't think Junio meant to imply that. Collecting the blame ranges\ncan/should be a distinct step from coalescing them. Junio is saying\nthat an -L /re/ range search should start after the maximum line\nnumber already specified by any preceding range. Once all input ranges\nare collected, they can be coalesced. (If a -L /re/ range happens to\nbe coalesced with or into some other range, that's fine: you're still\nseeing blame output for the requested lines.)\n\n-- ES\n"},{"id":"222947","messageId":"7vy59fv9zr.fsf@alter.siamese.dyndns.org","threadId":"34368","inReplyTo":"CAPig+cT9U7L-03Fe5YLft=WS2EZY1B_BhLzkM_sT_3wQQ1g1MQ@mail.gmail.com","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-09T18:55:36Z","receivedAt":"2013-07-09T18:55:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast wrote:\n>> Junio C Hamano writes:\n>>\n>>> (2) In the ranges \"-L ,/B/ -L /C/,\", the\n>>> beginning of the second range is found by choosing C that comes\n>>> _after_ the end of the previous range (/B/ may choose either\n>>> the second or the 4th line, and the only C that comes after\n>>> either of them is the 5th line and that is where the second\n>>> range should begin, not at the beginning of the file). The\n>>> same for \"-L 1,3 -L /C/\" (only C that comes after 3 is eligible\n>>> to be the beginning of the second range).\n>>\n>> So passing several -L arguments does not blame the union of what each\n>> argument would blame individually? Doesn't that make it rather harder\n>> to explain?\n>\n> I don't think Junio meant to imply that. Collecting the blame ranges\n> can/should be a distinct step from coalescing them. Junio is saying\n> that an -L /re/ range search should start after the maximum line\n> number already specified by any preceding range.\n\nI am not sure if I want \"maximum specified so far\". I meant \"start\nsearching at the last location\", e.g.\n\n\t-L 100,200 -L 4,6 -L /A/,+20\n\nwould want to find the first A after line 6, not after line 200.\n\n> Once all input ranges\n> are collected, they can be coalesced. (If a -L /re/ range happens to\n> be coalesced with or into some other range, that's fine: you're still\n> seeing blame output for the requested lines.)\n\nYes.\n"},{"id":"222948","messageId":"7vtxk3v9vs.fsf@alter.siamese.dyndns.org","threadId":"34368","inReplyTo":"87ehb7d3za.fsf@hexa.v.cablecom.net","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-09T18:57:59Z","receivedAt":"2013-07-09T18:57:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> Junio C Hamano writes:\n>\n>> (2) In the ranges \"-L ,/B/ -L /C/,\", the\n>> beginning of the second range is found by choosing C that comes\n>> _after_ the end of the previous range (/B/ may choose either\n>> the second or the 4th line, and the only C that comes after\n>> either of them is the 5th line and that is where the second\n>> range should begin, not at the beginning of the file). The\n>> same for \"-L 1,3 -L /C/\" (only C that comes after 3 is eligible\n>> to be the beginning of the second range).\n>\n> So passing several -L arguments does not blame the union of what each\n> argument would blame individually? Doesn't that make it rather harder\n> to explain?\n>\n> In any case, if you define it like that for blame, log -L should be\n> changed to match.\n\nI thought \"log -L\" was fundamnetally different as it is per path.\nFor example, -L1,100:hello.c and -L5,105:goodbye.c would not\nintersect/overlap.\n\nIf you mean to coalesce -L1,100:hello.c and -L5,105:hello.c into a\nsingle -L1,105:hello.c, then yes I think it makes sense.\n"},{"id":"222949","messageId":"CAPig+cTjNqopExzBGy7hwf+E=1BQNEZvk+JmoqUmRK=ZyBXH1w@mail.gmail.com","threadId":"34368","inReplyTo":"7vy59fv9zr.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-07-09T19:07:00Z","receivedAt":"2013-07-09T19:07:00Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Jul 9, 2013 at 2:55 PM, Junio C Hamano wrote:\n> Eric Sunshine writes:\n>\n>> On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast wrote:\n>>> Junio C Hamano writes:\n>>>\n>>>> (2) In the ranges \"-L ,/B/ -L /C/,\", the\n>>>> beginning of the second range is found by choosing C that comes\n>>>> _after_ the end of the previous range (/B/ may choose either\n>>>> the second or the 4th line, and the only C that comes after\n>>>> either of them is the 5th line and that is where the second\n>>>> range should begin, not at the beginning of the file). The\n>>>> same for \"-L 1,3 -L /C/\" (only C that comes after 3 is eligible\n>>>> to be the beginning of the second range).\n>>>\n>>> So passing several -L arguments does not blame the union of what each\n>>> argument would blame individually? Doesn't that make it rather harder\n>>> to explain?\n>>\n>> I don't think Junio meant to imply that. Collecting the blame ranges\n>> can/should be a distinct step from coalescing them. Junio is saying\n>> that an -L /re/ range search should start after the maximum line\n>> number already specified by any preceding range.\n>\n> I am not sure if I want \"maximum specified so far\". I meant \"start\n> searching at the last location\", e.g.\n>\n> -L 100,200 -L 4,6 -L /A/,+20\n>\n> would want to find the first A after line 6, not after line 200.\n\nOkay.\n\n>\n>> Once all input ranges\n>> are collected, they can be coalesced. (If a -L /re/ range happens to\n>> be coalesced with or into some other range, that's fine: you're still\n>> seeing blame output for the requested lines.)\n>\n> Yes.\n"},{"id":"222950","messageId":"87a9lvcztv.fsf@hexa.v.cablecom.net","threadId":"34368","inReplyTo":"7vy59fv9zr.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-07-09T19:12:28Z","receivedAt":"2013-07-09T19:12:28Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano writes:\n\n> Eric Sunshine writes:\n>\n>> On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast wrote:\n>>> Junio C Hamano writes:\n>>>\n>>>> (2) In the ranges \"-L ,/B/ -L /C/,\", the\n>>>> beginning of the second range is found by choosing C that comes\n>>>> _after_ the end of the previous range (/B/ may choose either\n>>>> the second or the 4th line, and the only C that comes after\n>>>> either of them is the 5th line and that is where the second\n>>>> range should begin, not at the beginning of the file). The\n>>>> same for \"-L 1,3 -L /C/\" (only C that comes after 3 is eligible\n>>>> to be the beginning of the second range).\n>>>\n>>> So passing several -L arguments does not blame the union of what each\n>>> argument would blame individually? Doesn't that make it rather harder\n>>> to explain?\n>>\n>> I don't think Junio meant to imply that. Collecting the blame ranges\n>> can/should be a distinct step from coalescing them. Junio is saying\n>> that an -L /re/ range search should start after the maximum line\n>> number already specified by any preceding range.\n>\n> I am not sure if I want \"maximum specified so far\". I meant \"start\n> searching at the last location\", e.g.\n>\n> \t-L 100,200 -L 4,6 -L /A/,+20\n>\n> would want to find the first A after line 6, not after line 200.\n\nOk, so my point (in new words, since the old one was apparently too\nterse) is:\n\nIf you define it that way, the output of\n\n git blame -L 4,6; git blame -L /A/,+20\n\nis significantly different from\n\n git blame -L 4,6 -L /A/,+20\n\nNot just in the presentation or any possible coalescing, but in the\nmeaning of the ranges.\n\nDo you really want to make it that way?\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"222951","messageId":"20130709192119.GY408@google.com","threadId":"34368","inReplyTo":"87a9lvcztv.fsf@hexa.v.cablecom.net","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-07-09T19:21:19Z","receivedAt":"2013-07-09T19:21:19Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Thomas Rast wrote:\n\n> If you define it that way, the output of\n>\n> git blame -L 4,6; git blame -L /A/,+20\n>\n> is significantly different from\n>\n> git blame -L 4,6 -L /A/,+20\n>\n> Not just in the presentation or any possible coalescing, but in the\n> meaning of the ranges.\n\nI can see both meanings being useful. I suspect that the \"restart at\nthe top of the file for each LHS regex\" meaning would be more useful,\nthough.\n\nThanks,\nJonathan\n"},{"id":"222953","messageId":"7vppurv8bl.fsf@alter.siamese.dyndns.org","threadId":"34368","inReplyTo":"87a9lvcztv.fsf@hexa.v.cablecom.net","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-09T19:31:42Z","receivedAt":"2013-07-09T19:31:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> If you define it that way, the output of\n>\n> git blame -L 4,6; git blame -L /A/,+20\n>\n> is significantly different from\n>\n> git blame -L 4,6 -L /A/,+20\n>\n> Not just in the presentation or any possible coalescing, but in the\n> meaning of the ranges.\n>\n> Do you really want to make it that way?\n\nAbsolutely. The primary reason I want to be able to specify two\nranges at the same time is to follow two functions in a file that\nappear in separate places, and /A/ might not be unique. When I want\nto say \"I want to see from here to there, and then from here to\nthere, and then from here to there\", it would be very frustrating if\n\"and then\" resets what I mean by \"here\" every time and make these\nthree evaluated independently.\n"},{"id":"222964","messageId":"51DC6B37.9030108@alum.mit.edu","threadId":"34368","inReplyTo":"7vppurv8bl.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-07-09T19:57:43Z","receivedAt":"2013-07-09T19:57:43Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 07/09/2013 09:31 PM, Junio C Hamano wrote:\n> Thomas Rast writes:\n> \n>> If you define it that way, the output of\n>>\n>> git blame -L 4,6; git blame -L /A/,+20\n>>\n>> is significantly different from\n>>\n>> git blame -L 4,6 -L /A/,+20\n>>\n>> Not just in the presentation or any possible coalescing, but in the\n>> meaning of the ranges.\n>>\n>> Do you really want to make it that way?\n> \n> Absolutely. The primary reason I want to be able to specify two\n> ranges at the same time is to follow two functions in a file that\n> appear in separate places, and /A/ might not be unique. When I want\n> to say \"I want to see from here to there, and then from here to\n> there, and then from here to there\", it would be very frustrating if\n> \"and then\" resets what I mean by \"here\" every time and make these\n> three evaluated independently.\n\nIt would be more general to support \"follow the second match to /A/\"\n*independent* of whether the first match is also followed. I think your\nproposal only allows the second to be followed if the first is also\nfollowed. Therefore it seems to me that your wish is to add a\nside-effect to one feature so that you can use it to obtain a simulacrum\nof a second feature, instead of building the second feature directly.\n\nPerhaps allow and to be a sequence of forms like\n\n/A//A/,+20\n\n Start at the second occurrence of /A/ an continue for 20 lines\n\n/A/+20,/B/\n\n Start 20 lines after the first match of /A/ until the subsequent\nmatch of /B/\n\nE.g., the body of function \"foo\" would be '/^int foo//^{/+1,/^}/-1'.\nThat should provide hours of amusement to baffled users ;-)\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"293756","messageId":"7vli5fv5ud.fsf@alter.siamese.dyndns.org","threadId":"34368","inReplyTo":"51DC6B37.9030108@alum.mit.edu","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-09T20:25:14Z","receivedAt":"2013-07-09T20:25:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> It would be more general to support \"follow the second match to /A/\"\n> *independent* of whether the first match is also followed. I think your\n> proposal only allows the second to be followed if the first is also\n> followed. Therefore it seems to me that your wish is to add a\n> side-effect to one feature so that you can use it to obtain a simulacrum\n> of a second feature, instead of building the second feature directly.\n>\n> Perhaps allow and to be a sequence of forms like\n>\n> /A//A/,+20\n\nRemember \"A\" is just a placeholder and in real life it would be more\nthan one character. It is just as annoying as hell you have to type\nit again.\n\nI am not saying that a mode that resets the \"start searching from\nhere\" pointer to the beginning of the file is useless. For example,\nI would not mind typing a special character, e.g.\n\n -L , -L !,\n\nthat resets the search pointer to the beginning, for a rare case\nwhere I want the search for to restart at the top.\n\nBut the thing is, the default matters. And it is far more common,\nat least to me, when I want to say \"from here to there, and then\nfrom here to there\", to expect the second \"from here\" would be below\nthe first one I already specified, while I am looking at the current\nstate of a single file from top to bottom and notice two places I am\ninterested in.\n\n> /A/+20,/B/\n>\n> Start 20 lines after the first match of /A/ until the subsequent\n> match of /B/\n\nYes, I think -L \"/^{/-4,/^}/\" would be a nice thing to have, but I\nthink it is orthogonal to the issue of \"where the search for /^{/\n"},{"id":"223000","messageId":"87mwpuepst.fsf@linux-k42r.v.cablecom.net","threadId":"34368","inReplyTo":"7vppurv8bl.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-07-10T09:18:26Z","receivedAt":"2013-07-10T09:18:26Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano writes:\n\n> Thomas Rast writes:\n>\n>> If you define it that way, the output of\n>>\n>> git blame -L 4,6; git blame -L /A/,+20\n>>\n>> is significantly different from\n>>\n>> git blame -L 4,6 -L /A/,+20\n>>\n>> Not just in the presentation or any possible coalescing, but in the\n>> meaning of the ranges.\n>>\n>> Do you really want to make it that way?\n>\n> Absolutely. The primary reason I want to be able to specify two\n> ranges at the same time is to follow two functions in a file that\n> appear in separate places, and /A/ might not be unique. When I want\n> to say \"I want to see from here to there, and then from here to\n> there, and then from here to there\", it would be very frustrating if\n> \"and then\" resets what I mean by \"here\" every time and make these\n> three evaluated independently.\n\nOk, fair enough. That is at least an argument other than \"trust me, I\ncare deeply\" :-)\n\nBut still, log -L should then be changed to match this behavior (for all\nargs affecting a single file). Currently it always does the scan for\nthe start of the range from line 1 of the file.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"223081","messageId":"7vd2qprqpr.fsf@alter.siamese.dyndns.org","threadId":"34368","inReplyTo":"87mwpuepst.fsf@linux-k42r.v.cablecom.net","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-11T16:44:48Z","receivedAt":"2013-07-11T16:44:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> But still, log -L should then be changed to match this behavior (for all\n> args affecting a single file). Currently it always does the scan for\n> the start of the range from line 1 of the file.\n\nThanks, I think that makes sense.\n"},{"id":"223913","messageId":"CAPig+cTh2t_Rc13U_F-prmm=sjs2OEHX5AX2DbC5DH+Tx_E5jg@mail.gmail.com","threadId":"34368","inReplyTo":"7vli5fv5ud.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-07-22T08:12:50Z","receivedAt":"2013-07-22T08:12:50Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Jul 9, 2013 at 4:25 PM, Junio C Hamano wrote:\n> Michael Haggerty writes:\n>\n>> It would be more general to support \"follow the second match to /A/\"\n>> *independent* of whether the first match is also followed. I think your\n>> proposal only allows the second to be followed if the first is also\n>> followed. Therefore it seems to me that your wish is to add a\n>> side-effect to one feature so that you can use it to obtain a simulacrum\n>> of a second feature, instead of building the second feature directly.\n>>\n>> Perhaps allow and to be a sequence of forms like\n>>\n>> /A//A/,+20\n>\n> Remember \"A\" is just a placeholder and in real life it would be more\n> than one character. It is just as annoying as hell you have to type\n> it again.\n>\n> I am not saying that a mode that resets the \"start searching from\n> here\" pointer to the beginning of the file is useless. For example,\n> I would not mind typing a special character, e.g.\n>\n> -L , -L !,\n>\n> that resets the search pointer to the beginning, for a rare case\n> where I want the search for to restart at the top.\n>\n> But the thing is, the default matters. And it is far more common,\n> at least to me, when I want to say \"from here to there, and then\n> from here to there\", to expect the second \"from here\" would be below\n> the first one I already specified, while I am looking at the current\n> state of a single file from top to bottom and notice two places I am\n> interested in.\n\nThe proposal currently is only for \"-L /RE/,whatever\" to behave in a\nrelative fashion, beginning the search at the end of the last range\nspecified via -L (or line 1 if there is no previous -L).\n\nWould it also make sense to support \"-L +N,whatever\" as relative to\nthe end of the last range specified via -L (or 1 if none).\n\nI ask because the implementation changes needed to also support \"-L\n+N,whatever\" appear to be less invasive than those only allowing \"-L\n/RE/,whatever/\" to be relative. On the other hand, supporting \"-L\n+N,whatever\" requires more documentation. I don't necessarily consider\nless invasive changes as a good reason to support \"-L +N,whatever\" but\nit got me thinking about it.\n"},{"id":"223918","messageId":"87r4er2ct4.fsf@linux-k42r.v.cablecom.net","threadId":"34368","inReplyTo":"CAPig+cTh2t_Rc13U_F-prmm=sjs2OEHX5AX2DbC5DH+Tx_E5jg@mail.gmail.com","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-07-22T10:39:40Z","receivedAt":"2013-07-22T10:39:40Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Eric Sunshine writes:\n\n> The proposal currently is only for \"-L /RE/,whatever\" to behave in a\n> relative fashion, beginning the search at the end of the last range\n> specified via -L (or line 1 if there is no previous -L).\n>\n> Would it also make sense to support \"-L +N,whatever\" as relative to\n> the end of the last range specified via -L (or 1 if none).\n\nSounds reasonable.\n\nI'm still not sure I am super-happy with /RE/ always being relative,\nthough I see Junio's problem space as something worth solving. How does\nit interact with -L:RE? Do you now have to know in what order the\nfunctions appear in the source to correctly specify -L:foo -L:bar or\nsimilarly, -L/foo/,/^}/ -L/bar/,/^}/? What if we supported +/RE/ as the\nrelative version?\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"223927","messageId":"7vr4eqcxub.fsf@alter.siamese.dyndns.org","threadId":"34368","inReplyTo":"87r4er2ct4.fsf@linux-k42r.v.cablecom.net","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-22T17:23:56Z","receivedAt":"2013-07-22T17:23:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> Eric Sunshine writes:\n>\n>> The proposal currently is only for \"-L /RE/,whatever\" to behave in a\n>> relative fashion, beginning the search at the end of the last range\n>> specified via -L (or line 1 if there is no previous -L).\n>>\n>> Would it also make sense to support \"-L +N,whatever\" as relative to\n>> the end of the last range specified via -L (or 1 if none).\n>\n> Sounds reasonable.\n>\n> I'm still not sure I am super-happy with /RE/ always being relative,\n> though I see Junio's problem space as something worth solving. How does\n> it interact with -L:RE? Do you now have to know in what order the\n> functions appear in the source to correctly specify -L:foo -L:bar or\n> similarly, -L/foo/,/^}/ -L/bar/,/^}/? What if we supported +/RE/ as the\n> relative version?\n\nTwo gripes I have are:\n\n (1) That sounds like making common things more cumbersome to ask.\n\n (2) In \"-L /RE1/,/RE2/\", you do not have to say +/RE2/ (and you\n shouldn't have to). /RE3/ without any magic that starts\n searching after the last match in \"-L /RE1/,/RE2/ -L /RE3/,+4\"\n feels a lot more consistent than requiring a prefix plus.\n\nI am OK if you made /RE/, which starts searching immediately after\nthe last match, wrap around and continue the search at the beginning\nupon finding nothing through the end of the file (and make sure you\nstop if you passed the last match again). That would solve your \"I\nhave two functions, and I can give them in any order\", while keeping\nthe consistency with \"In /RE1/,/RE2/, the latter is already relative\nto the former\".\n"},{"id":"223931","messageId":"87bo5uqu6i.fsf@linux-k42r.v.cablecom.net","threadId":"34368","inReplyTo":"7vr4eqcxub.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-07-22T19:19:17Z","receivedAt":"2013-07-22T19:19:17Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano writes:\n\n> Thomas Rast writes:\n>\n>> Eric Sunshine writes:\n>>\n>>> The proposal currently is only for \"-L /RE/,whatever\" to behave in a\n>>> relative fashion, beginning the search at the end of the last range\n>>> specified via -L (or line 1 if there is no previous -L).\n>>>\n>>> Would it also make sense to support \"-L +N,whatever\" as relative to\n>>> the end of the last range specified via -L (or 1 if none).\n>>\n>> Sounds reasonable.\n>>\n>> I'm still not sure I am super-happy with /RE/ always being relative,\n>> though I see Junio's problem space as something worth solving. How does\n>> it interact with -L:RE? Do you now have to know in what order the\n>> functions appear in the source to correctly specify -L:foo -L:bar or\n>> similarly, -L/foo/,/^}/ -L/bar/,/^}/? What if we supported +/RE/ as the\n>> relative version?\n>\n> Two gripes I have are:\n>\n> (1) That sounds like making common things more cumbersome to ask.\n>\n> (2) In \"-L /RE1/,/RE2/\", you do not have to say +/RE2/ (and you\n> shouldn't have to). /RE3/ without any magic that starts\n> searching after the last match in \"-L /RE1/,/RE2/ -L /RE3/,+4\"\n> feels a lot more consistent than requiring a prefix plus.\n>\n> I am OK if you made /RE/, which starts searching immediately after\n> the last match, wrap around and continue the search at the beginning\n> upon finding nothing through the end of the file (and make sure you\n> stop if you passed the last match again). That would solve your \"I\n> have two functions, and I can give them in any order\", while keeping\n> the consistency with \"In /RE1/,/RE2/, the latter is already relative\n> to the former\".\n\nDunno. It still doesn't really solve the order-of-L problem if there\nare multiple matches.\n\nI can't really say how they fare against each other. I have a bad\nfeeling about the consistency of what results, but as you say, doing it\nthe way I suggested isn't very consistent either. Perhaps in retrospect\neven -L/foo/,/bar/ should have required the + in +/bar/ to make it\nrelative.\n\nI'll just leave it at that and let you decide what to do (presumably go\nahead as you already outlined). I've never actually ever used multiple\n-L in the same log/blame invocation, anyway. I just think that when it\ncomes to it, I'll have to read the manpage before I try...\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"223938","messageId":"7va9lecm8l.fsf@alter.siamese.dyndns.org","threadId":"34368","inReplyTo":"87bo5uqu6i.fsf@linux-k42r.v.cablecom.net","subject":"Re: [PATCH/RFC] blame: accept multiple -L ranges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-22T21:34:34Z","receivedAt":"2013-07-22T21:34:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> I'll just leave it at that and let you decide what to do (presumably go\n> ahead as you already outlined). I've never actually ever used multiple\n> -L in the same log/blame invocation, anyway.\n\nNobody has ;-).\n\nIt is just between my \"I often wished while looking at 'less foo.c'\nI wanted to give more than on -L to cover two ranges I see in the\nfile\" and your \"I do not know if the user can give the first -L to\ncover the first range and the second -L to cover the second range\".\nI do not think neither of us successfully gave more than one -L and\ngot any useful result.\n"}]}