On 19 May 2018 at 03:02, Jeff King <peff@xxxxxxxx> wrote: > On Fri, May 18, 2018 at 03:30:44PM -0700, Elijah Newren wrote: > >> > 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). This does poke at the `string` member, but there is precedent for doing that. That also feels much closer to the purpose of a string list than the fiddling with `strdup_strings` that I do in my patch. I'll look into this over the weekend. Thanks for the suggestion. >> 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@xxxxxxxxxxxxxx/ >> ). 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. :) Obviously, I won't be tackling all of that now. I'll just look into making this final patch better and leave any further cleaning up for later. Martin
