kmx git

Commit	Date	Message
b3ba2e71	2019-03-29T11:15:26	tests: config: verify that the global config is actually readable While we do verify that we are able to open the global ".gitconfig" file in config::global::open_global, we never verify that we it is in fact readable. Do so by writing the global configuration file and verifying that reading from it produces the expected values.
25c085e6	2019-03-29T11:41:42	tests: repo: verify that we can open repos with symlinked global config We've got reports that users are unable to open repos when their global configuration ("~/.gitconfig") is a symlink. Add a test to verify that we are in fact able to do so as expected.
fa4505e6	2019-03-29T11:30:29	tests: config: make sure to clean up after each test The config::global test suite creates various different directories and files which are being populated with pretend-global files. Unfortunately, the tests do not clean up after themselves, which may cause subsequent tests to fail due to cruft left behind. Fix this by always removing created directories and their contents.
8e4927a4	2019-03-06T09:13:56	Merge pull request #5012 from dritter/dritter-patch-1 [Doc] Update URL to git2-rs
1fd0903a	2019-03-05T18:47:45	Update URL to git2-rs
79b26f20	2019-03-02T18:21:47	Merge pull request #5008 from libgit2/ethomson/remote_completion remote: Rename git_remote_completion_type to _t
7b083d3c	2019-03-02T18:14:36	Merge pull request #5005 from libgit2/ethomson/odb_backend_allocations odb: provide a free function for custom backends
c7e5eca6	2019-02-28T10:46:26	Revert "foo" This reverts commit 1fe3fa5e59818c851d50efc6563db5f8a5d7ae9b.
1fe3fa5e	2019-02-28T10:44:34	foo
b401273b	2019-02-27T10:08:28	Merge branch 'threading-docs'
02ab4841	2019-02-27T10:08:15	threading: clarify openssl default vs mbedtls
358a3b9c	2019-02-27T10:08:00	threading: clarify concurrency of access
2dd5a429	2019-02-25T13:16:13	remote: Rename git_remote_completion_type to _t For consistency with other "type" enums, rename git_remote_completion_type to git_remote_completion_t.
68729289	2019-02-25T09:25:34	Merge pull request #5000 from augfab/branch_lookup_all Have git_branch_lookup accept GIT_BRANCH_ALL
459ac856	2019-02-23T18:42:53	odb: provide a free function for custom backends Custom backends can allocate memory when reading objects and providing them to libgit2. However, if an error occurs in the custom backend after the memory has been allocated for the custom object but before it's returned to libgit2, the custom backend has no way to free that memory and it must be leaked. Provide a free function that corresponds to the alloc function so that custom backends have an opportunity to free memory before they return an error.
790aae77	2019-02-23T18:40:43	odb: rename git_odb_backend_malloc for consistency The `git_odb_backend_malloc` name is a system function that is provided for custom ODB backends and allows them to allocate memory for an ODB object in the read callback. This is important so that libgit2 can later free the memory used by an ODB object that was read from the custom backend. However, the name _suggests_ that it actually allocates a `git_odb_backend`. It does not; rename it to make it clear that it actually allocates backend _data_.
c5d8e300	2019-02-21T21:46:39	branch: have git_branch_lookup accept GIT_BRANCH_ALL
0a25141e	2019-02-21T21:42:25	branch: add test for git_branch_lookup to accept GIT_BRANCH_ALL
5a6a3c00	2019-02-22T11:45:42	Merge pull request #4997 from libgit2/ethomson/transfer_progress Rename git_transfer_progress to git_indexer_progress
ca909da5	2019-02-21T11:45:23	remote: deprecate git_push_transfer_progress Safely deprecate `git_push_transfer_progress`, forwarding it to the new `git_push_transfer_progress_cb` name.
59001e83	2019-02-21T11:41:19	remote: rename git_push_transfer_progress callback The `git_push_transfer_progress` is a callback and as such should be suffixed with `_cb` for consistency. Rename `git_push_transfer_progress` to `git_push_transfer_progress_cb`.
7506d34c	2019-02-21T10:38:53	indexer: deprecate git_transfer_progress Safely deprecate `git_transfer_progress` and `git_transfer_progress_cb` types, forwarding them to the new `git_indexer_progress` and `git_indexer_progress_cb`.
a1ef995d	2019-02-21T10:33:30	indexer: use git_indexer_progress throughout Update internal usage of `git_transfer_progress` to `git_indexer_progreses`.
975d6722	2019-02-21T10:13:29	indexer: rename git_transfer_progress The name `git_transfer_progress` does not reflect its true purpose. It suggests that it's progress for a non-existence `git_transfer` object, and is used for indexing callbacks more broadly than just during transfers. Rename `git_transfer_progress` to `git_indexer_progress`.
4069f924	2019-02-22T10:56:08	Merge pull request #4901 from pks-t/pks/uniform-map-api High-level map APIs
75dd7f2a	2019-02-22T10:13:00	Merge pull request #4984 from pks-t/pks/refdb-fs-race refdb_fs: fix loose/packed refs lookup racing with repacks
c5594852	2019-02-22T10:06:24	Merge pull request #4998 from pks-t/pks/allocator-restructuring Allocator restructuring
3aa8401a	2019-02-21T14:10:43	Merge pull request #4992 from pks-t/pks/cache-dispose cache: fix misnaming of `git_cache_free`
68ba2e8d	2019-02-21T13:42:18	Merge pull request #4956 from pks-t/pks/examples-cgit2-standalone examples: produce single cgit2 binary
bbdcd450	2019-02-20T10:40:06	cache: fix misnaming of `git_cache_free` Functions that free a structure's contents but not the structure itself shall be named `dispose` in the libgit2 project, but the function `git_cache_free` does not follow this naming pattern. Fix this by renaming it to `git_cache_dispose` and adjusting all callers to make use of the new name.
48727e5d	2019-02-21T12:27:42	allocators: extract crtdbg allocator into its own file The Windows-specific crtdbg allocator is currently mixed into the crtdbg stacktracing compilation unit, making it harder to find than necessary. Extract it and move it into the new "allocators/" subdirectory to improve discoverability. This change means that the crtdbg compilation unit is now compiled unconditionally, whereas it has previously only been compiled on Windows platforms. Thus we now have additional guards around the code so that it will only be compiled if GIT_MSVC_CRTDBG is defined. This also allows us to move over the fallback-implementation of `git_win32_crtdbg_init_allocator` into the same compilation unit.
765ff6e0	2019-02-21T12:35:48	allocators: make crtdbg allocator reuse its own realloc In commit 6e0dfc6ff (Make stdalloc__reallocarray call stdalloc__realloc, 2019-02-16), we have changed the stdalloc allocator to reuse `stdalloc__realloc` to implement `stdalloc__reallocarray`. This commit is making the same change for the Windows-specific crtdbg allocator to avoid code duplication.
b63396b7	2019-02-21T12:13:59	allocators: move standard allocator into subdirectory Right now, our two allocator implementations are scattered around the tree in "stdalloc.h" and "win32/w32_crtdbg_stacktrace.h". Start grouping them together in a single directory "allocators/", similar to how e.g. our streams are organized.
9eb098d8	2019-02-21T11:37:04	Merge pull request #4991 from libgit2/ethomson/inttypes Remove public 'inttypes.h' header
247e6d90	2019-02-18T07:22:20	Remove public 'inttypes.h' header Remove an `inttypes.h` header that is too large in scope, and far too public. For Visual Studio 2012 and earlier (ie, `_MSC_VER < 1800`), we do need to include `stdint.h` in our public headers, for types like `uint32_t`. Internally, we also need to define `PRId64` as a printf formatting string when it is not available.
554b3b9a	2019-02-21T10:31:21	Merge pull request #4996 from eaigner/master Prevent reading out of bounds memory
966b9440	2019-02-21T08:30:22	tests: apply: verify that we correctly truncate the source buffer Previously, we would fail to correctly truncate the source buffer if the source has more than one line and ends with a non-newline character. In the following call, we thus truncate the source string in the middle of the second line. Without the bug fixed, we would successfully apply the patch to the source and return success. With the overflow being fixed, we should return an error now.
014d4955	2019-02-20T15:30:11	apply: prevent OOB read when parsing source buffer When parsing the patch image from a string, we split the string by newlines to get a line-based view of it. To split, we use `memchr` on the buffer and limit the buffer length by the original length provided by the caller. This works just fine for the first line, but for every subsequent line we need to actually subtract the amount of bytes that we have already read. The above issue can be easily triggered by having a source buffer with at least two lines, where the second line does _not_ end in a newline. Given a string "foo\nb", we have an original length of five bytes. After having extracted the first line, we will point to 'b' and again try to `memchr(p, '\n', 5)`, resulting in an out-of-bounds read of four bytes. Fix the issue by correctly subtracting the amount of bytes already read.
6eb4947d	2019-02-21T08:02:45	Merge pull request #4987 from lhchavez/fix-odb_otype_fast-leak Fix a memory leak in odb_otype_fast()
6b3730d4	2019-02-16T19:55:30	Fix a memory leak in odb_otype_fast() This change frees a copy of a cached object in odb_otype_fast().
12c6e1fa	2019-02-20T10:54:00	Merge pull request #4986 from lhchavez/realloc Make stdalloc__reallocarray call stdalloc__realloc
9f388e9f	2019-02-20T10:51:33	Merge pull request #4990 from libgit2/remove_time_monotonic Remove `git_time_monotonic`
d900dde4	2019-02-20T10:37:20	Merge pull request #4988 from lhchavez/fix-improbable-odb-initialization-leak Fix a _very_ improbable memory leak in git_odb_new()
e6c6d3bb	2019-02-17T22:31:37	Remove `git_time_monotonic` `git_time_monotonic` was added so that non-native bindings like rugged could get high-resolution timing for benchmarking. However, this is outside the scope of libgit2 and rugged decided not to use this function in the first place. Google suggests that absolutely _nobody_ is using this function and we don't want to be in the benchmarking business. Remove the function.
cb150e60	2019-02-17T19:31:11	Merge pull request #4989 from libgit2/ethomson/ci_docs ci: publish documentation on merge
fbfa41a1	2019-02-17T19:07:37	ci: publish documentation on merge When a commit is pushed or merged into one of the release branches (master, maint/*) then push the documentation update to gh-pages.
b5b3aa93	2019-02-17T12:50:51	Revert "ci: publish documentation after merge" This reverts commit 2a4e866a43e3db1e2be8e2a3d986ddc9f855d2bc.
4a02d24a	2019-02-17T12:40:20	foo
484fff87	2019-02-17T12:36:41	foo
2a4e866a	2019-02-17T12:34:23	ci: publish documentation after merge When a continuous integration build runs (ie a commit is pushed or merged into one of the CI branches, `master` or `maint/*`) then push the rebuilt documentation into the `gh-pages` branch.
dd45539d	2019-02-16T22:06:58	Fix a _very_ improbable memory leak in git_odb_new() This change fixes a mostly theoretical memory leak in got_odb_new() that can only manifest if git_cache_init() fails due to running out of memory or not being able to acquire its lock.
6e0dfc6f	2019-02-16T20:26:17	Make stdalloc__reallocarray call stdalloc__realloc This change avoids calling realloc(3) in more than one place.
df42f368	2018-12-01T10:54:57	idxmap: remove legacy low-level interface Remove the low-level interface that was exposing implementation details of `git_idxmap` to callers. From now on, only the high-level functions shall be used to retrieve or modify values of a map. Adjust remaining existing callers.
bd66925a	2018-12-01T10:29:32	oidmap: remove legacy low-level interface Remove the low-level interface that was exposing implementation details of `git_oidmap` to callers. From now on, only the high-level functions shall be used to retrieve or modify values of a map. Adjust remaining existing callers.
4713e7c8	2018-12-01T09:58:30	offmap: remove legacy low-level interface Remove the low-level interface that was exposing implementation details of `git_offmap` to callers. From now on, only the high-level functions shall be used to retrieve or modify values of a map. Adjust remaining existing callers.
fdfabdc4	2018-12-01T09:49:10	strmap: remove legacy low-level interface Remove the low-level interface that was exposing implementation details of `git_strmap` to callers. From now on, only the high-level functions shall be used to retrieve or modify values of a map. Adjust remaining existing callers.
6a9117f5	2018-12-01T10:18:42	cache: use iteration interface for cache eviction To relieve us from memory pressure, we may regularly call `cache_evict_entries` to remove some entries from it. Unfortunately, our cache does not support a least-recently-used mode or something similar, which is why we evict entries completeley at random right now. Thing is, this is only possible due to the map interfaces exposing the entry indices, and we intend to completely remove those to decouple map users from map implementations. As soon as that is done, we are unable to do this random eviction anymore. Convert this to make use of an iterator for now. Obviously, there is no random eviction possible like that anymore, but we'll always start by evicting from the beginning of the map. Due to hashing, one may hope that the selected buckets will be evicted at least in some way unpredictably. But more likely than not, this will not be the case. But let's see what happens and if any users complain about degraded performance. If so, we might come up with a different scheme than random removal, e.g. by using an LRU cache.
c976b4f9	2018-12-01T10:18:26	indexer: use map iterator to delete expected OIDs To compute whether there are objects missing in a packfile, the indexer keeps around a map of OIDs that it still expects to see. This map does not store any values at all, but in fact the keys are owned by the map itself. Right now, we free these keys by iterating over the map and freeing the key itself, which is kind of awkward as keys are expected to be constant. We can make this a bit prettier by inserting the OID as value, too. As we already store the `NULL` pointer either way, this does not increase memory usage, but makes the code a tad more clear. Furthermore, we convert the previously existing map iteration via indices to make use of an iterator, instead.
d00c24a9	2019-01-23T10:49:25	idxmap: introduce high-level getter for values The current way of looking up an entry from a map is tightly coupled with the map implementation, as one first has to look up the index of the key and then retrieve the associated value by using the index. As a caller, you usually do not care about any indices at all, though, so this is more complicated than really necessary. Furthermore, it invites for errors to happen if the correct error checking sequence is not being followed. Introduce new high-level functions `git_idxmap_get` and `git_idxmap_icase_get` that take a map and a key and return a pointer to the associated value if such a key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can trivially be converted.
b9d0b664	2018-12-17T09:10:53	offmap: introduce high-level setter for key/value pairs Currently, there is only one caller that adds entries into an offset map, and this caller first uses `git_offmap_put` to add a key and then set the value at the returned index by using `git_offmap_set_value_at`. This is just too tighlty coupled with implementation details of the map as it exposes the index of inserted entries, which we really do not care about at all. Introduce a new function `git_offmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert the caller to make use of it instead.
aa245623	2018-11-30T18:28:05	offmap: introduce high-level getter for values The current way of looking up an entry from a map is tightly coupled with the map implementation, as one first has to look up the index of the key and then retrieve the associated value by using the index. As a caller, you usually do not care about any indices at all, though, so this is more complicated than really necessary. Furthermore, it invites for errors to happen if the correct error checking sequence is not being followed. Introduce a new high-level function `git_offmap_get` that takes a map and a key and returns a pointer to the associated value if such a key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can trivially be converted.
2e0a3048	2019-01-23T10:48:55	oidmap: introduce high-level setter for key/value pairs Currently, one would use either `git_oidmap_insert` to insert key/value pairs into a map or `git_oidmap_put` to insert a key only. These function have historically been macros, which is why their syntax is kind of weird: instead of returning an error code directly, they instead have to be passed a pointer to where the return value shall be stored. This does not match libgit2's common idiom of directly returning error codes.Furthermore, `git_oidmap_put` is tightly coupled with implementation details of the map as it exposes the index of inserted entries. Introduce a new function `git_oidmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert all trivial callers of `git_oidmap_insert` and `git_oidmap_put` to make use of it.
9694ef20	2018-12-17T09:01:53	oidmap: introduce high-level getter for values The current way of looking up an entry from a map is tightly coupled with the map implementation, as one first has to look up the index of the key and then retrieve the associated value by using the index. As a caller, you usually do not care about any indices at all, though, so this is more complicated than really necessary. Furthermore, it invites for errors to happen if the correct error checking sequence is not being followed. Introduce a new high-level function `git_oidmap_get` that takes a map and a key and returns a pointer to the associated value if such a key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can trivially be converted.
03555830	2019-01-23T10:44:33	strmap: introduce high-level setter for key/value pairs Currently, one would use the function `git_strmap_insert` to insert key/value pairs into a map. This function has historically been a macro, which is why its syntax is kind of weird: instead of returning an error code directly, it instead has to be passed a pointer to where the return value shall be stored. This does not match libgit2's common idiom of directly returning error codes. Introduce a new function `git_strmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert all callers of `git_strmap_insert` to make use of it.
ef507bc7	2019-01-23T10:44:02	strmap: introduce `git_strmap_get` and use it throughout the tree The current way of looking up an entry from a map is tightly coupled with the map implementation, as one first has to look up the index of the key and then retrieve the associated value by using the index. As a caller, you usually do not care about any indices at all, though, so this is more complicated than really necessary. Furthermore, it invites for errors to happen if the correct error checking sequence is not being followed. Introduce a new high-level function `git_strmap_get` that takes a map and a key and returns a pointer to the associated value if such a key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can trivially be converted.
7e926ef3	2018-11-30T12:14:43	maps: provide a uniform entry count interface There currently exist two different function names for getting the entry count of maps, where offmaps offset and string maps use `num_entries` and OID maps use `size`. In most programming languages with built-in map types, this is simply called `size`, which is also shorter to type. Thus, this commit renames the other two functions `num_entries` to match the common way and adjusts all callers.
351eeff3	2019-01-23T10:42:46	maps: use uniform lifecycle management functions Currently, the lifecycle functions for maps (allocation, deallocation, resize) are not named in a uniform way and do not have a uniform function signature. Rename the functions to fix that, and stick to libgit2's naming scheme of saying `git_foo_new`. This results in the following new interface for allocation: - `int git_<t>map_new(git_<t>map *out)` to allocate a new map, returning an error code if we ran out of memory - `void git_<t>map_free(git_<t>map map)` to free a map - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map This commit also fixes all existing callers.
18cf5698	2018-12-01T09:37:40	maps: provide high-level iteration interface Currently, our headers need to leak some implementation details of maps due to their direct use of indices in the implementation of their foreach macros. This makes it impossible to completely hide the map structures away, and also makes it impossible to include the khash implementation header in the C files of the respective map only. This is now being fixed by providing a high-level iteration interface `map_iterate`, which takes as inputs the map that shall be iterated over, an iterator as well as the locations where keys and values shall be put into. For simplicity's sake, the iterator is a simple `size_t` that shall initialized to `0` on the first call. All existing foreach macros are then adjusted to make use of this new function.
c50a8ac2	2018-12-01T08:59:24	maps: use high-level function to check existence of keys Some callers were still using the tightly-coupled pattern of `lookup_index` and `valid_index` to verify that an entry exists in a map. Instead, use the more high-level `exists` functions to decouple map users from its implementation.
84a089da	2018-12-01T08:50:36	maps: provide return value when deleting entries Currently, the delete functions of maps do not provide a return value. Like this, it is impossible to tell whether the entry has really been deleted or not. Change the implementation to provide either a return value of zero if the entry has been successfully deleted or `GIT_ENOTFOUND` if the key could not be found. Convert callers to the `delete_at` functions to instead use this higher-level interface.
8da93944	2018-12-01T10:52:44	idxmap: have `resize` functions return proper error code The currently existing function `git_idxmap_resize` and `git_idxmap_icase_resize` do not return any error codes at all due to their previous implementation making use of a macro. Due to that, it is impossible to see whether the resize operation might have failed due to an out-of-memory situation. Fix this by providing a proper error code. Adjust callers to make use of it.
661fc57b	2018-12-01T01:16:25	idxmap: introduce high-level setter for key/value pairs Currently, one would use the function `git_idxmap_insert` to insert key/value pairs into a map. This function has historically been a macro, which is why its syntax is kind of weird: instead of returning an error code directly, it instead has to be passed a pointer to where the return value shall be stored. This does not match libgit2's common idiom of directly returning error codes. Introduce a new function `git_idxmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert all callers of `git_idxmap_insert` to make use of it.
6cf47726	2019-01-15T13:54:18	examples/add: add explanatory comments and reformat
106998fc	2019-01-24T11:48:44	examples: print available commands if no args are given
ead10785	2019-01-24T11:31:49	examples: create common lg2 executable Inside of our networking example code, we have a git2 executable that acts as an entry point to all the different network examples. As such, it is kind of the same like the normal git(1) executable in that it simply arbitrates to the respective subcommands. Let's extend this approach and merge all examples into a single standalone lg2 executable. Instead of building an executable for all the existing examples we have, we now bundle them all inside of the lg2 one and let them be callable via subcommands. In the process, we can get rid of duplicated library initialization, deinitialization and repository discovery code. Instead of having each subcommand handle these on its own, we simply do it inside of the single main function now.
7562422a	2019-01-24T10:30:58	examples: merge common network code Right now, we have two sets of "common" code, one containing general common code and one containing network common code. As we intend to get rid of the network subdirectory and instead merge all examples into a single standalone executable, this distinction doesn't make a lot of sense now. Furthermore, the common network code is not that big. Let's get rid of the common network code by merging it into the general common code.
c4271314	2019-01-24T10:27:07	examples: remove unused Makefile This Makefile isn't used anymore and probably won't work anyway. Remove it in favor of the existing CMake build instructions.
a540e6bb	2019-01-24T10:07:31	examples: remove test script In commit 2e2332857 (examples: a test, for rev-list, 2013-03-20), a script was introduced with the intention of testing our rev-list example code. Nobody uses that script, and in fact it doesn't even properly work due to the not-so-recent addition out-of-source builds. Remove the script.
94743daf	2019-02-15T11:16:46	refdb_fs: fix race when migrating loose to packed refs in iteration Right now, we first load the packed refs cache and only afterwards load the loose references. This is susceptible to a race when the loose ref is being migrated to a packed cache by e.g. git-pack-refs(1): libgit2 git-pack-refs 1. We load the packed ref, which does not yet have the migrated reference. 2. git-pack-refs updates the packed ref file to have the migrated ref. 3. git-pack-refs deletes the old loose ref. 4. We look up the loose ref. So we now do not find the reference at all and will never iterate over it. Fix the issue by reversing the order: instead of first loading the packed refs, we will now look up the loose reference first. If it has already been deleted, then it must already be present in the packed-refs by definition, as git.git will only delete the reference after updating the packed refs file.
3ff0e3b5	2019-02-15T11:16:05	refdb_fs: remove ordering dependency on loose/packed refs loading Right now, loading loose refs has the side-effect of setting the `PACKREF_SHADOWED` flag for references that exist both in the loose and the packed refs. Because of this, we are force do first look up packed refs and only afterwards loading the packed refs. This is susceptible to a race, though, when refs are being repacked: when first loading the packed cache, then it may not yet have the migrated loose ref. But when now trying to look up the loose reference afterwards, then it may already have been migrated. Thus, we would fail to find this reference in this scenario. Remove this ordering dependency to allow fixing the above race. Instead of setting the flag when loading loose refs, we will now instead set it lazily when iterating over the loose refs. This even has the added benefit of not requiring us to lock the packed refs cache, as we already have an owned copy of it.
83333814	2019-02-15T10:56:50	refdb_fs: do not lazily copy packed ref cache When creating a new iterator, we eagerly load loose refs but only lazily create a copy of packed refs. The lazy load only happens as soon as we have iterated over all loose refs, opening up a potentially wide window for races. This may lead to an inconsistent view e.g. when the caller decides to reload packed references somewhen between iterating the loose refs, which is unexpected. Fix the issue by eagerly copying the sorted cache. Note that right now, we are heavily dependent on ordering here: we first need to reload packed refs, then we have to load loose refs and only as a last step are we allowed to copy the cache. This is because loading loose refs has the side-effect of setting the `PACKED_SHADOWED` flag in the packed refs cache, which we require to avoid outputting packed refs that already exist as loose refs.
32063d82	2019-02-15T10:41:30	refdb_fs: refactor error handling in iterator creation Refactor the error handling in `refdb_fs_backend__iterator` to always return the correct error code returned by the failing function.
8c773438	2019-02-15T10:15:39	refdb_fs: fix potential race with ref repacking in `exists` callback When repacking references, git.git will first update the packed refs and only afterwards delete any existing loose references that have now been moved to the new packed refs file. Due to this, there is a potential for racing if one first reads the packfile (which has not been updated yet) and only then trying to read the loose reference (which has just been deleted). In this case, one will incorrectly fail to lookup the reference and it will be reported as missing. Naturally, this is exactly what we've been doing in `refdb_fs_backend__exists`. Fix the race by reversing the lookup: we will now first check if the loose reference exists and only afterwards refresh the packed file.
bda08397	2019-02-14T16:57:47	Merge pull request #4982 from pks-t/pks/worktree-add-bare-head Enable creation of worktree from bare repo's default branch
48005936	2019-02-14T16:55:18	Merge pull request #4965 from hackworks/eliminate-check-for-keep-file Allow bypassing check for '.keep' file
b8837827	2019-02-14T13:09:23	Merge pull request #4979 from libgit2/ethomson/deprecate Deprecation: export the deprecated functions properly
bf013fc0	2019-02-14T13:30:33	branch: fix `branch_is_checked_out` with bare repos In a bare repository, HEAD usually points to the branch that is considered the "default" branch. As the current implementation for `git_branch_is_checked_out` only does a comparison of HEAD with the branch that is to be checked, it will say that the branch pointed to by HEAD in such a bare repo is checked out. Fix this by skipping the main repo's HEAD when it is bare.
efb20825	2019-02-14T13:05:49	branches: introduce flag to skip enumeration of certain HEADs Right now, the function `git_repository_foreach_head` will always iterate over all HEADs of the main repository and its worktrees. In some cases, it might be required to skip either of those, though. Add a flag in preparation for the following commit that enables this behaviour.
788cd2d5	2019-02-14T13:49:35	branches: do not assert that the given ref is a branch Libraries should use assert(3P) only very scarcely. First, we usually shouldn't cause the caller of our library to abort in case where the assert fails. Second, if code is compiled with -DNDEBUG, then the assert will not be included at all. In our `git_branch_is_checked_out` function, we have an assert that verifies that the given reference parameter is non-NULL and in fact a branch. While the first check is fine, the second is not. E.g. when compiled with -DNDEBUG, we'd proceed and treat the given reference as a branch in all cases. Fix the issue by instead treating a non-branch reference as not being checked out. This is the obvious solution, as references other than branches cannot be directly checked out.
a0f87e16	2019-02-14T13:26:30	branches: add tests for `git_branch_is_checked_out` We currently do not have any tests at all for the `git_branch_is_checked_out` function. Add some basic ones.
698eae13	2019-02-14T12:52:25	worktree: error out early if given ref is not valid When adding a new worktree, we only verify that an optionally given reference is valid half-way through the function. At this point, some data structures have already been created on-disk. If we bail out due to an invalid reference, these will be left behind and need to be manually cleaned up by the user. Improve the situation by moving the reference checks to the function's preamble. Like this, we error out as early as possible and will not leave behind any files.
3f823c2b	2019-02-14T00:00:06	ci: enable hard deprecation Enable hard deprecation in our builds to ensure that we do not call deprecated functions internally.
dcf81cdb	2019-02-13T23:56:40	deprecation: optionally enable hard deprecation Add a CMake option to enable hard deprecation; the resultant library will _not_ include any deprecated functions. This may be useful for internal CI builds that create libraries that are not shared with end-users to ensure that we do not use deprecated bits internally.
24ac9e0c	2019-02-13T23:26:54	deprecation: ensure we GIT_EXTERN deprecated funcs Although the error functions were deprecated, we did not properly mark them as deprecated. We need to include the `deprecated.h` file in order to ensure that the functions get their export attributes. Similarly, do not define `GIT_DEPRECATE_HARD` within the library, or those functions will also not get their export attributes. Define that only on the tests and examples.
e1916376	2019-02-14T09:22:57	Merge pull request #4980 from libgit2/ethomson/ci_nightly ci: skip ssh tests on macOS nightly
ef91917f	2019-02-14T09:19:32	ci: skip ssh tests on macOS nightly Like 811c1c0f8f80521dccc746a7bff180cd77a783ff, disable the SSH tests on macOS until we can resolve the newly introduced infrastructure issues.
85b2bd41	2019-02-14T01:13:33	Merge pull request #4976 from libgit2/ethomson/readme_v028 CI build fixups
811c1c0f	2019-02-14T00:51:39	ci: skip ssh tests on macOS SSH tests on macOS have begun failing for an unknown reason after an infrastructure upgrade to macOS 10.13.6. Disable those tests temporarily, until we can resolve it.
44f82134	2019-02-13T11:18:35	ci: provide more information about OS Subtle changes in the host OS can have impacts in the CI system that may be hard to debug. We previously showed the results of `uname` which can be difficult to interpret. Provide more information where available.
6f778351	2019-02-13T11:15:12	README: use correct badge for nightlies The URL was incorrect for the nightly badge image; it was erroneously showing the master branch continuous integration build badge.

b3ba2e71

2019-03-29T11:15:26

tests: config: verify that the global config is actually readable While we do verify that we are able to open the global ".gitconfig" file in config::global::open_global, we never verify that we it is in fact readable. Do so by writing the global configuration file and verifying that reading from it produces the expected values.

25c085e6

2019-03-29T11:41:42

tests: repo: verify that we can open repos with symlinked global config We've got reports that users are unable to open repos when their global configuration ("~/.gitconfig") is a symlink. Add a test to verify that we are in fact able to do so as expected.

fa4505e6

2019-03-29T11:30:29

tests: config: make sure to clean up after each test The config::global test suite creates various different directories and files which are being populated with pretend-global files. Unfortunately, the tests do not clean up after themselves, which may cause subsequent tests to fail due to cruft left behind. Fix this by always removing created directories and their contents.

8e4927a4

2019-03-06T09:13:56

Merge pull request #5012 from dritter/dritter-patch-1 [Doc] Update URL to git2-rs

1fd0903a

2019-03-05T18:47:45

Update URL to git2-rs

79b26f20

2019-03-02T18:21:47

Merge pull request #5008 from libgit2/ethomson/remote_completion remote: Rename git_remote_completion_type to _t

7b083d3c

2019-03-02T18:14:36

Merge pull request #5005 from libgit2/ethomson/odb_backend_allocations odb: provide a free function for custom backends

c7e5eca6

2019-02-28T10:46:26

Revert "foo" This reverts commit 1fe3fa5e59818c851d50efc6563db5f8a5d7ae9b.

1fe3fa5e

2019-02-28T10:44:34

foo

b401273b

2019-02-27T10:08:28

Merge branch 'threading-docs'

02ab4841

2019-02-27T10:08:15

threading: clarify openssl default vs mbedtls

358a3b9c

2019-02-27T10:08:00

threading: clarify concurrency of access

2dd5a429

2019-02-25T13:16:13

remote: Rename git_remote_completion_type to _t For consistency with other "type" enums, rename git_remote_completion_type to git_remote_completion_t.

68729289

2019-02-25T09:25:34

Merge pull request #5000 from augfab/branch_lookup_all Have git_branch_lookup accept GIT_BRANCH_ALL

459ac856

2019-02-23T18:42:53

odb: provide a free function for custom backends Custom backends can allocate memory when reading objects and providing them to libgit2. However, if an error occurs in the custom backend after the memory has been allocated for the custom object but before it's returned to libgit2, the custom backend has no way to free that memory and it must be leaked. Provide a free function that corresponds to the alloc function so that custom backends have an opportunity to free memory before they return an error.

790aae77

2019-02-23T18:40:43

odb: rename git_odb_backend_malloc for consistency The `git_odb_backend_malloc` name is a system function that is provided for custom ODB backends and allows them to allocate memory for an ODB object in the read callback. This is important so that libgit2 can later free the memory used by an ODB object that was read from the custom backend. However, the name _suggests_ that it actually allocates a `git_odb_backend`. It does not; rename it to make it clear that it actually allocates backend _data_.

c5d8e300

2019-02-21T21:46:39

branch: have git_branch_lookup accept GIT_BRANCH_ALL

0a25141e

2019-02-21T21:42:25

branch: add test for git_branch_lookup to accept GIT_BRANCH_ALL

5a6a3c00

2019-02-22T11:45:42

Merge pull request #4997 from libgit2/ethomson/transfer_progress Rename git_transfer_progress to git_indexer_progress

ca909da5

2019-02-21T11:45:23

remote: deprecate git_push_transfer_progress Safely deprecate `git_push_transfer_progress`, forwarding it to the new `git_push_transfer_progress_cb` name.

59001e83

2019-02-21T11:41:19

remote: rename git_push_transfer_progress callback The `git_push_transfer_progress` is a callback and as such should be suffixed with `_cb` for consistency. Rename `git_push_transfer_progress` to `git_push_transfer_progress_cb`.

7506d34c

2019-02-21T10:38:53

indexer: deprecate git_transfer_progress Safely deprecate `git_transfer_progress` and `git_transfer_progress_cb` types, forwarding them to the new `git_indexer_progress` and `git_indexer_progress_cb`.

a1ef995d

2019-02-21T10:33:30

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

975d6722

2019-02-21T10:13:29

indexer: rename git_transfer_progress The name `git_transfer_progress` does not reflect its true purpose. It suggests that it's progress for a non-existence `git_transfer` object, and is used for indexing callbacks more broadly than just during transfers. Rename `git_transfer_progress` to `git_indexer_progress`.

4069f924

2019-02-22T10:56:08

Merge pull request #4901 from pks-t/pks/uniform-map-api High-level map APIs

75dd7f2a

2019-02-22T10:13:00

Merge pull request #4984 from pks-t/pks/refdb-fs-race refdb_fs: fix loose/packed refs lookup racing with repacks

c5594852

2019-02-22T10:06:24

Merge pull request #4998 from pks-t/pks/allocator-restructuring Allocator restructuring

3aa8401a

2019-02-21T14:10:43

Merge pull request #4992 from pks-t/pks/cache-dispose cache: fix misnaming of `git_cache_free`

68ba2e8d

2019-02-21T13:42:18

Merge pull request #4956 from pks-t/pks/examples-cgit2-standalone examples: produce single cgit2 binary

bbdcd450

2019-02-20T10:40:06

cache: fix misnaming of `git_cache_free` Functions that free a structure's contents but not the structure itself shall be named `dispose` in the libgit2 project, but the function `git_cache_free` does not follow this naming pattern. Fix this by renaming it to `git_cache_dispose` and adjusting all callers to make use of the new name.

48727e5d

2019-02-21T12:27:42

allocators: extract crtdbg allocator into its own file The Windows-specific crtdbg allocator is currently mixed into the crtdbg stacktracing compilation unit, making it harder to find than necessary. Extract it and move it into the new "allocators/" subdirectory to improve discoverability. This change means that the crtdbg compilation unit is now compiled unconditionally, whereas it has previously only been compiled on Windows platforms. Thus we now have additional guards around the code so that it will only be compiled if GIT_MSVC_CRTDBG is defined. This also allows us to move over the fallback-implementation of `git_win32_crtdbg_init_allocator` into the same compilation unit.

765ff6e0

2019-02-21T12:35:48

allocators: make crtdbg allocator reuse its own realloc In commit 6e0dfc6ff (Make stdalloc__reallocarray call stdalloc__realloc, 2019-02-16), we have changed the stdalloc allocator to reuse `stdalloc__realloc` to implement `stdalloc__reallocarray`. This commit is making the same change for the Windows-specific crtdbg allocator to avoid code duplication.

b63396b7

2019-02-21T12:13:59

allocators: move standard allocator into subdirectory Right now, our two allocator implementations are scattered around the tree in "stdalloc.h" and "win32/w32_crtdbg_stacktrace.h". Start grouping them together in a single directory "allocators/", similar to how e.g. our streams are organized.

9eb098d8

2019-02-21T11:37:04

Merge pull request #4991 from libgit2/ethomson/inttypes Remove public 'inttypes.h' header

247e6d90

2019-02-18T07:22:20

Remove public 'inttypes.h' header Remove an `inttypes.h` header that is too large in scope, and far too public. For Visual Studio 2012 and earlier (ie, `_MSC_VER < 1800`), we do need to include `stdint.h` in our public headers, for types like `uint32_t`. Internally, we also need to define `PRId64` as a printf formatting string when it is not available.

554b3b9a

2019-02-21T10:31:21

Merge pull request #4996 from eaigner/master Prevent reading out of bounds memory

966b9440

2019-02-21T08:30:22

tests: apply: verify that we correctly truncate the source buffer Previously, we would fail to correctly truncate the source buffer if the source has more than one line and ends with a non-newline character. In the following call, we thus truncate the source string in the middle of the second line. Without the bug fixed, we would successfully apply the patch to the source and return success. With the overflow being fixed, we should return an error now.

014d4955

2019-02-20T15:30:11

apply: prevent OOB read when parsing source buffer When parsing the patch image from a string, we split the string by newlines to get a line-based view of it. To split, we use `memchr` on the buffer and limit the buffer length by the original length provided by the caller. This works just fine for the first line, but for every subsequent line we need to actually subtract the amount of bytes that we have already read. The above issue can be easily triggered by having a source buffer with at least two lines, where the second line does _not_ end in a newline. Given a string "foo\nb", we have an original length of five bytes. After having extracted the first line, we will point to 'b' and again try to `memchr(p, '\n', 5)`, resulting in an out-of-bounds read of four bytes. Fix the issue by correctly subtracting the amount of bytes already read.

6eb4947d

2019-02-21T08:02:45

Merge pull request #4987 from lhchavez/fix-odb_otype_fast-leak Fix a memory leak in odb_otype_fast()

6b3730d4

2019-02-16T19:55:30

Fix a memory leak in odb_otype_fast() This change frees a copy of a cached object in odb_otype_fast().

12c6e1fa

2019-02-20T10:54:00

Merge pull request #4986 from lhchavez/realloc Make stdalloc__reallocarray call stdalloc__realloc

9f388e9f

2019-02-20T10:51:33

Merge pull request #4990 from libgit2/remove_time_monotonic Remove `git_time_monotonic`

d900dde4

2019-02-20T10:37:20

Merge pull request #4988 from lhchavez/fix-improbable-odb-initialization-leak Fix a _very_ improbable memory leak in git_odb_new()

e6c6d3bb

2019-02-17T22:31:37

Remove `git_time_monotonic` `git_time_monotonic` was added so that non-native bindings like rugged could get high-resolution timing for benchmarking. However, this is outside the scope of libgit2 *and* rugged decided not to use this function in the first place. Google suggests that absolutely _nobody_ is using this function and we don't want to be in the benchmarking business. Remove the function.

cb150e60

2019-02-17T19:31:11

Merge pull request #4989 from libgit2/ethomson/ci_docs ci: publish documentation on merge

fbfa41a1

2019-02-17T19:07:37

ci: publish documentation on merge When a commit is pushed or merged into one of the release branches (master, maint/*) then push the documentation update to gh-pages.

b5b3aa93

2019-02-17T12:50:51

Revert "ci: publish documentation after merge" This reverts commit 2a4e866a43e3db1e2be8e2a3d986ddc9f855d2bc.

4a02d24a

2019-02-17T12:40:20

foo

484fff87

2019-02-17T12:36:41

foo

2a4e866a

2019-02-17T12:34:23

ci: publish documentation after merge When a continuous integration build runs (ie a commit is pushed or merged into one of the CI branches, `master` or `maint/*`) then push the rebuilt documentation into the `gh-pages` branch.

dd45539d

2019-02-16T22:06:58

Fix a _very_ improbable memory leak in git_odb_new() This change fixes a mostly theoretical memory leak in got_odb_new() that can only manifest if git_cache_init() fails due to running out of memory or not being able to acquire its lock.

6e0dfc6f

2019-02-16T20:26:17

Make stdalloc__reallocarray call stdalloc__realloc This change avoids calling realloc(3) in more than one place.

df42f368

2018-12-01T10:54:57

idxmap: remove legacy low-level interface Remove the low-level interface that was exposing implementation details of `git_idxmap` to callers. From now on, only the high-level functions shall be used to retrieve or modify values of a map. Adjust remaining existing callers.

bd66925a

2018-12-01T10:29:32

oidmap: remove legacy low-level interface Remove the low-level interface that was exposing implementation details of `git_oidmap` to callers. From now on, only the high-level functions shall be used to retrieve or modify values of a map. Adjust remaining existing callers.

4713e7c8

2018-12-01T09:58:30

offmap: remove legacy low-level interface Remove the low-level interface that was exposing implementation details of `git_offmap` to callers. From now on, only the high-level functions shall be used to retrieve or modify values of a map. Adjust remaining existing callers.

fdfabdc4

2018-12-01T09:49:10

strmap: remove legacy low-level interface Remove the low-level interface that was exposing implementation details of `git_strmap` to callers. From now on, only the high-level functions shall be used to retrieve or modify values of a map. Adjust remaining existing callers.

6a9117f5

2018-12-01T10:18:42

cache: use iteration interface for cache eviction To relieve us from memory pressure, we may regularly call `cache_evict_entries` to remove some entries from it. Unfortunately, our cache does not support a least-recently-used mode or something similar, which is why we evict entries completeley at random right now. Thing is, this is only possible due to the map interfaces exposing the entry indices, and we intend to completely remove those to decouple map users from map implementations. As soon as that is done, we are unable to do this random eviction anymore. Convert this to make use of an iterator for now. Obviously, there is no random eviction possible like that anymore, but we'll always start by evicting from the beginning of the map. Due to hashing, one may hope that the selected buckets will be evicted at least in some way unpredictably. But more likely than not, this will not be the case. But let's see what happens and if any users complain about degraded performance. If so, we might come up with a different scheme than random removal, e.g. by using an LRU cache.

c976b4f9

2018-12-01T10:18:26

indexer: use map iterator to delete expected OIDs To compute whether there are objects missing in a packfile, the indexer keeps around a map of OIDs that it still expects to see. This map does not store any values at all, but in fact the keys are owned by the map itself. Right now, we free these keys by iterating over the map and freeing the key itself, which is kind of awkward as keys are expected to be constant. We can make this a bit prettier by inserting the OID as value, too. As we already store the `NULL` pointer either way, this does not increase memory usage, but makes the code a tad more clear. Furthermore, we convert the previously existing map iteration via indices to make use of an iterator, instead.

d00c24a9

2019-01-23T10:49:25

idxmap: introduce high-level getter for values The current way of looking up an entry from a map is tightly coupled with the map implementation, as one first has to look up the index of the key and then retrieve the associated value by using the index. As a caller, you usually do not care about any indices at all, though, so this is more complicated than really necessary. Furthermore, it invites for errors to happen if the correct error checking sequence is not being followed. Introduce new high-level functions `git_idxmap_get` and `git_idxmap_icase_get` that take a map and a key and return a pointer to the associated value if such a key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can trivially be converted.

b9d0b664

2018-12-17T09:10:53

offmap: introduce high-level setter for key/value pairs Currently, there is only one caller that adds entries into an offset map, and this caller first uses `git_offmap_put` to add a key and then set the value at the returned index by using `git_offmap_set_value_at`. This is just too tighlty coupled with implementation details of the map as it exposes the index of inserted entries, which we really do not care about at all. Introduce a new function `git_offmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert the caller to make use of it instead.

aa245623

2018-11-30T18:28:05

offmap: introduce high-level getter for values The current way of looking up an entry from a map is tightly coupled with the map implementation, as one first has to look up the index of the key and then retrieve the associated value by using the index. As a caller, you usually do not care about any indices at all, though, so this is more complicated than really necessary. Furthermore, it invites for errors to happen if the correct error checking sequence is not being followed. Introduce a new high-level function `git_offmap_get` that takes a map and a key and returns a pointer to the associated value if such a key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can trivially be converted.

2e0a3048

2019-01-23T10:48:55

oidmap: introduce high-level setter for key/value pairs Currently, one would use either `git_oidmap_insert` to insert key/value pairs into a map or `git_oidmap_put` to insert a key only. These function have historically been macros, which is why their syntax is kind of weird: instead of returning an error code directly, they instead have to be passed a pointer to where the return value shall be stored. This does not match libgit2's common idiom of directly returning error codes.Furthermore, `git_oidmap_put` is tightly coupled with implementation details of the map as it exposes the index of inserted entries. Introduce a new function `git_oidmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert all trivial callers of `git_oidmap_insert` and `git_oidmap_put` to make use of it.

9694ef20

2018-12-17T09:01:53

oidmap: introduce high-level getter for values The current way of looking up an entry from a map is tightly coupled with the map implementation, as one first has to look up the index of the key and then retrieve the associated value by using the index. As a caller, you usually do not care about any indices at all, though, so this is more complicated than really necessary. Furthermore, it invites for errors to happen if the correct error checking sequence is not being followed. Introduce a new high-level function `git_oidmap_get` that takes a map and a key and returns a pointer to the associated value if such a key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can trivially be converted.

03555830

2019-01-23T10:44:33

strmap: introduce high-level setter for key/value pairs Currently, one would use the function `git_strmap_insert` to insert key/value pairs into a map. This function has historically been a macro, which is why its syntax is kind of weird: instead of returning an error code directly, it instead has to be passed a pointer to where the return value shall be stored. This does not match libgit2's common idiom of directly returning error codes. Introduce a new function `git_strmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert all callers of `git_strmap_insert` to make use of it.

ef507bc7

2019-01-23T10:44:02

strmap: introduce `git_strmap_get` and use it throughout the tree The current way of looking up an entry from a map is tightly coupled with the map implementation, as one first has to look up the index of the key and then retrieve the associated value by using the index. As a caller, you usually do not care about any indices at all, though, so this is more complicated than really necessary. Furthermore, it invites for errors to happen if the correct error checking sequence is not being followed. Introduce a new high-level function `git_strmap_get` that takes a map and a key and returns a pointer to the associated value if such a key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can trivially be converted.

7e926ef3

2018-11-30T12:14:43

maps: provide a uniform entry count interface There currently exist two different function names for getting the entry count of maps, where offmaps offset and string maps use `num_entries` and OID maps use `size`. In most programming languages with built-in map types, this is simply called `size`, which is also shorter to type. Thus, this commit renames the other two functions `num_entries` to match the common way and adjusts all callers.

351eeff3

2019-01-23T10:42:46

maps: use uniform lifecycle management functions Currently, the lifecycle functions for maps (allocation, deallocation, resize) are not named in a uniform way and do not have a uniform function signature. Rename the functions to fix that, and stick to libgit2's naming scheme of saying `git_foo_new`. This results in the following new interface for allocation: - `int git_<t>map_new(git_<t>map **out)` to allocate a new map, returning an error code if we ran out of memory - `void git_<t>map_free(git_<t>map *map)` to free a map - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map This commit also fixes all existing callers.

18cf5698

2018-12-01T09:37:40

maps: provide high-level iteration interface Currently, our headers need to leak some implementation details of maps due to their direct use of indices in the implementation of their foreach macros. This makes it impossible to completely hide the map structures away, and also makes it impossible to include the khash implementation header in the C files of the respective map only. This is now being fixed by providing a high-level iteration interface `map_iterate`, which takes as inputs the map that shall be iterated over, an iterator as well as the locations where keys and values shall be put into. For simplicity's sake, the iterator is a simple `size_t` that shall initialized to `0` on the first call. All existing foreach macros are then adjusted to make use of this new function.

c50a8ac2

2018-12-01T08:59:24

maps: use high-level function to check existence of keys Some callers were still using the tightly-coupled pattern of `lookup_index` and `valid_index` to verify that an entry exists in a map. Instead, use the more high-level `exists` functions to decouple map users from its implementation.

84a089da

2018-12-01T08:50:36

maps: provide return value when deleting entries Currently, the delete functions of maps do not provide a return value. Like this, it is impossible to tell whether the entry has really been deleted or not. Change the implementation to provide either a return value of zero if the entry has been successfully deleted or `GIT_ENOTFOUND` if the key could not be found. Convert callers to the `delete_at` functions to instead use this higher-level interface.

8da93944

2018-12-01T10:52:44

idxmap: have `resize` functions return proper error code The currently existing function `git_idxmap_resize` and `git_idxmap_icase_resize` do not return any error codes at all due to their previous implementation making use of a macro. Due to that, it is impossible to see whether the resize operation might have failed due to an out-of-memory situation. Fix this by providing a proper error code. Adjust callers to make use of it.

661fc57b

2018-12-01T01:16:25

idxmap: introduce high-level setter for key/value pairs Currently, one would use the function `git_idxmap_insert` to insert key/value pairs into a map. This function has historically been a macro, which is why its syntax is kind of weird: instead of returning an error code directly, it instead has to be passed a pointer to where the return value shall be stored. This does not match libgit2's common idiom of directly returning error codes. Introduce a new function `git_idxmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert all callers of `git_idxmap_insert` to make use of it.

6cf47726

2019-01-15T13:54:18

examples/add: add explanatory comments and reformat

106998fc

2019-01-24T11:48:44

examples: print available commands if no args are given

ead10785

2019-01-24T11:31:49

examples: create common lg2 executable Inside of our networking example code, we have a git2 executable that acts as an entry point to all the different network examples. As such, it is kind of the same like the normal git(1) executable in that it simply arbitrates to the respective subcommands. Let's extend this approach and merge all examples into a single standalone lg2 executable. Instead of building an executable for all the existing examples we have, we now bundle them all inside of the lg2 one and let them be callable via subcommands. In the process, we can get rid of duplicated library initialization, deinitialization and repository discovery code. Instead of having each subcommand handle these on its own, we simply do it inside of the single main function now.

7562422a

2019-01-24T10:30:58

examples: merge common network code Right now, we have two sets of "common" code, one containing general common code and one containing network common code. As we intend to get rid of the network subdirectory and instead merge all examples into a single standalone executable, this distinction doesn't make a lot of sense now. Furthermore, the common network code is not that big. Let's get rid of the common network code by merging it into the general common code.

c4271314

2019-01-24T10:27:07

examples: remove unused Makefile This Makefile isn't used anymore and probably won't work anyway. Remove it in favor of the existing CMake build instructions.

a540e6bb

2019-01-24T10:07:31

examples: remove test script In commit 2e2332857 (examples: a test, for rev-list, 2013-03-20), a script was introduced with the intention of testing our rev-list example code. Nobody uses that script, and in fact it doesn't even properly work due to the not-so-recent addition out-of-source builds. Remove the script.

94743daf

2019-02-15T11:16:46

refdb_fs: fix race when migrating loose to packed refs in iteration Right now, we first load the packed refs cache and only afterwards load the loose references. This is susceptible to a race when the loose ref is being migrated to a packed cache by e.g. git-pack-refs(1): libgit2 git-pack-refs 1. We load the packed ref, which does not yet have the migrated reference. 2. git-pack-refs updates the packed ref file to have the migrated ref. 3. git-pack-refs deletes the old loose ref. 4. We look up the loose ref. So we now do not find the reference at all and will never iterate over it. Fix the issue by reversing the order: instead of first loading the packed refs, we will now look up the loose reference first. If it has already been deleted, then it must already be present in the packed-refs by definition, as git.git will only delete the reference after updating the packed refs file.

3ff0e3b5

2019-02-15T11:16:05

refdb_fs: remove ordering dependency on loose/packed refs loading Right now, loading loose refs has the side-effect of setting the `PACKREF_SHADOWED` flag for references that exist both in the loose and the packed refs. Because of this, we are force do first look up packed refs and only afterwards loading the packed refs. This is susceptible to a race, though, when refs are being repacked: when first loading the packed cache, then it may not yet have the migrated loose ref. But when now trying to look up the loose reference afterwards, then it may already have been migrated. Thus, we would fail to find this reference in this scenario. Remove this ordering dependency to allow fixing the above race. Instead of setting the flag when loading loose refs, we will now instead set it lazily when iterating over the loose refs. This even has the added benefit of not requiring us to lock the packed refs cache, as we already have an owned copy of it.

83333814

2019-02-15T10:56:50

refdb_fs: do not lazily copy packed ref cache When creating a new iterator, we eagerly load loose refs but only lazily create a copy of packed refs. The lazy load only happens as soon as we have iterated over all loose refs, opening up a potentially wide window for races. This may lead to an inconsistent view e.g. when the caller decides to reload packed references somewhen between iterating the loose refs, which is unexpected. Fix the issue by eagerly copying the sorted cache. Note that right now, we are heavily dependent on ordering here: we first need to reload packed refs, then we have to load loose refs and only as a last step are we allowed to copy the cache. This is because loading loose refs has the side-effect of setting the `PACKED_SHADOWED` flag in the packed refs cache, which we require to avoid outputting packed refs that already exist as loose refs.

32063d82

2019-02-15T10:41:30

refdb_fs: refactor error handling in iterator creation Refactor the error handling in `refdb_fs_backend__iterator` to always return the correct error code returned by the failing function.

8c773438

2019-02-15T10:15:39

refdb_fs: fix potential race with ref repacking in `exists` callback When repacking references, git.git will first update the packed refs and only afterwards delete any existing loose references that have now been moved to the new packed refs file. Due to this, there is a potential for racing if one first reads the packfile (which has not been updated yet) and only then trying to read the loose reference (which has just been deleted). In this case, one will incorrectly fail to lookup the reference and it will be reported as missing. Naturally, this is exactly what we've been doing in `refdb_fs_backend__exists`. Fix the race by reversing the lookup: we will now first check if the loose reference exists and only afterwards refresh the packed file.

bda08397

2019-02-14T16:57:47

Merge pull request #4982 from pks-t/pks/worktree-add-bare-head Enable creation of worktree from bare repo's default branch

48005936

2019-02-14T16:55:18

Merge pull request #4965 from hackworks/eliminate-check-for-keep-file Allow bypassing check for '.keep' file

b8837827

2019-02-14T13:09:23

Merge pull request #4979 from libgit2/ethomson/deprecate Deprecation: export the deprecated functions properly

bf013fc0

2019-02-14T13:30:33

branch: fix `branch_is_checked_out` with bare repos In a bare repository, HEAD usually points to the branch that is considered the "default" branch. As the current implementation for `git_branch_is_checked_out` only does a comparison of HEAD with the branch that is to be checked, it will say that the branch pointed to by HEAD in such a bare repo is checked out. Fix this by skipping the main repo's HEAD when it is bare.

efb20825

2019-02-14T13:05:49

branches: introduce flag to skip enumeration of certain HEADs Right now, the function `git_repository_foreach_head` will always iterate over all HEADs of the main repository and its worktrees. In some cases, it might be required to skip either of those, though. Add a flag in preparation for the following commit that enables this behaviour.

788cd2d5

2019-02-14T13:49:35

branches: do not assert that the given ref is a branch Libraries should use assert(3P) only very scarcely. First, we usually shouldn't cause the caller of our library to abort in case where the assert fails. Second, if code is compiled with -DNDEBUG, then the assert will not be included at all. In our `git_branch_is_checked_out` function, we have an assert that verifies that the given reference parameter is non-NULL and in fact a branch. While the first check is fine, the second is not. E.g. when compiled with -DNDEBUG, we'd proceed and treat the given reference as a branch in all cases. Fix the issue by instead treating a non-branch reference as not being checked out. This is the obvious solution, as references other than branches cannot be directly checked out.

a0f87e16

2019-02-14T13:26:30

branches: add tests for `git_branch_is_checked_out` We currently do not have any tests at all for the `git_branch_is_checked_out` function. Add some basic ones.

698eae13

2019-02-14T12:52:25

worktree: error out early if given ref is not valid When adding a new worktree, we only verify that an optionally given reference is valid half-way through the function. At this point, some data structures have already been created on-disk. If we bail out due to an invalid reference, these will be left behind and need to be manually cleaned up by the user. Improve the situation by moving the reference checks to the function's preamble. Like this, we error out as early as possible and will not leave behind any files.

3f823c2b

2019-02-14T00:00:06

ci: enable hard deprecation Enable hard deprecation in our builds to ensure that we do not call deprecated functions internally.

dcf81cdb

2019-02-13T23:56:40

deprecation: optionally enable hard deprecation Add a CMake option to enable hard deprecation; the resultant library will _not_ include any deprecated functions. This may be useful for internal CI builds that create libraries that are not shared with end-users to ensure that we do not use deprecated bits internally.

24ac9e0c

2019-02-13T23:26:54

deprecation: ensure we GIT_EXTERN deprecated funcs Although the error functions were deprecated, we did not properly mark them as deprecated. We need to include the `deprecated.h` file in order to ensure that the functions get their export attributes. Similarly, do not define `GIT_DEPRECATE_HARD` within the library, or those functions will also not get their export attributes. Define that only on the tests and examples.

e1916376

2019-02-14T09:22:57

Merge pull request #4980 from libgit2/ethomson/ci_nightly ci: skip ssh tests on macOS nightly

ef91917f

2019-02-14T09:19:32

ci: skip ssh tests on macOS nightly Like 811c1c0f8f80521dccc746a7bff180cd77a783ff, disable the SSH tests on macOS until we can resolve the newly introduced infrastructure issues.

85b2bd41

2019-02-14T01:13:33

Merge pull request #4976 from libgit2/ethomson/readme_v028 CI build fixups

811c1c0f

2019-02-14T00:51:39

ci: skip ssh tests on macOS SSH tests on macOS have begun failing for an unknown reason after an infrastructure upgrade to macOS 10.13.6. Disable those tests temporarily, until we can resolve it.

44f82134

2019-02-13T11:18:35

ci: provide more information about OS Subtle changes in the host OS can have impacts in the CI system that may be hard to debug. We previously showed the results of `uname` which can be difficult to interpret. Provide more information where available.

6f778351

2019-02-13T11:15:12

README: use correct badge for nightlies The URL was incorrect for the nightly badge image; it was erroneously showing the master branch continuous integration build badge.

thodg/libgit2

Log