delta/git.git/Documentation/CodingGuidelines, branch jk/robustify-parse-commit

CodingGuidelines: Documentation/*.txt are the sources

2013-05-10T19:13:08+00:00

People not familiar with AsciiDoc may not realize they are
supposed to update *.txt files and not *.html/*.1 files when
preparing patches to the project.

Signed-off-by: Dale Worley 
Signed-off-by: Junio C Hamano

CodingGuidelines: our documents are in AsciiDoc

2013-03-21T21:17:32+00:00

Before talking about notations such as optional [--option] enclosed
in brackets, state that the documents are in AsciiDoc and processed
into other formats.

Signed-off-by: Junio C Hamano

Merge branch 'tz/perl-styles'

2013-02-14T18:28:55+00:00

Add coding guidelines for writing Perl scripts for Git.

* tz/perl-styles:
  Update CodingGuidelines for Perl

Merge branch 'jk/python-styles'

2013-02-07T22:41:31+00:00

* jk/python-styles:
  CodingGuidelines: add Python coding guidelines

Update CodingGuidelines for Perl

2013-02-06T22:02:03+00:00

Add the coding guidelines for Perl.

Signed-off-by: Ted Zlatanov 
Signed-off-by: Junio C Hamano

Documentation: the name of the system is 'Git', not 'git'

2013-02-01T21:53:33+00:00

Signed-off-by: Thomas Ackermann 
Signed-off-by: Junio C Hamano

Documentation: avoid poor-man's small caps GIT

2013-02-01T21:53:25+00:00

In the earlier days, we used to spell the name of the system as GIT,
to simulate as if it were typeset with capital G and IT in small
caps.  Later we stopped doing so at around 1.6.5 days.

Let's stop doing so throughout the documentation.  The name to refer
to the whole system (and the concept it embodies) is "Git"; the
command end-users type is "git".  And document this in the coding
guideline.

Signed-off-by: Thomas Ackermann 
Signed-off-by: Junio C Hamano

CodingGuidelines: add Python coding guidelines

2013-01-30T20:49:28+00:00

These are kept short by simply deferring to PEP-8.  Most of the Python
code in Git is already very close to this style (some things in contrib/
are not).

Rationale for version suggestions:

 - Amongst the noise in [1], there isn't any disagreement about using
   2.6 as a base (see also [2]), although Brandon Casey recently added
   support for 2.4 and 2.5 to git-p4 [3].

 - Restricting ourselves to 2.6+ makes aiming for Python 3 compatibility
   significantly easier [4].

 - Advocating Python 3 support in all scripts is currently unrealistic
   because:

     - 'p4 -G' provides output in a format that is very hard to use with
       Python 3 (and its documentation claims Python 3 is unsupported).

     - Mercurial does not support Python 3.

     - Bazaar does not support Python 3.

 - But we should try to make new scripts compatible with Python 3
   because all new Python development is happening on version 3 and the
   Python community will eventually stop supporting Python 2 [5].

 - Python 3.1 is required to support the 'surrogateescape' error handler
   for encoding/decodng filenames to/from Unicode strings and Python 3.0
   is not longer supported.

[1] http://thread.gmane.org/gmane.comp.version-control.git/210329
[2] http://article.gmane.org/gmane.comp.version-control.git/210429
[3] http://thread.gmane.org/gmane.comp.version-control.git/214579
[4] http://docs.python.org/3.3/howto/pyporting.html#try-to-support-python-2-6-and-newer-only
[5] http://www.python.org/dev/peps/pep-0404/

Signed-off-by: Junio C Hamano

Documentation: move support for old compilers to CodingGuidelines

2012-12-17T02:30:53+00:00

The "Try to be nice to older C compilers" text is clearly a guideline
to be borne in mind whilst coding rather than when submitting patches.

Signed-off-by: Adam Spiers 
Signed-off-by: Junio C Hamano

Documentation/CodingGuidelines: spell out more shell guidelines

2012-08-15T18:00:39+00:00

In earlier days, "imitate the style in the neibouring code" was
sufficient to keep the coherent style, but over time some parts of
the codebase have drifted enough to make it ineffective.

Spell some of the guidelines out.

Signed-off-by: Heiko Voigt 
Signed-off-by: Junio C Hamano