aboutsummaryrefslogtreecommitdiff
path: root/builtin-mailinfo.c
Commit message (Collapse)AuthorAge
* mailinfo: feed only one line to handle_filter() for QP inputJay Soffian2008-02-15
| | | | | | | | | | | | | | The function is intended to be fed one logical line at a time to inspect, but a QP encoded raw input line can have more than one lines, just like BASE64 encoded one. Quoting LF as =0A may be unusual but RFC2045 allows it. The issue was noticed and fixed by Jay Soffian. JC added a test to protect the fix from regressing later. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Make mailsplit and mailinfo strip whitespace from the start of the inputSimon Sasburg2007-11-02
| | | | | Signed-off-by: Simon Sasburg <Simon.Sasburg@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Improved const correctness for stringsShawn O. Pearce2007-10-21
| | | | Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Temporary fix for stack smashing in mailinfoAlex Riesen2007-08-30
| | | | | Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rebase: try not to munge commit log messageJunio C Hamano2007-07-29
| | | | | | | | | | | | | | | | | | | This makes rebase/am keep the original commit log message better, even when it does not conform to "single line paragraph to say what it does, then explain and defend why it is a good change in later paragraphs" convention. This change is a two-edged sword. While the earlier behaviour would make such commit log messages more friendly to readers who expect to get the birds-eye view with oneline summary formats, users who primarily use git as a way to interact with foreign SCM systems would not care much about the convenience of oneline git log tools, but care more about preserving their own convention. This changes their commits less useful to readers who read them with git tools while keeping them more consistent with the foreign SCM systems they interact with. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: fix 'fatal: cannot convert from utf-8 to utf-8'Johannes Schindelin2007-07-23
| | | | | | | | | For some reason, I got this error message. Maybe it does not make sense, but then we should not really try to convert the text when it is not necessary. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Do a better job at guessing unknown character setsLinus Torvalds2007-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least in the kernel development community, we're generally slowly converting to UTF-8 everywhere, and the old default of Latin1 in emails is being supplanted by UTF-8, and it doesn't necessarily show up as such in the mail headers (because, quite frankly, when people send patches around, they want the email client to do as little as humanly possible about the patch) Despite that, it's often the case that email addresses etc still have Latin1, so I've seen emails where this is a mixed bag, with Signed-off parts being copied from email (and containing Latin1 characters), and the rest of the email being a patch in UTF-8. So this suggests a very natural change: if the target character set is utf-8 (the default), and if the source already looks like utf-8, just assume that it doesn't need any conversion at all. Only assume that it needs conversion if it isn't already valid utf-8, in which case we (for historical reasons) will assume it's Latin1. Basically no really _valid_ latin1 will ever look like utf-8, so while this changes our historical behaviour, it doesn't do so in practice, and makes the default behaviour saner for the case where the input was already in proper format. We could do a more fancy guess, of course, but this correctly handled a series of patches I just got from Andrew that had a mixture of Latin1 and UTF-8 (in different emails, but without any character set indication). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* More missing staticJunio C Hamano2007-06-08
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-mailinfo fixes for patch mungingDon Zickus2007-03-31
| | | | | | | | | | | | | Don't translate the patch to UTF-8, instead preserve the data as is. This also reverts a test case that was included in the original patch series. Also allow overwriting the authorship and title information we gather from RFC2822 mail headers with additional in-body headers, which was pointed out by Linus. Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* restrict the patch filteringDon Zickus2007-03-12
| | | | | | | | | | | I have come across many emails that use long strings of '-'s as separators for ideas. This patch below limits the separator to only 3 '-', with the intent that long string of '-'s will stay in the commit msg and not in the patch file. Signed-off-by: Don Zickus <dzickus@redhat.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* builtin-mailinfo.c infrastrcture changesDon Zickus2007-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I am working on a project that required parsing through regular mboxes that didn't necessarily have patches embedded in them. I started by creating my own modified copy of git-am and working from there. Very quickly, I noticed git-mailinfo wasn't able to handle a big chunk of my email. After hacking up numerous solutions and running into more limitations, I decided it was just easier to rewrite a big chunk of it. The following patch has a bunch of fixes and features that I needed in order for me do what I wanted. Note: I'm didn't follow any email rfc papers but I don't think any of the changes I did required much knowledge (besides the boundary stuff). List of major changes/fixes: - can't create empty patch files fix - empty patch files don't fail, this failure will come inside git-am - multipart boundaries are now handled - only output inbody headers if a patch exists otherwise assume those headers are part of the reply and instead output the original headers - decode and filter base64 patches correctly - various other accidental fixes I believe I didn't break any existing functionality or compatibility (other than what I describe above, which is really only the empty patch file). I tested this through various mailing list archives and everything seemed to parse correctly (a couple thousand emails). [jc: squashed in another patch from Don's five patch series to fix the test case, as this patch exposes the bug in the test.] Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* General const correctness fixesShawn O. Pearce2007-03-07
| | | | | | | | | | | | | | | | We shouldn't attempt to assign constant strings into char*, as the string is not writable at runtime. Likewise we should always be treating unsigned values as unsigned values, not as signed values. Most of these are very straightforward. The only exception is the (unnecessary) xstrdup/free in builtin-branch.c for the detached head case. Since this is a user-level interactive type program and that particular code path is executed no more than once, I feel that the extra xstrdup call is well worth the easy elimination of this warning. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'maint'Junio C Hamano2007-02-27
|\ | | | | | | | | | | | | * maint: git-apply: do not fix whitespaces on context lines. diff --cc: integer overflow given a 2GB-or-larger file mailinfo: do not get confused with logical lines that are too long.
| * mailinfo: do not get confused with logical lines that are too long.Linus Torvalds2007-02-27
| | | | | | | | | | | | | | | | | | | | | | | | | | It basically considers all the continuation lines to be lines of their own, and if the total line is bigger than what we can fit in it, we just truncate the result rather than stop in the middle and then get confused when we try to parse the "next" line (which is just the remainder of the first line). [jc: added test, and tightened boundary a bit per list discussion.] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Mechanical conversion to use prefixcmp()Junio C Hamano2007-02-20
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | This mechanically converts strncmp() to use prefixcmp(), but only when the parameters match specific patterns, so that they can be verified easily. Leftover from this will be fixed in a separate step, including idiotic conversions like if (!strncmp("foo", arg, 3)) => if (!(-prefixcmp(arg, "foo"))) This was done by using this script in px.perl #!/usr/bin/perl -i.bak -p if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) { s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|; } if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) { s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|; } and running: $ git grep -l strncmp -- '*.c' | xargs perl px.perl Signed-off-by: Junio C Hamano <junkio@cox.net>
* -u is now default for 'git-mailinfo'.Junio C Hamano2007-01-09
| | | | | | | Originally from David Woodhouse, but also adjusts the callers of mailinfo to the new default. Signed-off-by: Junio C Hamano <junkio@cox.net>
* UTF-8: introduce i18n.logoutputencoding.Junio C Hamano2006-12-27
| | | | | | | | | | | | | | | | It is plausible for somebody to want to view the commit log in a different encoding from i18n.commitencoding -- the project's policy may be UTF-8 and the user may be using a commit message hook to run iconv to conform to that policy (and either not have i18n.commitencoding to default to UTF-8 or have it explicitly set to UTF-8). Even then, Latin-1 may be more convenient for the usual pager and the terminal the user uses. The new variable i18n.logoutputencoding is used in preference to i18n.commitencoding to decide what encoding to recode the log output in when git-log and friends formats the commit log message. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Move encoding conversion routine out of mailinfo to utf8.cJunio C Hamano2006-12-26
| | | | | | | This moves the body of convert_to_utf8() routine used in mailinfo to the utf8.c i18n library. Signed-off-by: Junio C Hamano <junkio@cox.net>
* simplify inclusion of system header files.Junio C Hamano2006-12-20
| | | | | | | | | | | | | | | | | | | | This is a mechanical clean-up of the way *.c files include system header files. (1) sources under compat/, platform sha-1 implementations, and xdelta code are exempt from the following rules; (2) the first #include must be "git-compat-util.h" or one of our own header file that includes it first (e.g. config.h, builtin.h, pkt-line.h); (3) system headers that are included in "git-compat-util.h" need not be included in individual C source files. (4) "git-compat-util.h" does not have to include subsystem specific header files (e.g. expat.h). Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make hexval() available to others.Junio C Hamano2006-09-20
| | | | | | | builtin-mailinfo.c has its own hexval implementaiton but it can share the table-lookup one recently implemented in sha1_file.c Signed-off-by: Junio C Hamano <junkio@cox.net>
* remove unnecessary initializationsDavid Rientjes2006-08-15
| | | | | | | | [jc: I needed to hand merge the changes to the updated codebase, so the result needs to be checked.] Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Call setup_git_directory() much earlierLinus Torvalds2006-07-29
| | | | | | | | | This changes the calling convention of built-in commands and passes the "prefix" (i.e. pathname of $PWD relative to the project root level) down to them. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* mailinfo: accept >From in message headerMichael S. Tsirkin2006-07-27
| | | | | | | | | | | | | | | | | Mail I get sometimes has multiple From lines, like this: From Majordomo@vger.kernel.org Thu Jul 27 16:39:36 2006 >From mtsirkin Thu Jul 27 16:39:36 2006 Received: from yok.mtl.com [10.0.8.11] ... which confuses git-mailinfo since that does not recognize >From as a valid header line. This patch makes it recognize >From XXX as a valid header line. Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Junio C Hamano <junkio@cox.net>
* mailinfo: assume input is latin-1 on the header as we do for the bodyJunio C Hamano2006-07-06
| | | | | | | | | | | When the input mbox does not identify what encoding it is in, and already have RFC2047 stripped away, we cannot tell what encoding the header text is in. For body text, when the message does not say what charset it is in, we fall back to assume latin-1 input when converting to utf8. This should be done consistently to the header as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make some strings constTimo Hirvonen2006-06-28
| | | | | Signed-off-by: Timo Hirvonen <tihirvon@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make git-mailinfo a builtinLukas Sandström2006-06-18
[jc: with a bit of constness tightening] Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>