From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Paul Tan <pyokagan@gmail.com>,
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: Tue, 8 Sep 2015 02:18:37 -0400 [thread overview]
Message-ID: <20150908061836.GD26331@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqd1xvbgw3.fsf@gitster.mtv.corp.google.com>
On Sun, Sep 06, 2015 at 10:24:12AM -0700, Junio C Hamano wrote:
> >> + /* 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?
Not really. I think git_committer_info(IDENT_STRICT | IDENT_NO_DATE)
runs the exact same code, with one exception: we would also set the
ident_explicitly_given variables. But nobody in builtin/am.c calls
committer_ident_sufficiently_given(). And if they did, I think the
change would be an improvement.
> >> + 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.
That actually goes double. We know sb.len. The ends_with() function is
built around strip_suffix(), which both operate on strings. But we do
not have ends_with_mem() built around strip_suffix_mem().
But we also know mine.len. Even strip_suffix_mem() assumes the suffix
itself is a string. So what you really want is:
int strip_suffix_mem_mem(const char *buf, size_t *len,
const char *suffix, size_t suffix_len);
and then you can trivially build the existing strip_suffix_mem() around
it, build strip_suffix() around that, and then build ends_with(),
ends_with_mem() and ends_with_mem_mem() around those. And don't forget
strbuf_ends_with(), strbuf_ends_with_mem(), and strbuf_ends_with_strbuf()
:) I am only half tongue in cheek. The proliferation of names is tedious
(and not appropriate for an -rc regression fix), but I do think the
resulting code is a lot more obvious as:
if (strbuf_ends_with_strbuf(&sb, &mine))
...
or even:
if (ends_with_mem_mem(sb->buf, sb->len, mine.buf, mine.len))
...
Of course given that this is run only once per program, and that these
_are_ in fact strings, we can probably not bother to optimize it and
just accept:
if (ends_with(sb->buf, mine.buf))
...
But if you want to go all-out on optimization, I think you can replace
your strcmp with memcmp:
if (mine.len < sb->len &&
!memcmp(mine.buf, sb->buf + sb->len - mine.len, mine.len))
(assuming that memcmp is in fact faster than strcmp).
-Peff
next prev parent reply other threads:[~2015-09-08 6:18 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
2015-09-08 6:18 ` Jeff King [this message]
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=20150908061836.GD26331@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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.