- 09 2月, 2009 1 次提交
-
-
由 Marius Storm-Olsen 提交于
This allows us to augment the repo mailmap file, and to use mailmap files elsewhere than the repository root. Meaning that the entries in mailmap.file will override the entries in "./.mailmap", should they match. Signed-off-by: NMarius Storm-Olsen <marius@trolltech.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 1月, 2009 1 次提交
-
-
由 Jeff King 提交于
Currently, the only colors available to --pretty=format users are red, green, and blue. Rather than expand it with a few new colors, this patch makes the usual config color syntax available, including more colors, backgrounds, and attributes. Because colors are no longer bounded to a single word (e.g., %Cred), this uses a more advanced syntax that features a beginning and end delimiter (but the old syntax still works). So you can now do: git log --pretty=tformat:'%C(yellow)%h%C(reset) %s' to emulate --pretty=oneline, or even git log --pretty=tformat:'%C(cyan magenta bold)%s%C(reset)' if you want to relive the awesomeness of 4-color CGA. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 1月, 2009 1 次提交
-
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 12月, 2008 3 次提交
-
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 René Scharfe 提交于
The patch after the next one will use it. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 10月, 2008 1 次提交
-
-
由 Alexander Gavrilov 提交于
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: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 10月, 2008 1 次提交
-
-
由 Brandon Casey 提交于
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: NBrandon Casey <casey@nrlssc.navy.mil> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 05 9月, 2008 1 次提交
-
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 8月, 2008 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 7月, 2008 1 次提交
-
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 7月, 2008 1 次提交
-
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 5月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
... nor bogus "format.pretty = '=short'". Both are syntax errors. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 4月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 23 3月, 2008 1 次提交
-
-
由 Govind Salinas 提交于
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: NGovind Salinas <blix@sophiasuchtig.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 3月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2008 1 次提交
-
-
由 Jim Meyering 提交于
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: NJim Meyering <meyering@redhat.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 2月, 2008 1 次提交
-
-
由 Daniel Barkalow 提交于
These will be used for generating the cover letter in addition to the patch emails. Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 2月, 2008 1 次提交
-
-
由 Marco Costalba 提交于
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: NMarco Costalba <mcostalba@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 1月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 27 12月, 2007 1 次提交
-
-
由 René Scharfe 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 11 11月, 2007 2 次提交
-
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 11月, 2007 1 次提交
-
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 11月, 2007 1 次提交
-
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 11月, 2007 1 次提交
-
-
由 Linus Torvalds 提交于
.. by not using quite so much indirection. This currently grows the "struct commit" a bit, which could be avoided by using a union for "util" and "indegree" (the topo-sort used to use "util" anyway, so you cannot use them together), but for now the goal of this was to simplify, not optimize. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 02 11月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
When the body of the commit log message contains a non-ASCII character, format-patch correctly emitted the encoding header to mark the resulting message as such. However, if the original message was fully ASCII, the command line switch "-s" was given to add a new sign-off, and the signer's name was not ASCII only, the resulting message would have contained non-ASCII character but was not marked as such. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 10月, 2007 1 次提交
-
-
由 Johannes Schindelin 提交于
Before this patch, clear_commit_marks() recursed for each parent. This could be potentially very expensive in terms of stack space. Probably the only reason that this did not lead to problems is the fact that we typically call clear_commit_marks() after marking a relatively small set of commits. Use (sort of) a tail recursion instead: first recurse on the parents other than the first one, and then continue the loop with the first parent. Noticed by Shawn Pearce. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NLars Hjemli <hjemli@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 29 9月, 2007 1 次提交
-
-
由 Pierre Habouzit 提交于
For that purpose, the ->buf is always initialized with a char * buf living in the strbuf module. It is made a char * so that we can sloppily accept things that perform: sb->buf[0] = '\0', and because you can't pass "" as an initializer for ->buf without making gcc unhappy for very good reasons. strbuf_init/_detach/_grow have been fixed to trust ->alloc and not ->buf anymore. as a consequence strbuf_detach is _mandatory_ to detach a buffer, copying ->buf isn't an option anymore, if ->buf is going to escape from the scope, and eventually be free'd. API changes: * strbuf_setlen now always works, so just make strbuf_reset a convenience macro. * strbuf_detatch takes a size_t* optional argument (meaning it can be NULL) to copy the buffer's len, as it was needed for this refactor to make the code more readable, and working like the callers. Signed-off-by: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 9月, 2007 1 次提交
-
-
由 Michal Vitecek 提交于
This changes the interporate() to replace entries with NULL values by the empty string, and uses it to interpolate missing fields in custom format output used in git-log and friends. It is most useful to avoid <unknown> output from %b format for a commit log message that lack any body text. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 9月, 2007 1 次提交
-
-
由 Pierre Habouzit 提交于
Add strbuf_remove, change strbuf_insert: As both are special cases of strbuf_splice, implement them as such. gcc is able to do the math and generate almost optimal code this way. Add strbuf_swap: Exchange the values of its arguments. Use it in fast-import.c Also fix spacing issues in strbuf.h Signed-off-by: NPierre Habouzit <madcoder@debian.org>
-
- 19 9月, 2007 1 次提交
-
-
由 Pierre Habouzit 提交于
Signed-off-by: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 9月, 2007 2 次提交
-
-
由 Pierre Habouzit 提交于
Careful profiling shows that we spend more time guessing what pattern allocation will have, whereas we can delay it only at the point where add_rfc2047 will be used and don't allocate huge memory area for the many cases where it's not. Signed-off-by: NPierre Habouzit <madcoder@debian.org> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Pierre Habouzit 提交于
* Be more clever in how we search for "encoding ...\n": parse for real instead of the sloppy strstr's. * use strbuf_splice to do the substring replacements. Signed-off-by: NPierre Habouzit <madcoder@debian.org> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 9月, 2007 2 次提交
-
-
由 Pierre Habouzit 提交于
Also remove the "len" parameter, as: (1) it was used as a max boundary, and every caller used ~0u (2) we check for final NUL no matter what, so it doesn't help for speed. As a result most of the pp_* function takes 3 arguments less, and we need a lot less local variables, this makes the code way more readable, and easier to extend if needed. This patch also fixes some spacing and cosmetic issues. This patch also fixes (as a side effect) a memory leak intoruced in builtin-archive.c at commit df4a394f (fmt was xmalloc'ed and not free'd) Signed-off-by: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Pierre Habouzit 提交于
Also fix many off-by-ones and a useless memset. Signed-off-by: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 9月, 2007 1 次提交
-
-
由 Ren,bi(B Scharfe 提交于
Drop the parameter "msg" of format_commit_message() (as it can be inferred from the parameter "commit"), add a parameter "template" in order to avoid accessing the static variable user_format directly and export the result. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 7月, 2007 1 次提交
-
-
由 Marco Costalba 提交于
When a commit message doesn't have encoding information and encoding output is utf-8 (default) then an useless xstrdup() of commit message is done. If we assume most of users live in an utf-8 world, this useless copy is the common case. Performance issue found with KCachegrind. Signed-off-by: NMarco Costalba <mcostalba@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 7月, 2007 2 次提交
-
-
由 Junio C Hamano 提交于
These days, show_date() takes a date_mode parameter to specify the output format, and a separate specialized function for dates in E-mails does not make much sense anymore. This retires show_rfc2822_date() function and make it just another date output format. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Robin Rosenberg 提交于
Support output of full ISO 8601 style dates in e.g. git log and other places that use interpolation for formatting. Signed-off-by: NRobin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-