All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karthik Nayak <karthik.188@gmail.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: Git <git@vger.kernel.org>,
	Christian Couder <christian.couder@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v15 07/13] ref-filter: add support for %(contents:lines=X)
Date: Thu, 3 Sep 2015 19:04:25 +0530	[thread overview]
Message-ID: <CAOLa=ZRiGg1snfsi_mxQYq-wV6Zz4cTkxum47dRowp1XopQejw@mail.gmail.com> (raw)
In-Reply-To: <vpq7fo8ol7i.fsf@anie.imag.fr>

On Wed, Sep 2, 2015 at 9:41 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Karthik Nayak <karthik.188@gmail.com> writes:
>
>> On Wed, Sep 2, 2015 at 2:37 PM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>> Karthik Nayak <karthik.188@gmail.com> 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

  reply	other threads:[~2015-09-03 13:35 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-01 18:26 [PATCH v15 00/13] port builtin/tag.c to use ref-filter APIs Karthik Nayak
2015-09-01 18:26 ` [PATCH v15 01/13] ref-filter: move `struct atom_value` to ref-filter.c Karthik Nayak
2015-09-01 18:26 ` [PATCH v15 02/13] ref-filter: introduce ref_formatting_state and ref_formatting_stack Karthik Nayak
2015-09-01 18:26 ` [PATCH v15 03/13] utf8: add function to align a string into given strbuf Karthik Nayak
2015-09-01 18:26 ` [PATCH v15 04/13] ref-filter: introduce handler function for each atom Karthik Nayak
2015-09-01 18:26 ` [PATCH v15 05/13] ref-filter: implement an `align` atom Karthik Nayak
2015-09-01 21:19   ` Junio C Hamano
2015-09-02 11:51     ` Karthik Nayak
2015-09-02 15:01       ` Junio C Hamano
2015-09-02 15:05         ` Karthik Nayak
2015-09-02 15:45           ` Junio C Hamano
2015-09-02 16:09             ` Karthik Nayak
2015-09-02 17:10             ` Matthieu Moy
2015-09-02 17:28               ` Junio C Hamano
2015-09-03 13:30                 ` Karthik Nayak
2015-09-02 15:50         ` Matthieu Moy
2015-09-02  8:41   ` Matthieu Moy
2015-09-02 12:51     ` Karthik Nayak
2015-09-02  8:45   ` Matthieu Moy
2015-09-02 13:12     ` Karthik Nayak
2015-09-02 15:50       ` Matthieu Moy
2015-09-03 14:12   ` Eric Sunshine
2015-09-03 16:01     ` Karthik Nayak
2015-09-03 16:23     ` Junio C Hamano
2015-09-04 18:02       ` Karthik Nayak
2015-09-01 18:26 ` [PATCH v15 06/13] ref-filter: add option to filter out tags, branches and remotes Karthik Nayak
2015-09-01 21:30   ` Junio C Hamano
2015-09-02  1:27     ` Karthik Nayak
2015-09-02  4:15       ` Junio C Hamano
2015-09-02 12:48         ` Karthik Nayak
2015-09-01 18:26 ` [PATCH v15 07/13] ref-filter: add support for %(contents:lines=X) Karthik Nayak
2015-09-02  9:07   ` Matthieu Moy
2015-09-02 14:16     ` Karthik Nayak
2015-09-02 16:11       ` Matthieu Moy
2015-09-03 13:34         ` Karthik Nayak [this message]
2015-09-03 13:49           ` Karthik Nayak
2015-09-03 14:47             ` Matthieu Moy
2015-09-03 16:05               ` Karthik Nayak
2015-09-03 14:39   ` Eric Sunshine
2015-09-03 14:47     ` Eric Sunshine
2015-09-03 15:05       ` Matthieu Moy
2015-09-03 16:04         ` Karthik Nayak
2015-09-03 16:27       ` Junio C Hamano
2015-09-04 12:35         ` Karthik Nayak
2015-09-03 15:01     ` Matthieu Moy
2015-09-03 16:03     ` Karthik Nayak
2015-09-01 18:26 ` [PATCH v15 08/13] ref-filter: add support to sort by version Karthik Nayak
2015-09-01 18:26 ` [PATCH v15 09/13] ref-filter: add option to match literal pattern Karthik Nayak
2015-09-01 18:26 ` [PATCH v15 10/13] tag.c: use 'ref-filter' data structures Karthik Nayak
2015-09-01 18:26 ` [PATCH v15 11/13] tag.c: use 'ref-filter' APIs Karthik Nayak
2015-09-02  9:09   ` Matthieu Moy
2015-09-02 15:10   ` Junio C Hamano
2015-09-02 15:40     ` Karthik Nayak
2015-09-02 16:13       ` Matthieu Moy
2015-09-02 16:43         ` Junio C Hamano
2015-09-03 13:32           ` Karthik Nayak
2015-09-01 18:26 ` [PATCH v15 12/13] tag.c: implement '--format' option Karthik Nayak
2015-09-01 18:26 ` [PATCH v15 13/13] tag.c: implement '--merged' and '--no-merged' options Karthik Nayak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOLa=ZRiGg1snfsi_mxQYq-wV6Zz4cTkxum47dRowp1XopQejw@mail.gmail.com' \
    --to=karthik.188@gmail.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.