summaryrefslogtreecommitdiff
path: root/pretty.c
AgeCommit message (Collapse)AuthorFilesLines
2009-01-06shortlog: handle multi-line subjects like log --pretty=oneline et. al. doLibravatar René Scharfe1-2/+2
The commit message parser of git shortlog used to treat only the first non-empty line of the commit message as the subject. Other log commands (e.g. --pretty=oneline) show the whole first paragraph instead (unwrapped into a single line). For consistency, this patch borrows format_subject() from pretty.c to make shortlog do the same. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-27pretty: support multiline subjects with format:Libravatar René Scharfe1-19/+34
git log --pretty=format:%s (and tformat:) used to display the first line of the subject, unlike the other --pretty options, which would construct a subject line from all lines of the first paragraph of the commit message. For consistency and increased code reuse, change format: to do the same as the other options. Before: $ git log --pretty=oneline v1.6.1 | md5sum 7c0896d2a94fc3315a0372b9b3373a8f - $ git log --pretty=tformat:"%H %s" v1.6.1 | md5sum 298903b1c065002e15daa5329213c51f - After: $ git log --pretty=tformat:"%H %s" v1.6.1 | md5sum 7c0896d2a94fc3315a0372b9b3373a8f - $ git log --pretty=oneline v1.6.1 | md5sum 7c0896d2a94fc3315a0372b9b3373a8f - Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-27pretty: factor out format_subject()Libravatar René Scharfe1-18/+24
The next patch will use it. In the version that was factored out, we can't rely on the len of the struct strbuf to find out if a line separator needs to be added, as it might already contain something. Add a guard variable ("first") instead. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-27pretty: factor out skip_empty_lines()Libravatar René Scharfe1-9/+15
The patch after the next one will use it. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-21builtin-blame: Reencode commit messages according to git-log rules.Libravatar Alexander Gavrilov1-6/+15
Currently git-blame outputs text from the commit messages (e.g. the author name and the summary string) as-is, without even providing any information about the encoding used for the data. It makes interpreting the data in multilingual environment very difficult. This commit changes the blame implementation to recode the messages using the rules used by other commands like git-log. Namely, the target encoding can be specified through the i18n.commitEncoding or i18n.logOutputEncoding options, or directly on the command line using the --encoding parameter. Converting the encoding before output seems to be more friendly to the porcelain tools than simply providing the value of the encoding header, and does not require changing the output format. If anybody needs the old behavior, it is possible to achieve it by specifying --encoding=none. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-12Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializerLibravatar Brandon Casey1-2/+1
Many call sites use strbuf_init(&foo, 0) to initialize local strbuf variable "foo" which has not been accessed since its declaration. These can be replaced with a static initialization using the STRBUF_INIT macro which is just as readable, saves a function call, and takes up fewer lines. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-04add '%d' pretty format specifier to show decorationLibravatar René Scharfe1-0/+21
Add a new format placeholder, %d, which expands to a ref name decoration (think git log --decorate). It expands to an empty string if the commit has no decoration, or otherwise to a comma (and space) separated list of decorations, surrounded by parentheses and a leading space. Michael Dressel implemented an initial version and chose the letter d, Junio suggested to add a leading space and parentheses. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-29pretty=format: respect date format optionsLibravatar Jeff King1-6/+11
When running a command like: git log --pretty=format:%ad --date=short the date option was ignored. This patch causes it to use whatever format was specified by --date (or by --relative-date, etc), just as the non-user formats would do. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-21Rename path_list to string_listLibravatar Johannes Schindelin1-2/+2
The name path_list was correct for the first usage of that data structure, but it really is a general-purpose string list. $ perl -i -pe 's/path-list/string-list/g' $(git grep -l path-list) $ perl -i -pe 's/path_list/string_list/g' $(git grep -l path_list) $ git mv path-list.h string-list.h $ git mv path-list.c string-list.c $ perl -i -pe 's/has_path/has_string/g' $(git grep -l has_path) $ perl -i -pe 's/path/string/g' string-list.[ch] $ git mv Documentation/technical/api-path-list.txt \ Documentation/technical/api-string-list.txt $ perl -i -pe 's/strdup_paths/strdup_strings/g' $(git grep -l strdup_paths) ... and then fix all users of string-list to access the member "string" instead of "path". Documentation/technical/api-string-list.txt needed some rewrapping, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-11Add pretty format %aN which gives the author name, respecting .mailmapLibravatar Johannes Schindelin1-2/+25
The pretty format %an does not respect .mailmap, but gives the exact author name recorded in the commit. Sometimes it is more desirable, however, to look if the email has another name mapped to it in .mailmap. This commit adds %aN (and %cN for the committer name) to do exactly that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25log --pretty: do not accept bogus "--prettyshort"Libravatar Junio C Hamano1-2/+0
... nor bogus "format.pretty = '=short'". Both are syntax errors. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-10log: teach "terminator" vs "separator" mode to "--pretty=format"Libravatar Junio C Hamano1-24/+33
This attached patch introduces a single bit "use_terminator" in "struct rev_info", which is normally false (i.e. most formats use separator semantics) but by flipping it to true, you can ask for terminator semantics just like oneline format does. The function get_commit_format(), which is what parses "--pretty=" option, now takes a pointer to "struct rev_info" and updates its commit_format and use_terminator fields. It used to return the value of type "enum cmit_fmt", but all the callers assigned it to rev->commit_format. There are only two cases the code turns use_terminator on. Obviously, the traditional oneline format (--pretty=oneline) is one of them, and the new case is --pretty=tformat:... that acts like --pretty=format:... but flips the bit on. With this, "--pretty=tformat:%H %s" acts like --pretty=oneline. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-23pretty.c: add %x00 format specifier.Libravatar Govind Salinas1-0/+11
This adds a %xXX format which inserts two hexdigits after %x as a byte value in the resulting string. This can be used to add a NUL byte or any other byte that can make machine parsing easier. It is also necessary to use fwrite to print out the data since printf will terminate if you feed it a NUL. Signed-off-by: Govind Salinas <blix@sophiasuchtig.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-15Merge branch 'maint'Libravatar Junio C Hamano1-13/+11
* maint: format-patch: generate MIME header as needed even when there is format.header
2008-03-15format-patch: generate MIME header as needed even when there is format.headerLibravatar Junio C Hamano1-13/+11
Earlier, the callchain from pretty_print_commit() down to pp_title_line() had an unwarranted assumption that the presense of "after_subject" parameter, means the caller has already output MIME headers for attachments. The parameter's primary purpose is to give extra header lines the caller wants to place after pp_title_line() generates the "Subject: " line. This assumption does not hold when the user used the format.header configuration variable to pass extra headers, and caused a message with non-ASCII character to lack proper MIME headers (e.g. 8-bit CTE header). The earlier logic also failed to suppress duplicated MIME headers when "format-patch -s --attach" is asked for and the signer's name demanded 8-bit clean transport. This patch fixes the logic by introducing a separate need_8bit_cte parameter passed down the callchain. This can have one of these values: -1 : we've already done MIME crap and we do not want to add extra header to say this is 8bit in pp_title_line(); 0 : we haven't done MIME and we have not seen anything that is 8bit yet; 1 : we haven't done MIME and we have seen something that is 8bit; pp_title_line() must add MIME header. It adds two tests by Jeff King who independently diagnosed this issue. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-27Merge branch 'jm/free'Libravatar Junio C Hamano1-2/+1
* jm/free: Avoid unnecessary "if-before-free" tests. Conflicts: builtin-branch.c
2008-02-27Merge branch 'db/cover-letter'Libravatar Junio C Hamano1-16/+16
* db/cover-letter: Improve collection of information for format-patch --cover-letter Add API access to shortlog t4014: Replace sed's non-standard 'Q' by standard 'q' Support a --cc=<email> option in format-patch Combine To: and Cc: headers Fix format.headers not ending with a newline Add tests for extra headers in format-patch Add a --cover-letter option to format-patch Export some email and pretty-printing functions Improve message-id generation flow control for format-patch Add more tests for format-patch Conflicts: builtin-log.c builtin-shortlog.c pretty.c
2008-02-22Avoid unnecessary "if-before-free" tests.Libravatar Jim Meyering1-2/+1
This change removes all obvious useless if-before-free tests. E.g., it replaces code like this: if (some_expression) free (some_expression); with the now-equivalent: free (some_expression); It is equivalent not just because POSIX has required free(NULL) to work for a long time, but simply because it has worked for so long that no reasonable porting target fails the test. Here's some evidence from nearly 1.5 years ago: http://www.winehq.org/pipermail/wine-patches/2006-October/031544.html FYI, the change below was prepared by running the following: git ls-files -z | xargs -0 \ perl -0x3b -pi -e \ 's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*NULL)?\s*\)\s+(free\s*\(\s*\1\s*\))/$2/s' Note however, that it doesn't handle brace-enclosed blocks like "if (x) { free (x); }". But that's ok, since there were none like that in git sources. Beware: if you do use the above snippet, note that it can produce syntactically invalid C code. That happens when the affected "if"-statement has a matching "else". E.g., it would transform this if (x) free (x); else foo (); into this: free (x); else foo (); There were none of those here, either. If you're interested in automating detection of the useless tests, you might like the useless-if-before-free script in gnulib: [it *does* detect brace-enclosed free statements, and has a --name=S option to make it detect free-like functions with different names] http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/useless-if-before-free Addendum: Remove one more (in imap-send.c), spotted by Jean-Luc Herren <jlh@gmx.ch>. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-19Export some email and pretty-printing functionsLibravatar Daniel Barkalow1-17/+17
These will be used for generating the cover letter in addition to the patch emails. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-09Avoid a useless prefix lookup in strbuf_expand()Libravatar Marco Costalba1-95/+73
Currently, the --pretty=format prefix is looked up in a tight loop in strbuf_expand(), if prefix is found it is then used as argument for format_commit_item() that does another search by a switch statement to select the proper operation. Because the switch statement is already able to discard unknown matches we don't need the prefix lookup before to call format_commit_item(). Signed-off-by: Marco Costalba <mcostalba@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-06custom pretty format: tolerate empty e-mail addressLibravatar Junio C Hamano1-4/+12
When e-mail address is empty (e.g. "A U Thor <>"), --pretty=format misparsed the commit header and did not pick up the date field correctly. Noticed by Marco, fixed slightly differently with additional sanity check and with a test. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-26Make "--pretty=format" parser a bit more careful.Libravatar René Scharfe1-1/+3
When a commit message that does not have a terminating LF is read in and the memory that was allocated to read it happens to have a LF immediately after that, the code was not careful and went past the terminating NUL. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-11--format=pretty: avoid calculating expensive expansions twiceLibravatar René Scharfe1-0/+32
As Jeff King remarked, format strings with duplicate placeholders can be slow to expand, because each instance is calculated anew. This patch makes use of the fact that format_commit_message() and its helper functions only ever add stuff to the end of the strbuf. For certain expensive placeholders, store the offset and length of their expansion with the strbuf at the first occurrence. Later they expansion result can simply be copied from there -- no malloc() or strdup() required. These certain placeholders are the abbreviated commit, tree and parent hashes, as the search for a unique abbreviated hash is quite costly. Here are the times for next (best of three runs): $ time git log --pretty=format:%h >/dev/null real 0m0.611s user 0m0.404s sys 0m0.204s $ time git log --pretty=format:%h%h%h%h >/dev/null real 0m1.206s user 0m0.744s sys 0m0.452s And here those with this patch (and the previous two); the speedup of the single placeholder case is just noise: $ time git log --pretty=format:%h >/dev/null real 0m0.608s user 0m0.416s sys 0m0.192s $ time git log --pretty=format:%h%h%h%h >/dev/null real 0m0.639s user 0m0.488s sys 0m0.140s Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-11--pretty=format: parse commit message only onceLibravatar René Scharfe1-42/+82
As Jeff King pointed out, some placeholder expansions are related to each other: the steps to calculate one go most of the way towards calculating the other, too. This patch makes format_commit_message() parse the commit message only once, remembering the position of each item. This speeds up handling of format strings containing multiple placeholders from the set %s, %a*, %c*, %e, %b. Here are the timings for the git version in next. The first one is to estimate the overhead of the caching, the second one is taken from http://svn.tue.mpg.de/tentakel/trunk/tentakel/Makefile as an example of a format string found in the wild. The times are the fastest of three consecutive runs in each case: $ time git log --pretty=format:%e >/dev/null real 0m0.381s user 0m0.340s sys 0m0.024s $ time git log --pretty=format:"* %cd %cn%n%n%s%n%b" >/dev/null real 0m0.623s user 0m0.556s sys 0m0.052s And here the times with this patch: $ time git log --pretty=format:%e >/dev/null real 0m0.385s user 0m0.332s sys 0m0.040s $ time git log --pretty=format:"* %cd %cn%n%n%s%n%b" >/dev/null real 0m0.563s user 0m0.504s sys 0m0.048s Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-09--pretty=format: on-demand format expansionLibravatar René Scharfe1-123/+153
Some of the --pretty=format placeholders expansions are expensive to calculate. This is made worse by the current code's use of interpolate(), which requires _all_ placeholders are to be prepared up front. One way to speed this up is to check which placeholders are present in the format string and to prepare only the expansions that are needed. That still leaves the allocation overhead of interpolate(). Another way is to use a callback based approach together with the strbuf library to keep allocations to a minimum and avoid string copies. That's what this patch does. It introduces a new strbuf function, strbuf_expand(). The function takes a format string, list of placeholder strings, a user supplied function 'fn', and an opaque pointer 'context' to tell 'fn' what thingy to operate on. The function 'fn' is expected to accept a strbuf, a parsed placeholder string and the 'context' pointer, and append the interpolated value for the 'context' thingy, according to the format specified by the placeholder. Thanks to Pierre Habouzit for his suggestion to use strchrnul() and the code surrounding its callsite. And thanks to Junio for most of this commit message. :) Here my measurements of most of Paul Mackerras' test cases that highlighted the performance problem (best of three runs): (master) $ time git log --pretty=oneline >/dev/null real 0m0.390s user 0m0.340s sys 0m0.040s (master) $ time git log --pretty=raw >/dev/null real 0m0.434s user 0m0.408s sys 0m0.016s (master) $ time git log --pretty="format:%H {%P} %ct" >/dev/null real 0m1.347s user 0m0.080s sys 0m1.256s (interp_find_active -- Dscho) $ time ./git log --pretty="format:%H {%P} %ct" >/dev/null real 0m0.694s user 0m0.020s sys 0m0.672s (strbuf_expand -- this patch) $ time ./git log --pretty="format:%H {%P} %ct" >/dev/null real 0m0.395s user 0m0.352s sys 0m0.028s Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05Split off the pretty print stuff into its own fileLibravatar Johannes Schindelin1-0/+723
The file commit.c got quite large, but it does not have to be: the code concerning pretty printing is pretty well contained. In fact, this commit just splits it off into pretty.c, leaving commit.c with just 672 lines. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>