{"thread":{"id":"24414","subject":"[BUG?] blame: Odd -L 1,+0 behavior","startedAt":"2010-07-16T15:50:52Z","lastAt":"2010-07-16T22:33:10Z","messageCount":4,"participants":["Ævar Arnfjörð Bjarmason","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"145698","messageId":"AANLkTin-6nck9aVKPTwOy_PmrGUs1iS8ruqzIORbf8jb@mail.gmail.com","threadId":"24414","inReplyTo":null,"subject":"[BUG?] blame: Odd -L 1,+0 behavior","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-07-16T15:50:52Z","receivedAt":"2010-07-16T15:50:52Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Jul 16, 2010 at 15:35, Ævar Arnfjörð Bjarmason wrote:\n> git-pickaxe (later git-blame) gained support for the -L/start/,/end/\n> form in 2006 (931233bc66 by Junio C Hamano), but nothing was added to\n> test this functionality. Change that by adding more -L tests to\n> t8003-blame.sh.\n\nI was also going to patch t8003-blame.sh to test for the functionality\nintroduced in 7bd9641df5, but I'm not sure what it's supposed to do:\n\nok:\n\n $ git blame cow\n 5b22ca36 (Fourth 2005-04-07 15:16:13 -0700 1) ABC\n 5b22ca36 (Fourth 2005-04-07 15:16:13 -0700 2) DEF\n 018e3134 (Fifth 2005-04-07 15:17:13 -0700 3) XXXX\n 5b22ca36 (Fourth 2005-04-07 15:16:13 -0700 4) GHIJK\n\nok:\n\n $ git blame -L 1,2 cow\n 5b22ca36 (Fourth 2005-04-07 15:16:13 -0700 1) ABC\n 5b22ca36 (Fourth 2005-04-07 15:16:13 -0700 2) DEF\n\nok, +/- are zero-indexed:\n\n $ git blame -L 1,+2 cow\n 5b22ca36 (Fourth 2005-04-07 15:16:13 -0700 1) ABC\n 5b22ca36 (Fourth 2005-04-07 15:16:13 -0700 2) DEF\n\nShouldn't this either print nothing, er be an error:\n\n $ git blame -L 1,+0 cow\n 5b22ca36 (Fourth 2005-04-07 15:16:13 -0700 1) ABC\n 5b22ca36 (Fourth 2005-04-07 15:16:13 -0700 2) DEF\n\nsame here, line 0-0 prints the whole file:\n\n $ git blame -L 0,0 cow\n 5b22ca36 (Fourth 2005-04-07 15:16:13 -0700 1) ABC\n 5b22ca36 (Fourth 2005-04-07 15:16:13 -0700 2) DEF\n 018e3134 (Fifth 2005-04-07 15:17:13 -0700 3) XXXX\n 5b22ca36 (Fourth 2005-04-07 15:16:13 -0700 4) GHIJK\n\nAnd these need a better error message:\n\n $ git blame -L 0,0a cow\n usage: git blame [options] [rev-opts] [rev] [--] file\n\nIs there any use for +/- 0, or should it always be an error?\n"},{"id":"145713","messageId":"7vy6dbqghl.fsf@alter.siamese.dyndns.org","threadId":"24414","inReplyTo":"AANLkTin-6nck9aVKPTwOy_PmrGUs1iS8ruqzIORbf8jb@mail.gmail.com","subject":"Re: [BUG?] blame: Odd -L 1,+0 behavior","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-07-16T21:11:34Z","receivedAt":"2010-07-16T21:11:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> ok, +/- are zero-indexed:\n>\n> $ git blame -L 1,+2 cow\n\nI don't know what \"zero-indexed\" means, but +2 means \"starting from the\nline I told you earlier, give me two lines\". Likewise -2 means \"ending at\nthe line I told you earlier, give me two lines\". As a side effect of the\ninternal implementation of this logic -L 5,3 means the same thing as -L 3,5\nbut that is not an intended nor documented behaviour.\n\n> Shouldn't this either print nothing, er be an error:\n(multiple)\n\nThe parsing code is lax in the sense that rejecting nonsensical input like\n\"-L 10,-100\" and \"-L 2,+0\" as an error was not considered a primary goal.\nThe only error checking it does is to make sure it does not parse numbers\nthat it cannot use (i.e. start from line 30 in a file that does not have\nthat many lines).\n"},{"id":"145715","messageId":"AANLkTinSO3S4hjuvzSOfEBwBEL8_amk7uM2-_LKMtE8k@mail.gmail.com","threadId":"24414","inReplyTo":"7vy6dbqghl.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG?] blame: Odd -L 1,+0 behavior","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-07-16T21:25:58Z","receivedAt":"2010-07-16T21:25:58Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Jul 16, 2010 at 21:11, Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> ok, +/- are zero-indexed:\n>>\n>>     $ git blame -L 1,+2 cow\n>\n> I don't know what \"zero-indexed\" means, but +2 means \"starting from the\n> line I told you earlier, give me two lines\".  Likewise -2 means \"ending at\n> the line I told you earlier, give me two lines\".\n\nFrom just using it I parsed 1,+1 as \"give me line #1 plus $n-1\nlines\". At first I thought 1,+1 would print two lines (line 1 *plus*\none). But it makes sense when you explain it.\n\n> As a side effect of the internal implementation of this logic -L 5,3\n> means the same thing as -L 3,5 but that is not an intended nor\n> documented behaviour.\n\nHow should L 5,3 and 3,5 work? Should the former give an error?\n\n>> Shouldn't this either print nothing, er be an error:\n> (multiple)\n>\n> The parsing code is lax in the sense that rejecting nonsensical input like\n> \"-L 10,-100\" and \"-L 2,+0\" as an error was not considered a primary goal.\n> The only error checking it does is to make sure it does not parse numbers\n> that it cannot use (i.e. start from line 30 in a file that does not have\n> that many lines).\n\nDo you want a patch to make it less lax?\n"},{"id":"145716","messageId":"7vmxtrqcpl.fsf@alter.siamese.dyndns.org","threadId":"24414","inReplyTo":"AANLkTinSO3S4hjuvzSOfEBwBEL8_amk7uM2-_LKMtE8k@mail.gmail.com","subject":"Re: [BUG?] blame: Odd -L 1,+0 behavior","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-07-16T22:33:10Z","receivedAt":"2010-07-16T22:33:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n>> As a side effect of the internal implementation of this logic -L 5,3\n>> means the same thing as -L 3,5 but that is not an intended nor\n>> documented behaviour.\n>\n> How should L 5,3 and 3,5 work? Should the former give an error?\n\n\"-L 3,5\" would choose \"lines 3,4, and 5\" (both ends inclusive). Currently\n\"-L 5,3\" does the same thing but as I said, that is not an intended nor\ndocumented behaviour, and if you are tackling this area to tighten the\nparsing and error diagnosis, I think it is reasonable to error it out.\n\n>>> Shouldn't this either print nothing, er be an error:\n>> (multiple)\n>>\n>> The parsing code is lax in the sense that rejecting nonsensical input like\n>> \"-L 10,-100\" and \"-L 2,+0\" as an error was not considered a primary goal.\n>> The only error checking it does is to make sure it does not parse numbers\n>> that it cannot use (i.e. start from line 30 in a file that does not have\n>> that many lines).\n>\n> Do you want a patch to make it less lax?\n\nBe my guest ;-) Thanks.\n"}]}