[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