Re: [PATCH 1/1] Don't free remote->name after fetch

Keith McGuigan writes: > As an alternative, I could xstrdup each instance where remote->name is > appended, > which would make the string_list a homogenous dup'd list, which we > could then free. Yeah, I think that is the right way to fix it, even though I agree

Re: [PATCH 1/1] Don't free remote->name after fetch

On Mon, Jun 13, 2016 at 08:14:43PM -0400, Keith McGuigan wrote: > Right. The string_list ends up getting (potentially) populated with a > mix of dup'd and borrowed values. I figured it was safer to leak here > (especially as we're on the way out anyway), than free memory that > shouldn't be

Re: [PATCH 1/1] Don't free remote->name after fetch

Right. The string_list ends up getting (potentially) populated with a mix of dup'd and borrowed values. I figured it was safer to leak here (especially as we're on the way out anyway), than free memory that shouldn't be freed. Actually, what motivates this (and I apologize that I didn't say

Re: [PATCH 1/1] Don't free remote->name after fetch

kmcgui...@twopensource.com writes: > From: Keith McGuigan > > The string_list gets populated with the names from the remotes[] array, > which are not dup'd and the list does not own. > > Signed-of-by: Keith McGuigan > --- For names that