kmx git

Commit	Date	Message
f66e7f36	2021-10-28T10:25:09	libgit2_clar is now libgit2_tests 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.
52693ab4	2021-09-26T23:11:13	cmake: stylistic refactoring Ensure that we always use lowercase function names, and that we do not have spaces preceding open parentheses, for consistency.
4e14d4c6	2021-09-26T22:06:49	cmake: BUILD_CLAR is now BUILD_TESTS Nobody knows what CLAR is. The test building option should be `BUILD_TESTS`.
f0e693b1	2021-09-07T17:53:49	str: introduce `git_str` for internal, `git_buf` is external libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
f0a09160	2021-10-02T13:50:12	fuzzers: use updated hash functions
25b75cd9	2021-03-10T07:06:15	commit-graph: Create `git_commit_graph` as an abstraction for the file This change does a medium-size refactor of the git_commit_graph_file and the interaction with the ODB. Now instead of the ODB owning a direct reference to the git_commit_graph_file, there will be an intermediate git_commit_graph. The main advantage of that is that now end users can explicitly set a git_commit_graph that is eagerly checked for errors, while still being able to lazily use the commit-graph in a regular ODB, if the file is present.
1f32ed25	2021-01-04T19:33:48	commit-graph: Support lookups of entries in a commit-graph This change introduces `git_commit_graph_entry_find()` and `git_commit_graph_entry_parent()`. These two functions allow a much faster lookup of commits by ID, since the ODB does not need to be consulted, the commit object does not need to be inflated, and the contents of the commit object do not need to be parsed. Part of: #5757
3fd57a75	2021-01-04T18:22:43	commit-graph: Introduce a parser for commit-graph files This change is the first in a series to add support for git's commit-graph. This should speed up commit graph traversals by avoiding object parsing and allowing some operations to terminate earlier. Part of: #5757
005e7715	2020-02-23T22:28:52	multipack: Introduce a parser for multi-pack-index files This change is the first in a series to add support for git's multi-pack-index. This should speed up large repositories significantly. Part of: #5399
92e011a7	2019-10-15T16:22:35	fuzzers: add a new fuzzer for patch parsing I was looking at this code anyway because the sr.ht people nerdsniped me, and it gave me that "I should fuzz this" feeling. So have a fuzzer!
071750a3	2019-08-15T14:18:26	cmake: move _WIN32_WINNT definitions to root
75cc755f	2019-07-29T18:05:35	cmake: fix _WIN32_WINNT for MinGW
82b1d1da	2019-07-21T12:25:10	Merge pull request #5141 from pks-t/pks/azure-drop-powershell azure: drop powershell
ecd4f97b	2019-07-20T21:15:47	fuzzer: use futils instead of fileops
e54343a4	2019-06-29T09:17:32	fileops: rename to "futils.h" to match function signatures Our file utils functions all have a "futils" prefix, e.g. `git_futils_touch`. One would thus naturally guess that their definitions and implementation would live in files "futils.h" and "futils.c", respectively, but in fact they live in "fileops.h". Rename the files to match expectations.
86ecd600	2019-06-28T15:11:27	fuzzers: provide test targets Instead of having to find the fuzzer executables in our Azure test scripts, provide test targets for each of our fuzzers that will run them with the correct paths.
3c966fb4	2019-06-28T10:53:03	fuzzers: clean up header includes There's multiple headers included in our fuzzers that aren't required at all. Furthermore, some of them are not available on Win32, causing builds to fail. Remove them to fix this.
9d43d45b	2019-06-28T12:10:51	fuzzers: use `git_buf_printf` instead of `snprintf` The `snprintf` function does not exist on Win32, it only has `_snprintf_s` available. Let's just avoid any cross-platform hassle and use our own `git_buf` functionality instead.
a6b2fffd	2019-06-28T11:04:21	fuzzers: use POSIX emulation layer to unlink files Use `p_unlink` instead of `unlink` to remove the generated packfiles in our packfile fuzzer. Like this, we do not have to worry about using proper includes that are known on all platforms, especially Win32.
69055813	2019-06-28T10:50:01	fuzzers: make printf formatters cross-platform compatible The `printf` formatters in our standalone fuzzing driver are currently using the "%m" specifier, which is a GNU extension that prints the error message for the error code in `errno`. As we're using libgit2 functions in both cases anyway, let's just use `git_error_last` instead to make this valid on all platforms.
48d56328	2019-06-28T10:47:37	fuzzers: implement `mkdtemp` alternative for Win32 The `mkdtemp` function is not available on Windows, so our download_refs fuzzer will fail to compile on Windows. Provide an alternative implementation to fix it.
d3a440ca	2019-01-13T10:50:13	fuzzers: use system includes Use the system includes (defined by libgit2) as the fuzzer includes. The fuzzers link against internal libgit2 API and therefore need to have the full include path that libgit2 uses.
a1ef995d	2019-02-21T10:33:30	indexer: use git_indexer_progress throughout Update internal usage of `git_transfer_progress` to `git_indexer_progreses`.
1c3daccf	2019-01-23T09:51:50	fuzzers: don't use deprecated types
115a6c50	2019-01-10T21:44:26	errors: remove giterr usage in fuzzers
83151018	2019-01-17T10:47:32	object_type: convert final internal users to new names Update some missed types that were continuing to use the old `GIT_OBJ` names.
7615794c	2018-10-15T18:08:13	Merge pull request #4845 from pks-t/pks/object-fuzzer Object parsing fuzzer
463c21e2	2018-10-11T13:27:06	Apply code review feedback
a1d5fd06	2018-10-11T12:46:11	fuzzers: add object parsing fuzzer Add a simple fuzzer that exercises our object parser code. The fuzzer is quite trivial in that it simply passes the input data directly to `git_object__from_raw` for each of the four object types.
6956a954	2018-10-11T12:26:44	fuzzers: initialize libgit2 in standalone driver The standalone driver for libgit2's fuzzing targets makes use of functions from libgit2 itself. While this is totally fine to do, we need to make sure to always have libgit2 initialized via `git_libgit2_init` before we call out to any of these. While this happens in most cases as we call `LLVMFuzzerInitialize`, which is provided by our fuzzers and which right now always calls `git_libgit2_init`, one exception to this rule is our error path when not enough arguments have been given. In this case, we will call `git_vector_free_deep` without libgit2 having been initialized. As we did not set up our allocation functions in that case, this will lead to a segmentation fault. Fix the issue by always initializing and shutting down libgit2 in the standalone driver. Note that we cannot let this replace the initialization in `LLVMFuzzerInitialize`, as it is required when using the "real" fuzzers by LLVM without our standalone driver. It's no problem to call the initialization and deinitialization functions multiple times, though.
416aafd1	2018-10-09T02:33:03	fuzzers: Port config_file_fuzzer to the new in-memory backend
6d6bec0c	2018-08-26T11:52:21	fuzzer: update for indexer changes
f556dea6	2018-08-16T15:10:51	Add a proper write loop
b8d4578a	2018-08-14T04:01:30	Add a copyright header.
298f5df6	2018-08-14T04:01:04	Further review comments, fix the build
8189642d	2018-08-14T03:55:58	Reformat
bcfa762b	2018-08-05T03:14:56	Add a config file to the corpus
1a8e22e8	2018-07-22T23:48:53	Add a config file fuzzer
e38ddc90	2018-07-26T15:41:41	fuzzers: limit maximum pack object count By default, libgit2 allows up to 2^32 objects when downloading a packfile from a remote. For each of these objects, libgit2 will allocate up to two small structs, which in total adds up to quite a lot of memory. As a result, our fuzzers might run out of memory rather quick in case where they receive as input a packfile with such a huge count of objects. Limit the packfile object count to 10M objects. This is sufficiently big to still work with most largish repos (linux.git has around 6M objects as of now), but small enough to not cause the fuzzer to OOM.
5db64e2f	2018-07-19T14:52:02	fuzzers: convert download_refs fuzzer to C Convert the "download_refs" fuzzer from C++ to C. Rename the source file to have it be picked up by our build system.
730c0edb	2018-07-19T14:21:35	fuzzers: import download_refs fuzzer from oss-fuzz This is a direct copy of the code from google/oss-fuzz, written by Nelson Elhage (@nelhage). Note that due to the ".cc" ending, the file will not yet be picked up by the build system. This is intended, as currently that file is partly written in C++, requiring a conversion to C.
de53972f	2018-07-20T11:07:47	fuzzers: avoid use of libgit2 internals in packfile_raw The packfile_raw fuzzer is using some internal APIs from libgit2, which makes it hard to compile it as part of the oss-fuzz project. As oss-fuzz requires us to link against the C++ FuzzingEngine library, we cannot use "-DBUILD_FUZZERS=ON" directly but instead have to first compile an object from our fuzzers and then link against the C++ library. Compiling the fuzzer objects thus requires an external invocation of CC, and we certainly don't want to do further black magic by adding libgit2's private source directory to the header include path. To fix the issue, convert the code to not use any internal APIs. Besides some headers which we have to add now, this also requires us to change to the hashing function of the ODB. Note that this will change the hashing result, as we have previously not prepended the object header to the data that is to be hashed. But this shouldn't matter in practice, as we don't care for the hash value anyway.
bf3382d5	2018-07-19T15:22:18	cmake: remove need to add "-fsanitize=fuzzer" flag for fuzzers 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.
07cf8b38	2018-07-20T09:03:10	cmake: use C90 standard for our fuzzing targets Like all our other internal code, we want to force the use of C90 for our fuzzers. Do so by setting the "C_STANDARD" property of our fuzzing targets.
ad087303	2018-07-20T14:20:07	fuzzers: move readme to docs/fuzzing.md
59328ed8	2018-07-19T13:29:46	fuzzers: rename "fuzz" directory to match our style Our layout uses names like "examples" or "tests" which is why the "fuzz" directory doesn't really fit in here. Rename the directory to be called "fuzzers" instead. Furthermore, we rename the fuzzer "fuzz_packfile_raw" to "packfile_raw_fuzzer", which is also in line with the already existing fuzzer at google/oss-fuzz. While at it, rename the "packfile_raw" fuzzer to instead just be called "packfile" fuzzer.

f66e7f36

2021-10-28T10:25:09

libgit2_clar is now libgit2_tests 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.

52693ab4

2021-09-26T23:11:13

cmake: stylistic refactoring Ensure that we always use lowercase function names, and that we do not have spaces preceding open parentheses, for consistency.

4e14d4c6

2021-09-26T22:06:49

cmake: BUILD_CLAR is now BUILD_TESTS Nobody knows what CLAR is. The test building option should be `BUILD_TESTS`.

f0e693b1

2021-09-07T17:53:49

str: introduce `git_str` for internal, `git_buf` is external libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.

f0a09160

2021-10-02T13:50:12

fuzzers: use updated hash functions

25b75cd9

2021-03-10T07:06:15

commit-graph: Create `git_commit_graph` as an abstraction for the file This change does a medium-size refactor of the git_commit_graph_file and the interaction with the ODB. Now instead of the ODB owning a direct reference to the git_commit_graph_file, there will be an intermediate git_commit_graph. The main advantage of that is that now end users can explicitly set a git_commit_graph that is eagerly checked for errors, while still being able to lazily use the commit-graph in a regular ODB, if the file is present.

1f32ed25

2021-01-04T19:33:48

commit-graph: Support lookups of entries in a commit-graph This change introduces `git_commit_graph_entry_find()` and `git_commit_graph_entry_parent()`. These two functions allow a much faster lookup of commits by ID, since the ODB does not need to be consulted, the commit object does not need to be inflated, and the contents of the commit object do not need to be parsed. Part of: #5757

3fd57a75

2021-01-04T18:22:43

commit-graph: Introduce a parser for commit-graph files This change is the first in a series to add support for git's commit-graph. This should speed up commit graph traversals by avoiding object parsing and allowing some operations to terminate earlier. Part of: #5757

005e7715

2020-02-23T22:28:52

multipack: Introduce a parser for multi-pack-index files This change is the first in a series to add support for git's multi-pack-index. This should speed up large repositories significantly. Part of: #5399

92e011a7

2019-10-15T16:22:35

fuzzers: add a new fuzzer for patch parsing I was looking at this code anyway because the sr.ht people nerdsniped me, and it gave me that "I should fuzz this" feeling. So have a fuzzer!

071750a3

2019-08-15T14:18:26

cmake: move _WIN32_WINNT definitions to root

75cc755f

2019-07-29T18:05:35

cmake: fix _WIN32_WINNT for MinGW

82b1d1da

2019-07-21T12:25:10

Merge pull request #5141 from pks-t/pks/azure-drop-powershell azure: drop powershell

ecd4f97b

2019-07-20T21:15:47

fuzzer: use futils instead of fileops

e54343a4

2019-06-29T09:17:32

fileops: rename to "futils.h" to match function signatures Our file utils functions all have a "futils" prefix, e.g. `git_futils_touch`. One would thus naturally guess that their definitions and implementation would live in files "futils.h" and "futils.c", respectively, but in fact they live in "fileops.h". Rename the files to match expectations.

86ecd600

2019-06-28T15:11:27

fuzzers: provide test targets Instead of having to find the fuzzer executables in our Azure test scripts, provide test targets for each of our fuzzers that will run them with the correct paths.

3c966fb4

2019-06-28T10:53:03

fuzzers: clean up header includes There's multiple headers included in our fuzzers that aren't required at all. Furthermore, some of them are not available on Win32, causing builds to fail. Remove them to fix this.

9d43d45b

2019-06-28T12:10:51

fuzzers: use `git_buf_printf` instead of `snprintf` The `snprintf` function does not exist on Win32, it only has `_snprintf_s` available. Let's just avoid any cross-platform hassle and use our own `git_buf` functionality instead.

a6b2fffd

2019-06-28T11:04:21

fuzzers: use POSIX emulation layer to unlink files Use `p_unlink` instead of `unlink` to remove the generated packfiles in our packfile fuzzer. Like this, we do not have to worry about using proper includes that are known on all platforms, especially Win32.

69055813

2019-06-28T10:50:01

fuzzers: make printf formatters cross-platform compatible The `printf` formatters in our standalone fuzzing driver are currently using the "%m" specifier, which is a GNU extension that prints the error message for the error code in `errno`. As we're using libgit2 functions in both cases anyway, let's just use `git_error_last` instead to make this valid on all platforms.

48d56328

2019-06-28T10:47:37

fuzzers: implement `mkdtemp` alternative for Win32 The `mkdtemp` function is not available on Windows, so our download_refs fuzzer will fail to compile on Windows. Provide an alternative implementation to fix it.

d3a440ca

2019-01-13T10:50:13

fuzzers: use system includes Use the system includes (defined by libgit2) as the fuzzer includes. The fuzzers link against internal libgit2 API and therefore need to have the full include path that libgit2 uses.

a1ef995d

2019-02-21T10:33:30

indexer: use git_indexer_progress throughout Update internal usage of `git_transfer_progress` to `git_indexer_progreses`.

1c3daccf

2019-01-23T09:51:50

fuzzers: don't use deprecated types

115a6c50

2019-01-10T21:44:26

errors: remove giterr usage in fuzzers

83151018

2019-01-17T10:47:32

object_type: convert final internal users to new names Update some missed types that were continuing to use the old `GIT_OBJ` names.

7615794c

2018-10-15T18:08:13

Merge pull request #4845 from pks-t/pks/object-fuzzer Object parsing fuzzer

463c21e2

2018-10-11T13:27:06

Apply code review feedback

a1d5fd06

2018-10-11T12:46:11

fuzzers: add object parsing fuzzer Add a simple fuzzer that exercises our object parser code. The fuzzer is quite trivial in that it simply passes the input data directly to `git_object__from_raw` for each of the four object types.

6956a954

2018-10-11T12:26:44

fuzzers: initialize libgit2 in standalone driver The standalone driver for libgit2's fuzzing targets makes use of functions from libgit2 itself. While this is totally fine to do, we need to make sure to always have libgit2 initialized via `git_libgit2_init` before we call out to any of these. While this happens in most cases as we call `LLVMFuzzerInitialize`, which is provided by our fuzzers and which right now always calls `git_libgit2_init`, one exception to this rule is our error path when not enough arguments have been given. In this case, we will call `git_vector_free_deep` without libgit2 having been initialized. As we did not set up our allocation functions in that case, this will lead to a segmentation fault. Fix the issue by always initializing and shutting down libgit2 in the standalone driver. Note that we cannot let this replace the initialization in `LLVMFuzzerInitialize`, as it is required when using the "real" fuzzers by LLVM without our standalone driver. It's no problem to call the initialization and deinitialization functions multiple times, though.

416aafd1

2018-10-09T02:33:03

fuzzers: Port config_file_fuzzer to the new in-memory backend

6d6bec0c

2018-08-26T11:52:21

fuzzer: update for indexer changes

f556dea6

2018-08-16T15:10:51

Add a proper write loop

b8d4578a

2018-08-14T04:01:30

Add a copyright header.

298f5df6

2018-08-14T04:01:04

Further review comments, fix the build

8189642d

2018-08-14T03:55:58

Reformat

bcfa762b

2018-08-05T03:14:56

Add a config file to the corpus

1a8e22e8

2018-07-22T23:48:53

Add a config file fuzzer

e38ddc90

2018-07-26T15:41:41

fuzzers: limit maximum pack object count By default, libgit2 allows up to 2^32 objects when downloading a packfile from a remote. For each of these objects, libgit2 will allocate up to two small structs, which in total adds up to quite a lot of memory. As a result, our fuzzers might run out of memory rather quick in case where they receive as input a packfile with such a huge count of objects. Limit the packfile object count to 10M objects. This is sufficiently big to still work with most largish repos (linux.git has around 6M objects as of now), but small enough to not cause the fuzzer to OOM.

5db64e2f

2018-07-19T14:52:02

fuzzers: convert download_refs fuzzer to C Convert the "download_refs" fuzzer from C++ to C. Rename the source file to have it be picked up by our build system.

730c0edb

2018-07-19T14:21:35

fuzzers: import download_refs fuzzer from oss-fuzz This is a direct copy of the code from google/oss-fuzz, written by Nelson Elhage (@nelhage). Note that due to the ".cc" ending, the file will not yet be picked up by the build system. This is intended, as currently that file is partly written in C++, requiring a conversion to C.

de53972f

2018-07-20T11:07:47

fuzzers: avoid use of libgit2 internals in packfile_raw The packfile_raw fuzzer is using some internal APIs from libgit2, which makes it hard to compile it as part of the oss-fuzz project. As oss-fuzz requires us to link against the C++ FuzzingEngine library, we cannot use "-DBUILD_FUZZERS=ON" directly but instead have to first compile an object from our fuzzers and then link against the C++ library. Compiling the fuzzer objects thus requires an external invocation of CC, and we certainly don't want to do further black magic by adding libgit2's private source directory to the header include path. To fix the issue, convert the code to not use any internal APIs. Besides some headers which we have to add now, this also requires us to change to the hashing function of the ODB. Note that this will change the hashing result, as we have previously not prepended the object header to the data that is to be hashed. But this shouldn't matter in practice, as we don't care for the hash value anyway.

bf3382d5

2018-07-19T15:22:18

cmake: remove need to add "-fsanitize=fuzzer" flag for fuzzers 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.

07cf8b38

2018-07-20T09:03:10

cmake: use C90 standard for our fuzzing targets Like all our other internal code, we want to force the use of C90 for our fuzzers. Do so by setting the "C_STANDARD" property of our fuzzing targets.

ad087303

2018-07-20T14:20:07

fuzzers: move readme to docs/fuzzing.md

59328ed8

2018-07-19T13:29:46

fuzzers: rename "fuzz" directory to match our style Our layout uses names like "examples" or "tests" which is why the "fuzz" directory doesn't really fit in here. Rename the directory to be called "fuzzers" instead. Furthermore, we rename the fuzzer "fuzz_packfile_raw" to "packfile_raw_fuzzer", which is also in line with the already existing fuzzer at google/oss-fuzz. While at it, rename the "packfile_raw" fuzzer to instead just be called "packfile" fuzzer.

thodg/libgit2/fuzzers

fuzzers

Log