git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters

From
APAdam Piatyszek <ediap@users.sourceforge.net>
Date
Jan 18, 2008, 09:42 UTC
Message-ID
<4790746D.1000502@users.sourceforge.net>
In-Reply-To
<47905F70.5090003@viscovery.net>
Hi,
* Johannes Sixt [18 I 2008 09:12]:
Show 5 quoted lines
> Is it good to die() in this situation? If you are sending a patch series
> and one patch in the middle triggers this condition, then only half of the
> series is sent. Maybe it would be better to warn here only, collect file
> names of the suspects, send the patch nevertheless, and write a summary at
> the end?

Unfortunately, my experience in perl programming is very, very limited. So, I did not prepared the final solution for this problem. ;-) The patch was intended as a startup of a discussion how to fix this issue.

IMHO it does not make much sense to send such patches nevertheless, if we are sure that they will be broken after SMTP transfer. Such a situation is similar to spamming. And sending only the ones that can be sent is not an option as well.

The proper solution would be to implement conditional encoding of such patches, e.g. quoted-printable as suggested by Peff, and warn users that some patches were send as encoded. Also an explicit option "--transfer-enc" might be added to control such a behaviour manually.

I guess, git send-email might reuse the code from this perl module: http://search.cpan.org/src/GAAS/MIME-Base64-Perl-1.00/lib/MIME/QuotedPrint/Perl.pm to implement the encoding routine.

There are although two things to implement:
1) When too long line is detected, the whole message body has to be 
encoded with QP.
2) Proper "Content-Transfer-Encoding: quoted-printable" needs to be set 
in the headers.

BTW, is "git am" or "git apply" able to decode the QP encoded message body? I guess yes, since it works with patches attached to emails as well...

Comments?

BR, /Adam

-- 
.:.  Adam Piatyszek (ediap)  .:.....................................:.
.:.  ediap@users.sourceforge.net  .:................................:.
Previous: Johannes SixtNext: Johannes Sixt
Message 7 of 24 in “[BUG] git send-email brakes patches with very long lines”
  1. Adam PiatyszekJan 17, 2008
  2. Adam PiatyszekJan 17, 2008
  3. Adam PiatyszekJan 17, 2008
  4. Jeff KingJan 17, 2008
  5. git-send-email.perl: check for lines longer than 998 charactersAdam Piątyszek, Jan 18, 2008
  6. Johannes SixtJan 18, 2008
  7. Adam PiatyszekJan 18, 2008
  8. Johannes SixtJan 18, 2008
  9. Junio C HamanoJan 18, 2008
  10. Adam PiatyszekJan 18, 2008
  11. Junio C HamanoJan 18, 2008
  12. Jeff KingJan 18, 2008
  13. 1/3 send-email: detect invocation errors earlierJeff King, Jan 18, 2008
  14. 2/3 send-email: validate patches before sending anythingJeff King, Jan 18, 2008
  15. Johannes SixtJan 18, 2008
  16. Jeff KingJan 18, 2008
  17. Jay SoffianJan 18, 2008
  18. Jeff KingJan 18, 2008
  19. 3/3 send-email: add no-validate optionJeff King, Jan 18, 2008
  20. Junio C HamanoJan 18, 2008
  21. Jeff KingJan 18, 2008
  22. Adam PiatyszekJan 20, 2008
  23. Jeff KingJan 20, 2008
  24. Adam PiatyszekJan 21, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.