Re: [PATCH v3 3/3] unpack_trees_options: free messages when done

From: Jeff King <peff@peff.net>
Date: May 19, 2018, 01:02 UTC
Message-ID: <20180519010220.GA16071@sigill.intra.peff.net>
In-Reply-To: <CABPp-BFdKFNLHxqt-rbSVPx_cXVG3iyad42qYFbWvP9_2fW2gQ@mail.gmail.com>

On Fri, May 18, 2018 at 03:30:44PM -0700, Elijah Newren wrote:

Show 14 quoted lines

> > would become:
> >
> >   msgs[ERROR_WOULD_OVERWRITE] = msgs[ERROR_NOUPTODATE_FILE] =
> >         string_list_appendf(&opts->msgs_to_free, msg, cmd, cmd)->string;
> >
> > I don't know if that's worth it or not (I suspect that there are other
> > places where appendf would be handy, but I didn't poke around).
> 
> The strdup_strings=1 immediately before calling string_list_clear()
> has been used in one other place in merge-recursive.c, and tripped up
> the reviewer requiring a big code comment to explain it. (See the very
> end of https://public-inbox.org/git/CABPp-BGh7QTTfu3kgH4KO5DrrXiQjtrNhx_uaQsB6fHXT+9hLQ@mail.gmail.com/
> ).  So there's already one other place in merge-recursive.c that might
> benefit from such a change.

Thanks. I knew I had seen such hackery before, but it's nice to have a specific site that would benefit.

IMHO the "nodup" variant of string_list is quite often a sign that things are more complicated than they need to be. Even in cases that are truly pointing to existing strings, is the complication really worth saving a few strdups? Perhaps sometimes, but I have a suspicion it's mostly premature optimization.

> Maybe someone wants to tackle that as a separate patch series?  (Maybe
> we make it a micro-project for future GSoC'ers?)

Yeah, I'm fine with these patches if somebody wants to do it separately. It would be a good micro-project, but I'd also be just as happy if somebody did it before next year. :)

-Peff