| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Since we now always build the library with cdecl calling conventions,
our callbacks should be decorated as such so that users will not be able
to provide callbacks defined with other calling conventions.
The `GIT_CALLBACK` macro will inject the `__cdecl` attribute as
appropriate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our current configuration logic is completely oblivious of any
repository, but only cares for actual file paths. Unfortunately, we are
forced to break this assumption by the introduction of conditional
includes, which are evaluated in the context of a repository. Right now,
only one conditional exists with "gitdir:" -- it will only include the
configuration if the current repository's git directory matches the
value passed to "gitdir:".
To support these conditionals, we have to break our API and make the
repository available when opening a configuration file. This commit
extends the `open` call of configuration backends to include another
repository and adjusts existing code to have it available. This includes
the user-visible functions `git_config_add_file_ondisk` and
`git_config_add_backend`.
|
| |
|
|
|
|
|
| |
When a configuration file is locked, any updates made to it will be done
to the in-memory copy of the file. This allows for multiple updates to
happen while we hold the lock, preventing races during complex
config-file manipulation.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the get_entry() method to return a refcounted version of
the config entry, which you have to free when you're done.
This allows us to avoid freeing the memory in which the entry is stored
on a refresh, which may happen at any time for a live config.
For this reason, get_string() has been forbidden on live configs and a
new function get_string_buf() has been added, which stores the string in
a git_buf which the user then owns.
The functions which parse the string value takea advantage of the
borrowing to parse safely and then release the entry.
|
| |
|
|
|
|
| |
We have been refreshing on read and write for a while now, so
git_config_refresh() is at best a no-op, and might just end up wasting
cycles.
|
| |\
| |
| | |
Configuration snapshotting
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With the isolation of complex reads, we can now try to refresh the
on-disk file before reading a value from it.
This changes the semantics a bit, as before we could be sure that a
string we got from the configuration was valid until we wrote or
refreshed. This is no longer the case, as a read can also invalidate the
pointer.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to have consistent views of the config files for remotes,
submodules et al. and a configuration that represents what is currently
stored on-disk, we need a way to provide a view of the configuration
that does not change.
The goal here is to provide the snapshotting part by creating a
read-only copy of the state of the configuration at a particular point
in time, which does not change when a repository's main config changes.
|
| |/
|
|
|
| |
There were a couple of "init_opts()" functions a few more cases
of structure initialization that I somehow missed.
|
| |
|
|
| |
The basic structure of each function is courtesy of arrbee.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At some moment git_config_delete_entry lost the ability to delete one entry of
a multivar configuration. The moment you had more than one fetch or push
ref spec for a remote you will not be able to save that remote anymore. The
changes in network::remote::remotes::save show that problem.
I needed to create a new git_config_delete_multivar because I was not able to
remove one or several entries of a multivar config with the current API.
Several tries modifying how git_config_set_multivar(..., NULL) behaved were
not successful.
git_config_delete_multivar is very similar to git_config_set_multivar, and
delegates into config_delete_multivar of config_file. This function search
for the cvar_t that will be deleted, storing them in a temporal array, and
rebuilding the linked list. After calling config_write to delete the entries,
the cvar_t stored in the temporal array are freed.
There is a little fix in config_write, it avoids an infinite loop when using
a regular expression (case for the multivars). This error was found by the
test network::remote::remotes::tagopt.
|
| |
|
|
|
| |
Build it on top of the normal iterator instead, which lets use re-use
a lot of code.
|
| |
|
|
| |
Implement the foreach version as a wrapper around the iterator.
|
| | |
|
| | |
|
| |
|
|
|
| |
Like we have in the references iterator, next and free belong in the
iterator itself.
|
| |
|
|
|
| |
The plain function will return an iterator, so move this one out of
the way.
|
| |
|
|
| |
Make the iterator structure opaque and make sure it compiles.
|
| |
|
|
|
|
|
|
|
| |
new functions in struct git_config_backend:
* iterator_new(...)
* iterator_free(...)
* next(...)
The old callback based foreach style can still be used with `git_config_backend_foreach_match`
|
| |
|
|
|
|
|
|
| |
The GIT_CONFIG_LEVEL constants actually work well as an enum
because they are mutually exclusive, so this adds a typedef to
the enum and uses that everywhere that one of these constants are
expected, instead of the old code that typically used an unsigned
int.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This moves some of the odb_backend stuff that is related to the
internals of an odb_backend implementation into include/git2/sys.
Some of the stuff related to streaming I left in include/git2
because it seemed like it would be reasonably needed by a normal
user who wanted to stream objects into and out of the ODB.
Also, I added APIs for traversing the list of backends so that
some of the tests would not need to access ODB internals.
|
|
|
Moving backend implementor objects into include/git2/sys so the
APIs can be isolated from the ones that normal libgit2 users
would be likely to use.
|
