- 26 4月, 2013 3 次提交
-
-
由 René Scharfe 提交于
Use namebuf/namelen and mailbuf/maillen directly instead of copying their contents into strbufs first. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 René Scharfe 提交于
Keep namelen unchanged and don't use it to hold a value that we're not interested in anyway -- we can use maillen and the constant part directly instead. This simplifies the code slightly and prepares for the next patch that makes use of the original value of namelen. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 René Scharfe 提交于
Instead of searching for LF and NUL with two strchr() calls use a single strchrnul() call. We don't need to check if the returned pointer is NULL because either we'll find the NUL at the end of line, or the caller forgot to NUL-terminate the string and we'll overrun the buffer in any case. Also we don't need to pass LF or NUL to split_ident_line() as it ignores it anyway. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 4月, 2013 1 次提交
-
-
由 René Scharfe 提交于
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: NIvan Lyapunov <dront78@gmail.com> Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 3月, 2013 1 次提交
-
-
由 Kirill Smelkov 提交于
Even though an earlier attempt (bafc478f..41dd00ba) 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: NKirill Smelkov <kirr@mns.spb.ru> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 2月, 2013 3 次提交
-
-
由 Michael J Gruber 提交于
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: NMichael J Gruber <git@drmicha.warpmail.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael J Gruber 提交于
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: NMichael J Gruber <git@drmicha.warpmail.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael J Gruber 提交于
Currently, verify_signed_buffer() returns the user facing output only. Allow callers to request the status output also. Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 1月, 2013 2 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 1月, 2013 1 次提交
-
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 1月, 2013 2 次提交
-
-
由 Antoine Pelisse 提交于
Use the mailmap information to display the rewritten username and email address in all log commands. Signed-off-by: NAntoine Pelisse <apelisse@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Antoine Pelisse 提交于
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: NAntoine Pelisse <apelisse@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 1月, 2013 1 次提交
-
-
由 Antoine Pelisse 提交于
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: NAntoine Pelisse <apelisse@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 12月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 12月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 04 11月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 19 10月, 2012 5 次提交
-
-
由 Jan H. Schönherr 提交于
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: NJan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jan H. Schönherr 提交于
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: NJan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jan H. Schönherr 提交于
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: NJan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jan H. Schönherr 提交于
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: NJan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jan H. Schönherr 提交于
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: NJan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 10月, 2012 4 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 23 5月, 2012 2 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 5月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 05 5月, 2012 1 次提交
-
-
由 Jeff King 提交于
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 f4ea32f0 (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 8f8f5476 (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 f4ea32f0. 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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 3月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 17 12月, 2011 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 11月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 24 10月, 2011 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 5月, 2011 3 次提交
-
-
由 Jeff King 提交于
In older versions of git, we used rfc822 header folding to indicate that the original subject line had multiple lines in it. But since a1f6baa5 (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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 5月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
This function was introduced in 5b163603 (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: NJunio C Hamano <gitster@pobox.com> Acked-by: NJeff King <peff@peff.net>
-
- 27 4月, 2011 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-