xzer <xiaozhu@xxxxxxxxx> writes: > 2011/2/23 Junio C Hamano <gitster@xxxxxxxxx>: >> xzer <xiaozhu@xxxxxxxxx> 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? >> ... 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html