mirror of
https://review.haiku-os.org/buildtools
synced 2025-02-07 14:34:51 +01:00
53 lines
2.1 KiB
Plaintext
53 lines
2.1 KiB
Plaintext
[Mostly copied from git's SubmittingPatches]
|
|
|
|
Commits:
|
|
|
|
- make commits of logical units
|
|
- check for unnecessary whitespace with "git diff --check"
|
|
before committing
|
|
- do not check in commented out code or unneeded files
|
|
- the first line of the commit message should be a short
|
|
description and should skip the full stop
|
|
- the body should provide a meaningful commit message, which
|
|
includes motivation for the change, and contrasts
|
|
its implementation with previous behaviour
|
|
- if you want your work included in isl.git, add a
|
|
"Signed-off-by: Your Name <you@example.com>" line to the
|
|
commit message (or just use the option "-s" when
|
|
committing) to confirm that you agree to the Developer's
|
|
Certificate of Origin
|
|
- make sure that you have tests for the bug you are fixing
|
|
- make sure that the test suite passes after your commit
|
|
|
|
Patch:
|
|
|
|
- use "git format-patch -M" to create the patch
|
|
- do not PGP sign your patch
|
|
- send a single patch per mail, e.g., using git-send-email(1)
|
|
- do not attach your patch, but read in the mail
|
|
body, unless you cannot teach your mailer to
|
|
leave the formatting of the patch alone.
|
|
- be careful doing cut & paste into your mailer, not to
|
|
corrupt whitespaces.
|
|
- provide additional information (which is unsuitable for
|
|
the commit message) between the "---" and the diffstat
|
|
- if you change, add, or remove a command line option or
|
|
make some other user interface change, the associated
|
|
documentation should be updated as well.
|
|
- if your name is not writable in ASCII, make sure that
|
|
you send off a message in the correct encoding.
|
|
- send the patch to the development mailing list
|
|
(isl-development@googlegroups.com). If you use
|
|
git-send-email(1), please test it first by sending email
|
|
to yourself.
|
|
|
|
Revisions:
|
|
|
|
- add the revision number inside square brackets to
|
|
the subject line (e.g., use --subject-prefix='PATCH v2'
|
|
when creating the patch)
|
|
- recall the major issues discovered during the previous
|
|
review and explain how you addressed them or why you
|
|
disagree. Do so either in a cover letter, between the
|
|
"---" and the diffstat or in a separate message.
|