summaryrefslogtreecommitdiff
path: root/pretty.c
Commit message (Collapse)AuthorAgeFilesLines
* logmsg_reencode: lazily load missing commit buffersJeff King2013-01-261-8/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* logmsg_reencode: never return NULLJeff King2013-01-261-16/+22
| | | | | | | | | | | | | | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ap/log-mailmap'Junio C Hamano2013-01-201-50/+64
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * pretty: use mailmap to display username and emailAntoine Pelisse2013-01-101-21/+37
| | | | | | | | | | | | | | | | Use the mailmap information to display the rewritten username and email address in all log commands. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * mailmap: simplify map_user() interfaceAntoine Pelisse2013-01-101-22/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simplify map_user(), mostly to avoid copies of string buffers. It also simplifies caller functions. map_user() directly receive pointers and length from the commit buffer as mail and name. If mapping of the user and mail can be done, the pointer is updated to a new location. Lengths are also updated if necessary. The caller of map_user() can then copy the new email and name if necessary. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Use split_ident_line to parse author and committerAntoine Pelisse2013-01-071-14/+21
| | | | | | | | | | | | | | | | | | | | | | Currently blame.c::get_acline(), pretty.c::pp_user_info() and shortlog.c::insert_one_record() are parsing author name, email, time and tz themselves. Use ident.c::split_ident_line() for better code reuse. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'rs/pretty-use-prefixcmp'Junio C Hamano2013-01-181-4/+4
|\ \ | | | | | | | | | | | | * rs/pretty-use-prefixcmp: pretty: use prefixcmp instead of memcmp on NUL-terminated strings
| * | pretty: use prefixcmp instead of memcmp on NUL-terminated stringsRené Scharfe2013-01-141-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | This conversion avoids the need for magic string length numbers in the code. And unlike memcmp(), prefixcmp() is careful to not run over the end of a string. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jc/format-color-auto'Junio C Hamano2013-01-051-3/+10
|\ \ \ | |/ / | | | | | | | | | | | | | | | | | | | | | Introduce "log --format=%C(auto,blue)Foo%C(auto,reset)" that does not color its output when writing to a non-terminal. * jc/format-color-auto: log --format: teach %C(auto,black) to respect color config t6006: clean up whitespace
| * | log --format: teach %C(auto,black) to respect color configJunio C Hamano2012-12-171-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Traditionally, %C(color attr) always emitted the ANSI color sequence; it was up to the scripts that wanted to conditionally color their output to omit %C(...) specifier when they do not want colors. Optionally allow "auto," to be prefixed to the color, so that the output is colored iff we would color regular "log" output (e.g., taking into account color.* and --color command line options). Tests and pretty_context bits by Jeff King <peff@peff.net>. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | Merge branch 'jc/same-encoding' into maintJunio C Hamano2012-12-071-1/+1
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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()
* | \ \ Merge branch 'jc/same-encoding'Junio C Hamano2013-01-031-12/+4
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | Finishing touches to the series to unify "Do we need to reencode between these two encodings?" logic. * jc/same-encoding: format_commit_message(): simplify calls to logmsg_reencode()
| * | | format_commit_message(): simplify calls to logmsg_reencode()Junio C Hamano2012-12-101-12/+4
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | All the other callers of logmsg_reencode() pass return value of get_commit_output_encoding() or get_log_output_encoding(). Teach the function to optionally take NULL as a synonym to "" aka "no conversion requested" so that we can simplify the only remaining calling site. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jc/prettier-pretty-note'Junio C Hamano2012-11-151-18/+4
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Emit the notes attached to the commit in "format-patch --notes" output after three-dashes. * jc/prettier-pretty-note: format-patch: add a blank line between notes and diffstat Doc User-Manual: Patch cover letter, three dashes, and --notes Doc format-patch: clarify --notes use case Doc notes: Include the format-patch --notes option Doc SubmittingPatches: Mention --notes option after "cover letter" Documentation: decribe format-patch --notes format-patch --notes: show notes after three-dashes format-patch: append --signature after notes pretty_print_commit(): do not append notes message pretty: prepare notes message at a centralized place format_note(): simplify API pretty: remove reencode_commit_message()
| * | | pretty_print_commit(): do not append notes messageJunio C Hamano2012-10-171-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only case pretty_print_commit() appends notes message to the log message taken from the commit is when show_log() calls it with the notes_message field set, and the output format is not the userformat (i.e. when substituting "%N"). No other users of this function sets this field in the pretty_print_context, as can be easily verified in the previous step. Hoist the code to append the notes message to the caller. Up to this point, no functionality change is intended. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | pretty: prepare notes message at a centralized placeJunio C Hamano2012-10-171-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of passing a boolean show_notes around, pass an optional string that is to be inserted after the log message proper is shown. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | format_note(): simplify APIJunio C Hamano2012-10-171-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We either stuff the notes message without modification for %N userformat, or format it for human consumption. Using two bits is an overkill that does not benefit anybody. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | pretty: remove reencode_commit_message()Junio C Hamano2012-10-171-11/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function has only two callsites, and is a thin wrapper whose usefulness is dubious. When the caller needs to learn the log output encoding, it should be able to do so by directly calling get_log_output_encoding() and calling the underlying logmsg_reencode() with it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'jc/same-encoding'Junio C Hamano2012-11-151-1/+1
|\ \ \ \ | | |/ / | |/| / | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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() Conflicts: builtin/mailinfo.c
| * | reencode_string(): introduce and use same_encoding()Junio C Hamano2012-11-041-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <gitster@pobox.com>
* | format-patch: fix rfc2047 address encoding with respect to rfc822 specialsJan H. Schönherr2012-10-181-17/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | format-patch: make rfc2047 encoding more strictJan H. Schönherr2012-10-181-8/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | format-patch: introduce helper function last_line_length()Jan H. Schönherr2012-10-181-12/+13
| | | | | | | | | | | | | | | | | | | | 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 <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | format-patch: do not wrap rfc2047 encoded headers too lateJan H. Schönherr2012-10-181-10/+16
| | | | | | | | | | | | | | | | | | | | | | | | 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 <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | format-patch: do not wrap non-rfc2047 headers too earlyJan H. Schönherr2012-10-181-1/+1
|/ | | | | | | | | | | | 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 <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jk/format-person-part-buffer-limit'Junio C Hamano2012-05-251-2/+4
|\ | | | | | | Avoid buffer overflow in format_person_part() function
| * pretty: avoid buffer overflow in format_person_partJeff King2012-05-221-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we parse the name and email from a commit to pretty-print them, we usually can just put the result directly into our strbuf result. However, if we are going to use the mailmap, then we must first copy them into a NUL-terminated buffer to feed to the mailmap machinery. We did so by using strlcpy into a static buffer, but we used it wrong. We fed it the length of the substring we wanted to copy, but never checked that that length was less than the size of the destination buffer. The simplest fix is to just use snprintf to copy the substring properly while still respecting the destination buffer's size. It might seem like replacing the static buffer with a strbuf would help, but we need to feed a static buffer to the mailmap machinery anyway, so there's not much benefit to handling arbitrary sizes. A more ideal solution would be for mailmap to grow an interface that: 1. Takes a pointer and length combination, instead of assuming a NUL-terminated string. 2. Returns a pointer to the mailmap's allocated string, rather than copying it into the buffer. Then we could avoid the need for an extra buffer entirely. However, doing this would involve a lot of refactoring of mailmap and of string_list (which mailmap uses to store the map itself). For now, let's do the simplest thing to fix the bug. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/pretty-commit-header-incomplete-line'Junio C Hamano2012-05-251-1/+4
|\ \ | | | | | | | | | | | | Fixes error codepath when a malformed commit object has a header line chomped in the middle.
| * | avoid segfault when reading header of malformed commitsJeff King2012-05-221-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jk/maint-reflog-walk-count-vs-time'Junio C Hamano2012-05-111-0/+1
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gives a better DWIM behaviour for --pretty=format:%gd, "stash list", and "log -g", depending on how the starting point ("master" vs "master@{0}" vs "master@{now}") and date formatting options (e.g. "--date=iso") are given on the command line. By Jeff King (4) and Junio C Hamano (1) * jk/maint-reflog-walk-count-vs-time: reflog-walk: tell explicit --date=default from not having --date at all reflog-walk: always make HEAD@{0} show indexed selectors reflog-walk: clean up "flag" field of commit_reflog struct log: respect date_mode_explicit with --format:%gd t1411: add more selector index/date tests
| * | reflog-walk: tell explicit --date=default from not having --date at allJunio C Hamano2012-05-071-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Introduction of opt->date_mode_explicit was a step in the right direction, but lost that crucial bit at the very end of the callchain, and the callee could not tell an explicitly specified "I want *date* but in default format" from the built-in default value passed when there was no --date specified. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | log: respect date_mode_explicit with --format:%gdJeff King2012-05-041-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we show a reflog selector (e.g., via "git log -g"), we perform some DWIM magic: while we normally show the entry's index (e.g., HEAD@{1}), if the user has given us a date with "--date", then we show a date-based select (e.g., HEAD@{yesterday}). However, we don't want to trigger this magic if the alternate date format we got was from the "log.date" configuration; that is not sufficiently strong context for us to invoke this particular magic. To fix this, commit f4ea32f (improve reflog date/number heuristic, 2009-09-24) introduced a "date_mode_explicit" flag in rev_info. This flag is set only when we see a "--date" option on the command line, and we a vanilla date to the reflog code if the date was not explicit. Later, commit 8f8f547 (Introduce new pretty formats %g[sdD] for reflog information, 2009-10-19) added another way to show selectors, and it did not respect the date_mode_explicit flag from f4ea32f. This patch propagates the date_mode_explicit flag to the pretty-print code, which can then use it to pass the appropriate date field to the reflog code. This brings the behavior of "%gd" in line with the other formats, and means that its output is independent of any user configuration. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | ident.c: add split_ident_line() to parse formatted ident lineJunio C Hamano2012-03-111-44/+20
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | The commit formatting logic format_person_part() in pretty.c implements the logic to split an author/committer ident line into its parts, intermixed with logic to compute its output using these piece it computes. Separate the former out to a helper function split_ident_line() so that other codepath can use the same logic, and rewrite the function using the helper function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jc/show-sig'Junio C Hamano2012-01-061-0/+86
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jc/show-sig: log --show-signature: reword the common two-head merge case log-tree: show mergetag in log --show-signature output log-tree.c: small refactor in show_signature() commit --amend -S: strip existing gpgsig headers verify_signed_buffer: fix stale comment gpg-interface: allow use of a custom GPG binary pretty: %G[?GS] placeholders test "commit -S" and "log --show-signature" log: --show-signature commit: teach --gpg-sign option Conflicts: builtin/commit-tree.c builtin/commit.c builtin/merge.c notes-cache.c pretty.c
| * | pretty: %G[?GS] placeholdersJunio C Hamano2011-11-121-0/+86
| |/ | | | | | | | | | | | | | | | | | | Add new placeholders related to the GPG signature on signed commits. - %GG to show the raw verification message from GPG; - %G? to show either "G" for Good, "B" for Bad; - %GS to show the name of the signer. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | pretty: give placeholders to reflog identityjk/pretty-reglog-entJeff King2011-12-161-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | When doing a reflog walk, you can get some information about the reflog (such as the subject line), but not the identity information (i.e., name and email). Let's make those available, mimicing the options for author and committer identity. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'nd/pretty-commit-log-message'Junio C Hamano2011-11-011-4/+6
|\ \ | |/ |/| | | | | | | * nd/pretty-commit-log-message: pretty.c: use original commit message if reencoding fails pretty.c: free get_header() return value
| * pretty.c: use original commit message if reencoding failsnd/pretty-commit-log-messageNguyễn Thái Ngọc Duy2011-10-231-1/+4
| | | | | | | | | | Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * pretty.c: free get_header() return valueNguyễn Thái Ngọc Duy2011-10-231-4/+3
| | | | | | | | | | Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/format-patch-am'Junio C Hamano2011-05-311-52/+55
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jk/format-patch-am: format-patch: preserve subject newlines with -k clean up calling conventions for pretty.c functions pretty: add pp_commit_easy function for simple callers mailinfo: always clean up rfc822 header folding t: test subject handling in format-patch / am pipeline Conflicts: builtin/branch.c builtin/log.c commit.h
| * | format-patch: preserve subject newlines with -kJeff King2011-05-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In older versions of git, we used rfc822 header folding to indicate that the original subject line had multiple lines in it. But since a1f6baa (format-patch: wrap long header lines, 2011-02-23), we now use header folding whenever there is a long line. This means that "git am" cannot trust header folding as a sign from format-patch that newlines should be preserved. Instead, format-patch needs to signal more explicitly that the newlines are significant. This patch does so by rfc2047-encoding the newlines in the subject line. No changes are needed on the "git am" end; it already decodes the newlines properly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | clean up calling conventions for pretty.c functionsJeff King2011-05-261-52/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a pretty_print_context representing the parameters for a pretty-print session, but we did not use it uniformly. As a result, functions kept growing more and more arguments. Let's clean this up in a few ways: 1. All pretty-print pp_* functions now take a context. This lets us reduce the number of arguments to these functions, since we were just passing around the context values separately. 2. The context argument now has a cmit_fmt field, which was passed around separately. That's one less argument per function. 3. The context argument always comes first, which makes calling a little more uniform. This drops lines from some callers, and adds lines in a few places (because we need an extra line to set the context's fmt field). Overall, we don't save many lines, but the lines that are there are a lot simpler and more readable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | pretty: add pp_commit_easy function for simple callersJeff King2011-05-261-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many callers don't actually care about the pretty print context at all; let's just give them a simple way of pretty-printing a commit without having to create a context struct. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jc/fmt-req-fix'Junio C Hamano2011-05-301-1/+1
|\ \ \ | | | | | | | | | | | | | | | | * jc/fmt-req-fix: userformat_find_requirements(): find requirement for the correct format
| * | | userformat_find_requirements(): find requirement for the correct formatJunio C Hamano2011-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function was introduced in 5b16360 (pretty: Initialize notes if %N is used, 2010-04-13) to check what kind of information the "log --format=..." user format string wants. The function can be passed a NULL instead of a format string to ask it to check user_format variable kept by an earlier call to save_user_format(). But it unconditionally checked user_format and not the string it was given. The only caller introduced by the change passes NULL, which kept the bug unnoticed, until a new GCC noticed that there is an assignment to fmt that is never used. Noticed-by: Chris Wilson's compiler Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Jeff King <peff@peff.net>
| * | | Merge branch 'jk/format-patch-quote-special-in-from' into maintJunio C Hamano2011-05-151-1/+60
| |\ \ \ | | | | | | | | | | | | | | | | | | | | * jk/format-patch-quote-special-in-from: pretty: quote rfc822 specials in email addresses
* | \ \ \ Merge branch 'jk/format-patch-quote-special-in-from'Junio C Hamano2011-05-061-1/+60
|\ \ \ \ \ | | |/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jk/format-patch-quote-special-in-from: pretty: quote rfc822 specials in email addresses Conflicts: pretty.c t/t4014-format-patch.sh
| * | | | pretty: quote rfc822 specials in email addressesJeff King2011-04-261-1/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If somebody has a name that includes an rfc822 special, we will output it literally in the "From:" header. This is usually OK, but certain characters (like ".") are supposed to be enclosed in double-quotes in a mail header. In practice, whether this matters may depend on your MUA. Some MUAs will happily take in: From: Foo B. Bar <author@example.com> without quotes, and properly quote the "." when they send the actual mail. Others may not, or may screw up harder things like: From: Foo "The Baz" Bar <author@example.com> For example, mutt will strip the quotes, thinking they are actual syntactic rfc822 quotes. So let's quote properly, and then (if necessary) we still apply rfc2047 encoding on top of that, which should make all MUAs happy. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'jk/format-patch-multiline-header'Junio C Hamano2011-05-041-0/+9
|\ \ \ \ \ | |_|/ / / |/| | / / | | |/ / | |/| | * jk/format-patch-multiline-header: format-patch: wrap email addresses after long names
| * | | format-patch: wrap email addresses after long namesJeff King2011-04-141-0/+9
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already wrap names in "from" headers, which tend to be the long part of an address. But it's also possible for a long name to not be wrapped, but to make us want to wrap the email address. For example (imagine for the sake of readability we want to wrap at 50 characters instead of 78): From: this is my really long git name <foo@example.com> The name does not overflow the line, but the name and email together do. So we would rather see: From: this is my really long git name <git@example.com> Because we wrap the name separately during add_rfc2047, we neglected this case. Instead, we should see how long the final line of the wrapped name ended up, and decide whether or not to wrap based on that. We can't break the address into multiple parts, so we either leave it with the name, or put it by itself on a line. Test by Erik Faye-Lund. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
View Lorry Controller Status