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

[Junio C Hamano <gitster@pobox.com>]

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

> 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?