aboutsummaryrefslogtreecommitdiff
path: root/builtin-mailinfo.c
Commit message (Collapse)AuthorAge
* builtin-mailinfo.c: check error status from rewind and ftruncateJunio C Hamano2009-09-29
| | | | | | | | | | A recent "cut at scissors" implementation rewinds and truncates the output file to store the message when it sees a scissors mark, but it did not check if these library calls succeeded. Signed-off-by: Junio C Hamano <gitster@pobox.com> [sp: Use fseek as rewind returns void] Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* add documentation for mailinfo.scissors and '--no-scissors'Nicolas Sebrecht2009-09-11
| | | | | Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: add '--scissors' to usage messageNicolas Sebrecht2009-09-11
| | | | | Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo.scissors: new configurationJunio C Hamano2009-08-26
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* am/mailinfo: Disable scissors processing by defaultJunio C Hamano2009-08-26
| | | | | | You can enable it by giving --scissors to "git am". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Teach mailinfo to ignore everything before -- >8 -- markJunio C Hamano2009-08-26
| | | | | | | | | This teaches mailinfo the scissors -- >8 -- mark; the command ignores everything before it in the message body. For lefties among us, we also support -- 8< -- ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-mailinfo.c: fix confusing internal API to mailinfo()Junio C Hamano2009-08-26
| | | | | | | | | | It fed two arguments to override the corresponding global variables, but the caller always assigned the values to the global variables first and then passed those global variables to this function. Stop pretending to be a proper API to confuse people. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-mailinfo,builtin-mailsplit: use strbufsBrandon Casey2009-08-05
| | | | | | | | | There should be no functional change. Just the necessary changes and simplifications associated with calling strbuf_getwholeline() rather than an internal function or fgets. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Revert "mailinfo: Remove only one set of square brackets"v1.6.4-rc1Junio C Hamano2009-07-15
| | | | | | | | | | | | This reverts commit 650d30d8a120c8982309ccb9ef40432b4ea2eb74. Some mailing lists are configured add prefix "[listname] " to all their messages, and also people hand-edit subject lines, be it an output from format-patch or a patch generated by some other means. We cannot stop people from mucking with the subject line, and with the change, there always will be need for hand editing the subject when that happens. People have depended on the leading [bracketed string] removal.
* Merge branch 'ae/maint-mailinfo-rm-only-one-patch-marker'Junio C Hamano2009-07-10
|\ | | | | | | | | * ae/maint-mailinfo-rm-only-one-patch-marker: mailinfo: Remove only one set of square brackets
| * mailinfo: Remove only one set of square bracketsAndreas Ericsson2009-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git-format-patch prepends patches with a [PATCH x/n] prefix, but mailinfo used to remove any number of square-bracket pairs and the content between them. This prevents one from using a commit subject like this: [ and ] must be allowed as input Removing the square bracket pair from this rather clumsily constructed subject line loses important information, so we must take care not to. This patch causes the subject stripping to stop after it has encountered one pair of square brackets. One possible downside of this patch is that the patch-handling programs will now fail at removing author-added square-brackets to be removed, such as [RFC][PATCH x/n] However, since format-patch only adds one set of square brackets, this behaviour is quite easily undesrstood and defended while the previous behaviour is not. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | builtin-mailinfo.c: use "ISO8859-1" instead of "latin1" as fallback encodingBrandon Casey2009-05-18
| | | | | | | | | | | | | | | | | | Some platforms do not understand the character encoding "latin1" which is another name for "ISO8859-1". So use "ISO8859-1" instead which all tested platforms understand. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | builtin-mailinfo.c: compare character encodings case insensitivelyBrandon Casey2009-05-18
| | | | | | | | | | | | | | | | | | | | | | | | | | When converting between character encodings, git tests whether the "from" encoding and the "to" encoding have the same name. git should perform this test case insensitively so that e.g. utf-8 is not seen as a different encoding than UTF-8. Additionally, it is not necessary to call tolower() anymore on the encodings extracted from the mail message. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Use 'UTF-8' rather than 'utf-8' everywhere for backward compatibilityBrandon Casey2009-05-18
|/ | | | | | | | Some ancient platforms (Solaris 7, IRIX 6.5) do not understand 'utf-8', but all tested implementations understand 'UTF-8'. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Remove unused assignmentsBenjamin Kramer2009-03-14
| | | | | | | | | | | | | | | | | These variables were always overwritten or the assigned value was unused: builtin-diff-tree.c::cmd_diff_tree(): nr_sha1 builtin-for-each-ref.c::opt_parse_sort(): sort_tail builtin-mailinfo.c::decode_header_bq(): in builtin-shortlog.c::insert_one_record(): len connect.c::git_connect(): path imap-send.c::v_issue_imap_cmd(): n pretty.c::pp_user_info(): filler remote::parse_refspec_internal(): llen Signed-off-by: Benjamin Kramer <benny.kra@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: cleanup extra spaces for complex 'From:'Kirill Smelkov2009-02-01
| | | | | | | | | | | | | | | | | currently for cases like From: A U Thor <a.u.thor@example.com> (Comment) mailinfo extracts the following 'Author:' field: Author: A U Thor (Comment) ^^ which has two extra spaces left in there after removed email part. I think this is wrong so here is a fix. Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ks/maint-mailinfo-folded'Junio C Hamano2009-01-31
|\ | | | | | | | | | | | | | | * ks/maint-mailinfo-folded: mailinfo: tests for RFC2047 examples mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)' mailinfo: 'From:' header should be unfold as well mailinfo: correctly handle multiline 'Subject:' header
| * mailinfo: 'From:' header should be unfold as wellKirill Smelkov2009-01-12
| | | | | | | | | | | | | | | | | | | | At present we do headers unfolding (see RFC822 3.1.1. LONG HEADER FIELDS) for all fields except 'From' (always) and 'Subject' (when keep_subject is set) Not unfolding 'From' is a bug -- see above-mentioned RFC link. Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * mailinfo: correctly handle multiline 'Subject:' headerKirill Smelkov2009-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When native language (RU) is in use, subject header usually contains several parts, e.g. Subject: [Navy-patches] [PATCH] =?utf-8?b?0JjQt9C80LXQvdGR0L0g0YHQv9C40YHQvtC6INC/0LA=?= =?utf-8?b?0LrQtdGC0L7QsiDQvdC10L7QsdGF0L7QtNC40LzRi9GFINC00LvRjyA=?= =?utf-8?b?0YHQsdC+0YDQutC4?= This exposes several bugs in builtin-mailinfo.c: 1. decode_b_segment: do not append explicit NUL -- explicit NUL was preventing correct header construction on parts concatenation via strbuf_addbuf in decode_header_bq. Fixes: -Subject: Изменён список пакетов необходимых для сборки +Subject: Изменён список па Then 2. Do not emit '\n' between "encoded-word" where RFC2046 says that linear white space between them are ignored when displaying. Fixes: -Subject: Изменён список пакетов необходимых для сборки +Subject: Изменён список па кетов необходимых для сборки Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | remove trailing LF in die() messagesAlexander Potashev2009-01-05
|/ | | | | | | | LF at the end of format strings given to die() is redundant because die already adds one on its own. Signed-off-by: Alexander Potashev <aspotashev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: avoid violating strbuf assertionJeff King2008-08-19
| | | | | | | | | | | | | | | | | | | | | | | In handle_from, we calculate the end boundary of a section to remove from a strbuf using strcspn like this: el = strcspn(buf, set_of_end_boundaries); strbuf_remove(&sb, start, el + 1); This works fine if "el" is the offset of the boundary character, meaning we remove up to and including that character. But if the end boundary didn't match (that is, we hit the end of the string as the boundary instead) then we want just "el". Asking for "el+1" caught an out-of-bounds assertion in the strbuf library. This manifested itself when we got a 'From' header that had just an email address with nothing else in it (the end of the string was the end of the address, rather than, e.g., a trailing '>' character), causing git-mailinfo to barf. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: re-fix MIME multipart boundary parsingDon Zickus2008-08-18
| | | | | | | | | | | | | | | | | | Recent changes to is_multipart_boundary() caused git-mailinfo to segfault. The reason was after handling the end of the boundary the code tried to look for another boundary. Because the boundary list was empty, dereferencing the pointer to the top of the boundary caused the program to go boom. The fix is to check to see if the list is empty and if so go on its merry way instead of looking for another boundary. I also fixed a couple of increments and decrements that didn't look correct relating to content_top. The boundary test case was updated to catch future problems like this again. Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: fix MIME multi-part message boundary handlingJunio C Hamano2008-08-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After finding a MIME multi-part message boundary line, the handle_body() function is supposed to first flush any accumulated contents from the previous part to the output stream. However, the code mistakenly output the boundary line it found. The old code that used one global, fixed-length buffer line[] used an alternate static buffer newline[] for keeping track of this accumulated contents and flushed newline[] upon seeing the boundary; when 3b6121f (git-mailinfo: use strbuf's instead of fixed buffers, 2008-07-13) converted a fixed-length buffer in this program to use strbuf,these two buffers were converted to "line" and "prev" (the latter of which now has a much more sensible name) strbufs, but the code mistakenly flushed "line" (which contains the boundary we have just found), instead of "prev". This resulted in the first boundary to be output in front of the first line of the message. The rewritten implementation of handle_boundary() lost the terminating newline; this would then result in the second line of the message to be stuck with the first line. The is_multipart_boundary() was designed to catch both the internal boundary and the terminating one (the one with trailing "--"); this also was broken with the rewrite, and the code in the handle_boundary() to handle the terminating boundary was never triggered. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: better parse email adresses containg parenthesesPhilippe Bruhat (BooK)2008-07-21
| | | | | | | | | | | | | | | | | When using git-rebase, author fields containing a ')' at the last position had the close-parens character removed; the removal should be done only when it is of this form: user@host (User Name) i.e. the remainder after stripping the e-mail address part is enclosed in a parentheses pair as a whole, not for addresses like this: User Name (me) <user@host> Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org> Acked-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: off-by-one fix for [PATCH (foobar)] removal from Subject: lineJunio C Hamano2008-07-16
| | | | | | | | A patch title "[PATCH] 1" was sanitized by the original code by stripping the "[PATCH]" from the front, but after the conversion to use strbuf this behaviour was broken due to a counting error. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ls/mailinfo'Junio C Hamano2008-07-16
|\ | | | | | | | | | | | | | | | | | | * ls/mailinfo: git-mailinfo: use strbuf's instead of fixed buffers Add some useful functions for strbuf manipulation. Make some strbuf_*() struct strbuf arguments const. Conflicts: builtin-mailinfo.c
| * git-mailinfo: use strbuf's instead of fixed buffersLukas Sandström2008-07-13
| | | | | | | | | | Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'sb/dashless'Junio C Hamano2008-07-16
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * sb/dashless: Make usage strings dash-less t/: Use "test_must_fail git" instead of "! git" t/test-lib.sh: exit with small negagive int is ok with test_must_fail Conflicts: builtin-blame.c builtin-mailinfo.c builtin-mailsplit.c builtin-shortlog.c git-am.sh t/t4150-am.sh t/t4200-rerere.sh
| * | Make usage strings dash-lessStephan Beyer2008-07-13
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you misuse a git command, you are shown the usage string. But this is currently shown in the dashed form. So if you just copy what you see, it will not work, when the dashed form is no longer supported. This patch makes git commands show the dash-less version. For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh generates a dash-less usage string now. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-mailinfo: Fix getting the subject from the in-body [PATCH] lineLukas Sandström2008-07-13
| | | | | | | | | | | | | | | | | | | | | | "Subject: " isn't in the static array "header", and thus memcmp("Subject:", header[i], 7) will never match. Even if it did so, hdr_data[] may not have been allocated if there weren't a "Subject: " in-body when we process "[PATCH]" in the affected codepath. Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-mailinfo: document the -n optionLukas Sandström2008-07-11
|/ | | | | Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: feed the correct line length to decode_transfer_encoding()Junio C Hamano2008-07-06
| | | | | | | | | | | | When handling a MIME multipart message, multi-part boundary lines are eaten by a call to handle_boundary() function from the main loop of handle_body(), and after that happens, we should update the line length correctly, because handle_boundary() udpates line[] with new data. This was caused by a thinko in 9aa2309 (mailinfo: apply the same fix not to lose NULs in BASE64 and QP codepaths, 2008-05-25). Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'js/config-cb'v1.5.6-rc0Junio C Hamano2008-05-25
|\ | | | | | | | | | | | | | | | | | | * js/config-cb: Provide git_config with a callback-data parameter Conflicts: builtin-add.c builtin-cat-file.c
| * Provide git_config with a callback-data parameterJohannes Schindelin2008-05-14
| | | | | | | | | | | | | | | | | | | | | | | | git_config() only had a function parameter, but no callback data parameter. This assumes that all callback functions only modify global variables. With this patch, every callback gets a void * parameter, and it is hoped that this will help the libification effort. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | mailinfo: apply the same fix not to lose NULs in BASE64 and QP codepathsJunio C Hamano2008-05-25
| | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | mailsplit and mailinfo: gracefully handle NUL charactersJohannes Schindelin2008-05-25
|/ | | | | | | | | | | | | The function fgets() has a big problem with NUL characters: it reads them, but nobody will know if the NUL comes from the file stream, or was appended at the end of the line. So implement a custom read_line_with_nul() function. Noticed by Tommy Thorn. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 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>
generated by cgit v1.2.1 (git 2.18.0) at 2024-12-27 06:12:51 +0000