> Don't t800[12]-*.sh need adjustment for this change, too?
Apologies. I will make sure I've run the whole test suite against my patches in
future. I've sent through a 7th (and hopefully final) version.
On 30/5/18 6:45 pm, Eric Sunshine wrote:
>> diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
>> @@ -152,6 +152,16 @@ Also you can use a regular expression to specify the
>> line range:
>> which limits the annotation to the body of the `hello` subroutine.
>>
>> +A range that
> Maybe I misread the previous discussion and/or your cover letter,
> but I have been assuming that you are trying to avoid failing the
> command in a useless way (e.g. when the file has only ~800 lines but
> the user does not know exactly how many, instead of letting -L1,820
> to fail with "the
My intention was to modify existing behaviour as little as possible,
but I agree clipping to the first line makes a lot more sense. That
raises the question though, do we clip to 1 and treat -L,-n as a valid
input, or clip to -1 so that this case be detected?
On 27/4/18 10:50 am, Junio C Hamano
On 27/10/17 12:58 pm, Junio C Hamano wrote:
> Isabella Stephens <isteph...@atlassian.com> writes:
>
>> diff --git a/builtin/blame.c b/builtin/blame.c
>> index 67adaef4d..b5b9db147 100644
>> --- a/builtin/blame.c
>> +++ b/builtin/blame.c
>> @@ -878,13 +87
that is entirely outside the bounds of the file will
still fail.
This commit also ammends the relevant test and adds clarification to
the documentation.
Signed-off-by: Isabella Stephens <isteph...@atlassian.com>
---
Documentation/git-blame.txt | 10 ++
builtin/blame.c
d be kept
> consistent in the two commands, and 'git log' shouldn't error out,
> either.
Good suggestion. I'll submit a separate patch for git log.
>
>> Signed-off-by: Isabella Stephens <isteph...@atlassian.com>
>> ---
>> builtin/blame.c | 4 ++--
&g
On 26/10/17 7:48 pm, Jacob Keller wrote:
> On Thu, Oct 26, 2017 at 12:01 AM, Isabella Stephens
> <isteph...@atlassian.com> wrote:
>> If the -L option is used to specify a line range in git blame, and the
>> end of the range is past the end of the file, at present git w
On 26/10/17 5:15 pm, Junio C Hamano wrote:
> Isabella Stephens <isteph...@atlassian.com> writes:
>
>> If the -L option is used to specify a line range in git blame, and the
>> end of the range is past the end of the file, git will fail with a fatal
>> error. It may i
-by: Isabella Stephens <isteph...@atlassian.com>
---
builtin/blame.c | 4 ++--
t/t8003-blame-corner-cases.sh | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 67adaef4d..b5b9db147 100644
--- a/builtin/blame.c
+++ b/b
adds a --fuzzy-lines command line option to allow this.
Signed-off-by: Isabella Stephens <isteph...@atlassian.com>
---
Documentation/blame-options.txt | 5 +
builtin/blame.c | 4
t/t8003-blame-corner-cases.sh | 6 ++
3 files changed, 15 insertions(+)
diff
11 matches
Mail list logo
