All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Sixt <j.sixt@viscovery.net>
To: Adam Piatyszek <ediap@users.sourceforge.net>
Cc: 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 11:01:56 +0100	[thread overview]
Message-ID: <47907914.6000105@viscovery.net> (raw)
In-Reply-To: <4790746D.1000502@users.sourceforge.net>

Adam Piatyszek schrieb:
> * Johannes Sixt [18 I 2008 09:12]:
>> 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?

> 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.

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.

-- Hannes

  reply	other threads:[~2008-01-18 10:02 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 [this message]
2008-01-18 10:08               ` Junio C Hamano
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=47907914.6000105@viscovery.net \
    --to=j.sixt@viscovery.net \
    --cc=ediap@users.sourceforge.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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.