| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| | |
config: don't write duplicate section
|
| | | |
|
| | |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
|
|
| |
This special-casing ignores that we might have a locked file, so the
hashtable does not represent the contents of the file we want to
write. This causes multivar writes to overwrite entries instead of add
to them when under lock.
There is no need for this as the normal code-path will write to the file
just fine, so simply get rid of it.
|
| | |
|
| | |
|
| |
|
|
|
| |
Query the `GIT_CONFIG_LEVEL_PROGRAMDATA` location when setting it up
for tests, in case the test runner has sandboxed it.
|
| |
|
|
|
|
|
|
|
| |
We currently use the timestamp in order to decide whether a config file
has changed since we last read it.
This scheme falls down if the file is written twice within the same
second, as we fail to detect the file change after the first read in
that second.
|
| |
|
|
|
| |
This is where portable git stores the global configuration which we can
use to adhere to it even though git isn't quite installed on the system.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Untangle git_futils_mkdir from git_futils_mkdir_ext - the latter
assumes that we own everything beneath the base, as if it were
being called with a base of the repository or working directory,
and is tailored towards checkout and ensuring that there is no
bogosity beneath the base that must be cleaned up.
This is (at best) slow and (at worst) unsafe in the larger context
of a filesystem where we do not own things and cannot do things like
unlink symlinks that are in our way.
|
| |
|
|
| |
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.
|
| |
|
|
|
|
| |
Don't assume that comment chars are comment chars, they may be (an
attempt to be escaped). If so, \; is not a valid escape sequence,
complain.
|
| |
|
|
|
| |
Combine unquoting and multiline detection to avoid ambiguity when
parsing.
|
| |
|
|
|
|
|
|
| |
The regcomp function returns a non-zero value if compilation of
a regular expression fails. In most places we only check for
negative values, but positive values indicate an error, as well.
Fix this tree-wide, fixing a segmentation fault when calling
git_config_iterator_glob_new with an invalid regexp.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
It fails at least on my computer, though it may depend on some unpredictable
factors (say, will realloc() extend the memory segment in place, or it will
allocate new memory).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
* Error-handling is cleaned up to only let a file-not-found error
through, not other sorts of errors. And when a file-not-found
error happens, we clean up the error.
* Test now checks that file-not-found introduces no error. And
other minor cleanups.
|
| |
|
|
|
|
|
|
|
|
|
| |
For example, if you have
[include]
path = foo
and foo didn't exist, git_config_open_ondisk() would just give up
on the rest of the file. Now it ignores the unresolved include
without error and continues reading the rest of the file.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the check for multiline, we traverse the backslashes from the end
backwards and int the end assert that we haven't gone past the beginning
of the line. We make sure of this in the loop condition, but we also
check in the return value.
However, for certain configurations, a line in a multiline variable
might be empty to aid formatting. In that case, 'end' == 'start', since
we ended up looking at the first char which made it a multiline.
There is no need for the (end > start) check in the return, since the
loop guarantees we won't go further back than the first char in the
line, and we do accept the first char to be the final backslash.
This fixes #2483.
|
| | |
|
| |\
| |
| | |
Remote deletion
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
There are a number of tests that modify the global or system
search paths during the tests. This adds a helper function to
make it easier to restore those paths and makes sure that they
are getting restored in a manner that preserves test isolation.
|
| |\ \
| | |
| | | |
Configuration snapshotting
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When we delete an entry, we also want to refresh the configuration to
catch any changes that happened externally.
This allows us to simplify the logic, as we no longer need to delete
these variables internally. The whole state will be refreshed and the
deleted entries won't be there.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
