Re: [PATCH] format-patch: Use --mbox by default.

From: Junio C Hamano <junkio@cox.net>
Date: Jan 8, 2006, 20:28 UTC
Message-ID: <7vhd8ezcol.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060108140109.909925BE8D@nox.op5.se>

Andreas Ericsson <ae@op5.se> writes:

> This patch enables a slightly modified and more correct --mbox
> output by default. The --date, --author and --mbox options
> are obsoleted and removed.

I always use format-patch with -k -m (or -k --stdout), so I have no objections to making --mbox the default. I do not think anybody uses --date or --author in their scripts, but removing the --mbox option _might_ break things for people's scripts. Maybe it is worthwhile to keep it as a no-op option for a while.

Show 5 quoted lines

> Previously, author-info and date was by default only printed if the
> commit was made by someone else, irrespective of the obsoleted options.
> Since it does no harm having ones own info there too it shouldn't really
> matter much, and should lessen the confusion regarding how to use
> git-format-patch with git-am.

True. Originally it was really "format my changes to submission" tool (--signoff option is a sure sign to tell you that) and propagating authorship info was added as afterthought.

> The patches generated also had bad mail headers for sendmail (of
> postfix 2.2.2 at least) to use directly (From: line must be on top,
> Subject: last of header),...

I do not think RFC2822 specifies that. See "3.6 Field definitions", third paragraph, first two sentences.

In that sense, technically they are not "bad mail headers", but at the same time, since it is valid in any order, if _one_ popular MTA is unconfortable with a particular ordering, we could order things differently to make it happier (mind you, this would not work for more than one such broken MTAs).

Another thing I've been considering is to handle UTF-8 (or i18n.commitencoding in general) a bit better. We currently do not have Content-Type: header, so if you pipe the output to "am", it must be invoked without "-u" to make sure that it takes things as-is ("am -u" assumes things are in latin1 without Content-Type:). If we start to tackle that issue, we might also want to do RFC2047 in headers.