On Mon, Sep 07 2009, Pierre Habouzit wrote:
> On Mon, Sep 07, 2009 at 10:30:14PM +0200, Raphael Hertzog wrote:
>> git format-patch alone will stil not be enough to generate a DEP3-compliant
>> header but would that resolve your concerns?
>
> It will be compatible if you relax the use of headers to pseudo headers,
> and forget about your (sorry) ridiculous request for Description to be a
> rfc822 formatted field. Not only it's never used by anyone, but it's
> also a major PITA to edit.
>
> Like I said in my other mail, you want a Subject as a summary, and what
> you call Description is all that:
> - isn't a header
> - isn't a recognized pseudo-header
> - is before the patch or an optional "---\n" line.
>
> It's a pretty simple definition, rather simple to implement in any kind
> of patch parsing tool.
>
> Indeed it's not compatible with grep-dctrl or whatever, but sadly for
> you, there _IS_ a standard for patches already, and it looks like that:
>
> - http://lkml.org/lkml/2009/8/31/369
> - http://lkml.org/lkml/2009/8/31/40
> - http://article.gmane.org/gmane.comp.version-control.git/126207
> - http://article.gmane.org/gmane.comp.parsers.sparse/2001
> - and I could go on with wine, x.org, gnome, ... patch submissions...
> damn even the glibc nowadays !
>
>> Anyway, I'd rather wait some time until people have tried using this
>> format before deciding if we must make some special case due to
>> git format-patch.
>
> It's not a special case. Kernel people, git people, gnome people, X.org
> people, all can cherry-pick patches and format-patch them away. If you
> ask them to add one missing header like the actual source or commid-id
> they took the patch from, they'll probably do it (I would at least). If
> you ask to rewrite the full stuff, then really, "go to hell" will
> probably be the (sane) answer you'll get.
(Adding SELinux mailing lists where git format-patch rules). I
think that git format-patch format seems to be emerging as a de facto
standard for interchanging changesets, and if we are to create a new
standard, we should stick close to ones that exist and are popular, and
only differ from that if there is a compelling reason to be different.
Is there a compelling reason to differ from what git
format-patch and git am already use?
manoj
--
"Every year a few research results pay the freight for all the rest."
Robert A. Frosch, General Motors
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C