user/sven/git.git/pretty.c, branch v1.8.0.2

Merge branch 'jc/same-encoding' into maint

2012-12-07T22:10:56Z

Various codepaths checked if two encoding names are the same using ad-hoc code and some of them ended up asking iconv() to convert between "utf8" and "UTF-8". The former is not a valid way to spell the encoding name, but often people use it by mistake, and we equated them in some but not all codepaths. Introduce a new helper function to make these codepaths consistent. * jc/same-encoding: reencode_string(): introduce and use same_encoding()

reencode_string(): introduce and use same_encoding()

2012-11-04T13:10:33Z

Callers of reencode_string() that re-encodes a string from one encoding to another all used ad-hoc way to bypass the case where the input and the output encodings are the same. Some did strcmp(), some did strcasecmp(), yet some others when converting to UTF-8 used is_encoding_utf8(). Introduce same_encoding() helper function to make these callers use the same logic. Notably, is_encoding_utf8() has a work-around for common misconfiguration to use "utf8" to name UTF-8 encoding, which does not match "UTF-8" hence strcasecmp() would not consider the same. Make use of it in this helper function. Signed-off-by: Junio C Hamano

format-patch: fix rfc2047 address encoding with respect to rfc822 specials

2012-10-18T21:24:16Z

According to RFC 2047 and RFC 822, rfc2047 encoded words and and rfc822 quoted strings do not mix. Since add_rfc2047() no longer leaves RFC 822 specials behind, the quoting is also no longer necessary to create a standard-conforming mail. Remove the quoting, when RFC 2047 encoding takes place. This actually requires to refactor add_rfc2047() a bit, so that the different cases can be distinguished. With this patch, my own name gets correctly decoded as Jan H. Schönherr (without quotes) and not as "Jan H. Schönherr" (with quotes). Signed-off-by: Jan H. Schönherr Signed-off-by: Junio C Hamano

format-patch: make rfc2047 encoding more strict

2012-10-18T21:23:34Z

RFC 2047 requires more characters to be encoded than it is currently done. Especially, RFC 2047 distinguishes between allowed remaining characters in encoded words in addresses (From, To, etc.) and other headers, such as Subject. Make add_rfc2047() and is_rfc2047_special() location dependent and include all non-allowed characters to hopefully be RFC 2047 conformant. This especially fixes a problem, where RFC 822 specials (e. g. ".") were left unencoded in addresses, which was solved with a non-standard-conforming workaround in the past (which is going to be removed in a follow-up patch). Signed-off-by: Jan H. Schönherr Signed-off-by: Junio C Hamano

format-patch: introduce helper function last_line_length()

2012-10-18T21:23:29Z

Currently, an open-coded loop to calculate the length of the last line of a string buffer is used in multiple places. Move that code into a function of its own. Signed-off-by: Jan H. Schönherr Signed-off-by: Junio C Hamano

format-patch: do not wrap rfc2047 encoded headers too late

2012-10-18T21:23:19Z

Encoded characters add more than one character at once to an encoded header. Include all characters that are about to be added in the length calculation for wrapping. Additionally, RFC 2047 imposes a maximum line length of 76 characters if that line contains an rfc2047 encoded word. Signed-off-by: Jan H. Schönherr Signed-off-by: Junio C Hamano

format-patch: do not wrap non-rfc2047 headers too early

2012-10-18T21:23:12Z

Do not wrap the second and later lines of non-rfc2047-encoded headers substantially before the 78 character limit. Instead of passing the remaining length of the first line as wrapping width, use the correct maximum length and tell strbuf_add_wrapped_bytes() how many characters of the first line are already used. Signed-off-by: Jan H. Schönherr Signed-off-by: Junio C Hamano

Merge branch 'jk/format-person-part-buffer-limit'

2012-05-25T19:06:16Z

Avoid buffer overflow in format_person_part() function

Merge branch 'jk/pretty-commit-header-incomplete-line'

2012-05-25T19:05:35Z

Fixes error codepath when a malformed commit object has a header line chomped in the middle.

avoid segfault when reading header of malformed commits

2012-05-22T19:53:42Z

If a commit object has a header line at the end of the buffer that is missing its newline (or if it appears so because the content on the header line contains a stray NUL), then git will segfault. Interestingly, this case is explicitly handled and we do correctly scan the final line for the header we are looking for. But if we don't find it, we will dereference NULL while trying to look at the next line. Git will never generate such a commit, but it's good to be defensive. We could die() in such a case, but since it's easy enough to handle it gracefully, let's just issue a warning and continue (so you could still view such a commit with "git show", though you might be missing headers after the NUL). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano