summaryrefslogtreecommitdiff
path: root/builtin/mailinfo.c
AgeCommit message (Collapse)AuthorFilesLines
2012-09-25Merge branch 'jc/maint-mailinfo-mime-attr'Libravatar Junio C Hamano1-3/+2
When "git am" is fed an input that has multiple "Content-type: ..." header, it did not grok charset= attribute correctly. * jc/maint-mailinfo-mime-attr: mailinfo: do not concatenate charset= attribute values from mime headers
2012-09-17mailinfo: do not concatenate charset= attribute values from mime headersLibravatar Junio C Hamano1-3/+2
"Content-type: text/plain; charset=UTF-8" header should not appear twice in the input, but it is always better to gracefully deal with such a case. The current code concatenates the value to the values we have seen previously, producing nonsense such as "utf8UTF-8". Instead of concatenating, forget the previous value and use the last value we see. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-14Merge branch 'jc/mailinfo-RE'Libravatar Junio C Hamano1-1/+3
We strip the prefix from "Re: subject" and also from a less common "re: subject", but left even less common "RE: subject" intact. * jc/mailinfo-RE: mailinfo: strip "RE: " prefix
2012-09-09mailinfo: strip "RE: " prefixLibravatar Junio C Hamano1-1/+3
We already strip the more common Re: and re:, and we do not often see RE: from saner MUA, but this prefix does exist and gets used from time to time. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-21commit/commit-tree: correct latin1 to utf-8Libravatar Linus Torvalds1-26/+2
When a line in the message is not a valid utf-8, "git mailinfo" attempts to convert it to utf-8 assuming the input is latin1 (and punt if it does not convert cleanly). Using the same heuristics in "git commit" and "git commit-tree" lets the editor output be in latin1 to make the overall system more consistent. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-16mailinfo: with -b, keep space after [foo]Libravatar Thomas Rast1-1/+10
The logic for the -b mode, where [PATCH] is dropped but [foo] is not, silently ate all spaces after the ]. Fix this by keeping the next isspace() character, if there is any. Being more thorough is pointless, as the later cleanup_space() call will normalize any sequence of whitespace to a single ' '. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-26mailinfo: always clean up rfc822 header foldingLibravatar Jeff King1-1/+1
Without the "-k" option, mailinfo will convert a folded subject header like: Subject: this is a subject that doesn't fit on one line into a single line. With "-k", however, we assumed that these newlines were significant and represented something that the sending side would want us to preserve. For messages created by format-patch, this assumption was broken by a1f6baa (format-patch: wrap long header lines, 2011-02-23). For messages sent by arbitrary MUAs, this was probably never a good assumption to make, as they may have been folding subjects in accordance with rfc822's line length recommendations all along. This patch now joins folded lines with a single whitespace character. This treats header folding purely as a syntactic feature of the transport mechanism, not as something that format-patch is trying to tell us about the original subject. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-04commit: helper methods to reduce redundant blocks of codeLibravatar Pat Notz1-1/+1
* builtin/commit.c: Replace block of code with a one-liner call to logmsg_reencode(). * commit.c: new function for looking up a comit by name * pretty.c: helper methods for getting output encodings Add helpers get_log_output_encoding() and get_commit_output_encoding() that eliminate some messy and duplicate if-blocks. Signed-off-by: Pat Notz <patnotz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-31enums: omit trailing comma for portabilityLibravatar Gary V. Vaughan1-2/+2
Without this patch at least IBM VisualAge C 5.0 (I have 5.0.2) on AIX 5.1 fails to compile git. enum style is inconsistent already, with some enums declared on one line, some over 3 lines with the enum values all on the middle line, sometimes with 1 enum value per line... and independently of that the trailing comma is sometimes present and other times absent, often mixing with/without trailing comma styles in a single file, and sometimes in consecutive enum declarations. Clearly, omitting the comma is the more portable style, and this patch changes all enum declarations to use the portable omitted dangling comma style consistently. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-04Teach mailinfo %< as an alternative scissors markLibravatar Jonathan Nieder1-1/+2
Handle perforations found “in the wild” more robustly by recognizing “%<” as an alternative scissors mark. This feature is only meant to support old habits. Discourage new use of the percent-based version by only documenting the 8< symbol so new users’ perforations can still be recognized by old versions of Git. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-10Merge branch 'lt/deepen-builtin-source'Libravatar Junio C Hamano1-0/+1063
* lt/deepen-builtin-source: Move 'builtin-*' into a 'builtin/' subdirectory Conflicts: Makefile
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLibravatar Linus Torvalds1-0/+1064
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>