summaryrefslogtreecommitdiff
path: root/src/transaction.c
Commit message (Collapse)AuthorAgeFilesLines
* strmap: introduce high-level setter for key/value pairsPatrick Steinhardt2019-02-151-2/+1
| | | | | | | | | | | | 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.
* strmap: introduce `git_strmap_get` and use it throughout the treePatrick Steinhardt2019-02-151-5/+1
| | | | | | | | | | | | | | 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.
* maps: use uniform lifecycle management functionsPatrick Steinhardt2019-02-151-1/+1
| | | | | | | | | | | | | | | | 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.
* git_error: use new names in internal APIs and usageEdward Thomson2019-01-221-12/+12
| | | | | Move to the `git_error` name in the internal API for error-related functions.
* references: use new names in internal usageethomson/git_refEdward Thomson2019-01-171-10/+10
| | | | Update internal usage to use the `git_reference` names for constants.
* khash: remove intricate knowledge of khash typesPatrick Steinhardt2018-11-281-1/+1
| | | | | | | 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.
* Make sure to always include "common.h" firstPatrick Steinhardt2017-07-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | 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.
* strmap: remove GIT__USE_STRMAP macroPatrick Steinhardt2017-02-171-2/+0
|
* khash: avoid using macro magic to get return addressPatrick Steinhardt2017-02-171-1/+1
|
* khash: avoid using `kh_foreach`/`kh_foreach_value` directlyPatrick Steinhardt2017-02-171-14/+4
|
* pool: Simplify implementationVicent Marti2015-10-281-2/+1
|
* Don't free config in `git_transaction_commit`.Arthur Schreiber2015-09-131-1/+0
| | | | The config is not owned by the transaction, so please don’t free it.
* config: perform unlocking via git_transactioncmn/config-txCarlos Martín Nieto2015-08-121-0/+42
| | | | | This makes the API for commiting or discarding changes the same as for references.
* Fix visibility of transaction symbolDamien PROFETA2015-06-121-0/+1
| | | | | Transaction.c did not include the visibility definition of its symbol (that are in git2/transaction.h) and so was by default hidden.
* Remove extra semicolon outside of a functionStefan Widgren2015-02-151-1/+1
| | | | | Without this change, compiling with gcc and pedantic generates warning: ISO C does not allow extra ‘;’ outside of a function.
* Clean up various compiler warningsEdward Thomson2014-10-261-3/+3
|
* transaction: rename lock() to lock_ref()cmn/reference-transactionCarlos Martín Nieto2014-10-091-1/+1
| | | | | This leaves space for future expansion to locking other resources without having to change the API for references.
* Introduce reference transactionsCarlos Martín Nieto2014-09-301-0/+352
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.