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 <sriva...@debian.org> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org