Re: [PATCH v2] blame: report correct number of lines in progress when using ranges

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Apr 05 2022, Bagas Sanjaya wrote:

> On 05/04/22 01.21, Edmundo Carmona Antoranz wrote:
>> When using ranges, use their sizes as the limit for progress
>> instead of the size of the full file.
>> 
>
> The progress limit is defined by number of affected lines, right?
>
>> +test_expect_success 'blame progress on a full file' '
>> +	cat >progress.txt <<-\EOF &&
>> +	a simple test file
>> +
>> +	no relevant content is expected here
>> +
>> +	If the file is too short, we cannot test ranges
>> +
>> +	EOF
>> +	git add progress.txt &&
>> +	git commit -m "add a file for testing progress" &&
>> +	GIT_PROGRESS_DELAY=0 \
>> +	git blame --progress progress.txt > /dev/null 2> full_progress.txt &&
>> +	grep "Blaming lines: 100% (6/6), done." full_progress.txt
>> +'
>> +
>> +test_expect_success 'blame progress on a single range' '
>> +	GIT_PROGRESS_DELAY=0 \
>> +	git blame --progress -L 2,5 progress.txt > /dev/null 2> range_progress.txt &&
>> +	grep "Blaming lines: 100% (4/4), done." range_progress.txt
>> +'
>> +
>> +test_expect_success 'blame progress on multiple ranges' '
>> +	GIT_PROGRESS_DELAY=0 \
>> +	git blame --progress -L 1,2 -L 4,6 progress.txt > /dev/null 2> range_progress.txt &&
>> +	grep "Blaming lines: 100% (5/5), done." range_progress.txt
>> +'
>> +
>
> Why not using test_i18ngrep?

Nothing should be using test_i18ngrep nowadays, just grep is better. We
no longer test with the gettext "poison" mode which necessitated it.