kernel
/
git
mirror of https://git.kernel.org/pub/scm/git/git.git
1
0
Fork 0
Code Releases Activity

Merge branch 'js/contributor-docs-updates' into maint-2.43 

Doc update.

* js/contributor-docs-updates:
  SubmittingPatches: hyphenate non-ASCII
  SubmittingPatches: clarify GitHub artifact format
  SubmittingPatches: clarify GitHub visual
  SubmittingPatches: provide tag naming advice
  SubmittingPatches: update extra tags list
  SubmittingPatches: discourage new trailers
  SubmittingPatches: drop ref to "What's in git.git"
  CodingGuidelines: write punctuation marks
  CodingGuidelines: move period inside parentheses
maint
Junio C Hamano 2024-02-08 16:22:11 -08:00
parent 232953b904 291873e5d6
commit 5a322a2d3d
2 changed files with 24 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Documentation/CodingGuidelines
View File

@ -450,7 +450,7 @@ For C programs:
one of the approved headers that includes it first for you. (The one of the approved headers that includes it first for you. (The
approved headers currently include "builtin.h", approved headers currently include "builtin.h",
"t/helper/test-tool.h", "xdiff/xinclude.h", or "t/helper/test-tool.h", "xdiff/xinclude.h", or
"reftable/system.h"). You do not have to include more than one of "reftable/system.h".) You do not have to include more than one of
these. these.


- A C file must directly include the header files that declare the - A C file must directly include the header files that declare the
@ -578,7 +578,7 @@ Externally Visible Names
. The variable name describes the effect of tweaking this knob. . The variable name describes the effect of tweaking this knob.


The section and variable names that consist of multiple words are The section and variable names that consist of multiple words are
formed by concatenating the words without punctuations (e.g. `-`), formed by concatenating the words without punctuation marks (e.g. `-`),
and are broken using bumpyCaps in documentation as a hint to the and are broken using bumpyCaps in documentation as a hint to the
reader. reader.



31
Documentation/SubmittingPatches
View File

@ -355,9 +355,21 @@ If you like, you can put extra tags at the end:
patch after a detailed analysis. patch after a detailed analysis.
. `Tested-by:` is used to indicate that the person applied the patch . `Tested-by:` is used to indicate that the person applied the patch
and found it to have the desired effect. and found it to have the desired effect.
. `Co-authored-by:` is used to indicate that people exchanged drafts
of a patch before submitting it.
. `Helped-by:` is used to credit someone who suggested ideas for
changes without providing the precise changes in patch form.
. `Mentored-by:` is used to credit someone with helping develop a
patch as part of a mentorship program (e.g., GSoC or Outreachy).
. `Suggested-by:` is used to credit someone with suggesting the idea
for a patch.


You can also create your own tag or use one that's in common usage While you can also create your own trailer if the situation warrants it, we
such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:". encourage you to instead use one of the common trailers in this project
highlighted above.

Only capitalize the very first letter of tags, i.e. favor
"Signed-off-by" over "Signed-Off-By" and "Acked-by:" over "Acked-By".


[[git-tools]] [[git-tools]]
=== Generate your patch using Git tools out of your commits. === Generate your patch using Git tools out of your commits.
@ -570,7 +582,7 @@ their trees themselves.
master). master).


* Read the Git mailing list, the maintainer regularly posts messages * Read the Git mailing list, the maintainer regularly posts messages
entitled "What's cooking in git.git" and "What's in git.git" giving entitled "What's cooking in git.git" giving
the status of various proposed changes. the status of various proposed changes.


== GitHub CI[[GHCI]] == GitHub CI[[GHCI]]
@ -590,11 +602,12 @@ After the initial setup, CI will run whenever you push new changes
to your fork of Git on GitHub. You can monitor the test state of all your to your fork of Git on GitHub. You can monitor the test state of all your
branches here: `https://github.com/<Your GitHub handle>/git/actions/workflows/main.yml` branches here: `https://github.com/<Your GitHub handle>/git/actions/workflows/main.yml`


If a branch did not pass all test cases then it is marked with a red If a branch does not pass all test cases then it will be marked with a
cross. In that case you can click on the failing job and navigate to red +x+, instead of a green check. In that case, you can click on the
"ci/run-build-and-tests.sh" and/or "ci/print-test-failures.sh". You failing job and navigate to "ci/run-build-and-tests.sh" and/or
can also download "Artifacts" which are tarred (or zipped) archives "ci/print-test-failures.sh". You can also download "Artifacts" which
with test data relevant for debugging. are zip archives containing tarred (or zipped) archives with test data
relevant for debugging.


Then fix the problem and push your fix to your GitHub fork. This will Then fix the problem and push your fix to your GitHub fork. This will
trigger a new CI build to ensure all tests pass. trigger a new CI build to ensure all tests pass.
@ -686,7 +699,7 @@ message to an external program, and this is a handy way to drive
`git am`. However, if the message is MIME encoded, what is `git am`. However, if the message is MIME encoded, what is
piped into the program is the representation you see in your piped into the program is the representation you see in your
`*Article*` buffer after unwrapping MIME. This is often not what `*Article*` buffer after unwrapping MIME. This is often not what
you would want for two reasons. It tends to screw up non ASCII you would want for two reasons. It tends to screw up non-ASCII
characters (most notably in people's names), and also characters (most notably in people's names), and also
whitespaces (fatal in patches). Running "C-u g" to display the whitespaces (fatal in patches). Running "C-u g" to display the
message in raw form before using "|" to run the pipe can work message in raw form before using "|" to run the pipe can work