On Wed, Jan 14, 2015 at 09:22:52AM -0800, Junio C Hamano wrote: > Lukas Fleischer <git@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html