{"thread":{"id":"11655","subject":"[BUG] git send-email brakes patches with very long lines","startedAt":"2008-01-17T10:10:28Z","lastAt":"2008-01-21T10:21:35Z","messageCount":24,"participants":["Adam Piatyszek","Jeff King","Adam Piątyszek","Johannes Sixt","Junio C Hamano","Jay Soffian"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"65705","messageId":"478F2994.9080708@users.sourceforge.net","threadId":"11655","inReplyTo":null,"subject":"[BUG] git send-email brakes patches with very long lines","fromName":"Adam Piatyszek","fromEmail":"ediap@users.sourceforge.net","sentAt":"2008-01-17T10:10:28Z","receivedAt":"2008-01-17T10:10:28Z","isPatch":false,"sender":{"key":"ediap@users.sourceforge.net","avatar":null},"body":"Hi Giters,\n\nI suspect that \"git send-email\" has problems with sending patches with \nvery long lines.\n\nPlease find the attached two emails, which show this problem. The \noriginal file (0001-Add-Dolph-Chebyshev-window.patch) was produced with \n\"git format-patch\" from one of my private Git repositories. The other \nfile (0001-Add-Dolph-Chebyshev-window-sent.patch) includes the same \npatch but sent with \"git send-email\". The problem is with the last hunk, \nwhich is somehow broken by the \"git send-email\" tool. The very long \nlines are wrapped and some exclamation marks are inserted.\n\nThe result of applying such a broken patch in my repository is as follows:\n\n===== >8 =====\nediap@lespaul ~/git/itpp $ git am 0001-Add-Dolph-Chebyshev-window-sent.patch\nApplying Add Dolph Chebyshev window.\nfatal: corrupt patch at line 126\nPatch failed at 0001.\nWhen you have resolved this problem run \"git-am --resolved\".\nIf you would prefer to skip this patch, instead run \"git-am --skip\".\n===== >8 =====\n\nIf I send the same patch with mutt inlined or attached, the patch is not \nbroken and applies cleanly.\n\nThis problem was observed for the following git versions:\n- 1.5.3.8\n- 1.5.4.rc3.4.g1633\n\nBR,\n/Adam\n\n\nPS. Email and IP addresses have been removed from the attached patches.\n\n-- \n.:.  Adam Piatyszek (ediap)  .:.....................................:.\n.:.  ediap@users.sourceforge.net  .:................................:.\n\n\nFrom 171043d6daec26ede0c4d6584d7a70eea214f0fe Mon Sep 17 00:00:00 2001\nFrom: K <email@example.com>\nDate: Tue, 15 Jan 2008 22:52:14 +0530\nSubject: [PATCH] Add Dolph Chebyshev window.\n\nAdd the chebwin function to evaluate the coefficients of the\nDolph-Chebyshev Window, with tests.\n\nThe tests check the values output by the Dolph-Chebyshev window\nfunction for lengths 32 and 33 for 50 dB suppression and for lengths\n127 and 128 at 25 dB suppression.\n\nSigned-off-by: K <email@example.com>\n---\n itpp/signal/window.cpp |   39 ++++++++++++++++++++++++++++++++++++++-\n itpp/signal/window.h   |   18 ++++++++++++++++++\n tests/window_test.cpp  |    5 +++++\n tests/window_test.ref  |    4 ++++\n 4 files changed, 65 insertions(+), 1 deletions(-)\n\ndiff --git a/itpp/signal/window.cpp b/itpp/signal/window.cpp\nindex 0bf4be5..cfe27a8 100644\n--- a/itpp/signal/window.cpp\n+++ b/itpp/signal/window.cpp\n@@ -27,7 +27,12 @@\n  */\n \n #include <itpp/signal/window.h>\n-\n+#include <itpp/signal/poly.h>\n+#include <itpp/base/specmat.h>\n+#include <itpp/base/converters.h>\n+#include <itpp/base/math/trig_hyp.h>\n+#include <itpp/signal/transforms.h>\n+#include <itpp/base/operators.h>\n \n namespace itpp {\n \n@@ -106,6 +111,38 @@ namespace itpp {\n     return t;\n   }\n \n+  vec chebwin(int n, double at)\n+  {\n+    it_assert((n > 0), \"chebwin(): need a positive order n!\");\n+    if (n == 1) {\n+      return vec(\"1\");\n+    }\n+\n+    at = at < 0 ? -at : at;\n+    // compute the parameter beta\n+    double beta = std::cosh(::acosh(pow10(at/20.)) / (n-1));\n+    vec k = (pi / n) * linspace(0, n - 1, n);\n+    vec cos_k = cos(k);\n+    // find the window's DFT coefficients\n+    vec p = cheb(n - 1, beta * cos_k);\n+\n+    // Appropriate IDFT and filling up\n+    // depending on even/odd n\n+    vec w; // the window vector.\n+    if (is_even(n)) {\n+      w = ifft_real(to_cvec(elem_mult(p, cos_k), elem_mult(p,-sin(k))));\n+      int half_length = n / 2 + 1;\n+      w = w / w(1);\n+      w = concat(reverse(w.left(half_length)), w.mid(2, half_length - 2));\n+    }\n+    else {\n+      w = ifft_real(to_cvec(p));\n+      int half_length = (n + 1) / 2;\n+      w = w.left(half_length) / w(0);\n+      w = concat(reverse(w), w.right(half_length - 1));\n+    }\n+    return w;\n+  }\n \n \n } // namespace itpp\ndiff --git a/itpp/signal/window.h b/itpp/signal/window.h\nindex aad510f..12f5205 100644\n--- a/itpp/signal/window.h\n+++ b/itpp/signal/window.h\n@@ -105,6 +105,24 @@ namespace itpp {\n   sqrt_win(n) = sqrt(triang(n))\n   */\n   vec sqrt_win(int n);\n+\n+  /*! \\brief Dolph-Chebyshev Window\n+\n+\n+  The length \\c n Dolph-Chebyshev window is a vector \\f$w\\f$ whose \\f$i\\f$th\n+  transform component is given by\n+  \\f[\n+  W[k] = \\frac{T_M\\left(\\beta \\cos\\left(\\frac{\\pi k}{M}\\right)\n+  \\right)}{T_M(\\beta)},k = 0, 1, 2, \\ldots, M - 1\n+  \\f]\n+\n+  where \\c T_n(x) is the order \\c n Chebyshev polynomial of the first kind.\n+  \\param n Length of the Doplh-Chebyshev window.\n+  \\param at Attenutation of side lobe (in dB).\n+  \\return Symmetric length \\c n Doplh-Chebyshev window.\n+  \\author\n+  */\n+  vec chebwin(int n, double at);\n   //!@}\n \n \ndiff --git a/tests/window_test.cpp b/tests/window_test.cpp\nindex 31fcff5..6d3fb15 100644\n--- a/tests/window_test.cpp\n+++ b/tests/window_test.cpp\n@@ -56,5 +56,10 @@ int main(void)\n   cout << \"triang(32) = \" << round_to_zero(triang(32)) << endl;\n   cout << \"triang(128) = \" << round_to_zero(triang(128)) << endl;\n \n+  cout << \"chebwin(32) = \" << round_to_zero(chebwin(32, 50)) << endl;\n+  cout << \"chebwin(33) = \" << round_to_zero(chebwin(33, 20)) << endl;\n+  cout << \"chebwin(127) = \" << round_to_zero(chebwin(127, 25)) << endl;\n+  cout << \"chebwin(128) = \" << round_to_zero(chebwin(128, 25)) << endl;\n+\n   return 0;\n }\ndiff --git a/tests/window_test.ref b/tests/window_test.ref\nindex 7b1793c..e988967 100644\n--- a/tests/window_test.ref\n+++ b/tests/window_test.ref\n@@ -11,3 +11,7 @@ blackman(32) = [0 0.0037516543 0.015638448 0.0374027 0.071464607 0.12028646 0.18\n blackman(128) = [0 0.00022048463 0.00088426938 0.0019983131 0.0035741016 0.0056274806 0.008178424 0.011250741 0.014871722 0.019071735 0.023883764 0.029342905 0.035485826 0.042350182 0.049974012 0.058395105 0.067650362 0.077775135 0.08880258 0.100763 0.11368324 0.12758601 0.14248936 0.15840611 0.17534333 0.19330184 0.21227586 0.23225262 0.25321203 0.27512651 0.29796076 0.32167173 0.34620856 0.37151262 0.3975177 0.42415015 0.45132921 0.47896731 0.50697053 0.53523907 0.56366781 0.59214691 0.62056245 0.64879721 0.67673135 0.70424322 0.73121023 0.7575096 0.7830193 0.80761885 0.83119025 0.85361875 0.87479376 0.89460963 0.91296646 0.9297708 0.94493641 0.95838489 0.97004626 0.97985951 0.98777306 0.99374518 0.99774428 0.99974914 0.99974914 0.99774428 0.99374518 0.98777306 0.97985951 0.97004626 0.95838489 0.94493641 0.9297708 0.91296646 0.89460963 0.87479376 0.85361875 0.83119025 0.80761885 0.7830193 0.7575096 0.73121023 0.70424322 0.67673135 0.64879721 0.62056245 0.59214691 0.56366781 0.53523907 0.50697053 0.47896731 0.45132921 0.42415015 0.3975177 0.37151262 0.34620856 0.32167173 0.29796076 0.27512651 0.25321203 0.23225262 0.21227586 0.19330184 0.17534333 0.15840611 0.14248936 0.12758601 0.11368324 0.100763 0.08880258 0.077775135 0.067650362 0.058395105 0.049974012 0.042350182 0.035485826 0.029342905 0.023883764 0.019071735 0.014871722 0.011250741 0.008178424 0.0056274806 0.0035741016 0.0019983131 0.00088426938 0.00022048463 0]\n triang(32) = [0.03125 0.09375 0.15625 0.21875 0.28125 0.34375 0.40625 0.46875 0.53125 0.59375 0.65625 0.71875 0.78125 0.84375 0.90625 0.96875 0.96875 0.90625 0.84375 0.78125 0.71875 0.65625 0.59375 0.53125 0.46875 0.40625 0.34375 0.28125 0.21875 0.15625 0.09375 0.03125]\n triang(128) = [0.0078125 0.0234375 0.0390625 0.0546875 0.0703125 0.0859375 0.1015625 0.1171875 0.1328125 0.1484375 0.1640625 0.1796875 0.1953125 0.2109375 0.2265625 0.2421875 0.2578125 0.2734375 0.2890625 0.3046875 0.3203125 0.3359375 0.3515625 0.3671875 0.3828125 0.3984375 0.4140625 0.4296875 0.4453125 0.4609375 0.4765625 0.4921875 0.5078125 0.5234375 0.5390625 0.5546875 0.5703125 0.5859375 0.6015625 0.6171875 0.6328125 0.6484375 0.6640625 0.6796875 0.6953125 0.7109375 0.7265625 0.7421875 0.7578125 0.7734375 0.7890625 0.8046875 0.8203125 0.8359375 0.8515625 0.8671875 0.8828125 0.8984375 0.9140625 0.9296875 0.9453125 0.9609375 0.9765625 0.9921875 0.9921875 0.9765625 0.9609375 0.9453125 0.9296875 0.9140625 0.8984375 0.8828125 0.8671875 0.8515625 0.8359375 0.8203125 0.8046875 0.7890625 0.7734375 0.7578125 0.7421875 0.7265625 0.7109375 0.6953125 0.6796875 0.6640625 0.6484375 0.6328125 0.6171875 0.6015625 0.5859375 0.5703125 0.5546875 0.5390625 0.5234375 0.5078125 0.4921875 0.4765625 0.4609375 0.4453125 0.4296875 0.4140625 0.3984375 0.3828125 0.3671875 0.3515625 0.3359375 0.3203125 0.3046875 0.2890625 0.2734375 0.2578125 0.2421875 0.2265625 0.2109375 0.1953125 0.1796875 0.1640625 0.1484375 0.1328125 0.1171875 0.1015625 0.0859375 0.0703125 0.0546875 0.0390625 0.0234375 0.0078125]\n+chebwin(32) = [0.050664426 0.066069435 0.10497972 0.15478981 0.21565675 0.28701938 0.36753634 0.45508472 0.5468251 0.63933249 0.72878615 0.81120512 0.88271105 0.93979671 0.97957695 1 1 0.97957695 0.93979671 0.88271105 0.81120512 0.72878615 0.63933249 0.5468251 0.45508472 0.36753634 0.28701938 0.21565675 0.15478981 0.10497972 0.066069435 0.050664426]\n+chebwin(33) = [1.5667761 0.436121 0.4911289 0.5465011 0.60155649 0.65559419 0.70790584 0.75778846 0.80455735 0.84755887 0.8861828 0.91987396 0.94814295 0.97057557 0.98684093 0.99669794 1 0.99669794 0.98684093 0.97057557 0.94814295 0.91987396 0.8861828 0.84755887 0.80455735 0.75778846 0.70790584 0.65559419 0.60155649 0.5465011 0.4911289 0.436121 1.5667761]\n+chebwin(127) = [2.8062784 0.28379647 0.29780485 0.31203524 0.32647609 0.34111535 0.3559405 0.37093856 0.38609612 0.40139932 0.41683391 0.43238525 0.44803833 0.46377779 0.47958794 0.49545281 0.51135612 0.52728135 0.54321176 0.55913036 0.57502004 0.59086348 0.60664326 0.62234187 0.63794169 0.65342508 0.66877439 0.68397195 0.69900016 0.71384147 0.72847843 0.7428937 0.75707013 0.77099071 0.78463866 0.79799743 0.81105075 0.82378262 0.83617737 0.84821968 0.85989459 0.87118755 0.88208441 0.89257149 0.90263557 0.91226391 0.9214443 0.93016505 0.93841505 0.94618372 0.95346113 0.9602379 0.96650532 0.97225529 0.9774804 0.98217387 0.98632963 0.98994228 0.99300712 0.99552018 0.99747819 0.99887858 0.99971955 1 0.99971955 0.99887858 0.99747819 0.99552018 0.99300712 0.98994228 0.98632963 0.98217387 0.9774804 0.97225529 0.96650532 0.9602379 0.95346113 0.94618372 0.93841505 0.93016505 0.9214443 0.91226391 0.90263557 0.89257149 0.88208441 0.87118755 0.85989459 0.84821968 0.83617737 0.82378262 0.81105075 0.79799743 0.78463866 0.77099071 0.75707013 0.7428937 0.72847843 0.71384147 0.69900016 0.68397195 0.66877439 0.65342508 0.63794169 0.62234187 0.60664326 0.59086348 0.57502004 0.55913036 0.54321176 0.52728135 0.51135612 0.49545281 0.47958794 0.46377779 0.44803833 0.43238525 0.41683391 0.40139932 0.38609612 0.37093856 0.3559405 0.34111535 0.32647609 0.31203524 0.29780485 0.28379647 2.8062784]\n+chebwin(128) = [2.8276135 0.28370485 0.29760123 0.31171632 0.32603887 0.34055711 0.35525884 0.37013139 0.38516169 0.40033623 0.41564112 0.43106209 0.4465845 0.46219339 0.47787346 0.49360915 0.50938459 0.52518367 0.54099005 0.55678721 0.57255843 0.58828682 0.6039554 0.61954706 0.63504462 0.65043087 0.66568854 0.68080039 0.69574922 0.71051786 0.72508926 0.73944646 0.75357265 0.76745118 0.78106561 0.79439972 0.80743754 0.82016335 0.83256177 0.84461773 0.85631651 0.86764377 0.87858557 0.88912838 0.89925915 0.90896528 0.91823465 0.92705566 0.93541726 0.94330891 0.95072067 0.95764316 0.96406763 0.96998592 0.97539051 0.98027451 0.9846317 0.98845652 0.99174407 0.99449016 0.99669127 0.99834457 0.99944796 1 1 0.99944796 0.99834457 0.99669127 0.99449016 0.99174407 0.98845652 0.9846317 0.98027451 0.97539051 0.96998592 0.96406763 0.95764316 0.95072067 0.94330891 0.93541726 0.92705566 0.91823465 0.90896528 0.89925915 0.88912838 0.87858557 0.86764377 0.85631651 0.84461773 0.83256177 0.82016335 0.80743754 0.79439972 0.78106561 0.76745118 0.75357265 0.73944646 0.72508926 0.71051786 0.69574922 0.68080039 0.66568854 0.65043087 0.63504462 0.61954706 0.6039554 0.58828682 0.57255843 0.55678721 0.54099005 0.52518367 0.50938459 0.49360915 0.47787346 0.46219339 0.4465845 0.43106209 0.41564112 0.40033623 0.38516169 0.37013139 0.35525884 0.34055711 0.32603887 0.31171632 0.29760123 0.28370485 2.8276135]\n-- \n1.5.4.rc3.4.g1633\n\n\n\nFrom ediap@users.sourceforge.net Thu Jan 17 10:20:44 2008\nFrom: =?utf-8?q?Adam=20Pi=C4=85tyszek?= <ediap@users.sourceforge.net>\nTo: ediap@Example.Com\nCc: K <email@example.com>\nSubject: [PATCH] Add Dolph Chebyshev window.\nDate: Thu, 17 Jan 2008 10:09:20 +0100\nMessage-Id: <1200560960-696-1-git-send-email-ediap@users.sourceforge.net>\nX-Mailer: git-send-email 1.5.4.rc3.4.g1633\nStatus: RO\nContent-Length: 10365\nLines: 136\n\nFrom: K <email@example.com>\n\nAdd the chebwin function to evaluate the coefficients of the\nDolph-Chebyshev Window, with tests.\n\nThe tests check the values output by the Dolph-Chebyshev window\nfunction for lengths 32 and 33 for 50 dB suppression and for lengths\n127 and 128 at 25 dB suppression.\n\nSigned-off-by: K <email@example.com>\n---\n itpp/signal/window.cpp |   39 ++++++++++++++++++++++++++++++++++++++-\n itpp/signal/window.h   |   18 ++++++++++++++++++\n tests/window_test.cpp  |    5 +++++\n tests/window_test.ref  |    4 ++++\n 4 files changed, 65 insertions(+), 1 deletions(-)\n\ndiff --git a/itpp/signal/window.cpp b/itpp/signal/window.cpp\nindex 0bf4be5..cfe27a8 100644\n--- a/itpp/signal/window.cpp\n+++ b/itpp/signal/window.cpp\n@@ -27,7 +27,12 @@\n  */\n \n #include <itpp/signal/window.h>\n-\n+#include <itpp/signal/poly.h>\n+#include <itpp/base/specmat.h>\n+#include <itpp/base/converters.h>\n+#include <itpp/base/math/trig_hyp.h>\n+#include <itpp/signal/transforms.h>\n+#include <itpp/base/operators.h>\n \n namespace itpp {\n \n@@ -106,6 +111,38 @@ namespace itpp {\n     return t;\n   }\n \n+  vec chebwin(int n, double at)\n+  {\n+    it_assert((n > 0), \"chebwin(): need a positive order n!\");\n+    if (n == 1) {\n+      return vec(\"1\");\n+    }\n+\n+    at = at < 0 ? -at : at;\n+    // compute the parameter beta\n+    double beta = std::cosh(::acosh(pow10(at/20.)) / (n-1));\n+    vec k = (pi / n) * linspace(0, n - 1, n);\n+    vec cos_k = cos(k);\n+    // find the window's DFT coefficients\n+    vec p = cheb(n - 1, beta * cos_k);\n+\n+    // Appropriate IDFT and filling up\n+    // depending on even/odd n\n+    vec w; // the window vector.\n+    if (is_even(n)) {\n+      w = ifft_real(to_cvec(elem_mult(p, cos_k), elem_mult(p,-sin(k))));\n+      int half_length = n / 2 + 1;\n+      w = w / w(1);\n+      w = concat(reverse(w.left(half_length)), w.mid(2, half_length - 2));\n+    }\n+    else {\n+      w = ifft_real(to_cvec(p));\n+      int half_length = (n + 1) / 2;\n+      w = w.left(half_length) / w(0);\n+      w = concat(reverse(w), w.right(half_length - 1));\n+    }\n+    return w;\n+  }\n \n \n } // namespace itpp\ndiff --git a/itpp/signal/window.h b/itpp/signal/window.h\nindex aad510f..12f5205 100644\n--- a/itpp/signal/window.h\n+++ b/itpp/signal/window.h\n@@ -105,6 +105,24 @@ namespace itpp {\n   sqrt_win(n) = sqrt(triang(n))\n   */\n   vec sqrt_win(int n);\n+\n+  /*! \\brief Dolph-Chebyshev Window\n+\n+\n+  The length \\c n Dolph-Chebyshev window is a vector \\f$w\\f$ whose \\f$i\\f$th\n+  transform component is given by\n+  \\f[\n+  W[k] = \\frac{T_M\\left(\\beta \\cos\\left(\\frac{\\pi k}{M}\\right)\n+  \\right)}{T_M(\\beta)},k = 0, 1, 2, \\ldots, M - 1\n+  \\f]\n+\n+  where \\c T_n(x) is the order \\c n Chebyshev polynomial of the first kind.\n+  \\param n Length of the Doplh-Chebyshev window.\n+  \\param at Attenutation of side lobe (in dB).\n+  \\return Symmetric length \\c n Doplh-Chebyshev window.\n+  \\author\n+  */\n+  vec chebwin(int n, double at);\n   //!@}\n \n \ndiff --git a/tests/window_test.cpp b/tests/window_test.cpp\nindex 31fcff5..6d3fb15 100644\n--- a/tests/window_test.cpp\n+++ b/tests/window_test.cpp\n@@ -56,5 +56,10 @@ int main(void)\n   cout << \"triang(32) = \" << round_to_zero(triang(32)) << endl;\n   cout << \"triang(128) = \" << round_to_zero(triang(128)) << endl;\n \n+  cout << \"chebwin(32) = \" << round_to_zero(chebwin(32, 50)) << endl;\n+  cout << \"chebwin(33) = \" << round_to_zero(chebwin(33, 20)) << endl;\n+  cout << \"chebwin(127) = \" << round_to_zero(chebwin(127, 25)) << endl;\n+  cout << \"chebwin(128) = \" << round_to_zero(chebwin(128, 25)) << endl;\n+\n   return 0;\n }\ndiff --git a/tests/window_test.ref b/tests/window_test.ref\nindex 7b1793c..e988967 100644\n--- a/tests/window_test.ref\n+++ b/tests/window_test.ref\n@@ -11,3 +11,7 @@ blackman(32) = [0 0.0037516543 0.015638448 0.0374027 0.071464607 0.12028646 0.18\n blackman(128) = [0 0.00022048463 0.00088426938 0.0019983131 0.0035741016 0.0056274806 0.008178424 0.011250741 0.014871722 0.019071735 0.023883764 0.029342905 0.035485826 0.042350182 0.049974012 0.058395105 0.067650362 0.077775135 0.08880258 0.100763 0.11368324 0.12758601 0.14248936 0.15840611 0.17534333 0.19330184 0.21227586 0.23225262 0.25321203 0.27512651 0.29796076 0.32167173 0.34620856 0.37151262 0.3975177 0.42415015 0.45132921 0.47896731 0.50697053 0.53523907 0.56366781 0.59214691 0.62056245 0.64879721 0.67673135 0.70424322 0.73121023 0.7575096 0.7830193 0.80761885 0.83119025 0.85361875 0.87479376 0.89460963 0.91296646 0.9297708 0.94493641 0.95838489 0.97004626 0.97985951 0.98777306 0.99374518 0.99774428 0.99974914 0.99974914 0.99774428 0.99374518 0.98777306 0.97985951 0.97004626 0.95838489 0.94493641 0.9297708 0.91296646 0.89460963 0.87479376 0.85361875 0.83119025 0.80761885 0.7830193 0.7575096 0.73121023 0.70424322 0.67673135 0.64879721 0.62056245 0.59214691 0.563667!\n 81 0.53523907 0.50697053 0.47896731 0.45132921 0.42415015 0.3975177 0.37151262 0.34620856 0.32167173 0.29796076 0.27512651 0.25321203 0.23225262 0.21227586 0.19330184 0.17534333 0.15840611 0.14248936 0.12758601 0.11368324 0.100763 0.08880258 0.077775135 0.067650362 0.058395105 0.049974012 0.042350182 0.035485826 0.029342905 0.023883764 0.019071735 0.014871722 0.011250741 0.008178424 0.0056274806 0.0035741016 0.0019983131 0.00088426938 0.00022048463 0]\n triang(32) = [0.03125 0.09375 0.15625 0.21875 0.28125 0.34375 0.40625 0.46875 0.53125 0.59375 0.65625 0.71875 0.78125 0.84375 0.90625 0.96875 0.96875 0.90625 0.84375 0.78125 0.71875 0.65625 0.59375 0.53125 0.46875 0.40625 0.34375 0.28125 0.21875 0.15625 0.09375 0.03125]\n triang(128) = [0.0078125 0.0234375 0.0390625 0.0546875 0.0703125 0.0859375 0.1015625 0.1171875 0.1328125 0.1484375 0.1640625 0.1796875 0.1953125 0.2109375 0.2265625 0.2421875 0.2578125 0.2734375 0.2890625 0.3046875 0.3203125 0.3359375 0.3515625 0.3671875 0.3828125 0.3984375 0.4140625 0.4296875 0.4453125 0.4609375 0.4765625 0.4921875 0.5078125 0.5234375 0.5390625 0.5546875 0.5703125 0.5859375 0.6015625 0.6171875 0.6328125 0.6484375 0.6640625 0.6796875 0.6953125 0.7109375 0.7265625 0.7421875 0.7578125 0.7734375 0.7890625 0.8046875 0.8203125 0.8359375 0.8515625 0.8671875 0.8828125 0.8984375 0.9140625 0.9296875 0.9453125 0.9609375 0.9765625 0.9921875 0.9921875 0.9765625 0.9609375 0.9453125 0.9296875 0.9140625 0.8984375 0.8828125 0.8671875 0.8515625 0.8359375 0.8203125 0.8046875 0.7890625 0.7734375 0.7578125 0.7421875 0.7265625 0.7109375 0.6953125 0.6796875 0.6640625 0.6484375 0.6328125 0.6171875 0.6015625 0.5859375 0.5703125 0.5546875 0.5390625 0.5234375 0.5078125 0.4921875 0.4!\n 765625 0.4609375 0.4453125 0.4296875 0.4140625 0.3984375 0.3828125 0.3671875 0.3515625 0.3359375 0.3203125 0.3046875 0.2890625 0.2734375 0.2578125 0.2421875 0.2265625 0.2109375 0.1953125 0.1796875 0.1640625 0.1484375 0.1328125 0.1171875 0.1015625 0.0859375 0.0703125 0.0546875 0.0390625 0.0234375 0.0078125]\n+chebwin(32) = [0.050664426 0.066069435 0.10497972 0.15478981 0.21565675 0.28701938 0.36753634 0.45508472 0.5468251 0.63933249 0.72878615 0.81120512 0.88271105 0.93979671 0.97957695 1 1 0.97957695 0.93979671 0.88271105 0.81120512 0.72878615 0.63933249 0.5468251 0.45508472 0.36753634 0.28701938 0.21565675 0.15478981 0.10497972 0.066069435 0.050664426]\n+chebwin(33) = [1.5667761 0.436121 0.4911289 0.5465011 0.60155649 0.65559419 0.70790584 0.75778846 0.80455735 0.84755887 0.8861828 0.91987396 0.94814295 0.97057557 0.98684093 0.99669794 1 0.99669794 0.98684093 0.97057557 0.94814295 0.91987396 0.8861828 0.84755887 0.80455735 0.75778846 0.70790584 0.65559419 0.60155649 0.5465011 0.4911289 0.436121 1.5667761]\n+chebwin(127) = [2.8062784 0.28379647 0.29780485 0.31203524 0.32647609 0.34111535 0.3559405 0.37093856 0.38609612 0.40139932 0.41683391 0.43238525 0.44803833 0.46377779 0.47958794 0.49545281 0.51135612 0.52728135 0.54321176 0.55913036 0.57502004 0.59086348 0.60664326 0.62234187 0.63794169 0.65342508 0.66877439 0.68397195 0.69900016 0.71384147 0.72847843 0.7428937 0.75707013 0.77099071 0.78463866 0.79799743 0.81105075 0.82378262 0.83617737 0.84821968 0.85989459 0.87118755 0.88208441 0.89257149 0.90263557 0.91226391 0.9214443 0.93016505 0.93841505 0.94618372 0.95346113 0.9602379 0.96650532 0.97225529 0.9774804 0.98217387 0.98632963 0.98994228 0.99300712 0.99552018 0.99747819 0.99887858 0.99971955 1 0.99971955 0.99887858 0.99747819 0.99552018 0.99300712 0.98994228 0.98632963 0.98217387 0.9774804 0.97225529 0.96650532 0.9602379 0.95346113 0.94618372 0.93841505 0.93016505 0.9214443 0.91226391 0.90263557 0.89257149 0.88208441 0.87118755 0.85989459 0.84821968 0.83617737 0.82378262 !\n 0.81105075 0.79799743 0.78463866 0.77099071 0.75707013 0.7428937 0.72847843 0.71384147 0.69900016 0.68397195 0.66877439 0.65342508 0.63794169 0.62234187 0.60664326 0.59086348 0.57502004 0.55913036 0.54321176 0.52728135 0.51135612 0.49545281 0.47958794 0.46377779 0.44803833 0.43238525 0.41683391 0.40139932 0.38609612 0.37093856 0.3559405 0.34111535 0.32647609 0.31203524 0.29780485 0.28379647 2.8062784]\n+chebwin(128) = [2.8276135 0.28370485 0.29760123 0.31171632 0.32603887 0.34055711 0.35525884 0.37013139 0.38516169 0.40033623 0.41564112 0.43106209 0.4465845 0.46219339 0.47787346 0.49360915 0.50938459 0.52518367 0.54099005 0.55678721 0.57255843 0.58828682 0.6039554 0.61954706 0.63504462 0.65043087 0.66568854 0.68080039 0.69574922 0.71051786 0.72508926 0.73944646 0.75357265 0.76745118 0.78106561 0.79439972 0.80743754 0.82016335 0.83256177 0.84461773 0.85631651 0.86764377 0.87858557 0.88912838 0.89925915 0.90896528 0.91823465 0.92705566 0.93541726 0.94330891 0.95072067 0.95764316 0.96406763 0.96998592 0.97539051 0.98027451 0.9846317 0.98845652 0.99174407 0.99449016 0.99669127 0.99834457 0.99944796 1 1 0.99944796 0.99834457 0.99669127 0.99449016 0.99174407 0.98845652 0.9846317 0.98027451 0.97539051 0.96998592 0.96406763 0.95764316 0.95072067 0.94330891 0.93541726 0.92705566 0.91823465 0.90896528 0.89925915 0.88912838 0.87858557 0.86764377 0.85631651 0.84461773 0.83256177 0.820!\n 16335 0.80743754 0.79439972 0.78106561 0.76745118 0.75357265 0.73944646 0.72508926 0.71051786 0.69574922 0.68080039 0.66568854 0.65043087 0.63504462 0.61954706 0.6039554 0.58828682 0.57255843 0.55678721 0.54099005 0.52518367 0.50938459 0.49360915 0.47787346 0.46219339 0.4465845 0.43106209 0.41564112 0.40033623 0.38516169 0.37013139 0.35525884 0.34055711 0.32603887 0.31171632 0.29760123 0.28370485 2.8276135]\n-- \n1.5.4.rc3.4.g1633\n\n"},{"id":"65718","messageId":"478F5478.7000200@users.sourceforge.net","threadId":"11655","inReplyTo":"478F2994.9080708@users.sourceforge.net","subject":"Re: [BUG] git send-email brakes patches with very long lines","fromName":"Adam Piatyszek","fromEmail":"ediap@users.sourceforge.net","sentAt":"2008-01-17T13:13:28Z","receivedAt":"2008-01-17T13:13:28Z","isPatch":false,"sender":{"key":"ediap@users.sourceforge.net","avatar":null},"body":"* Adam Piatyszek [17 I 2008 11:10]:\n> Please find the attached two emails, which show this problem. The \n> original file (0001-Add-Dolph-Chebyshev-window.patch) was produced with \n> \"git format-patch\" from one of my private Git repositories. The other \n> file (0001-Add-Dolph-Chebyshev-window-sent.patch) includes the same \n> patch but sent with \"git send-email\". The problem is with the last hunk, \n> which is somehow broken by the \"git send-email\" tool. The very long \n> lines are wrapped and some exclamation marks are inserted.\n> \n> The result of applying such a broken patch in my repository is as follows:\n> \n> ===== >8 =====\n> ediap@lespaul ~/git/itpp $ git am 0001-Add-Dolph-Chebyshev-window-sent.patch\n> Applying Add Dolph Chebyshev window.\n> fatal: corrupt patch at line 126\n> Patch failed at 0001.\n> When you have resolved this problem run \"git-am --resolved\".\n> If you would prefer to skip this patch, instead run \"git-am --skip\".\n> ===== >8 =====\n> \n> If I send the same patch with mutt inlined or attached, the patch is not \n> broken and applies cleanly.\n\nSorry for the noise! It seems that it is not a problem of \"git send-email\".\n\nI have just resent this patch to myself once again, this time using mutt \n\"bounce\" function, and it resulted in the broken patch in exactly the \nsame way.\n\nThe incorrect line wrapping with an exclamation mark is exactly at 990 \ncolumn. Is there any limitation of the line size for text/plain messages?\n\nBR,\n/Adam\n\n\n-- \n.:.  Adam Piatyszek (ediap)  .:.....................................:.\n.:.  ediap@users.sourceforge.net  .:................................:.\n"},{"id":"65717","messageId":"478F5798.6020405@users.sourceforge.net","threadId":"11655","inReplyTo":"478F5478.7000200@users.sourceforge.net","subject":"Re: [BUG] git send-email brakes patches with very long lines","fromName":"Adam Piatyszek","fromEmail":"ediap@users.sourceforge.net","sentAt":"2008-01-17T13:26:48Z","receivedAt":"2008-01-17T13:26:48Z","isPatch":false,"sender":{"key":"ediap@users.sourceforge.net","avatar":null},"body":"* Adam Piatyszek [17 I 2008 14:13]:\n> The incorrect line wrapping with an exclamation mark is exactly at 990 \n> column. Is there any limitation of the line size for text/plain messages?\n\nReplying to myself again:\n\nRFC2822 (Internet Message Format) states:\n\n   2.1.1. Line Length Limits\n\n     There are two limits that this standard places on the number of\n     characters in a line. Each line of characters MUST be no more than\n     998 characters, and SHOULD be no more than 78 characters, excluding\n     the CRLF.\n\nRFC2821 (Simple Mail Transfer Protocol) states:\n\n   4.5.3.1 Size limits and minimums\n   [...]\n   text line\n     The maximum total length of a text line including the <CRLF> is 1000\n     characters (not counting the leading dot duplicated for\n     transparency).  This number may be increased by the use of SMTP\n     Service Extensions.\n\n\nNow, the question is. Don't you think that \"git send-email\" should at \nleast warn users that they are trying to send emails with patches that \nwill be broken at the end?\n\nBR,\n/Adam\n\n\n-- \n.:.  Adam Piatyszek (ediap)  .:.....................................:.\n.:.  ediap@users.sourceforge.net  .:................................:.\n"},{"id":"65727","messageId":"20080117153252.GD2816@coredump.intra.peff.net","threadId":"11655","inReplyTo":"478F5798.6020405@users.sourceforge.net","subject":"Re: [BUG] git send-email brakes patches with very long lines","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-01-17T15:32:52Z","receivedAt":"2008-01-17T15:32:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 17, 2008 at 02:26:48PM +0100, Adam Piatyszek wrote:\n\n> RFC2822 (Internet Message Format) states:\n>\n>   2.1.1. Line Length Limits\n>\n>     There are two limits that this standard places on the number of\n>     characters in a line. Each line of characters MUST be no more than\n>     998 characters, and SHOULD be no more than 78 characters, excluding\n>     the CRLF.\n> [...]\n>\n> Now, the question is. Don't you think that \"git send-email\" should at  \n> least warn users that they are trying to send emails with patches that  \n> will be broken at the end?\n\nIt could actually QP-encode the data in that case, I think. git-mailinfo\nappears to have code to handle the decoding.\n\n-Peff\n"},{"id":"65830","messageId":"1200642458-3280-1-git-send-email-ediap@users.sourceforge.net","threadId":"11655","inReplyTo":"20080117153252.GD2816@coredump.intra.peff.net","subject":"[PATCH] git-send-email.perl: check for lines longer than 998 characters","fromName":"Adam Piątyszek","fromEmail":"ediap@users.sourceforge.net","sentAt":"2008-01-18T07:47:38Z","receivedAt":"2008-01-18T07:47:38Z","isPatch":true,"sender":{"key":"ediap@users.sourceforge.net","avatar":null},"body":"According to RFC2822 (Internet Message Format), each line of a message\nmust be no more than 998 characters. This patch adds a check for the\nlength of each body line of a message and dies if the length exceeds\nthe limit.\n\nSigned-off-by: Adam Piątyszek <ediap@users.sourceforge.net>\n---\n git-send-email.perl |    3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex e47994a..6d623ea 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -748,6 +748,9 @@ foreach my $t (@files) {\n \t\t\t\t$header_done = 1;\n \t\t\t}\n \t\t} else {\n+\t\t\tif (length($_) > 998) {\n+\t\t\t\tdie \"(msg) This message contains lines longer than 998 characters,\\nwhich can not be correctly send as plain text using SMTP.\\n\";\n+\t\t\t}\n \t\t\t$message .=  $_;\n \t\t\tif (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {\n \t\t\t\tmy $c = $2;\n-- \n1.5.4.rc3.4.g1633\n"},{"id":"65832","messageId":"47905F70.5090003@viscovery.net","threadId":"11655","inReplyTo":"1200642458-3280-1-git-send-email-ediap@users.sourceforge.net","subject":"Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-01-18T08:12:32Z","receivedAt":"2008-01-18T08:12:32Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Adam Piątyszek schrieb:\n> According to RFC2822 (Internet Message Format), each line of a message\n> must be no more than 998 characters. This patch adds a check for the\n> length of each body line of a message and dies if the length exceeds\n> the limit.\n> \n> Signed-off-by: Adam Piątyszek <ediap@users.sourceforge.net>\n> ---\n>  git-send-email.perl |    3 +++\n>  1 files changed, 3 insertions(+), 0 deletions(-)\n> \n> diff --git a/git-send-email.perl b/git-send-email.perl\n> index e47994a..6d623ea 100755\n> --- a/git-send-email.perl\n> +++ b/git-send-email.perl\n> @@ -748,6 +748,9 @@ foreach my $t (@files) {\n>  \t\t\t\t$header_done = 1;\n>  \t\t\t}\n>  \t\t} else {\n> +\t\t\tif (length($_) > 998) {\n> +\t\t\t\tdie \"(msg) This message contains lines longer than 998 characters,\\nwhich can not be correctly send as plain text using SMTP.\\n\";\n> +\t\t\t}\n>  \t\t\t$message .=  $_;\n>  \t\t\tif (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {\n>  \t\t\t\tmy $c = $2;\n\nIs it good to die() in this situation? If you are sending a patch series\nand one patch in the middle triggers this condition, then only half of the\nseries is sent. Maybe it would be better to warn here only, collect file\nnames of the suspects, send the patch nevertheless, and write a summary at\nthe end?\n\n-- Hannes\n"},{"id":"65844","messageId":"4790746D.1000502@users.sourceforge.net","threadId":"11655","inReplyTo":"47905F70.5090003@viscovery.net","subject":"Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters","fromName":"Adam Piatyszek","fromEmail":"ediap@users.sourceforge.net","sentAt":"2008-01-18T09:42:05Z","receivedAt":"2008-01-18T09:42:05Z","isPatch":true,"sender":{"key":"ediap@users.sourceforge.net","avatar":null},"body":"Hi,\n\n* Johannes Sixt [18 I 2008 09:12]:\n> Is it good to die() in this situation? If you are sending a patch series\n> and one patch in the middle triggers this condition, then only half of the\n> series is sent. Maybe it would be better to warn here only, collect file\n> names of the suspects, send the patch nevertheless, and write a summary at\n> the end?\n\nUnfortunately, my experience in perl programming is very, very limited. \nSo, I did not prepared the final solution for this problem. ;-) The \npatch was intended as a startup of a discussion how to fix this issue.\n\nIMHO it does not make much sense to send such patches nevertheless, if \nwe are sure that they will be broken after SMTP transfer. Such a \nsituation is similar to spamming. And sending only the ones that can be \nsent is not an option as well.\n\nThe proper solution would be to implement conditional encoding of such \npatches, e.g. quoted-printable as suggested by Peff, and warn users that \nsome patches were send as encoded. Also an explicit option \n\"--transfer-enc\" might be added to control such a behaviour manually.\n\nI guess, git send-email might reuse the code from this perl module:\nhttp://search.cpan.org/src/GAAS/MIME-Base64-Perl-1.00/lib/MIME/QuotedPrint/Perl.pm\nto implement the encoding routine.\n\nThere are although two things to implement:\n1) When too long line is detected, the whole message body has to be \nencoded with QP.\n2) Proper \"Content-Transfer-Encoding: quoted-printable\" needs to be set \nin the headers.\n\nBTW, is \"git am\" or \"git apply\" able to decode the QP encoded message \nbody? I guess yes, since it works with patches attached to emails as well...\n\nComments?\n\nBR,\n/Adam\n\n\n-- \n.:.  Adam Piatyszek (ediap)  .:.....................................:.\n.:.  ediap@users.sourceforge.net  .:................................:.\n"},{"id":"65845","messageId":"47907914.6000105@viscovery.net","threadId":"11655","inReplyTo":"4790746D.1000502@users.sourceforge.net","subject":"Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-01-18T10:01:56Z","receivedAt":"2008-01-18T10:01:56Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Adam Piatyszek schrieb:\n> * Johannes Sixt [18 I 2008 09:12]:\n>> Is it good to die() in this situation? If you are sending a patch series\n>> and one patch in the middle triggers this condition, then only half of\n>> the\n>> series is sent. Maybe it would be better to warn here only, collect file\n>> names of the suspects, send the patch nevertheless, and write a\n>> summary at\n>> the end?\n\n> IMHO it does not make much sense to send such patches nevertheless, if\n> we are sure that they will be broken after SMTP transfer. Such a\n> situation is similar to spamming. And sending only the ones that can be\n> sent is not an option as well.\n\nYou are right here. My thought was that even though the recipient gets a\nbroken patch, he would be able to fix it up. This may be acceptable for\npeer-to-peer communication, but not for a development style that involves\nmany recipients.\n\nThen git-format-patch and log-family with --pretty=email -p could warn\nabout these candidates-to-be-broken patches.\n\n-- Hannes\n"},{"id":"65846","messageId":"7v1w8fh2ef.fsf@gitster.siamese.dyndns.org","threadId":"11655","inReplyTo":"47907914.6000105@viscovery.net","subject":"Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-18T10:08:24Z","receivedAt":"2008-01-18T10:08:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j.sixt@viscovery.net> writes:\n\n> You are right here. My thought was that even though the recipient gets a\n> broken patch, he would be able to fix it up. This may be acceptable for\n> peer-to-peer communication, but not for a development style that involves\n> many recipients.\n>\n> Then git-format-patch and log-family with --pretty=email -p could warn\n> about these candidates-to-be-broken patches.\n\nI'd rather not, unless it is explicitly asked for by a separate\ncommand line option.  Transferring over SMTP is not the only\n(nor even primary) use of format-patch output.\n\nOn the other hand, git-send-email _is_ all about SMTP transfer.\nPerhaps a loop over input files upfront to check the line length\nlimit, and warn if there are suspiciously long lines even before\nsending the first piece of e-mail out, would be a reasonable\napproach.\n"},{"id":"65852","messageId":"47908150.9040201@users.sourceforge.net","threadId":"11655","inReplyTo":"7v1w8fh2ef.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters","fromName":"Adam Piatyszek","fromEmail":"ediap@users.sourceforge.net","sentAt":"2008-01-18T10:37:04Z","receivedAt":"2008-01-18T10:37:04Z","isPatch":true,"sender":{"key":"ediap@users.sourceforge.net","avatar":null},"body":"* Junio C Hamano [18 I 2008 11:08]:\n> Johannes Sixt <j.sixt@viscovery.net> writes:\n>> Then git-format-patch and log-family with --pretty=email -p could warn\n>> about these candidates-to-be-broken patches.\n> \n> I'd rather not, unless it is explicitly asked for by a separate\n> command line option.  Transferring over SMTP is not the only\n> (nor even primary) use of format-patch output.\n\nAgree.\n\n> On the other hand, git-send-email _is_ all about SMTP transfer.\n> Perhaps a loop over input files upfront to check the line length\n> limit, and warn if there are suspiciously long lines even before\n> sending the first piece of e-mail out, would be a reasonable\n> approach.\n\nBut what next? Still send the problematic patches not encoded?\n\nIn my opinion, it is more reasonable to provide an optional encoding of \nsuch patches. And only throw a warning message that some of the patches \nhad to be encoded. Then, we would not need an extra loop over all patches.\n\nAs git-send-email _is_ all about SMTP transfer, we should be interested \nthat the stuff we transfer is sent correctly.\n\n/Adam\n\n-- \n.:.  Adam Piatyszek (ediap)  .:.....................................:.\n.:.  ediap@users.sourceforge.net  .:................................:.\n"},{"id":"65856","messageId":"7v4pdbfle1.fsf@gitster.siamese.dyndns.org","threadId":"11655","inReplyTo":"47908150.9040201@users.sourceforge.net","subject":"Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-18T11:01:10Z","receivedAt":"2008-01-18T11:01:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Adam Piatyszek <ediap@users.sourceforge.net> writes:\n\n> But what next? Still send the problematic patches not encoded?\n\nI meant \"warn and stop before sending anything\".  The sender can\nfix it up in any way he wants.\n\nYou _could_ give an option to send-email to allow it to QP and\nwrap without failing (perhaps with warning), but that should be\nexplicitly asked for, as some people/list do not want MIME.  On\nsuch a list, the sender may even have to go back to the tree and\nfix the file contents before regenerating the patches.\n"},{"id":"65876","messageId":"20080118141638.GA14928@coredump.intra.peff.net","threadId":"11655","inReplyTo":"7v1w8fh2ef.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-01-18T14:16:39Z","receivedAt":"2008-01-18T14:16:39Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 18, 2008 at 02:08:24AM -0800, Junio C Hamano wrote:\n\n> On the other hand, git-send-email _is_ all about SMTP transfer.\n> Perhaps a loop over input files upfront to check the line length\n> limit, and warn if there are suspiciously long lines even before\n> sending the first piece of e-mail out, would be a reasonable\n> approach.\n\nI think that is sensible. Patch series will follow:\n\n  1/3: send-email: detect invocation errors earlier\n\n       This is a code cleanup in preparation for 2/3, but has\n       user-friendly side effects.\n\n  2/3: send-email: validate patches before sending anything\n\n       The actual up front long-lines check.\n\n  3/3: send-email: add no-validate option\n\n       A knob for users who know something send-email doesn't.\n\nThat at least detects the situation and lets the user deal with it (by\nfixing the patch, or by sending it as an attachment with another MUA).\nProbably there should be a\n\n  4/3: send-email: add --encoding parameter\n\nbut I am not inclined to code it, especially this late in the release\nfreeze (though I think the first three are reasonable for v1.5.4, I am\nalso fine if you want to put them off -- I don't see this as a common\nproblem).\n\n-Peff\n"},{"id":"65877","messageId":"20080118141935.GA19783@coredump.intra.peff.net","threadId":"11655","inReplyTo":"20080118141638.GA14928@coredump.intra.peff.net","subject":"[PATCH 1/3] send-email: detect invocation errors earlier","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-01-18T14:19:36Z","receivedAt":"2008-01-18T14:19:36Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"We never even look at the command line arguments until after\nwe have prompted the user for some information. So running\n\"git send-email\" without arguments would prompt for \"from\"\nand \"to\" headers, only to then die with \"No patch files\nspecified.\" Instead, let's try to do as much error checking\nas possible before getting user input.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n git-send-email.perl |   55 +++++++++++++++++++++++++--------------------------\n 1 files changed, 27 insertions(+), 28 deletions(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex e47994a..7a86977 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -314,6 +314,33 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {\n \n ($sender) = expand_aliases($sender) if defined $sender;\n \n+# Now that all the defaults are set, process the rest of the command line\n+# arguments and collect up the files that need to be processed.\n+for my $f (@ARGV) {\n+\tif (-d $f) {\n+\t\topendir(DH,$f)\n+\t\t\tor die \"Failed to opendir $f: $!\";\n+\n+\t\tpush @files, grep { -f $_ } map { +$f . \"/\" . $_ }\n+\t\t\t\tsort readdir(DH);\n+\n+\t} elsif (-f $f) {\n+\t\tpush @files, $f;\n+\n+\t} else {\n+\t\tprint STDERR \"Skipping $f - not found.\\n\";\n+\t}\n+}\n+\n+if (@files) {\n+\tunless ($quiet) {\n+\t\tprint $_,\"\\n\" for (@files);\n+\t}\n+} else {\n+\tprint STDERR \"\\nNo patch files specified!\\n\\n\";\n+\tusage();\n+}\n+\n my $prompting = 0;\n if (!defined $sender) {\n \t$sender = $repoauthor || $repocommitter;\n@@ -427,34 +454,6 @@ EOT\n \t@files = ($compose_filename . \".final\");\n }\n \n-\n-# Now that all the defaults are set, process the rest of the command line\n-# arguments and collect up the files that need to be processed.\n-for my $f (@ARGV) {\n-\tif (-d $f) {\n-\t\topendir(DH,$f)\n-\t\t\tor die \"Failed to opendir $f: $!\";\n-\n-\t\tpush @files, grep { -f $_ } map { +$f . \"/\" . $_ }\n-\t\t\t\tsort readdir(DH);\n-\n-\t} elsif (-f $f) {\n-\t\tpush @files, $f;\n-\n-\t} else {\n-\t\tprint STDERR \"Skipping $f - not found.\\n\";\n-\t}\n-}\n-\n-if (@files) {\n-\tunless ($quiet) {\n-\t\tprint $_,\"\\n\" for (@files);\n-\t}\n-} else {\n-\tprint STDERR \"\\nNo patch files specified!\\n\\n\";\n-\tusage();\n-}\n-\n # Variables we set as part of the loop over files\n our ($message_id, %mail, $subject, $reply_to, $references, $message);\n \n-- \n1.5.4.rc3.1128.g1826-dirty\n"},{"id":"65878","messageId":"20080118141948.GB19783@coredump.intra.peff.net","threadId":"11655","inReplyTo":"20080118141638.GA14928@coredump.intra.peff.net","subject":"[PATCH 2/3] send-email: validate patches before sending anything","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-01-18T14:19:48Z","receivedAt":"2008-01-18T14:19:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"We try to catch errors early so that we don't end up sending\nhalf of a broken patch series. Right now the only validation\nis checking that line-lengths are under the SMTP-mandated\nlimit of 998.\n\nThe validation parsing is very crude (it just checks each\nline length without understanding the mailbox format) but\nshould work fine for this simple check.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n git-send-email.perl   |   17 +++++++++++++++++\n t/t9001-send-email.sh |   20 ++++++++++++++++++++\n 2 files changed, 37 insertions(+), 0 deletions(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 7a86977..144d7d4 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -332,6 +332,11 @@ for my $f (@ARGV) {\n \t}\n }\n \n+foreach my $f (@files) {\n+\tmy $error = validate_patch($f);\n+\t$error and die \"fatal: $f: $error\\nwarning: no patches were sent\\n\";\n+}\n+\n if (@files) {\n \tunless ($quiet) {\n \t\tprint $_,\"\\n\" for (@files);\n@@ -837,3 +842,15 @@ sub unique_email_list(@) {\n \t}\n \treturn @emails;\n }\n+\n+sub validate_patch {\n+\tmy $fn = shift;\n+\topen(my $fh, '<', $fn)\n+\t\tor die \"unable to open $fn: $!\\n\";\n+\twhile (my $line = <$fh>) {\n+\t\tif (length($line) > 998) {\n+\t\t\treturn \"patch contains line longer than 998 characters\";\n+\t\t}\n+\t}\n+\treturn undef;\n+}\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex 659f9c7..1c41810 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -78,4 +78,24 @@ test_expect_success 'Show all headers' '\n \tdiff -u expected-show-all-headers actual-show-all-headers\n '\n \n+z8=zzzzzzzz\n+z64=$z8$z8$z8$z8$z8$z8$z8$z8\n+z512=$z64$z64$z64$z64$z64$z64$z64$z64\n+test_expect_success 'reject long lines' '\n+\trm -f commandline &&\n+\tcp $patches longline.patch &&\n+\techo $z512$z512 >>longline.patch &&\n+\t! git send-email \\\n+\t\t--from=\"Example <nobody@example.com>\" \\\n+\t\t--to=nobody@example.com \\\n+\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n+\t\t$patches longline.patch \\\n+\t\t2>errors &&\n+\tgrep longline.patch errors\n+'\n+\n+test_expect_success 'no patch was sent' '\n+\t! test -e commandline\n+'\n+\n test_done\n-- \n1.5.4.rc3.1128.g1826-dirty\n"},{"id":"65880","messageId":"20080118142010.GC19783@coredump.intra.peff.net","threadId":"11655","inReplyTo":"20080118141638.GA14928@coredump.intra.peff.net","subject":"[PATCH 3/3] send-email: add no-validate option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-01-18T14:20:10Z","receivedAt":"2008-01-18T14:20:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Since we are now sanity-checking the contents of patches and\nrefusing to send ones with long lines, this knob provides a\nway for the user to override the new behavior (if, e.g., he\nknows his SMTP path will handle it).\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n git-send-email.perl   |   12 +++++++++---\n t/t9001-send-email.sh |   10 ++++++++++\n 2 files changed, 19 insertions(+), 3 deletions(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 144d7d4..39e0222 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -100,6 +100,8 @@ Options:\n \n    --envelope-sender\tSpecify the envelope sender used to send the emails.\n \n+   --no-validate\tDon't perform any sanity checks on patches.\n+\n EOT\n \texit(1);\n }\n@@ -177,6 +179,7 @@ my ($quiet, $dry_run) = (0, 0);\n my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);\n my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_authpass, $smtp_ssl);\n my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);\n+my ($no_validate);\n \n my %config_bool_settings = (\n     \"thread\" => [\\$thread, 1],\n@@ -222,6 +225,7 @@ my $rc = GetOptions(\"sender|from=s\" => \\$sender,\n \t\t    \"dry-run\" => \\$dry_run,\n \t\t    \"envelope-sender=s\" => \\$envelope_sender,\n \t\t    \"thread!\" => \\$thread,\n+\t\t    \"no-validate\" => \\$no_validate,\n \t );\n \n unless ($rc) {\n@@ -332,9 +336,11 @@ for my $f (@ARGV) {\n \t}\n }\n \n-foreach my $f (@files) {\n-\tmy $error = validate_patch($f);\n-\t$error and die \"fatal: $f: $error\\nwarning: no patches were sent\\n\";\n+if (!$no_validate) {\n+\tforeach my $f (@files) {\n+\t\tmy $error = validate_patch($f);\n+\t\t$error and die \"fatal: $f: $error\\nwarning: no patches were sent\\n\";\n+\t}\n }\n \n if (@files) {\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex 1c41810..4f6822f 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -98,4 +98,14 @@ test_expect_success 'no patch was sent' '\n \t! test -e commandline\n '\n \n+test_expect_success 'allow long lines with --no-validate' '\n+\tgit send-email \\\n+\t\t--from=\"Example <nobody@example.com>\" \\\n+\t\t--to=nobody@example.com \\\n+\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n+\t\t--no-validate \\\n+\t\t$patches longline.patch \\\n+\t\t2>errors\n+'\n+\n test_done\n-- \n1.5.4.rc3.1128.g1826-dirty\n"},{"id":"65884","messageId":"4790C11F.8010809@viscovery.net","threadId":"11655","inReplyTo":"20080118141948.GB19783@coredump.intra.peff.net","subject":"Re: [PATCH 2/3] send-email: validate patches before sending anything","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-01-18T15:09:19Z","receivedAt":"2008-01-18T15:09:19Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Jeff King schrieb:\n> +sub validate_patch {\n> +\tmy $fn = shift;\n> +\topen(my $fh, '<', $fn)\n> +\t\tor die \"unable to open $fn: $!\\n\";\n> +\twhile (my $line = <$fh>) {\n> +\t\tif (length($line) > 998) {\n> +\t\t\treturn \"patch contains line longer than 998 characters\";\n\n\"... contains line_s_ longer than...\"\n\n-- Hannes\n"},{"id":"65901","messageId":"76718490801180939v12112b5btd71dfb1fb5be5897@mail.gmail.com","threadId":"11655","inReplyTo":"20080118141948.GB19783@coredump.intra.peff.net","subject":"Re: [PATCH 2/3] send-email: validate patches before sending anything","fromName":"Jay Soffian","fromEmail":"jaysoffian+git@gmail.com","sentAt":"2008-01-18T17:39:45Z","receivedAt":"2008-01-18T17:39:45Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On 1/18/08, Jeff King <peff@peff.net> wrote:\n\n> +foreach my $f (@files) {\n> +       my $error = validate_patch($f);\n> +       $error and die \"fatal: $f: $error\\nwarning: no patches were sent\\n\";\n> +}\n> +\n>  if (@files) {\n>         unless ($quiet) {\n>                 print $_,\"\\n\" for (@files);\n> @@ -837,3 +842,15 @@ sub unique_email_list(@) {\n>         }\n>         return @emails;\n>  }\n> +\n> +sub validate_patch {\n> +       my $fn = shift;\n> +       open(my $fh, '<', $fn)\n> +               or die \"unable to open $fn: $!\\n\";\n> +       while (my $line = <$fh>) {\n> +               if (length($line) > 998) {\n> +                       return \"patch contains line longer than 998 characters\";\n> +               }\n> +       }\n> +       return undef;\n> +}\n\nHow about offering the line number. e.g.:\n\nreturn \"patch line number $. is longer than 998 characters\";\n\n> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\n> index 659f9c7..1c41810 100755\n> --- a/t/t9001-send-email.sh\n> +++ b/t/t9001-send-email.sh\n> @@ -78,4 +78,24 @@ test_expect_success 'Show all headers' '\n>         diff -u expected-show-all-headers actual-show-all-headers\n>  '\n>\n> +test_expect_success 'no patch was sent' '\n\nShouldn't that be \"no patches were sent\" to match the perl output?\n\nj.\n"},{"id":"65910","messageId":"20080118190910.GA21044@coredump.intra.peff.net","threadId":"11655","inReplyTo":"4790C11F.8010809@viscovery.net","subject":"Re: [PATCH 2/3] send-email: validate patches before sending anything","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-01-18T19:09:10Z","receivedAt":"2008-01-18T19:09:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 18, 2008 at 04:09:19PM +0100, Johannes Sixt wrote:\n\n> Jeff King schrieb:\n> > +sub validate_patch {\n> > +\tmy $fn = shift;\n> > +\topen(my $fh, '<', $fn)\n> > +\t\tor die \"unable to open $fn: $!\\n\";\n> > +\twhile (my $line = <$fh>) {\n> > +\t\tif (length($line) > 998) {\n> > +\t\t\treturn \"patch contains line longer than 998 characters\";\n> \n> \"... contains line_s_ longer than...\"\n\nI actually had that and changed it, since we know of only one such line\n(since we bail at that point). I think Jay's suggestion of outputting\nthe line number is even better.\n\n-Peff\n"},{"id":"65911","messageId":"20080118191201.GB21044@coredump.intra.peff.net","threadId":"11655","inReplyTo":"76718490801180939v12112b5btd71dfb1fb5be5897@mail.gmail.com","subject":"Re: [PATCH 2/3] send-email: validate patches before sending anything","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-01-18T19:12:01Z","receivedAt":"2008-01-18T19:12:01Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 18, 2008 at 12:39:45PM -0500, Jay Soffian wrote:\n\n> > +                       return \"patch contains line longer than 998 characters\";\n> How about offering the line number. e.g.:\n> \n> return \"patch line number $. is longer than 998 characters\";\n\nI think that is sensible (Junio, if you apply pre-1.5.4, can you mark it\nup?  Otherwise I will put it in the post-1.5.4 resend).\n\n> > +test_expect_success 'no patch was sent' '\n> \n> Shouldn't that be \"no patches were sent\" to match the perl output?\n\nIt's purely an informational message for the test script output, so it\ndoesn't matter.\n\n-Peff\n"},{"id":"65920","messageId":"7v8x2mdf7e.fsf@gitster.siamese.dyndns.org","threadId":"11655","inReplyTo":"20080118141638.GA14928@coredump.intra.peff.net","subject":"Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-18T20:57:41Z","receivedAt":"2008-01-18T20:57:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, Jan 18, 2008 at 02:08:24AM -0800, Junio C Hamano wrote:\n>\n>> On the other hand, git-send-email _is_ all about SMTP transfer.\n>> Perhaps a loop over input files upfront to check the line length\n>> limit, and warn if there are suspiciously long lines even before\n>> sending the first piece of e-mail out, would be a reasonable\n>> approach.\n>\n> I think that is sensible. Patch series will follow:\n>\n>   1/3: send-email: detect invocation errors earlier\n>\n>        This is a code cleanup in preparation for 2/3, but has\n>        user-friendly side effects.\n>\n>   2/3: send-email: validate patches before sending anything\n>\n>        The actual up front long-lines check.\n\nI wonder what the performance implication of this approach would\nbe, though.  I am tempted to say that it would be negligible --\nscanning text in Perl is fast enough.\n\n>   3/3: send-email: add no-validate option\n>\n>        A knob for users who know something send-email doesn't.\n>\n> That at least detects the situation and lets the user deal with it (by\n> fixing the patch, or by sending it as an attachment with another MUA).\n\nI suspect that taking this \"Safe against SMTP line length limit\"\ntopic all the way (\"all the way\" is post 1.5.4, I am inclined to\nagree that this may be a good fix to an existing bug) would\nrequire that git-format-patch --attach to learn to apply QP on\npatch text to avoid producing very long lines to root-cause the\nissue [*1*].\n\n[Footnote]\n\n*1* It's actually second-to-root-cause it, because the real root\ncause is for the source tree to have such an insanely long line.\n"},{"id":"65925","messageId":"20080118213051.GA21321@coredump.intra.peff.net","threadId":"11655","inReplyTo":"7v8x2mdf7e.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-01-18T21:30:51Z","receivedAt":"2008-01-18T21:30:51Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 18, 2008 at 12:57:41PM -0800, Junio C Hamano wrote:\n\n> >   2/3: send-email: validate patches before sending anything\n> >\n> >        The actual up front long-lines check.\n> \n> I wonder what the performance implication of this approach would\n> be, though.  I am tempted to say that it would be negligible --\n> scanning text in Perl is fast enough.\n\nWe now open and do one conditional per line for each file (in addition\nto already going through each file a separate time and doing more\ncomplex processing).  Doing that over the entirety of \"git log\n--pretty=email -p\" on git.git takes about 1 second on my machine for\n11402 patches.  Obviously there's slightly more syscall overhead as you\nhave to open() each patch, but I think think it is clear that the\nparsing overhead is negligible.\n\n> I suspect that taking this \"Safe against SMTP line length limit\"\n> topic all the way (\"all the way\" is post 1.5.4, I am inclined to\n> agree that this may be a good fix to an existing bug) would\n> require that git-format-patch --attach to learn to apply QP on\n> patch text to avoid producing very long lines to root-cause the\n> issue [*1*].\n\nPerhaps. If such things are sufficiently rare, one could simply attach\nthe patch in their MUA. I think the most important thing is for git to\nat least stop and warn the user that it might not be sending something\nvalid. But implementing N different fixes that haven't even been\nrequested by users seems like a waste of time.\n\n-Peff\n"},{"id":"66057","messageId":"4793CCA2.4060407@users.sourceforge.net","threadId":"11655","inReplyTo":"7v8x2mdf7e.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters","fromName":"Adam Piatyszek","fromEmail":"ediap@users.sourceforge.net","sentAt":"2008-01-20T22:35:14Z","receivedAt":"2008-01-20T22:35:14Z","isPatch":true,"sender":{"key":"ediap@users.sourceforge.net","avatar":null},"body":"Hi,\n\n> Jeff King <peff@peff.net> writes:\n>> I think that is sensible. Patch series will follow:\n>>\n>>   1/3: send-email: detect invocation errors earlier\n>>\n>>        This is a code cleanup in preparation for 2/3, but has\n>>        user-friendly side effects.\n>>\n>>   2/3: send-email: validate patches before sending anything\n>>\n>>        The actual up front long-lines check.\n> \n> I wonder what the performance implication of this approach would\n> be, though.  I am tempted to say that it would be negligible --\n> scanning text in Perl is fast enough.\n> \n>>   3/3: send-email: add no-validate option\n>>\n>>        A knob for users who know something send-email doesn't.\n>>\n>> That at least detects the situation and lets the user deal with it (by\n>> fixing the patch, or by sending it as an attachment with another MUA).\n\nThanks Peff for your patches. I was about to implement your first two, \nbut it would take me much more time to do it in a sane way. ;-)\n\nSo:\n\nAcked-by: Adam Piątyszek <ediap@users.sourceforge.net>\n\n* Junio C Hamano [18 I 2008 21:57]:\n> I suspect that taking this \"Safe against SMTP line length limit\"\n> topic all the way (\"all the way\" is post 1.5.4, I am inclined to\n> agree that this may be a good fix to an existing bug) would\n> require that git-format-patch --attach to learn to apply QP on\n> patch text to avoid producing very long lines to root-cause the\n> issue [*1*].\n\nI support this idea. \"git-format-patch --attach\" is a good place to \nimplement such an additional encoding. Of course, git-mailinfo needs to \nbe extended with a decoding method as well.\n\n> [Footnote]\n> \n> *1* It's actually second-to-root-cause it, because the real root\n> cause is for the source tree to have such an insanely long line.\n\nI can not fully agree with this statement. You should have in mind that \ngit is by the definition a \"stupid content tracker\" and should not \nassume any particular kind of data being processed.\nFor instance, the reported problem with git-send-email was discovered \nwhen I tried to send a patch with some reference data of an unformatted \nstandard output of a test program.\n\nBR,\n/Adam\n\n-- \n.:.  Adam Piatyszek (ediap)  .:.....................................:.\n.:.  ediap@users.sourceforge.net  .:................................:.\n"},{"id":"66058","messageId":"20080120225313.GA14762@coredump.intra.peff.net","threadId":"11655","inReplyTo":"4793CCA2.4060407@users.sourceforge.net","subject":"Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-01-20T22:53:13Z","receivedAt":"2008-01-20T22:53:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jan 20, 2008 at 11:35:14PM +0100, Adam Piatyszek wrote:\n\n> I support this idea. \"git-format-patch --attach\" is a good place to  \n> implement such an additional encoding. Of course, git-mailinfo needs to  \n> be extended with a decoding method as well.\n\nI think mailinfo already does support qp, but I haven't tested it (see\nbuiltin-mailinfo.c:decode_q_segment).\n\n>> *1* It's actually second-to-root-cause it, because the real root\n>> cause is for the source tree to have such an insanely long line.\n> I can not fully agree with this statement. You should have in mind that  \n> git is by the definition a \"stupid content tracker\" and should not assume \n> any particular kind of data being processed.\n> For instance, the reported problem with git-send-email was discovered  \n> when I tried to send a patch with some reference data of an unformatted  \n> standard output of a test program.\n\nI agree with you. One of the things that makes git so useful is that you\ncan feed it any content and everything \"just works\".\n\nThat being said, there is often a distinction in git between 'text' that\nis reasonable for patches, mailing, etc, and 'binary', which is not.\nBoth cases are handled by git, but in different ways appropriate to\neach. 1000-character lines are awfully long; should they perhaps be\nhandled as binary files?  The upside is that this fits them into a\nwell-established niche within git. The downside is that the diffs aren't\nreadable (though who is reading diffs with such long lines?) and I don't\nbelieve the conflict resolution is as simple.\n\n-Peff\n"},{"id":"66116","messageId":"4794722F.7060401@users.sourceforge.net","threadId":"11655","inReplyTo":"20080120225313.GA14762@coredump.intra.peff.net","subject":"Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters","fromName":"Adam Piatyszek","fromEmail":"ediap@users.sourceforge.net","sentAt":"2008-01-21T10:21:35Z","receivedAt":"2008-01-21T10:21:35Z","isPatch":true,"sender":{"key":"ediap@users.sourceforge.net","avatar":null},"body":"* Jeff King [20 I 2008 23:53]:\n> On Sun, Jan 20, 2008 at 11:35:14PM +0100, Adam Piatyszek wrote:\n> \n>> I support this idea. \"git-format-patch --attach\" is a good place to  \n>> implement such an additional encoding. Of course, git-mailinfo needs to  \n>> be extended with a decoding method as well.\n> \n> I think mailinfo already does support qp, but I haven't tested it (see\n> builtin-mailinfo.c:decode_q_segment).\n\nYou are right. I've just tested it and it works fine when \n\"Content-Transfer-Encoding: quoted-printable\" is declared in the header \npart of the email. So only the git-format-patch needs some extension for \noptional QP encoding.\n\nBR,\n/Adam\n\n\n-- \n.:.  Adam Piatyszek (ediap)  .:.....................................:.\n.:.  ediap@users.sourceforge.net  .:................................:.\n"}]}