Re: [PATCH] generate a valid rfc2047 mail header for multi-line subject.
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 23, 2011, 17:45 UTC
- Message-ID
- <7v8vx6abm7.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <AANLkTinf6P-erY-9p5WPWbK+uAf1hozvAutV0zPSpHGQ@mail.gmail.com>
xzer <xiaozhu@gmail.com> writes:
Show 16 quoted lines
> 2011/2/23 Junio C Hamano <gitster@pobox.com>: >> xzer <xiaozhu@gmail.com> writes: >> >>> Subject: Re: [PATCH] generate a valid rfc2047 mail header for multi-line subject. >> >> We prefer to have "[PATCH] subsystem: description without final full-stop" here. >> >>> There is still a problem that git-am will lost the line break. >> >> What does "still" refer to? It is unclear under what condition the >> command lose "the line break" (nor which line break you are refering to; I >> am guessing that you have a commit that begins with a multi-line paragraph >> and you are talking about line breaks between the lines in the first >> paragraph). > > Yes, that is what I am refering, the line breaks in the first paragraph.
Hmm, I gave a suggestion and asked three questions, and only get one answer back?
Show 7 quoted lines
>> ... After all we know in this static function that >> the caller is feeding the contents from a strbuf, which always have a >> terminating NUL (and that is why it is Ok that get_one_line() is not a >> counted string interface). > > I am not sure that who will call this function in future, I think since there is > a argument as len, so I'd better to obey the function declare.
If that is the case I would have preferred to see you give get_one_line() that is a function static to this file an ability to read from a counted string, instead of making an extra allcation. But I think you will notice that all the callchain that pass a pointer into the message around knows and relies on the fact that the buffer is NUL terminated if you look around in the file, and that was why I made that suggestion.