All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Paul Tan <pyokagan@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] am: match --signoff to the original scripted version
Date: Sun, 06 Sep 2015 10:24:12 -0700	[thread overview]
Message-ID: <xmqqd1xvbgw3.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CACRoPnTUzeF=RUVv_0+2Ej422Vh-NH+KpYaKH0VKNmGbuVQ_8g@mail.gmail.com> (Paul Tan's message of "Sun, 6 Sep 2015 17:04:13 +0800")

Paul Tan <pyokagan@gmail.com> writes:

> s/reimplementated/reimplemented/ ?
> s/resulting an/resulting in an/ ?
> s/extra blank/extra blank line/ ?

Thanks.

>> +static void am_signoff(struct strbuf *sb)
>> +{
>
> Hmm, okay, but now we have two similarly named functions am_signoff()
> and am_append_signoff() which both do nearly similar things, the only
> difference being am_signoff() operates on a strbuf while
> am_append_signoff() operates on the "msg" char* field in the am_state,
> which seems a bit iffy to me.

I do recall advising you not to overuse strbuf in am_state, and
specifically not to use strbuf for a field like author_name, and the
criteria to tell why a field should not be a strbuf in am_state is
if the code used its strbuf-ness only because it is initially read
with strbuf_read_file(), but afterwards it is necessary to use the
field as a strbuf because the field is not modified later and is not
passed to a helper function that takes a strbuf.

I think the final code ended up following that piece of advice a bit
too aggressively.  The <msg, msg_len> pair in am_state did need to
be modified with sign-off, and it was done by passing it as a strbuf
to append_signoff() in the code we are fixing here; keeping msg
field that you wrote as a strbuf in the original would have made
am_append_signoff() unnecessary.

But this patch you are commenting on is purely for regression fix,
and I didn't want to change other things like data representation at
the same time.

>> +       /* Does it end with our own sign-off? */
>> +       strbuf_addf(&mine, "\n%s%s\n",
>> +                   sign_off_header,
>> +                   fmt_name(getenv("GIT_COMMITTER_NAME"),
>> +                            getenv("GIT_COMMITTER_EMAIL")));
>
> Maybe use git_committer_info() here?

Perhaps, but I wanted to make sure I am doing the same thing as the
codepath of sequencer.c::append_signoff(), which the original ended
up calling.  git_committer_info() does way more than that, no?

>> +       if (mine.len < sb->len &&
>> +           !strcmp(mine.buf, sb->buf + sb->len - mine.len))
>
> Perhaps use ends_with()?

This caller already _knows_ how long the sb->buf string is; it is
pointless to have ends_with() run strlen() on it.

  reply	other threads:[~2015-09-06 17:24 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-04 23:47 More builtin git-am issues Linus Torvalds
2015-09-04 23:52 ` Linus Torvalds
2015-09-05  0:07   ` Jeff King
2015-09-05  0:36     ` Linus Torvalds
2015-09-05  0:54   ` Junio C Hamano
2015-09-05  1:06     ` Linus Torvalds
2015-09-05  1:23       ` Junio C Hamano
2015-09-05  1:35         ` Linus Torvalds
2015-09-05 16:01           ` Junio C Hamano
2015-09-05  7:30     ` Johannes Sixt
2015-09-05  8:03       ` Jeff King
2015-09-05 16:10         ` Junio C Hamano
2015-09-05 16:32           ` Junio C Hamano
2015-09-05 16:57             ` Junio C Hamano
2015-09-05 19:39           ` Junio C Hamano
2015-09-07 19:27             ` Christian Couder
2015-09-05 15:24       ` Junio C Hamano
2015-09-05 15:34         ` Junio C Hamano
2015-09-05  1:06 ` Junio C Hamano
2015-09-05  1:20   ` Linus Torvalds
2015-09-05  1:24     ` Junio C Hamano
2015-09-06  4:56 ` [PATCH] am: match --signoff to the original scripted version Junio C Hamano
2015-09-06  9:04   ` Paul Tan
2015-09-06 17:24     ` Junio C Hamano [this message]
2015-09-08  6:18       ` Jeff King
2015-09-06 14:21   ` Paul Tan
2015-09-06 17:39     ` Junio C Hamano
2015-09-06 16:16   ` Linus Torvalds
2015-09-08  6:25   ` Jeff King
2015-09-08 18:14     ` Junio C Hamano

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=xmqqd1xvbgw3.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=pyokagan@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /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.