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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 6, 2022, 16:52 UTC
Message-ID: <xmqq7d82yx06.fsf@gitster.g>
In-Reply-To: <220406.86wng2eh0l.gmgdl@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 9 quoted lines

> Are the small number of missing steps above expected? E.g. 1-2/7 and 5/7
> in the last tets above, ditto the rest?
>
> Mm, yes, looking at assign_blame() in blame.c we'll "skip" some.
>
> So if we ever change that algorithm we'll need to adjust these, but it's
> probably good to notice that then, even if the test_cmp here does
> implicitly encode a bit of internal implementation details, i.e. when
> exactly we update the progress bar.

I do not think that is something we want to test, or distract the developers by forcing them to update the skipping hardcoded in the test.

Is it easy to grab the last progress message from the output? What we care, and have cared in the past, is that we expect that the 100% is paired with the number of lines in the ranges, and the progress actually ends at 100% (we had different bugs that did not bring the meter to 100% at the end), so checking that end result would be what matters most, e.g.

    tr '\015' '\012' output | tail -n 1

or something?