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.
