On Wed, Aug 26, 2015 at 12:46 AM, Junio C Hamano <[email protected]> wrote:
> Karthik Nayak <[email protected]> writes:
>
>>> Here is what I see...
>>>
>>> ok 98 - verifying rfc1991 signature
>>>
>>> expecting success:
>>> echo "rfc1991" >gpghome/gpg.conf &&
>>> echo "rfc1991-signed-tag RFC1991 signed tag" >expect &&
>>> git tag -l -n1 rfc1991-signed-tag >actual &&
>>> test_cmp expect actual &&
>>> git tag -l -n2 rfc1991-signed-tag >actual &&
>>> test_cmp expect actual &&
>>> git tag -l -n999 rfc1991-signed-tag >actual &&
>>> test_cmp expect actual
>>>
>>> --- expect 2015-08-24 22:54:44.607272653 +0000
>>> +++ actual 2015-08-24 22:54:44.611272643 +0000
>>> @@ -1 +1 @@
>>> -rfc1991-signed-tag RFC1991 signed tag
>>> +rfc1991-signed-tagRFC1991 signed tag
>>> not ok 99 - list tag with rfc1991 signature
>>
>> Thats weird, I just ran all tests, and nothing failed.
>
> You may be missing GPG or RFC1991 prerequisites and not running this
> particular test, which could be why you missed it.
>
That explains.
> Your builtin/tag.c calls show_ref_array_item() with
>
> "%(align:16,left)%(refname:short)%(end)"
>
> as the format, and "rfc1991-signed-tag" is longer than 16.
>
> And immediately after showing that, there is this hack at the end of
> show_ref_array_item() function, which I _think_ should not be there
> in ref-filter.c:show_ref_array_item() in the first place.
>
> if (lines > 0) {
> struct object_id oid;
> hashcpy(oid.hash, info->objectname);
> show_tag_lines(&oid, lines);
> }
>
> This belongs to the caller who knows that it is dealing with a tag.
>
Explained the idea behind this below.
> But that broken design aside, the reason why this breaks is because
> you do not have a separating SP after the aligned short refs.
>
Makes sense.
> I didn't check how wide the original is supposed to be, but perhaps
> changing builtin/tag.c this way
>
> if (filter->lines)
> - format = "%(align:16,left)%(refname:short)%(end)";
> + format = "%(align:15,left)%(refname:short)%(end) ";
> else
> format = "%(refname:short)";
> }
>
> may be one way to fix it. Check the original "tag -l" output for
> tags whose names are 14, 15, 16 and 17 display-columns wide and try
> to match it.
>
That should be the fix, since it's a space problem.
> And then move the tag-specific code at the end of
> show_ref_array_item() to here:
>
> verify_ref_format(format);
> filter_refs(&array, filter, FILTER_REFS_TAGS);
> ref_array_sort(sorting, &array);
>
> - for (i = 0; i < array.nr; i++)
> + for (i = 0; i < array.nr; i++) {
> show_ref_array_item(array.items[i], format, QUOTE_NONE,
> filter->lines);
> + if (lines) {
> + struct object_id oid;
> + hashcpy(oid.hash, info->objectname);
> + show_tag_lines(&oid, lines);
> + }
> + }
>
> perhaps.
The problem with doing this is, the lines need to be displayed
immediately after the refname,
followed by a newline, what you're suggesting breaks that flow.
We could pass a boolean to show_ref_array_item() and print a newline if no
lines are to be printed and probably print the newline in tag.c
itself, but seems confusing to me.
> Heh, I did it myself. %(align:15) with trailing whitespace is what
> you want.
>
> An alternative way to spell it would be
>
> "%(align:16,left)%(refname:short) %(end)"
>
> I don't know which one is more readable, though.
I find this more readable, since the space is clearly visible, unlike
format = "%(align:15,left)%(refname:short)%(end) "; in which the space
after %(end) is easily unnoticeable.
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
