From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <johannes.schindelin@gmx.de>
Cc: Paul Tan <pyokagan@gmail.com>,
git@vger.kernel.org, Stefan Beller <sbeller@google.com>,
Stephen Robin <stephen.robin@gmail.com>
Subject: Re: [PATCH 10/14] pull: set reflog message
Date: Mon, 18 May 2015 14:53:07 -0700 [thread overview]
Message-ID: <xmqqmw11a6yk.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <390e789e8f84122d52185f22e6e798f2@www.dscho.org> (Johannes Schindelin's message of "Mon, 18 May 2015 21:27:36 +0200")
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>> /**
>> + * Sets the GIT_REFLOG_ACTION environment variable to the concatenation of argv
>> + */
>> +static void set_reflog_message(int argc, const char **argv)
>> +{
>> + int i;
>> + struct strbuf msg = STRBUF_INIT;
>> +
>> + for (i = 0; i < argc; i++) {
>> + strbuf_addstr(&msg, argv[i]);
>> + strbuf_addch(&msg, ' ');
>> + }
>> +
>> + strbuf_rtrim(&msg);
>
> Since this is not performance critical code, I would be slightly in
> favor of simplifying thusly:
>
> /* Join the argument list, separated by spaces */
> for (i = 0; i < argc; i++)
> strbuf_addf(&msg, "%s%s", i ? " " : "", argv[i]);
Yeah, either that, or "insert separator only before adding to
something else" pattern, i.e.
for (i = 0; i < argc; i++) {
if (i)
addch(&msg, ' ');
addstr(&msg, argv[i]);
}
Both are easier to read than "always append SP and trim at the end".
Besides, trimming at the end makes readers wonder if there are cases
where argv[argc-1] ends with whitespaces and the code on purpose
removes them.
next prev parent reply other threads:[~2015-05-18 21:53 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-18 15:05 [PATCH 00/14] Make git-pull a builtin Paul Tan
2015-05-18 15:05 ` [PATCH 01/14] pull: implement fetch + merge Paul Tan
2015-05-18 15:55 ` Johannes Schindelin
2015-05-18 15:05 ` [PATCH 02/14] pull: pass verbosity, --progress flags to fetch and merge Paul Tan
2015-05-18 17:41 ` Johannes Schindelin
2015-05-21 9:48 ` Paul Tan
2015-05-21 15:59 ` Johannes Schindelin
2015-05-22 13:38 ` Paul Tan
2015-05-18 15:06 ` [PATCH 03/14] pull: pass git-merge's options to git-merge Paul Tan
2015-05-18 15:06 ` [PATCH 04/14] pull: pass git-fetch's options to git-fetch Paul Tan
2015-05-18 15:06 ` [PATCH 05/14] pull: error on no merge candidates Paul Tan
2015-05-18 18:56 ` Johannes Schindelin
2015-05-18 15:06 ` [PATCH 06/14] pull: support pull.ff config Paul Tan
2015-05-18 19:02 ` Johannes Schindelin
2015-05-21 9:53 ` Paul Tan
2015-05-18 15:06 ` [PATCH 07/14] pull: check if in unresolved merge state Paul Tan
2015-05-18 19:06 ` Johannes Schindelin
2015-05-18 15:06 ` [PATCH 08/14] pull: fast-forward working tree if head is updated Paul Tan
2015-05-18 19:18 ` Johannes Schindelin
2015-05-18 15:06 ` [PATCH 09/14] pull: implement pulling into an unborn branch Paul Tan
2015-05-18 15:06 ` [PATCH 10/14] pull: set reflog message Paul Tan
2015-05-18 19:27 ` Johannes Schindelin
2015-05-18 21:53 ` Junio C Hamano [this message]
2015-05-21 10:08 ` Paul Tan
2015-05-18 15:06 ` [PATCH 11/14] pull: teach git pull about --rebase Paul Tan
2015-05-18 23:36 ` Stefan Beller
2015-05-19 13:04 ` Johannes Schindelin
2015-05-31 8:18 ` Paul Tan
2015-06-02 11:26 ` Paul Tan
2015-05-18 15:06 ` [PATCH 12/14] pull: configure --rebase via branch.<name>.rebase or pull.rebase Paul Tan
2015-05-18 23:58 ` Stefan Beller
2015-05-18 15:06 ` [PATCH 13/14] pull --rebase: exit early when the working directory is dirty Paul Tan
2015-05-18 15:06 ` [PATCH 14/14] pull --rebase: error on no merge candidate cases Paul Tan
2015-05-19 0:12 ` Stefan Beller
2015-05-19 13:10 ` Johannes Schindelin
2015-05-19 16:27 ` Junio C Hamano
2015-05-22 13:48 ` Paul Tan
2015-05-22 14:14 ` Johannes Schindelin
2015-05-22 17:12 ` Stefan Beller
2015-05-18 19:21 ` [PATCH 00/14] Make git-pull a builtin Junio C Hamano
2015-05-30 7:29 ` Paul Tan
2015-05-30 8:00 ` Paul Tan
2015-05-18 19:41 ` Johannes Schindelin
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=xmqqmw11a6yk.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
--cc=pyokagan@gmail.com \
--cc=sbeller@google.com \
--cc=stephen.robin@gmail.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.