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 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).