[x264-devel] fix rd related functions

Tomas Carnecky tom at dbservice.com
Wed Mar 5 16:29:17 CET 2008


Pierre d'Herbemont wrote:
> On Mar 5, 2008, at 2:35 PM, Noboru Asai wrote:
> 
>> Any comments are welcome.
> 
> You might want to use git-format-patch. It's a bit nicer for committers.

Here is a nice guide how to use git-format-patch and have the mails 
automatically sent or copied to an imap folder as drafts:

http://wiki.winehq.org/GitWine#head-f7a29e7ed999b5924748a60c5a1cd4a019032d26

git-format-patch creates one email per patch, if several patches depend 
on each other, git-format-patch can add numbers to the subject line (use 
the -n switch), like this: "[PATCH x/y] commit message", so that the 
commiter knows to apply them in the right order.

git-format-patch takes the first line of the commit message as the 
subject, the rest of the commit message goes into the email body. Then 
it adds a '---' delimiter following by a git diffstat (git-diff --stat). 
git-am ignores everything after that delimiter, so you can add your own 
comments after the diffstat, in case there is anything you want to add 
but don't want to appear in the commit message.

Then there is the question whether to use git-format-patch --inline or 
--attach or neither. If the code is more then 80 character per line, I 
advise to use --inline or --attach, otherwise your email client may wrap 
the lines when you send the email. The wine source code is more then 80 
chars in many places so the folks there use --attach or --inline. The 
linux kernel is strictly max 80 chars so most of the patches sent to the 
LKML are in the message body. (This may be a bit misleading: --inline 
does not mean the patch is part of the message body, it still creates a 
multipart/mixed mail! Read the git-format-patch manpage.)

I hope this gets you all accustomed to git :)

tom


More information about the x264-devel mailing list