NuKVM/libvirt
3
0
Fork 0
mirror of https://github.com/libvirt/libvirt.git synced 2025-02-25 18:55:26 -06:00
Code Issues Packages Projects Releases Wiki Activity

docs: point out git send-email location, be more stern about make check

Browse Source 
An email came to libvir-list wondering why the git send-email command
was missing in spite of having git installed; this is due to the
send-email command being in a sub-package of the main git package.

While touching the hacking file, I thought it would be useful to 1)
indicate the location of the source (docs/hacking.html.in) in the
message at the top of HACKING, and also to make the note about running
"make check" and "make syntax-check" a bit more stern.
This commit is contained in:
Laine Stump
2012-09-06 13:21:21 -04:00
parent 892242519a
commit 7038322991
3 changed files with 34 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
HACKING
View File

@@ -1,5 +1,6 @@
-*- buffer-read-only: t -*- vi: set ro:
DO NOT EDIT THIS FILE! IT IS GENERATED AUTOMATICALLY!
DO NOT EDIT THIS FILE! IT IS GENERATED AUTOMATICALLY
from docs/hacking.html.in!
@@ -32,11 +33,14 @@ Then, when you want to post your patches:
git pull --rebase
(fix any conflicts)
git send-email --cover-letter --no-chain-reply-to --annotate --to=libvir-list@redhat.com master
git send-email --cover-letter --no-chain-reply-to --annotate \
--to=libvir-list@redhat.com master
For a single patch you can omit "--cover-letter", but series of a two or more
patches needs a cover letter. If you get tired of typing
"--to=libvir-list@redhat.com" designation you can set it in git config:
(Note that the "git send-email" subcommand is usually not in the main git
package, but part of a sub-package called "git-email".) For a single patch you
can omit "--cover-letter", but series of a two or more patches needs a cover
letter. If you get tired of typing "--to=libvir-list@redhat.com" designation
you can set it in git config:
git config sendemail.to libvir-list@redhat.com
@@ -56,9 +60,11 @@ though).
(3) Split large changes into a series of smaller patches, self-contained if
possible, with an explanation of each patch and an explanation of how the
sequence of patches fits together. Moreover, please keep in mind that it's
required to be able to compile cleanly after each patch. A feature does not
have to work until the end of a series, as long as intermediate patches don't
cause test-suite failures.
required to be able to compile cleanly (*including* "make check" and "make
syntax-check") after each patch. A feature does not have to work until the end
of a series, but intermediate patches must compile and not cause test-suite
failures (this is to preserve the usefulness of "git bisect", among other
things).