[RFC] format-patch stuff

[RFC] format-patch stuff

[Daniel Barkalow]

It would be nice if git-format-patch would generate a [PATCH 0/n] message 
at the start of the series if some option were given. This would, of 
course, have to be editted afterwards to include actual information, but 
it would at least be pre-generated in series and with the configured 
headers and such.

Shouldn't the format.headers configuration automatically apply the correct 
line termination? Currently, you need to know to put in \r\n at the end of 
each one, and the example isn't even right (only puts \n).

Once we've got library support for remotes configuration, it would be nice 
to be able to have "mailto:" remotes with emailed patch configuration 
stuff per-destination.

	-Daniel
*This .sig left intentionally blank*

Re: [RFC] format-patch stuff

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> It would be nice if git-format-patch would generate a [PATCH 0/n] message 
> at the start of the series if some option were given. This would, of 
> course, have to be editted afterwards to include actual information, but 
> it would at least be pre-generated in series and with the configured 
> headers and such.

It would be helpful for git-send-email users.  I've done that by
hand by copying 0001-*.txt to 0000-*.txt and editing as needed
by hand.

> Shouldn't the format.headers configuration automatically apply the correct 
> line termination? Currently, you need to know to put in \r\n at the end of 
> each one, and the example isn't even right (only puts \n).

Sorry, I do not follow.  Where does that "\r\n" come from?  If
you are talking about RFC 2822 line ending conventions, I think
that is a job for MUA (including git-send-email).  Remember,
MUA's are not the only consumer of format-patch output.

Although "2.3. Body" says "CR and LF MUST only occur together as
CRLF", the body of the text we output from format-patch is a
straight text with LF termination and let the MUA handle that
SMTP specific conversion.  I do not think there is reason to
treat the header part any differently.

Re: [RFC] format-patch stuff

[Frank Lichtenheld]

On Sat, May 12, 2007 at 01:24:25PM -0700, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > It would be nice if git-format-patch would generate a [PATCH 0/n] message 
> > at the start of the series if some option were given. This would, of 
> > course, have to be editted afterwards to include actual information, but 
> > it would at least be pre-generated in series and with the configured 
> > headers and such.
> 
> It would be helpful for git-send-email users.  I've done that by
> hand by copying 0001-*.txt to 0000-*.txt and editing as needed
> by hand.

But git-send-email users can already use --compose which serves
exactly this use case, doesn't it?

I would have thought such an option would be useful exactly for
git-send-email non-users ;)

Gruesse,
-- 
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/

Re: [RFC] format-patch stuff

[david]

On Sat, 12 May 2007, Daniel Barkalow wrote:

> It would be nice if git-format-patch would generate a [PATCH 0/n] message
> at the start of the series if some option were given. This would, of
> course, have to be editted afterwards to include actual information, but
> it would at least be pre-generated in series and with the configured
> headers and such.

instead of the 0/n message be empty, have it start off listing the subject 
lines of the patches to follow (makeing it easier to add any comments 
about them)

David Lang

Re: [RFC] format-patch stuff

[Junio C Hamano]

david@lang.hm writes:

> On Sat, 12 May 2007, Daniel Barkalow wrote:
>
>> It would be nice if git-format-patch would generate a [PATCH 0/n] message
>> at the start of the series if some option were given. This would, of
>> course, have to be editted afterwards to include actual information, but
>> it would at least be pre-generated in series and with the configured
>> headers and such.
>
> instead of the 0/n message be empty, have it start off listing the
> subject lines of the patches to follow (makeing it easier to add any
> comments about them)

Sounds sane.  "git-format-patch -n --cover origin..master"?