git/Documentation/CodingGuidelines, branch v2.46.2

Merge branch 'jc/coding-style-c-operator-with-spaces' into maint-2.46

2024-09-13T22:26:51Z

Write down whitespacing rules around C opeators. * jc/coding-style-c-operator-with-spaces: CodingGuidelines: spaces around C operators

Merge branch 'jc/document-use-of-local' into maint-2.46

2024-08-26T18:10:23Z

Doc update. * jc/document-use-of-local: doc: note that AT&T ksh does not work with our test suite

CodingGuidelines: spaces around C operators

2024-08-20T21:10:10Z

As we have operated with "write like how your surrounding code is written" for too long, after a huge code drop from another project, we'll end up being inconsistent before such an imported code is cleaned up. We have many uses of cast operator with a space before its operand, mostly in the reftable code. Spell the convention out before it spreads to other places. Signed-off-by: Junio C Hamano

CodingGuidelines: document a shell that "fails" "VAR=VAL shell_func"

2024-07-23T15:28:43Z

Over the years, we accumulated the community wisdom to avoid the common "one-short export" construct for shell functions, but seem to have lost on which exact platform it is known to fail. Now during an investigation on a breakage for a recent topic, we found one example of failing shell. Let's document that. This does *not* mean that we can freely start using the construct once Ubuntu 20.04 is retired. But it does mean that we cannot use the construct until Ubuntu 20.04 is fully retired from the machines that matter. Moreover, posix explicitly says that the behaviour for the construct is unspecified. Helped-by: Kyle Lippincott Signed-off-by: Junio C Hamano

doc: note that AT&T ksh does not work with our test suite

2024-07-15T17:14:52Z

The scripted Porcelain commands do not allow use of "local" because it is not universally supported, but we use it liberally in our test scripts, which means some POSIX compliant shells (like "ksh93") can not be used to run our tests. Document the status quo, to help the next person who gets perplexed seeing our tests fail. Signed-off-by: Junio C Hamano

Merge branch 'jc/local-extern-shell-rules'

2024-04-16T21:50:27Z

Document and apply workaround for a buggy version of dash that mishandles "local var=val" construct. * jc/local-extern-shell-rules: t1016: local VAR="VAL" fix t0610: local VAR="VAL" fix t: teach lint that RHS of 'local VAR=VAL' needs to be quoted t: local VAR="VAL" (quote ${magic-reference}) t: local VAR="VAL" (quote command substitution) t: local VAR="VAL" (quote positional parameters) CodingGuidelines: quote assigned value in 'local var=$val' CodingGuidelines: describe "export VAR=VAL" rule

CodingGuidelines: quote assigned value in 'local var=$val'

2024-04-06T05:50:05Z

Dash bug https://bugs.launchpad.net/ubuntu/+source/dash/+bug/139097 lets the shell erroneously perform field splitting on the expansion of a command substitution during declaration of a local or an extern variable. The explanation was stolen from ebee5580 (parallel-checkout: avoid dash local bug in tests, 2021-06-06). Signed-off-by: Junio C Hamano

CodingGuidelines: describe "export VAR=VAL" rule

2024-04-06T05:48:12Z

https://lore.kernel.org/git/201307081121.22769.tboegi@web.de/ resulted in 9968ffff (test-lint: detect 'export FOO=bar', 2013-07-08) to add a rule to t/check-non-portable-shell.pl script to reject export VAR=VAL and suggest us to instead write it as two statements, i.e., VAR=VAL export VAR This however was not spelled out in the CodingGuidelines document. We may want to re-evaluate the rule since it is from ages ago, but for now, let's make the written rule and what the automation enforces consistent. Signed-off-by: Junio C Hamano

doc: rework CodingGuidelines with new formatting rules

2024-03-29T17:57:40Z

Literal and placeholder formatting is more heavily enforced, with some asciidoc magic. Basically, the markup is preserved everywhere. Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

Merge branch 'jc/doc-compat-util'

2024-03-05T17:44:43Z

Clarify wording in the CodingGuidelines that requires to be the first header file. * jc/doc-compat-util: doc: clarify the wording on requirement