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
Junio C Hamano <gitster@pobox.com>
Date
Jan 18, 2008, 20:57 UTC
Message-ID
<7v8x2mdf7e.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<20080118141638.GA14928@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 18 quoted lines
> On Fri, Jan 18, 2008 at 02:08:24AM -0800, Junio C Hamano wrote:
>
>> On the other hand, git-send-email _is_ all about SMTP transfer.
>> Perhaps a loop over input files upfront to check the line length
>> limit, and warn if there are suspiciously long lines even before
>> sending the first piece of e-mail out, would be a reasonable
>> approach.
>
> I think that is sensible. Patch series will follow:
>
>   1/3: send-email: detect invocation errors earlier
>
>        This is a code cleanup in preparation for 2/3, but has
>        user-friendly side effects.
>
>   2/3: send-email: validate patches before sending anything
>
>        The actual up front long-lines check.

I wonder what the performance implication of this approach would be, though. I am tempted to say that it would be negligible -- scanning text in Perl is fast enough.

Show 6 quoted lines
>   3/3: send-email: add no-validate option
>
>        A knob for users who know something send-email doesn't.
>
> That at least detects the situation and lets the user deal with it (by
> fixing the patch, or by sending it as an attachment with another MUA).

I suspect that taking this "Safe against SMTP line length limit" topic all the way ("all the way" is post 1.5.4, I am inclined to agree that this may be a good fix to an existing bug) would require that git-format-patch --attach to learn to apply QP on patch text to avoid producing very long lines to root-cause the issue [*1*].

[Footnote]

*1* It's actually second-to-root-cause it, because the real root cause is for the source tree to have such an insanely long line.

Previous: Jeff KingNext: Jeff King
Message 20 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.