From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Lukas Fleischer <git@cryptocrack.de>, git@vger.kernel.org
Subject: Re: [PATCH] blame.c: fix garbled error message
Date: Wed, 14 Jan 2015 15:49:26 -0500 [thread overview]
Message-ID: <20150114204926.GA1155@peff.net> (raw)
In-Reply-To: <xmqqr3uxb7kj.fsf@gitster.dls.corp.google.com>
On Wed, Jan 14, 2015 at 09:22:52AM -0800, Junio C Hamano wrote:
> Lukas Fleischer <git@cryptocrack.de> writes:
>
> >> [1/5]: git-compat-util: add xstrdup_or_null helper
> >> [2/5]: builtin/apply.c: use xstrdup_or_null instead of null_strdup
> >> [3/5]: builtin/commit.c: use xstrdup_or_null instead of envdup
> >> [4/5]: use xstrdup_or_null to replace ternary conditionals
> >> [5/5]: blame.c: fix garbled error message
> >>
> >
> > Looks good to me! I am not sure whether those patches should be built on
> > top of (a fixed version of) my patch, though, which would make
> > backporting the fix to the maintenance branch straightforward. Junio?
>
> We can queue these five on top of 1da1e07c (clean up name allocation
> in prepare_revision_walk, 2014-10-15), which changed the rule of the
> game to break this code, that only is in v2.2 and later.
>
> And the result should merge just fine to 'maint'.
Are we in agreement then that the resulting code with the helper is
actually easier to read? I think replacing the straight ?: lines is, but
I am on the fence on whether:
const char *x = some_fun(...);
return xstrdup_or_null(x);
is better or worse than:
return xstrdup_or_null(some_fun(....));
-Peff
next prev parent reply other threads:[~2015-01-14 20:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-10 21:33 [PATCH] blame.c: fix garbled error message Lukas Fleischer
2015-01-12 19:08 ` Junio C Hamano
2015-01-12 20:40 ` Jeff King
2015-01-12 22:55 ` Junio C Hamano
2015-01-12 23:12 ` Jeff King
2015-01-13 0:11 ` Junio C Hamano
2015-01-13 1:54 ` Jeff King
2015-01-13 1:57 ` [PATCH 1/5] git-compat-util: add xstrdup_or_null helper Jeff King
2015-01-13 2:21 ` Jonathan Nieder
2015-01-13 2:23 ` Jeff King
2015-01-13 1:58 ` [PATCH 2/5] builtin/apply.c: use xstrdup_or_null instead of null_strdup Jeff King
2015-01-13 1:58 ` [PATCH 3/5] builtin/commit.c: use xstrdup_or_null instead of envdup Jeff King
2015-01-13 1:59 ` [PATCH 4/5] use xstrdup_or_null to replace ternary conditionals Jeff King
2015-01-13 1:59 ` [PATCH 5/5] blame.c: fix garbled error message Jeff King
2015-01-14 14:21 ` [PATCH] " Lukas Fleischer
2015-01-14 17:22 ` Junio C Hamano
2015-01-14 20:49 ` Jeff King [this message]
2015-01-14 21:54 ` Junio C Hamano
2015-01-12 23:18 ` Lukas Fleischer
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=20150114204926.GA1155@peff.net \
--to=peff@peff.net \
--cc=git@cryptocrack.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 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).