275
edits
Changes
Jump to navigation
Jump to search
Line 51:
Line 51: − + Line 58:
Line 58: − git format-patch+ Line 64:
Line 64: + + + + + + + + + + + + + + + + + + + + + + + + + + + +
→Make a patch: Fix git send-email example to use "criu-dev" instead of "master" branch
In case you'd rather have someone else run the tests, you can use travis-ci for your
In case you'd rather have someone else run the tests, you can use travis-ci for your
own github fork of CRIU. It will check the compilation for various supported platforms,
own github fork of CRIU. It will check the compilation for various supported platforms,
as well as run most of the tests from the suite. See https://travis-ci.org/xemul/criu
as well as run most of the tests from the suite. See https://travis-ci.org/checkpoint-restore/criu
for more details.
for more details.
To create a patch, run
To create a patch, run
git format-patch --signoff origin/criu-dev
You might need to read GIT documentation on how to prepare patches
You might need to read GIT documentation on how to prepare patches
http://git-scm.com/documentation for details. It should not be hard
http://git-scm.com/documentation for details. It should not be hard
at all.
at all.
We recommend to post patches using <code>git send-email</code>
git send-email --cover-letter --no-chain-reply-to --annotate \
--confirm=always --to=criu@openvz.org criu-dev
Note that the <code>git send-email</code> subcommand may not be in
the main git package and using it may require installation of a
separate package, for example the "git-email" package in Fedora and
Debian.
If this is your first time using git send-email, you might need to
configure it to point it to your SMTP server with something like:
git config --global sendemail.smtpServer stmp.example.net
If you get tired of typing <code>--to=criu@openvz.org</code> all the time,
you can configure that to be automatically handled as well:
git config sendemail.to criu@openvz.org
If a developer is sending another version of the patch (e.g. to address
review comments), they are advised to note differences to previous versions
after the <code>---</code> line in the patch so that it helps reviewers but
doesn't become part of git history. Moreover, such patch needs to be prefixed
correctly with <code>--subject-prefix=PATCHv2</code> appended to
<code>git send-email</code> (substitute <code>v2</code> with the correct
version if needed though).
== Sign your work ==
== Sign your work ==