- 06 Jan, 2022 1 commit
-
-
Edward Thomson committed
-
- 11 Nov, 2021 1 commit
-
-
Threading can now be disabled with `USE_THREADS=OFF` instead of `THREADSAFE=OFF` to better support the other cmake semantics. Nanosecond support is the default _if_ we can detect it. This should be our default always - like threads - and people can opt out explicitly.
Edward Thomson committed
-
- 10 Nov, 2021 1 commit
-
-
Commit 4ae41f9c made `git_odb` race-free, and added internal locking. Update `docs/threading.md` accordingly, so that APIs built atop libgit2 (e.g. language bindings) can count on this.
Josh Triplett committed
-
- 28 Oct, 2021 1 commit
-
-
in #6083 the test runner was renamed to libgit2_tests, but not all references to the old name were updated. this change changes all of them to use the new name.
Martin Kühl committed
-
- 17 Oct, 2021 2 commits
-
-
Nobody knows what CLAR is. The test building option should be `BUILD_TESTS`.
Edward Thomson committed -
We have been inconsistent about the way that we handle `git_buf`s provided by users. _Usually_ we require that it has been properly initialized with `GIT_BUF_INIT`, but _sometimes_ we simply overwrite the data in it regardless. And even more rarely, we will grow a user-provided buffer and concatenate data onto it (see `git_diff_format_email`). Document the path forward for `git_buf`, which is that we always require that the buffer is intitialized with `GIT_BUF_INIT`. `git_diff_format_email` will be kept backward compatible but users are encouraged to switch to the new `git_email` APIs.
Edward Thomson committed
-
- 27 Sep, 2021 2 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
- 22 Sep, 2021 3 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
Edward Thomson committed
-
- 31 Aug, 2021 1 commit
-
-
Edward Thomson committed
-
- 25 Jun, 2021 1 commit
-
-
Co-authored-by: lhchavez <lhchavez@lhchavez.com>
Edward Thomson committed
-
- 23 Jun, 2021 1 commit
-
-
The name of libgit2's main branch is now "main" but contributing.md and release.md still reference "master" as the main branch. Fix it.
Nicolas Cavallari committed
-
- 17 Jun, 2021 1 commit
-
-
Peter Pettersson committed
-
- 11 Jun, 2021 1 commit
-
-
Alex Good committed
-
- 27 May, 2021 1 commit
-
-
Etienne Samson committed
-
- 14 Apr, 2021 1 commit
-
-
Edward Thomson committed
-
- 21 Nov, 2020 1 commit
-
-
Edward Thomson committed
-
- 25 Oct, 2020 1 commit
-
-
Edward Thomson committed
-
- 12 Oct, 2020 1 commit
-
-
Edward Thomson committed
-
- 05 Apr, 2020 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 28 Mar, 2020 1 commit
-
-
Patrick Steinhardt committed
-
- 19 Feb, 2020 1 commit
-
-
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.
Edward Thomson committed
-
- 15 Feb, 2020 1 commit
-
-
Some of the commands are now out of date.
lhchavez committed
-
- 07 Feb, 2020 2 commits
-
-
When the failure is clearly an auth failure (as opposed to possibly an auth failure), use the error code GIT_EAUTH instead of GIT_ERROR. While we're here, fix a typo and improve an error message. Fixes #5389.
Josh Bleecher Snyder committed -
Updates #5389
Josh Bleecher Snyder committed
-
- 10 Dec, 2019 1 commit
-
-
Patrick Steinhardt committed
-
- 04 Dec, 2019 2 commits
-
-
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!
Josh Bleecher Snyder committed -
Note that for security releases, we update the two most recent major release branches.
Edward Thomson committed
-
- 13 Sep, 2019 1 commit
-
-
Etienne Samson committed
-
- 13 Aug, 2019 1 commit
-
-
Edward Thomson committed
-
- 14 Jun, 2019 1 commit
-
-
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.
Etienne Samson committed
-
- 13 Jun, 2019 1 commit
-
-
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.
Edward Thomson committed
-
- 27 Feb, 2019 2 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
- 07 Feb, 2019 1 commit
-
-
Etienne Samson committed
-
- 31 Jan, 2019 1 commit
-
-
Edward Thomson committed
-
- 28 Jan, 2019 1 commit
-
-
Etienne Samson committed
-
- 25 Jan, 2019 1 commit
-
-
Edward Thomson committed
-