| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
The header "config_file.h" has a list of inline-functions to access the
contents of a config backend without directly messing with the struct's
function pointers. While all these functions are called
"git_config_file_*", they are in fact completely backend-agnostic and
don't care whether it is a file or not. Rename all the function to
instead be backend-agnostic versions called "git_config_backend_*" and
rename the header to match.
|
| |
|
|
|
|
|
|
|
| |
C++ style comment ("//") are not specified by the ISO C90 standard and
thus do not conform to it. While libgit2 aims to conform to C90, we did
not enforce it until now, which is why quite a lot of these
non-conforming comments have snuck into our codebase. Do a tree-wide
conversion of all C++ style comments to the supported C style comments
to allow us enforcing strict C90 compliance in a later commit.
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| | |
While most parts of a configuration key are case-insensitive, we should still be
case-preserving and write down whatever string the caller provided.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| | |
|
| | |
|
| |
|
|
|
| |
We should notice that we are in the correct section to add. This is a
cosmetic bug, since replacing any of these settings does work.
|
| | |
|
| |
|
|
| |
The config is not owned by the transaction, so please don’t free it.
|
| |
|
|
|
| |
This makes the API for commiting or discarding changes the same as for
references.
|
| |
|
|
|
|
|
|
|
| |
This lock/unlock pair allows for the cller to lock a configuration file
to avoid concurrent operations.
It also allows for a transactional approach to updating a configuration
file. If multiple updates must be made atomically, they can be done
while the config is locked.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
If a multivar exists within two sections (of the same name)
then they should both be updated in a `set_multivar`. Ensure
that this is the case.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Add a test that exposes a bug in config_write.
It is valid to have multiple separate headers for the same config section, but
config_write will exit after finding the first matching section in certain
situations.
This test proves that config_write will duplicate a variable that already
exists instead of overwriting it if the variable is defined under a duplicate
section header.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would try to be clever when writing the configuration
file and try to stop parsing (and simply copy the rest of the old
file) when we either found the value we were trying to write,
or when we left the section that value was in, the assumption being
that there was no more work to do.
Regrettably, you can have another section with the same name later
in the file, and we must cope with that gracefully, thus we read the
whole file in order to write a new file.
Now, writing a file looks even more than reading. Pull the config
parsing out into its own function that can be used by both reading
and writing the configuration.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Instead of using a config file in resources, include the config file content to
be tested directly in the test.
|
| |
|
|
|
|
| |
Add a unittest to validate bug #3043, where a duplicate empty config header
could cause deletion of a config entry to fail silently. The bug is currently
unresolved and this test will fail.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
When writing out, parse the resulting file instead of adding or
replacing the value locally. This has the effect of reading external
changes as well.
|
| |
|
|
|
|
|
| |
On set, we set/add the value written to the config's internal values,
but we do not refresh old values.
Document this in a test in preparation for the refresh changes.
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds giterr_user_cancel to return GIT_EUSER and clear any
error message that is sitting around. As a result of using that
in places, we need to be more thorough with capturing errors that
happen inside a callback when used internally. To help with that,
this also adds giterr_capture and giterr_restore so that when we
internally use a foreach-type function that clears errors and
converts them to GIT_EUSER, it is easier to restore not just the
return value, but the actual error message text.
|
| |
|
