git/pretty.c, branch v1.8.2.2

pretty: handle broken commit headers gracefully

2013-04-17T21:50:36Z

Centralize the parsing of the date and time zone strings in the new helper function show_ident_date() and make sure it checks the pointers provided by split_ident_line() for NULL before use. Reported-by: Ivan Lyapunov Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

Merge branch 'mg/gpg-interface-using-status' into maint

2013-04-03T16:26:27Z

Verification of signed tags were not done correctly when not in C or en/US locale. * mg/gpg-interface-using-status: pretty: make %GK output the signing key for signed commits pretty: parse the gpg status lines rather than the output gpg_interface: allow to request status return log-tree: rely upon the check in the gpg_interface gpg-interface: check good signature in a reliable way

Merge branch 'ks/rfc2047-one-char-at-a-time' into maint

2013-04-03T16:25:29Z

When "format-patch" quoted a non-ascii strings on the header files, it incorrectly applied rfc2047 and chopped a single character in the middle of it. * ks/rfc2047-one-char-at-a-time: format-patch: RFC 2047 says multi-octet character may not be split

format-patch: RFC 2047 says multi-octet character may not be split

2013-03-09T19:11:19Z

Even though an earlier attempt (bafc478..41dd00bad) cleaned up RFC 2047 encoding, pretty.c::add_rfc2047() still decides where to split the output line by going through the input one byte at a time, and potentially splits a character in the middle. A subject line may end up showing like this: ".... fö?? bar". (instead of ".... föö bar".) if split incorrectly. RFC 2047, section 5 (3) explicitly forbids such beaviour Each 'encoded-word' MUST represent an integral number of characters. A multi-octet character may not be split across adjacent 'encoded- word's. that means that e.g. for Subject: .... föö bar encoding Subject: =?UTF-8?q?....=20f=C3=B6=C3=B6?= =?UTF-8?q?=20bar?= is correct, and Subject: =?UTF-8?q?....=20f=C3=B6=C3?= <-- NOTE ö is broken here =?UTF-8?q?=B6=20bar?= is not, because "ö" character UTF-8 encoding C3 B6 is split here across adjacent encoded words. To fix the problem, make the loop grab one _character_ at a time and determine its output length to see where to break the output line. Note that this version only knows about UTF-8, but the logic to grab one character is abstracted out in mbs_chrlen() function to make it possible to extend it to other encodings with the help of iconv in the future. Signed-off-by: Kirill Smelkov Signed-off-by: Junio C Hamano

pretty: make %GK output the signing key for signed commits

2013-02-14T17:30:36Z

In order to employ signed keys in an automated way it is absolutely necessary to check which keys the signatures come from. Signed-off-by: Michael J Gruber Signed-off-by: Junio C Hamano

pretty: parse the gpg status lines rather than the output

2013-02-14T17:30:22Z

Currently, parse_signature_lines() parses the gpg output for strings which depend on LANG so it fails to recognize good commit signatures (and thus does not fill in %G? and the like) in most locales. Make it parse the status lines from gpg instead, which are the proper machine interface. This fixes the problem described above. There is a change in behavior for "%GS" which we intentionally do not work around: "%GS" used to put quotes around the signer's uid (or rather: it inherited from the gpg user output). We output the uid without quotes now, just like author and committer names. Signed-off-by: Michael J Gruber Signed-off-by: Junio C Hamano

gpg_interface: allow to request status return

2013-02-14T17:30:04Z

Currently, verify_signed_buffer() returns the user facing output only. Allow callers to request the status output also. Signed-off-by: Michael J Gruber Signed-off-by: Junio C Hamano

logmsg_reencode: lazily load missing commit buffers

2013-01-26T21:28:22Z

Usually a commit that makes it to logmsg_reencode will have been parsed, and the commit->buffer struct member will be valid. However, some code paths will free commit buffers after having used them (for example, the log traversal machinery will do so to keep memory usage down). Most of the time this is fine; log should only show a commit once, and then exits. However, there are some code paths where this does not work. At least two are known: 1. A commit may be shown as part of a regular ref, and then it may be shown again as part of a submodule diff (e.g., if a repo contains refs to both the superproject and subproject). 2. A notes-cache commit may be shown during "log --all", and then later used to access a textconv cache during a diff. Lazily loading in logmsg_reencode does not necessarily catch all such cases, but it should catch most of them. Users of the commit buffer tend to be either parsing for structure (in which they will call parse_commit, and either we will already have parsed, or we will load commit->buffer lazily there), or outputting (either to the user, or fetching a part of the commit message via format_commit_message). In the latter case, we should always be using logmsg_reencode anyway (and typically we do so via the pretty-print machinery). If there are any cases that this misses, we can fix them up to use logmsg_reencode (or handle them on a case-by-case basis if that is inappropriate). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

logmsg_reencode: never return NULL

2013-01-26T21:28:21Z

The logmsg_reencode function will return the reencoded commit buffer, or NULL if reencoding failed or no reencoding was necessary. Since every caller then ends up checking for NULL and just using the commit's original buffer, anyway, we can be a bit more helpful and just return that buffer when we would have returned NULL. Since the resulting string may or may not need to be freed, we introduce a logmsg_free, which checks whether the buffer came from the commit object or not (callers either implemented the same check already, or kept two separate pointers, one to mark the buffer to be used, and one for the to-be-freed string). Pushing this logic into logmsg_* simplifies the callers, and will let future patches lazily load the commit buffer in a single place. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'ap/log-mailmap'

2013-01-21T01:06:53Z

Teach commands in the "log" family to optionally pay attention to the mailmap. * ap/log-mailmap: log --use-mailmap: optimize for cases without --author/--committer search log: add log.mailmap configuration option log: grep author/committer using mailmap test: add test for --use-mailmap option log: add --use-mailmap option pretty: use mailmap to display username and email mailmap: add mailmap structure to rev_info and pp mailmap: simplify map_user() interface mailmap: remove email copy and length limitation Use split_ident_line to parse author and committer string-list: allow case-insensitive string list