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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Patrick Steinhardt <ps@xxxxxx> 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?

Thanks.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux