From: Junio C Hamano <gitster@pobox.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: git@vger.kernel.org, Pierre Habouzit <madcoder@debian.org>
Subject: Re: [PATCH 1/4] Improve message-id generation flow control for format-patch
Date: Wed, 06 Feb 2008 12:31:08 -0800 [thread overview]
Message-ID: <7vsl05vncj.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: alpine.LNX.1.00.0802061140360.13593@iabervon.org
Daniel Barkalow <barkalow@iabervon.org> writes:
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> ---
> builtin-log.c | 29 ++++++++++++++---------------
> 1 files changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/builtin-log.c b/builtin-log.c
> index dcc9f81..1f74d66 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -576,16 +576,19 @@ static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids, const cha
> o2->flags = flags2;
> }
>
> -static void gen_message_id(char *dest, unsigned int length, char *base)
> +static void gen_message_id(struct rev_info *info, char *base)
> {
> const char *committer = git_committer_info(IDENT_WARN_ON_NO_NAME);
> const char *email_start = strrchr(committer, '<');
> const char *email_end = strrchr(committer, '>');
> - if(!email_start || !email_end || email_start > email_end - 1)
> + struct strbuf buf;
> + if (!email_start || !email_end || email_start > email_end - 1)
> die("Could not extract email from committer identity.");
> - snprintf(dest, length, "%s.%lu.git.%.*s", base,
> - (unsigned long) time(NULL),
> - (int)(email_end - email_start - 1), email_start + 1);
> + strbuf_init(&buf, 0);
> + strbuf_addf(&buf, "%s.%lu.git.%.*s", base,
> + (unsigned long) time(NULL),
> + (int)(email_end - email_start - 1), email_start + 1);
> + info->message_id = buf.buf;
I wonder how the rule established by b315c5c (strbuf change: be
sure ->buf is never ever NULL) and at the beginning of strbuf.h
applies here. I think the current implementation of strbuf
happens to allow this, and it is very handy. Perhaps the rule
stated there should be loosened and allow copying the buf away
when you know you have stuff in there (i.e. ->buf != slopbuf).
Pierre, what do you think?
What the patch does itself is much nicer than the original.
next prev parent reply other threads:[~2008-02-06 20:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-06 16:43 [PATCH 1/4] Improve message-id generation flow control for format-patch Daniel Barkalow
2008-02-06 20:31 ` Junio C Hamano [this message]
2008-02-06 21:13 ` Pierre Habouzit
2008-02-06 22:10 ` Daniel Barkalow
2008-02-06 22:53 ` Pierre Habouzit
2008-02-06 22:56 ` Pierre Habouzit
2008-02-06 23:01 ` Daniel Barkalow
-- strict thread matches above, loose matches on Subject: below --
2008-02-17 18:35 Daniel Barkalow
2008-02-18 12:41 ` Johannes Schindelin
2008-02-18 17:43 ` Daniel Barkalow
2008-02-18 18:00 ` 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=7vsl05vncj.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=madcoder@debian.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).