Re: [PATCH 7/8] fetch: fix inconsistent summary width for pruned and updated refs

[Patrick Steinhardt <ps@pks.im>]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

On Thu, Mar 16, 2023 at 09:30:46AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Practically speaking we could go even further than the current version,
> > as I now compute the width across _all_ reference updates, even those
> > which are deletions. But theoretically speaking, we could just skip over
> > any deletions completely as they won't ever contribute to the column
> > width anyway.
> 
> OK.  It's good to see that you have thought it through.
> 
> > Fair, having a test for this would be great. But what kept me from
> > adding one here is that the column width depends on the length of the
> > longest shared prefix of two object IDs that are about to be updated.
> 
> You do not have to prepare "this is the correct expected output",
> when you need to make sure that two kinds of lines use the same
> width settings, no?  Extract such lines from the two camps, measure
> them and see if they are of the same length, or something?

Well, comparing widths of these two lines is the easy version of the
test, agreed. But in order to test for the bug I'm fixing I'd need to
generate two sets of object IDs, where the first set of object IDs has a
longer shared prefix length than the second. Because otherwise, the bug
wouldn't be guaranteed to even surface.

Anyway -- I'll have a look at adding the easy version.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]