git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Jeff King <peff@peff.net>
Cc: Karthik Nayak <karthik.188@gmail.com>,
	Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v5 02/12] ref-filter: use strbuf_split_str_omit_term()
Date: Tue, 16 Feb 2016 15:12:29 -0500	[thread overview]
Message-ID: <CAPig+cTiwHs+dD+jqAp8SNkwjQ2OzDsC8yopRgF7gctrGi5uUw@mail.gmail.com> (raw)
In-Reply-To: <20160216192231.GA16567@sigill.intra.peff.net>

On Tue, Feb 16, 2016 at 2:22 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Feb 17, 2016 at 12:30:05AM +0530, Karthik Nayak wrote:
>> Use the newly introduced strbuf_split_str_omit_term() rather than
>> using strbuf_split_str() and manually removing the ',' terminator.
>>
>> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
>> Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
>> ---
> Did you consider just using string_list_split for this? AFAICT, you
> don't care about the results being strbufs themselves, and it would do
> what you want without having to bother with patch 1. [...]
>
> Sorry to waltz into a review of v5 with a suggestion to throw out all
> the work done in previous iterations. :-/ I just think the strbuf_split
> interface is kind of clunky and I'd be happy if we could slowly get rid
> of it rather than growing it. [...]

That's a nice idea, however, I'm not sure if making it part of this
series this late in the game is a good idea. The series has gone
through major changes and heavy review in each of the preceding
versions, and turnaround time has been consequently quite slow (due
both to the amount of work required by Karthik for each version, and
to the amount of time needed by reviewers to digest all the new
changes). v4 was the first one which had settled to the point where
only minor changes were needed, and we were hoping to land the series
with v5. (A few larger changes were also discussed in v4 reviews, but
we concluded that they could be done as follow-up patches.)

With that in mind, it might be better to make this change as a
followup to this series. On the other hand, as you say, waiting would
expand the strbuf_split interface undesirably, so the alternative
would be for Karthik to submit v6 with this change only (to wit: drop
patch 1 and rewrite patch 2 as you've shown). While such a change will
again require careful review, at least it is well localized, and
Karthik's turnaround time shouldn't be too bad. So...

  parent reply	other threads:[~2016-02-16 20:12 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-16 19:00 [PATCH v5 00/12] ref-filter: use parsing functions Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 01/12] strbuf: introduce strbuf_split_str_omit_term() Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 02/12] ref-filter: use strbuf_split_str_omit_term() Karthik Nayak
2016-02-16 19:22   ` Jeff King
2016-02-16 19:23     ` Jeff King
2016-02-16 20:12     ` Eric Sunshine [this message]
2016-02-16 20:49       ` Jeff King
2016-02-16 21:09         ` Eric Sunshine
2016-02-16 22:34           ` Jeff King
2016-02-16 22:49             ` Eric Sunshine
2016-02-16 23:18               ` Jeff King
2016-02-17  0:12                 ` Junio C Hamano
2016-02-17  0:22                   ` Jeff King
2016-02-17  0:28                     ` Junio C Hamano
2016-02-17  0:32                       ` Jeff King
2016-02-17 17:50                         ` Junio C Hamano
2016-02-17 17:04           ` Karthik Nayak
2016-02-17 17:39             ` Eric Sunshine
2016-02-17 18:07               ` Karthik Nayak
2016-02-17 18:17                 ` Eric Sunshine
2016-02-17 18:21                   ` Karthik Nayak
2016-02-17 16:58     ` Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 03/12] ref-filter: bump 'used_atom' and related code to the top Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 04/12] ref-filter: introduce struct used_atom Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 05/12] ref-filter: introduce parsing functions for each valid atom Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 06/12] ref-filter: introduce color_atom_parser() Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 07/12] ref-filter: introduce parse_align_position() Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 08/12] ref-filter: introduce align_atom_parser() Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 09/12] ref-filter: align: introduce long-form syntax Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 10/12] ref-filter: introduce remote_ref_atom_parser() Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 11/12] ref-filter: introduce contents_atom_parser() Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 12/12] ref-filter: introduce objectname_atom_parser() 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=CAPig+cTiwHs+dD+jqAp8SNkwjQ2OzDsC8yopRgF7gctrGi5uUw@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@gmail.com \
    --cc=peff@peff.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).