From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <chriscool@tuxfamily.org>
Cc: git@vger.kernel.org, Johan Herland <johan@herland.net>,
Josh Triplett <josh@joshtriplett.org>,
Thomas Rast <tr@thomasrast.ch>,
Michael Haggerty <mhagger@alum.mit.edu>,
Dan Carpenter <dan.carpenter@oracle.com>,
Greg Kroah-Hartman <greg@kroah.com>, Jeff King <peff@peff.net>,
Eric Sunshine <sunshine@sunshineco.com>,
Ramsay Jones <ramsay@ramsay1.demon.co.uk>,
Jonathan Nieder <jrnieder@gmail.com>,
Marc Branchaud <marcnarc@xiplink.com>
Subject: Re: [PATCH 4/5] trailer: reuse ignore_non_trailer() to ignore conflict lines
Date: Fri, 07 Nov 2014 12:27:03 -0800 [thread overview]
Message-ID: <xmqqzjc2eoyw.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20141107185053.16854.5660.chriscool@tuxfamily.org> (Christian Couder's message of "Fri, 07 Nov 2014 19:50:51 +0100")
Christian Couder <chriscool@tuxfamily.org> writes:
> * Copyright (c) 2013, 2014 Christian Couder <chriscool@tuxfamily.org>
> @@ -791,14 +792,24 @@ static int process_input_file(struct strbuf **lines,
> struct trailer_item **in_tok_last)
> {
> int count = 0;
> - int patch_start, trailer_start, i;
> + int trailer_start, trailer_end, patch_start, ignore_bytes, i;
> + struct strbuf sb;
>
> /* Get the line count */
> while (lines[count])
> count++;
>
> patch_start = find_patch_start(lines, count);
> - trailer_start = find_trailer_start(lines, patch_start);
> +
> + /* Get the index of the end of the trailers */
> + for (i = 0; i < patch_start; i++)
> + strbuf_addbuf(&sb, lines[i]);
> + ignore_bytes = ignore_non_trailer(&sb);
> + for (i = patch_start - 1; i >= 0 && ignore_bytes > 0; i--)
> + ignore_bytes -= lines[i]->len;
> + trailer_end = i + 1;
Looks like there is an impedance mismatch between the caller and the
callee here. I can sort of understand why you might want to have an
array of trailer items, one element per line in the trailer block,
as that would make it easier on your brain when you have to reorder
them, insert a new one or a remove an existing one, but you seem to
be keeping _everything_ in that format, an array of strbuf with one
strbuf per line, which sounds really wasteful. The data structure
might need to be rethoughtbefore this code becomes ready for
production.
I would have expected it to be more like (1) slurp everything in a
single strbuf, (2) find the trailer block inside that single strbuf,
splitting what you read in the previous step into one strbuf for
stuff before the trailer block, another strbuf for stuff after the
trailer block and an array of lines in the tailer block, (3) do
whatever your trailer flipping logic inside that array without
having to worry about stuff before or after the trailer block and
then finally (4) spit the whole thing out by concatenating the stuff
before the trailer block, the stuff in the trailer block and the
stuff after the trailer block.
Oh well...
next prev parent reply other threads:[~2014-11-07 20:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-07 18:50 [PATCH 0/5] Small "git interpret-trailers" fixes Christian Couder
2014-11-07 18:50 ` [PATCH 1/5] trailer: ignore comment lines inside the trailers Christian Couder
2014-11-07 18:50 ` [PATCH 2/5] trailer: display a trailer without its trailing newline Christian Couder
2014-11-07 19:22 ` Jeff King
2014-11-07 19:26 ` Junio C Hamano
2014-11-07 18:50 ` [PATCH 3/5] commit: make ignore_non_trailer() non static Christian Couder
2014-11-07 18:50 ` [PATCH 4/5] trailer: reuse ignore_non_trailer() to ignore conflict lines Christian Couder
2014-11-07 20:27 ` Junio C Hamano [this message]
2014-11-09 10:35 ` Christian Couder
2014-11-09 16:45 ` Junio C Hamano
2014-11-09 18:24 ` Junio C Hamano
2014-11-09 22:40 ` Junio C Hamano
2014-11-07 18:50 ` [PATCH 5/5] trailer: add test with an old style conflict block Christian Couder
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=xmqqzjc2eoyw.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=chriscool@tuxfamily.org \
--cc=dan.carpenter@oracle.com \
--cc=git@vger.kernel.org \
--cc=greg@kroah.com \
--cc=johan@herland.net \
--cc=josh@joshtriplett.org \
--cc=jrnieder@gmail.com \
--cc=marcnarc@xiplink.com \
--cc=mhagger@alum.mit.edu \
--cc=peff@peff.net \
--cc=ramsay@ramsay1.demon.co.uk \
--cc=sunshine@sunshineco.com \
--cc=tr@thomasrast.ch \
/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.