git/Documentation/CodingGuidelines, branch v2.3.8Mirror of https://git.kernel.org/pub/scm/git/git.git/
https://git.shady.money/git/atom?h=v2.3.82015-04-21T19:12:19ZMerge branch 'jg/cguide-we-cannot-count' into maint2015-04-21T19:12:19ZJunio C Hamanogitster@pobox.com2015-04-21T19:12:19Zurn:sha1:e8281f01642fe17d6f44b3b18ed333b322770e81
* jg/cguide-we-cannot-count:
CodingGuidelines: update 'rough' rule count
CodingGuidelines: update 'rough' rule count2015-04-14T16:50:31ZJulian Gindijuliangindi@gmail.com2015-04-13T12:54:14Zurn:sha1:6c3b2afe6f64d33c176a8d369793392d7659fd6f
Changed inaccurate count of "rough rules" from three to the more
generic 'a few'.
Signed-off-by: Julian Gindi <juliangindi@gmail.com>
Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CodingGuidelines: describe naming rules for configuration variables2015-02-02T19:28:55ZJunio C Hamanogitster@pobox.com2015-01-27T20:26:03Zurn:sha1:35840a3e789dd67528caefc146deb698bd6ac7a5
We may want to say something about command line option names in the
new section as well, but for now, let's make sure everybody is clear
on how to structure and name their configuration variables.
The text for the rules are partly taken from the log message of
Jonathan's 6b3020a2 (add: introduce add.ignoreerrors synonym for
add.ignore-errors, 2010-12-01).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'po/error-message-style'2014-07-16T18:33:03ZJunio C Hamanogitster@pobox.com2014-07-16T18:33:03Zurn:sha1:7591e2c53c6f02626e376a98b5f95745fbfe108f
* po/error-message-style:
doc: give some guidelines for error messages
doc: give some guidelines for error messages2014-07-10T20:31:55ZPhilip Oakleyphilipoakley@iee.org2014-06-16T12:55:57Zurn:sha1:0ae0e882b2dd8048e2096138561f0b2ab0cad454
Clarify error message puntuation to reduce review workload.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CodingGuidelines: avoid "test <cond> -a/-o <cond>"2014-05-20T18:19:43ZJunio C Hamanogitster@pobox.com2014-05-20T18:12:02Zurn:sha1:897f964c0dce8e7cc2cc53bb19b83cadce106773
The construct is error-prone; "test" being built-in in most modern
shells, the reason to avoid "test <cond> && test <cond>" spawning
one extra process by using a single "test <cond> -a <cond>" no
longer exists.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CodingGuidelines: on splitting a long line2014-05-02T21:08:16ZJunio C Hamanogitster@pobox.com2014-05-02T20:42:39Zurn:sha1:f26443da0449c459dab8b91d963bd91dd4335657
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CodingGuidelines: on comparison2014-05-02T20:44:46ZJunio C Hamanogitster@pobox.com2014-04-30T21:26:23Zurn:sha1:5db9ab82b94fab16e69b0228aaf1e972520bd04a
There are arguments for writing a conditional as "a < b" rather than
"b > a", or vice versa. Let's give guidance on which we prefer.
See http://thread.gmane.org/gmane.comp.version-control.git/3903/focus=4126
for the original discussion.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CodingGuidelines: do not call the conditional statement "if()"2014-05-02T20:26:07ZJunio C Hamanogitster@pobox.com2014-04-30T21:25:47Zurn:sha1:691d0dd0a9c901286c2a0a28c30ec4d13bcd2032
The point immediately before it is about having SP after the control
keyword. Spell it out as 'an "if" statement' instead.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CodingGuidelines: give an example for shell function preamble2014-05-02T20:24:57ZJunio C Hamanogitster@pobox.com2014-04-30T21:25:11Zurn:sha1:6117a3d4946e35c7d4a38c0b443891c81808a838
Signed-off-by: Junio C Hamano <gitster@pobox.com>