Bert Wesarg venit, vidit, dixit 16.06.2009 09:56: > On Tue, Jun 16, 2009 at 09:39, Michael J Gruber<git@xxxxxxxxxxxxxxxxxxxx> wrote: >> Bert Wesarg venit, vidit, dixit 15.06.2009 22:45: >>> Signed-off-by: Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> >>> >>> --- >>> >>> On Mon, Jun 15, 2009 at 09:49, Michael J Gruber<git@xxxxxxxxxxxxxxxxxxxx> wrote: >>>> Jim Meyering venit, vidit, dixit 14.06.2009 21:46: >>>>> >>>>> * builtin-remote.c (get_one_entry): Use xmalloc, not malloc. >>>> >>>> Learning something new with every patch... Sorry, Junio; thanks, Jim! >>>> >>> One more reason to re-use existing string handling functions. >> >> Well, when we discussed this before v2 I asked for guidance about >> strbuf, esp. regarding the issue of allocating/freeing. > Well, I stopped reading after this question of yours: "But what do > strbufs bring us here?" Well, as I said I was strbuf-agnostic - some questions are really meant to be questions ;) In any case, I've learned from your patch. > >> From your patch >> I infer that "strbuf_detach" is what I was looking for. (And yes, it is >> in the api doc where I overlooked it.) >> >>> builtin-remote.c | 21 ++++++++++----------- >>> 1 files changed, 10 insertions(+), 11 deletions(-) >>> >>> diff --git a/builtin-remote.c b/builtin-remote.c >>> index 709f8a6..31adeaa 100644 >>> --- a/builtin-remote.c >>> +++ b/builtin-remote.c >> >> For whatever reason, your patch does not apply (am) here on top of next >> + Jim's patch. Given the context (xmallocs), it looks like it's against >> something + Jim's patch. OTOH: 709f8a6 show's a get_one_entry with >> mallocs. Did you hand edit the diff? > Its on top of next (d6a466e528119011d512379f7f9dfac26deb7fd9), plus > hand editing s/malloc/xmalloc/g. > Sorry for this. > > Bert Junio will have to deal with it... Michael -- 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