Re: [PATCH] blame: report correct number of lines in progress when using ranges
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Apr 4, 2022, 06:15 UTC
- Message-ID
- <220404.86y20ljrui.gmgdl@evledraar.gmail.com>
- In-Reply-To
- <CAOc6etac3tQdOzY1bF7qBVOJ_ndns-KOSum8w-Jie06Ynz_cWw@mail.gmail.com>
On Mon, Apr 04 2022, Edmundo Carmona Antoranz wrote:
Show 21 quoted lines
> On Mon, Apr 4, 2022 at 12:42 AM Junio C Hamano <gitster@pobox.com> wrote: >> >> Wow. I am reasonably sure that this was broken since the >> introduction of the progress meter to "git blame". Thanks for >> finding and fixing. > > As the person who originally wrote said support, I feel like I > am just nurturing it. :-D > >> >> Can we have a test, too, or is that too cumbersome to add for some >> reason? > > Correct me if I'm wrong but it could be a little tricky because "progress > display" shows up only if it happens to "lose" a race. Progress is > skipped altogether if blame process goes too fast. Even if you run > blame on a file with a lot of history, if box is fast enough and info is > cached, it will fail to display progress. So, all in all, it would be like > trying to unit test output coming out of a race condition. > > Let me know what you think.
You can make it always show up by using GIT_PROGRESS_DELAY=0, grep for it in existing tests, skimming the code that coupled with --progress should guarantee that it shows up.