* Junio C Hamano [18 I 2008 11:08]:
Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx .:................................:.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
