Subject: Re: [PATCH] git-mailinfo fixes for patch munging

From: Don Zickus <[email-masked]>
Date: Fri, 30 Mar 2007 17:32:10 -0400

On Fri, Mar 30, 2007 at 02:19:42PM -0700, Junio C Hamano wrote:
> Don Zickus <[email-masked]> writes:
> 
> > Don't translate the patch to UTF-8, instead preserve the data as is.  Also
> > allow overwriting the primary mail headers (addresses Linus's concern).  
> >
> > I also revert a test case that was included in the original patch.  Now it
> > makes sense why it was the way it was. :)
> >
> > Cheers,
> > Don
> 
> Thanks.  Sign-off would have been nice.

Doh. Sorry.  Should I repost with fix below?

> This check_header is called from each multi-part boundary with
> overwrite=1, so if you have two parts and you have From: or
> Subject: in the multi-part header (not in-body), wouldn't they
> overwrite what we already have?  That is not desired, I would
> think.

Hmm.  I guess I never thought about that case.  You are right, that check
can be changed to a zero (because the rfc2822 are checked elsewhere).

> > @@ -614,6 +614,7 @@ static int find_boundary(void)
> >  
> >  static int handle_boundary(void)
> >  {
> > +	char newline[]="\n";
> >  again:
> >  	if (!memcmp(line+content_top->boundary_len, "--", 2)) {
> >  		/* we hit an end boundary */
> > @@ -628,7 +629,7 @@ again:
> >  					"can't recover\n");
> >  			exit(1);
> >  		}
> > -		handle_filter("\n");
> > +		handle_filter(newline);
> >  
> >  		/* skip to the next boundary */
> >  		if (!find_boundary())
> 
> These two hunks certainly do not hurt, but why?  Is this about
> the constness of the first parameter to handle_filter() and its
> call chain?

Yeah, I SEGFAULT'd when trying to convert_to_utf8() a fixed string. :-)

Cheers,
Don