summaryrefslogtreecommitdiff
path: root/docs
Commit message (Collapse)AuthorAgeFilesLines
* docs: add documentation for our coding stylePatrick Steinhardt2020-04-051-0/+364
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For years, we've repeatedly had confusion about what our actual coding style is not only for newcomers, but also across the core contributors. This can mostly be attributed to the fact that we do not have any coding conventions written down. This is now a thing of the past with the introduction of a new document that gives an initial overview of our style and most important best practices for both our C codebase as well as for CMake. While the proposed coding style for our C codebase should be rather uncontroversial, the coding style for CMake might be. This can be attributed to multiple facts. First, the CMake code base doesn't really have any uniform coding style and is quite outdated in a lot of places. Second, the proposed coding style actually breaks with our existing one: we currently use all-uppercase function names and variables, but the documented coding style says we use all-lowercase function names but all-uppercase variables. It's common practice in CMake to write variables in all upper-case, and in fact all variables made available by CMake are exactly that. As variables are case-sensitive in CMake, we cannot and shouldn't break with this. In contrast, function calls are case insensitive, and modern CMake always uses all-lowercase ones. I argue we should do the same to get in line with other codebases and to reduce the likelihood of repetitive strain injuries. So especially for CMake, the proposed coding style says something we don't have yet. I'm fine with that, as the document explicitly says that it's what we want to have and not what we have right now.
* docs: update changelog for v1.0Patrick Steinhardt2020-03-281-0/+51
|
* docs: update changelog for v0.99Edward Thomson2020-02-191-18/+342
| | | | | | Give the release a name, "Torschlusspanik" (the fear that time is running out to act). Indeed, the time is running out for changes to be included in v1.0.
* fuzzers: Fix the documentationlhchavez2020-02-151-6/+7
| | | | Some of the commands are now out of date.
* Merge pull request #5320 from josharian/minor-docsPatrick Steinhardt2019-12-131-2/+4
|\ | | | | Minor doc improvements
| * changelog: add more newly-accepted urlsJosh Bleecher Snyder2019-12-041-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | I encountered some problematic URLs, and was delighted to see that they were already fixed. I figured I may as well add them to the changelog. For the record, URLs with no path used to be rejected. That is arguably correct, but command line git accepts them. URLs with a path of / and a non-standard port used to have their port completely ignored!
* | changelog: document security fixesPatrick Steinhardt2019-12-101-0/+57
|/
* release.md: note that we do two security releasesethomson/release_docsEdward Thomson2019-12-041-1/+1
| | | Note that for security releases, we update the two most recent major release branches.
* cred: separate public interface from low-level detailsEtienne Samson2019-09-131-0/+8
|
* changelog: include security updatesusers/ethomson/security_updatesEdward Thomson2019-08-131-0/+10
|
* cmake: Modulize our TLS & hash detectionEtienne Samson2019-06-141-0/+7
| | | | | | | | | | | | | | | The interactions between `USE_HTTPS` and `SHA1_BACKEND` have been streamlined. Previously we would have accepted not quite working configurations (like, `-DUSE_HTTPS=OFF -DSHA1_BACKEND=OpenSSL`) and, as the OpenSSL detection only ran with `USE_HTTPS`, the link would fail. The detection was moved to a new `USE_SHA1`, modeled after `USE_HTTPS`, which takes the values "CollisionDetection/Backend/Generic", to better match how the "hashing backend" is selected, the default (ON) being "CollisionDetection". Note that, as `SHA1_BACKEND` is still used internally, you might need to check what customization you're using it for.
* http-parser: use our bundled http-parser by defaultethomson/urlparse_empty_portEdward Thomson2019-06-131-0/+17
| | | | | | | | | | | Our bundled http-parser includes bugfixes, therefore we should prefer our http-parser until such time as we can identify that the system http-parser has these bugfixes (using a version check). Since these bugs are - at present - minor, retain the ability for users to force that they want to use the system http-parser anyway. This does change the cmake specification so that people _must_ opt-in to the new behavior knowingly.
* threading: clarify openssl default vs mbedtlsEdward Thomson2019-02-271-4/+5
|
* threading: clarify concurrency of accessEdward Thomson2019-02-271-1/+1
|
* Update threading.mdthreading-docsEtienne Samson2019-02-071-24/+15
|
* changelog: this is 0.28Edward Thomson2019-01-311-2/+2
|
* docs: document GIT_EUSER/GIT_EPASSTHROUGHEtienne Samson2019-01-281-1/+10
|
* Merge pull request #4858 from tiennou/fix/index-ext-readEdward Thomson2019-01-251-0/+3
|\ | | | | index: preserve extension parsing errors
| * index: preserve extension parsing errorsEtienne Samson2019-01-241-0/+3
| | | | | | | | | | | | | | Previously, we would clobber any extension-specific error message with an "extension is truncated" message. This makes `read_extension` correctly preserve those errors, takes responsibility for truncation errors, and adds a new message with the actual extension signature for unsupported mandatory extensions.
* | deprecation: update changelog to reflect new policiesEdward Thomson2019-01-251-6/+14
|/
* errors: update docs for giterr changesethomson/giterrEdward Thomson2019-01-223-19/+19
|
* changelog: document that we always build cdeclethomson/cdeclEdward Thomson2019-01-171-0/+3
|
* changelog: document git_merge_analysis_for_refethomson/changelogEdward Thomson2019-01-171-0/+3
|
* changelog: document openssl fixesEdward Thomson2019-01-171-0/+2
|
* changelog: document core.logallrefupdates=alwaysEdward Thomson2019-01-171-0/+2
|
* fixup! changelog: document changes since 0.27Edward Thomson2019-01-171-1/+1
|
* changelog: document changes since 0.27Edward Thomson2019-01-171-0/+87
|
* docs: fix transparent/opaque confusion in the conventions filecmn/not-opaqueCarlos Martín Nieto2018-10-191-2/+2
|
* Merge pull request #4789 from pks-t/pks/licensingEdward Thomson2018-09-061-3/+12
|\ | | | | docs: clarify and include licenses of dependencies
| * docs: clarify and include licenses of dependenciesPatrick Steinhardt2018-08-301-3/+12
| | | | | | | | | | | | | | | | While our contribution guide tries to make clear the licenses that apply to libgit2, it does not make clear that different licenses apply to our bundled dependencies. Make this clear by listing each dependency together with the licenses that they are governed by. Furthermore, bundle the complete license texts next to the code they apply to.
* | Add two words to clarifyJohan Abildskov2018-08-271-1/+1
| |
* | Rephrase wording on giterr_last documentationJohan Abildskov2018-08-201-2/+5
| |
* | Document giterr_last() use only after error. #4772Johan Abildskov2018-08-201-0/+2
|/
* cmake: remove USE_SANITIZER and USE_COVERAGE optionsPatrick Steinhardt2018-08-031-6/+6
| | | | | | | | | | | Both the USE_SANITIZER and USE_COVERAGE options are convenience options that turn on a set of CFLAGS. Despite our own set of CFLAGS required to build libgit2, we have no real business to mess with them, though, as they can easily be passed in by the user via specifying the CFLAGS environment variable. The reasoning behind not providing them is that as soon as we start adding those for some usecases, users might ask for other sets of CFLAGS catering to their specific need in another usecase. Thus, we do not want to support them here.
* cmake: remove need to add "-fsanitize=fuzzer" flag for fuzzersPatrick Steinhardt2018-08-031-6/+4
| | | | | | | | Right now, users are being instrucded to add the "-DCMAKE_EXE_LINKER_FLAGS=-fsanitize=fuzzer" flag when they want to build our fuzzers. This is error-prone and user unfriendly. Instead, just add the flag to our fuzzers' build instructions so that it happens automatically. Adjust the README accordingly.
* fuzzers: move readme to docs/fuzzing.mdPatrick Steinhardt2018-08-031-0/+73
|
* docs: add unsaved index safety to changelogethomson/index_dirtyEdward Thomson2018-06-291-0/+12
|
* docs: fix statement about tab widthPatrick Steinhardt2018-06-121-1/+1
| | | | | | | The libgit2 project mostly follows the coding style of git and thus the linux project. While those two projects use a recommended tab width of eight spaces, we instruct users to set their editor's tab width to four spaces. Fix this to say eight instead.
* Merge branch 'pks/docs-improvements'Edward Thomson2018-06-098-4/+1772
|\
| * docs: reorganize documentsPatrick Steinhardt2018-05-308-4/+1769
| | | | | | | | | | | | | | | | | | | | Our non-technical documents are currently floating around loosely in our project's root, making it harden than necessary to discover what one is searching for. We do have a "docs/" directory, though, which serves exactly that purpose of hosting documentation. Move our non-technical documentation into the "docs/" directory. Adjust all links to these documents.
* | Merge branch 'compat/clibs'Edward Thomson2018-06-091-1/+3
|\ \ | |/ |/|
| * docs: update release steps to include clib manifestEdward Thomson2018-06-091-1/+3
| | | | | | | | | | | | We've introduced a manifest for the clib version system that includes a version number; we should update it at release time to correspond with the version number in the header.
* | docs: added note regarding difference in treatment of junction points from gitJason Haslam2018-05-211-0/+7
| |
* | docs: update differences-from-git to be more conciseCarson Howard2018-05-022-40/+20
| |
* | docs: add documentation to state differences from the git cliCarson Howard2018-03-301-0/+40
|/
* docs: document increasing the version number for releasesPatrick Steinhardt2018-02-201-0/+7
|
* docs: fix typo in "release.md" filenamePatrick Steinhardt2018-02-151-0/+0
|
* docs: udpates to wording in release documentationcmn/release-docsCarlos Martín Nieto2018-01-271-5/+17
|
* docs: add release documentationCarlos Martín Nieto2018-01-191-0/+62
| | | | | This should provide the release manager enough to know which steps to take when it's time to cut a new release.
* checkout: handle dirty submodules correctlyJason Haslam2016-05-261-1/+28
| | | | | Don't generate conflicts when checking out a modified submodule and the submodule is dirty or modified in the workdir.
View Lorry Controller Status