git/Documentation/CodingGuidelines, branch main

CodingGuidelines: document our style for flags

2026-04-01T03:43:13Z

We have recently iterated a bit on our style for flags. Document this. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'lo/repo-leftover-bits'

2026-03-04T18:53:01Z

Clean-up the code around "git repo info" command. * lo/repo-leftover-bits: Documentation/git-repo: capitalize format descriptions Documentation/git-repo: replace 'NUL' with '_NUL_' t1901: adjust nul format output instead of expected value t1900: rename t1900-repo to t1900-repo-info repo: rename struct field to repo_info_field repo: replace get_value_fn_for_key by get_repo_info_field repo: rename repo_info_fields to repo_info_field CodingGuidelines: instruct to name arrays in singular

Merge branch 'jc/doc-cg-needswork'

2026-02-25T19:54:17Z

A CodingGuidelines update. * jc/doc-cg-needswork: CodingGuidelines: document NEEDSWORK comments

CodingGuidelines: instruct to name arrays in singular

2026-02-25T19:47:41Z

Arrays should be named in the singular form, ensuring that when accessing an element within an array (e.g. dog[0]) it's clear that we're referring to an element instead of a collection. Add a new rule to CodingGuidelines asking for arrays to be named in singular instead of plural. Helped-by: Eric Sunshine Signed-off-by: Lucas Seiki Oshiro Signed-off-by: Junio C Hamano

CodingGuidelines: document NEEDSWORK comments

2026-02-14T15:37:33Z

We often say things like /* NEEDSWORK: further _do_ _this_ */ in comments, but it is a short-hand to say "We might later want to do this. We might not. We do not have to decide it right now at this moment in the commit this comment was added. If somebody is inclined to work in this area further, the first thing they need to do is to figure out if it truly makes sense to do so, before blindly doing it." This seems to have never been documented. Do so now. Signed-off-by: Junio C Hamano

CodingGuidelines: document // comments

2026-02-11T21:29:36Z

We do not use // comments in our C code, which is implied by the description of multi-line comment rule and its examples, but is not explicitly spelled out. Spell it out. Signed-off-by: Junio C Hamano

Documentation: note styling for bit fields

2025-08-26T22:46:03Z

Our codebase uses a lot of bit field variables, generally to mark boolean type variables. While there is a formatting rule in the '.clang-format', there is no guideline specified in the 'CodingGuidelines'. Since the '.clang-format' is not yet enforced, let's also add a guideline with the same rule as mentioned in the '.clang-format', which is to not use any spaces around the colon, like so: unsigned my_field:1; unsigned other_field:1; unsigned field_with_longer_name:1; This would allow us not to modify the clang-format file, and more importantly, discourage people from doing ugly alignment with spaces, i.e. unsigned my_field : 1; unsigned other_field : 1; unsigned field_with_longer_name : 1; Helped-by: Junio C Hamano Signed-off-by: Karthik Nayak Signed-off-by: Junio C Hamano

Merge branch 'jc/doc-release-vs-clear'

2025-08-04T15:10:35Z

Doc update. * jc/doc-release-vs-clear: CodingGuidelines: clarify that S_release() does not reinitialize

Merge branch 'jc/document-test-balloons-in-flight'

2025-08-01T18:27:13Z

To help our developers, document what C99 language features are being considered for adoption, in addition to what past experiments have already decided. * jc/document-test-balloons-in-flight: CodingGuidelines: document test balloons in flight

CodingGuidelines: clarify that S_release() does not reinitialize

2025-08-01T17:08:17Z

In the section for naming various API functions, the fact that S_release() only releases the resources without preparing the structure for immediate reuse becomes only apparent when you readentries for S_release() and S_clear(). Clarify the description of S_release() a bit to make the entry self sufficient. Signed-off-by: Junio C Hamano