* Junio C Hamano [18 I 2008 11:08]:
quoted text
> 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.

quoted text
> 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  .:................................:.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html