|
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.
|
|
|
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.
|
|
f673e232
|
2018-12-27T13:47:34
|
|
git_error: use new names in internal APIs and usage
Move to the `git_error` name in the internal API for error-related
functions.
|
|
|
ed8cfbf0
|
2019-01-17T00:32:31
|
|
references: use new names in internal usage
Update internal usage to use the `git_reference` names for constants.
|
|
|
852bc9f4
|
2018-11-23T19:26:24
|
|
khash: remove intricate knowledge of khash types
Instead of using the `khiter_t`, `git_strmap_iter` and `khint_t` types,
simply use `size_t` instead. This decouples code from the khash stuff
and makes it possible to move the khash includes into the implementation
files.
|
|
|
0c7f49dd
|
2017-06-30T13:39:01
|
|
Make sure to always include "common.h" first
Next to including several files, our "common.h" header also declares
various macros which are then used throughout the project. As such, we
have to make sure to always include this file first in all
implementation files. Otherwise, we might encounter problems or even
silent behavioural differences due to macros or defines not being
defined as they should be. So in fact, our header and implementation
files should make sure to always include "common.h" first.
This commit does so by establishing a common include pattern. Header
files inside of "src" will now always include "common.h" as its first
other file, separated by a newline from all the other includes to make
it stand out as special. There are two cases for the implementation
files. If they do have a matching header file, they will always include
this one first, leading to "common.h" being transitively included as
first file. If they do not have a matching header file, they instead
include "common.h" as first file themselves.
This fixes the outlined problems and will become our standard practice
for header and source files inside of the "src/" from now on.
|
|
|
13c3bc9a
|
2017-01-27T14:32:23
|
|
strmap: remove GIT__USE_STRMAP macro
|
|
|
73028af8
|
2017-01-27T14:20:24
|
|
khash: avoid using macro magic to get return address
|
|
|
9694d9ba
|
2017-01-25T14:09:17
|
|
khash: avoid using `kh_foreach`/`kh_foreach_value` directly
|
|
1e5e02b4
|
2015-10-27T17:26:04
|
|
pool: Simplify implementation
|
|
548cb334
|
2015-09-13T16:32:24
|
|
Don't free config in `git_transaction_commit`.
The config is not owned by the transaction, so please don’t free it.
|
|
5340d63d
|
2015-07-12T12:50:23
|
|
config: perform unlocking via git_transaction
This makes the API for commiting or discarding changes the same as for
references.
|
|
5c757327
|
2015-06-12T18:14:32
|
|
Fix visibility of transaction symbol
Transaction.c did not include the visibility definition of its symbol
(that are in git2/transaction.h) and so was by default hidden.
|
|
c8e02b87
|
2015-02-15T21:07:05
|
|
Remove extra semicolon outside of a function
Without this change, compiling with gcc and pedantic generates warning:
ISO C does not allow extra ‘;’ outside of a function.
|
|
369b0217
|
2014-10-13T13:34:15
|
|
Clean up various compiler warnings
|
|
|
c327d5db
|
2014-10-09T16:29:30
|
|
transaction: rename lock() to lock_ref()
This leaves space for future expansion to locking other resources
without having to change the API for references.
|
|
|
ab8d9242
|
2014-06-28T06:39:38
|
|
Introduce reference transactions
A transaction allows you to lock multiple references and set up changes
for them before applying the changes all at once (or as close as the
backend supports).
This can be used for replication purposes, or for making sure some
operations run when the reference is locked and thus cannot be changed.
|