Re: [PATCH v15 07/13] ref-filter: add support for %(contents:lines=X)

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

 



On Wed, Sep 2, 2015 at 9:41 PM, Matthieu Moy
<Matthieu.Moy@xxxxxxxxxxxxxxx> wrote:
> Karthik Nayak <karthik.188@xxxxxxxxx> writes:
>
>> On Wed, Sep 2, 2015 at 2:37 PM, Matthieu Moy
>> <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote:
>>> Karthik Nayak <karthik.188@xxxxxxxxx> writes:
>>>
>>>> --- a/builtin/tag.c
>>>> +++ b/builtin/tag.c
>>>> @@ -185,6 +185,10 @@ static enum contains_result contains(struct commit *candidate,
>>>>       return contains_test(candidate, want);
>>>>  }
>>>>
>>>> +/*
>>>> + * Currently modified and used in ref-filter as append_lines(), will
>>>> + * eventually be removed as we port tag.c to use ref-filter APIs.
>>>> + */
>>>>  static void show_tag_lines(const struct object_id *oid, int lines)
>>>
>>> I would rather have one "cut and paste" patch followed by a "modify and
>>> use" patch for review.
>>>
>>> As-is, reading the patch doesn't tell me what change you did.
>>>
>>> That said, I did get this information in the interdiff, so I won't
>>> insist on that.
>>
>> Its only borrowed slightly, so I don't really see the need for this.
>> But if you insist, we could do that .
>
> As you prefer.
>
> Perhaps just adapt the comment to say "Currently redundant with
> ref-filter'.c's append_line ...", but that's not important.

"Currently modified and used in ref-filter as append_lines()" seems better
as only a part of this is used.

>
>>>> +static void append_lines(struct strbuf *out, const char *buf, unsigned long size, int lines)
>>>> +{
>>>> +     int i;
>>>> +     const char *sp, *eol;
>>>> +     size_t len;
>>>> +
>>>> +     if ((sp = strstr(buf, "\n\n")) && (sp <= buf + size))
>>>> +             size += 2;
>>>
>>> Why is this "size += 2" needed?
>>>
>>
>> We pass size as "sublen + bodylen - siglen" if there exists a "\n\n"
>> between sublen and bodylen this is not accounted for. hence we
>> add 2 here.
>
> That's too much magic for uncommented code. If this is really needed,
> then thes explanations should go in a comment, and I think this logic
> should be moved out of append_lines (if you read the comment above, the
> function, it is actually lying about what the function does).
>
> I think you can simplify this: you know where the buffer ends (bodypos +
> bodylen) and where it starts (subpos), so you know the size: bodypos +
> bodylen - subpos.
>
> IOW, I think you can apply this:
>
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -645,9 +645,6 @@ static void append_lines(struct strbuf *out, const char *buf, unsigned long size
>         const char *sp, *eol;
>         size_t len;
>
> -       if ((sp = strstr(buf, "\n\n")) && (sp <= buf + size))
> -               size += 2;
> -
>         sp = buf;
>
>         for (i = 0; i < lines && sp < buf + size; i++) {
> @@ -707,7 +704,7 @@ static void grab_sub_body_contents(struct atom_value *val, int deref, struct obj
>                         struct strbuf s = STRBUF_INIT;
>                         if (strtoul_ui(valp, 10, &v->u.contents.lines))
>                                 die(_("positive width expected contents:lines=%s"), valp);
> -                       append_lines(&s, subpos, sublen + bodylen - siglen, v->u.contents.lines);
> +                       append_lines(&s, subpos, bodypos + bodylen - subpos, v->u.contents.lines);
>                         v->s = strbuf_detach(&s, NULL);
>                 }
>         }
>
> (half-tested only)

It is important, without it we'll be missing characters at the end.

I'll try what you suggested. Looks good, will test :)

-- 
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[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]