| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
The test failure is unrelated |
Sorry, something went wrong.
| // Including the `git2.h` header will include all the other libgit2 headers | ||
| // that you need. It should be the only thing you need to include in order | ||
| // to compile properly and get all the libgit2 API. | ||
| /* [**libgit2**][lg] is a portable, pure C implementation of the Git core |
There was a problem hiding this comment.
This would hide this text from the docco output. We need C++ comments or /** here for it to show.
Sorry, something went wrong.
There was a problem hiding this comment.
Now that you mention docco: my patches have another problem in that they change the order of documentation. With these patches, we will not have a logical order of initializing the library, opening repo, etc., but instead first describe all functions and at long last initialize the library.
I guess I'll re-order this such that the single functions will go after the main function.
Sorry, something went wrong.
|
Okay, fixed up comments such that they appear in the correct order and are evaluated as documentation. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Recently, I wanted to build our examples and was hugely annoyed by all those warnings that were spilled left and right. So I cleaned up our tests, particularly the examples/general.c one, so that no warnings get thrown anymore.
Furthermore, I've changed CI scripts to build all tests to catch errors early on. I know that the examples aren't of huge importance, but considering they might be the first contact point with libgit2 for new developers, I'd say they should be reasonably clean and, as a bare minimum, compile. So that's why I think it is only sensible to break our CI builds when changes inside libgit2 break our examples.