From: Junio C Hamano <gitster@pobox.com>
To: Johannes Sixt <j.sixt@viscovery.net>
Cc: Adam Piatyszek <ediap@users.sourceforge.net>,
Jeff King <peff@peff.net>,
git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters
Date: Fri, 18 Jan 2008 02:08:24 -0800 [thread overview]
Message-ID: <7v1w8fh2ef.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <47907914.6000105@viscovery.net> (Johannes Sixt's message of "Fri, 18 Jan 2008 11:01:56 +0100")
Johannes Sixt <j.sixt@viscovery.net> writes:
> You are right here. My thought was that even though the recipient gets a
> broken patch, he would be able to fix it up. This may be acceptable for
> peer-to-peer communication, but not for a development style that involves
> many recipients.
>
> Then git-format-patch and log-family with --pretty=email -p could warn
> about these candidates-to-be-broken patches.
I'd rather not, unless it is explicitly asked for by a separate
command line option. Transferring over SMTP is not the only
(nor even primary) use of format-patch output.
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.
next prev parent reply other threads:[~2008-01-18 10:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-17 10:10 [BUG] git send-email brakes patches with very long lines Adam Piatyszek
2008-01-17 13:13 ` Adam Piatyszek
2008-01-17 13:26 ` Adam Piatyszek
2008-01-17 15:32 ` Jeff King
2008-01-18 7:47 ` [PATCH] git-send-email.perl: check for lines longer than 998 characters Adam Piątyszek
2008-01-18 8:12 ` Johannes Sixt
2008-01-18 9:42 ` Adam Piatyszek
2008-01-18 10:01 ` Johannes Sixt
2008-01-18 10:08 ` Junio C Hamano [this message]
2008-01-18 10:37 ` Adam Piatyszek
2008-01-18 11:01 ` Junio C Hamano
2008-01-18 14:16 ` Jeff King
2008-01-18 14:19 ` [PATCH 1/3] send-email: detect invocation errors earlier Jeff King
2008-01-18 14:19 ` [PATCH 2/3] send-email: validate patches before sending anything Jeff King
2008-01-18 15:09 ` Johannes Sixt
2008-01-18 19:09 ` Jeff King
2008-01-18 17:39 ` Jay Soffian
2008-01-18 19:12 ` Jeff King
2008-01-18 14:20 ` [PATCH 3/3] send-email: add no-validate option Jeff King
2008-01-18 20:57 ` [PATCH] git-send-email.perl: check for lines longer than 998 characters Junio C Hamano
2008-01-18 21:30 ` Jeff King
2008-01-20 22:35 ` Adam Piatyszek
2008-01-20 22:53 ` Jeff King
2008-01-21 10:21 ` Adam Piatyszek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v1w8fh2ef.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=ediap@users.sourceforge.net \
--cc=git@vger.kernel.org \
--cc=j.sixt@viscovery.net \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.