Markdownize CONVENTIONS
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 488732a..8561794 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -43,5 +43,5 @@ porting code *from* to see what you need to do.
We like to keep the source code consistent and easy to read. Maintaining this
takes some discipline, but it's been more than worth it. Take a look at the
-[conventions file](https://github.com/libgit2/libgit2/blob/development/CONVENTIONS).
+[conventions file](https://github.com/libgit2/libgit2/blob/development/CONVENTIONS.md).
diff --git a/CONVENTIONS b/CONVENTIONS
deleted file mode 100644
index f082d8e..0000000
--- a/CONVENTIONS
+++ /dev/null
@@ -1,107 +0,0 @@
-libgit2 conventions
-===================
-
-Namespace Prefixes
-------------------
-
-All types and functions start with 'git_'.
-
-All #define macros start with 'GIT_'.
-
-
-Type Definitions
-----------------
-
-Most types should be opaque, e.g.:
-
-----
- typedef struct git_odb git_odb;
-----
-
-with allocation functions returning an "instance" created within
-the library, and not within the application. This allows the type
-to grow (or shrink) in size without rebuilding client code.
-
-
-Public Exported Function Definitions
-------------------------------------
-
-All exported functions must be declared as:
-
-----
- GIT_EXTERN(result_type) git_modulename_functionname(arg_list);
-----
-
-
-Semi-Private Exported Functions
--------------------------------
-
-Functions whose modulename is followed by two underscores,
-for example 'git_odb__read_packed', are semi-private functions.
-They are primarily intended for use within the library itself,
-and may disappear or change their signature in a future release.
-
-
-Calling Conventions
--------------------
-
-Functions should prefer to return a 'int' to indicate success or
-failure and supply any output through the first argument (or first
-few arguments if multiple outputs are supplied).
-
-int status codes are 0 for GIT_OK and < 0 for an error.
-This permits common POSIX result testing:
-
-----
- if (git_odb_open(&odb, path))
- abort("odb open failed");
-----
-
-Functions returning a pointer may return NULL instead of an int
-if there is only one type of failure (GIT_ENOMEM).
-
-Functions returning a pointer may also return NULL if the common
-case needed by the application is strictly success/failure and a
-(possibly slower) function exists that the caller can use to get
-more detailed information. Parsing common data structures from
-on-disk formats is a good example of this pattern; in general a
-"corrupt" entity can be treated as though it does not exist but
-a more sophisticated "fsck" support function can report how the
-entity is malformed.
-
-
-Documentation Fomatting
------------------------
-
-All comments should conform to Doxygen "javadoc" style conventions
-for formatting the public API documentation.
-
-
-Public Header Format
---------------------
-
-All public headers defining types, functions or macros must use
-the following form, where ${filename} is the name of the file,
-after replacing non-identifier characters with '_'.
-
-----
- #ifndef INCLUDE_git_${filename}_h__
- #define INCLUDE_git_${filename}_h__
-
- #include "git/common.h"
-
- /**
- * @file git/${filename}.h
- * @brief Git some description
- * @defgroup git_${filename} some description routines
- * @ingroup Git
- * @{
- */
- GIT_BEGIN_DECL
-
- ... definitions ...
-
- /** @} */
- GIT_END_DECL
- #endif
-----
diff --git a/CONVENTIONS.md b/CONVENTIONS.md
new file mode 100644
index 0000000..06d3e87
--- /dev/null
+++ b/CONVENTIONS.md
@@ -0,0 +1,107 @@
+libgit2 conventions
+===================
+
+Namespace Prefixes
+------------------
+
+All types and functions start with 'git_'.
+
+All #define macros start with 'GIT_'.
+
+
+Type Definitions
+----------------
+
+Most types should be opaque, e.g.:
+
+```C
+ typedef struct git_odb git_odb;
+```
+
+with allocation functions returning an "instance" created within
+the library, and not within the application. This allows the type
+to grow (or shrink) in size without rebuilding client code.
+
+
+Public Exported Function Definitions
+------------------------------------
+
+All exported functions must be declared as:
+
+```C
+ GIT_EXTERN(result_type) git_modulename_functionname(arg_list);
+```
+
+
+Semi-Private Exported Functions
+-------------------------------
+
+Functions whose modulename is followed by two underscores,
+for example 'git_odb__read_packed', are semi-private functions.
+They are primarily intended for use within the library itself,
+and may disappear or change their signature in a future release.
+
+
+Calling Conventions
+-------------------
+
+Functions should prefer to return a 'int' to indicate success or
+failure and supply any output through the first argument (or first
+few arguments if multiple outputs are supplied).
+
+int status codes are 0 for GIT_OK and < 0 for an error.
+This permits common POSIX result testing:
+
+```C
+ if (git_odb_open(&odb, path))
+ abort("odb open failed");
+```
+
+Functions returning a pointer may return NULL instead of an int
+if there is only one type of failure (GIT_ENOMEM).
+
+Functions returning a pointer may also return NULL if the common
+case needed by the application is strictly success/failure and a
+(possibly slower) function exists that the caller can use to get
+more detailed information. Parsing common data structures from
+on-disk formats is a good example of this pattern; in general a
+"corrupt" entity can be treated as though it does not exist but
+a more sophisticated "fsck" support function can report how the
+entity is malformed.
+
+
+Documentation Fomatting
+-----------------------
+
+All comments should conform to Doxygen "javadoc" style conventions
+for formatting the public API documentation.
+
+
+Public Header Format
+--------------------
+
+All public headers defining types, functions or macros must use
+the following form, where ${filename} is the name of the file,
+after replacing non-identifier characters with '_'.
+
+```C
+ #ifndef INCLUDE_git_${filename}_h__
+ #define INCLUDE_git_${filename}_h__
+
+ #include "git/common.h"
+
+ /**
+ * @file git/${filename}.h
+ * @brief Git some description
+ * @defgroup git_${filename} some description routines
+ * @ingroup Git
+ * @{
+ */
+ GIT_BEGIN_DECL
+
+ ... definitions ...
+
+ /** @} */
+ GIT_END_DECL
+ #endif
+```