On 10/15/2019 3:11 AM, Eric Wong wrote: > Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Eric Wong <e@xxxxxxxxx> writes: >> >>> I just took a brief look, but that appears to leak memory. >>> >>> "hashmap_free(var, 1)" should be replaced with >>> "hashmap_free_entries(var, struct foo, member)" >>> >>> Only "hashmap_free(var, 0)" can become "hashmap_free(var)" >> >> I deliberately avoided merge-time band-aid fixups on this topic and >> ew/hashmap exactly because I was sure that I'd introduce a similar >> bugs by doing so myself. Using evil merges can be a great way to >> help multiple topics polished independently at the same time, but >> when overused, can hide this kind of gotchas quite easily. >> >> A reroll on top of ew/hashmap would be desirable, now that topic is >> ready for 'master'. > > Just to be clear, that reroll should come from Stolee (+Cc-ed), right? > I'll be around to help answer questions, but also pretty busy > with other stuff and I think Stolee knows this API pretty well :> I'm working on the re-roll, yes. I was waiting for ew/hashmap to merge with history that included ds/include-exclude. Now the current 'master' has both, so I can rebase and check everything carefully. v4 should have every commit compile with the new hashmap API. Thanks for pointing out the bugs with the suggested fixups. I'll be careful as I adapt the new API. -Stolee
