From: Adam Piatyszek <ediap@users.sourceforge.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Sixt <j.sixt@viscovery.net>, Jeff King <peff@peff.net>,
git@vger.kernel.org
Subject: Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters
Date: Fri, 18 Jan 2008 11:37:04 +0100 [thread overview]
Message-ID: <47908150.9040201@users.sourceforge.net> (raw)
In-Reply-To: <7v1w8fh2ef.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano [18 I 2008 11:08]:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>> 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.
Agree.
> 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.
But what next? Still send the problematic patches not encoded?
In my opinion, it is more reasonable to provide an optional encoding of
such patches. And only throw a warning message that some of the patches
had to be encoded. Then, we would not need an extra loop over all patches.
As git-send-email _is_ all about SMTP transfer, we should be interested
that the stuff we transfer is sent correctly.
/Adam
--
.:. Adam Piatyszek (ediap) .:.....................................:.
.:. ediap@users.sourceforge.net .:................................:.
next prev parent reply other threads:[~2008-01-18 10:51 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
2008-01-18 10:37 ` Adam Piatyszek [this message]
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=47908150.9040201@users.sourceforge.net \
--to=ediap@users.sourceforge.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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.