user/sven/git.git/Documentation/CodingGuidelines, branch v2.26.0-rc2

Documentation: fix a bunch of typos, both old and new

2019-11-07T04:42:00Z

Reported-by: Jens Schleusener Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

Merge branch 'jc/post-c89-rules-doc'

2019-07-25T20:59:23Z

We have been trying out a few language features outside c89; the coding guidelines document did not talk about them and instead had a blanket ban against them. * jc/post-c89-rules-doc: CodingGuidelines: spell out post-C89 rules

CodingGuidelines: spell out post-C89 rules

2019-07-18T22:16:04Z

Even though we have been sticking to C89, there are a few handy features we borrow from more recent C language in our codebase after trying them in weather balloons and saw that nobody screamed. Spell them out. While at it, extend the existing variable declaration rule a bit to read better with the newly spelled out rule for the for loop. Signed-off-by: Junio C Hamano

Merge branch 'es/git-debugger-doc'

2019-06-17T17:15:14Z

Doc update. * es/git-debugger-doc: doc: hint about GIT_DEBUGGER in CodingGuidelines

doc: hint about GIT_DEBUGGER in CodingGuidelines

2019-05-28T20:42:33Z

We check for a handy environment variable GIT_DEBUGGER when running via bin-wrappers/, but this feature is undocumented. Add a hint to how to use it into the CodingGuidelines (which is where other useful environment settings like DEVELOPER are documented). Signed-off-by: Emily Shaffer Signed-off-by: Junio C Hamano

doc/CodingGuidelines: URLs and paths as monospace

2019-03-13T02:14:10Z

The current documentation uses both quotes (italics) and backquotes (monospace) to render URLs and pathnames, which is inconsistent. Document a best practice in CodingGuidelines to help reduce inconsistencies in the future. We set the best practice to using backquotes, since: * It is already an established practice. For exemple: $ git grep "'[^']/*[^']'" | wc -l 206 $ git grep '`[^`]/*[^`]`' | wc -l 690 There are false positives on both sides, but after a cursory look at the output of both, it doesn't seem the false positive rate is really higher in the second case. At least, this shows that the existing documentation uses inconsistent formatting, and that it would be good to do something about it. * It may be debatable whether path names need to be typed in monospace but having them in italics is really unusual. Signed-off-by: Corentin BOMPARD Signed-off-by: Nathan BERBEZIER Signed-off-by: Pablo CHABANNE Signed-off-by: Matthieu MOY Signed-off-by: Junio C Hamano

Merge branch 'jc/how-to-document-api'

2018-10-19T04:34:05Z

Doc update. * jc/how-to-document-api: CodingGuidelines: document the API in *.h files

Documentation: add shell guidelines

2018-10-06T23:51:17Z

Add the following guideline to Documentation/CodingGuidelines: Break overlong lines after "&&", "||", and "|", not before them; that way the command can continue to subsequent lines without backslash at the end. And the following to t/README (since it is specific to writing tests): Pipes and $(git ...) should be avoided when they swallow exit codes of Git processes Signed-off-by: Matthew DeVore Signed-off-by: Junio C Hamano

CodingGuidelines: document the API in *.h files

2018-09-29T18:18:01Z

It makes it harder to let the API description and the reality drift apart if the doc is kept close to the implementation or the header of the API. We have been slowly migrating API docs out of the Documentation/technical/api-* to *.h files, and the development community generally considers that how inline docs in strbuf.h is done the best current practice. We recommend documenting in the header over documenting near the implementation to encourage people to write the docs that are readable without peeking at the implemention. Helped-by: Jeff King Signed-off-by: Junio C Hamano

CodingGuidelines: mention "static" and "extern"

2018-02-08T22:20:43Z

It perhaps goes without saying that file-local stuff should be marked static, but it does not hurt to remind people. Less obvious is that we are settling on "do not include extern in function declarations". It is already the default unless the function was previously declared static (but if you are following a static declaration with an unmarked one, you should think about why you are declaring the thing twice). And so it just becomes an extra noise-word in our header files. We used to give the opposite advice, so there are quite a few "extern" markers in early Git code. But this at least makes a concrete suggestion that we can follow going forward. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano