|
69cd4141
|
2018-10-19T16:30:43
|
|
docs: fix transparent/opaque confusion in the conventions file
|
|
0a4284b1
|
2018-10-19T14:54:13
|
|
Merge pull request #4819 from libgit2/cmn/config-nonewline
Configuration variables can appear on the same line as the section header
|
|
f010b66b
|
2018-10-17T14:33:47
|
|
Merge pull request #4849 from libgit2/cmn/expose-gitfile-check
path: export the dotgit-checking functions
|
|
|
5be63f6d
|
2018-10-17T10:01:22
|
|
Merge pull request #4850 from libgit2/ethomson/libssh2_not_libssh
cmake: correct comment from libssh to libssh2
|
|
|
b160a64f
|
2018-10-17T09:38:30
|
|
cmake: correct comment from libssh to libssh2
We use libssh2. We do not use libssh. Make sure to disambiguate them
correctly.
|
|
7615794c
|
2018-10-15T18:08:13
|
|
Merge pull request #4845 from pks-t/pks/object-fuzzer
Object parsing fuzzer
|
|
|
9b6e4081
|
2018-10-15T17:08:38
|
|
Merge commit 'afd10f0' (Follow 308 redirects)
|
|
|
05e54e00
|
2018-10-15T13:54:17
|
|
path: export the dotgit-checking functions
These checks are preformed by libgit2 on checkout, but they're also useful for
performing checks in applications which do not involve checkout.
Expose them under `sys/` as it's still fairly in the weeds even for this
library.
|
|
|
1d718fa5
|
2018-09-28T11:55:34
|
|
config: variables might appear on the same line as a section header
While rare and a machine would typically not generate such a configuration file,
it is nevertheless valid to write
[foo "bar"] baz = true
and we need to deal with that instead of assuming everything is on its own line.
|
|
|
1cbc9604
|
2018-09-28T10:57:50
|
|
config: add failing test for no newline after section header
|
|
afd10f0b
|
2018-10-13T09:31:20
|
|
Follow 308 redirects (as used by GitLab)
|
|
|
814e7acb
|
2018-10-12T12:38:06
|
|
Merge pull request #4842 from nelhage/fuzz-config-memory
config: Port config_file_fuzzer to the new in-memory backend.
|
|
463c21e2
|
2018-10-11T13:27:06
|
|
Apply code review feedback
|
|
|
a1d5fd06
|
2018-10-11T12:46:11
|
|
fuzzers: add object parsing fuzzer
Add a simple fuzzer that exercises our object parser code. The fuzzer
is quite trivial in that it simply passes the input data directly to
`git_object__from_raw` for each of the four object types.
|
|
|
6562cdda
|
2018-10-11T12:43:08
|
|
object: properly propagate errors on parsing failures
When failing to parse a raw object fromits data, we free the
partially parsed object but then fail to propagate the error to the
caller. This may lead callers to operate on objects with invalid memory,
which will sooner or later cause the program to segfault.
Fix the issue by passing up the error code returned by `parse_raw`.
|
|
|
6956a954
|
2018-10-11T12:26:44
|
|
fuzzers: initialize libgit2 in standalone driver
The standalone driver for libgit2's fuzzing targets makes use of
functions from libgit2 itself. While this is totally fine to do, we need
to make sure to always have libgit2 initialized via `git_libgit2_init`
before we call out to any of these. While this happens in most cases as
we call `LLVMFuzzerInitialize`, which is provided by our fuzzers and
which right now always calls `git_libgit2_init`, one exception to this
rule is our error path when not enough arguments have been given. In
this case, we will call `git_vector_free_deep` without libgit2 having
been initialized. As we did not set up our allocation functions in that
case, this will lead to a segmentation fault.
Fix the issue by always initializing and shutting down libgit2 in the
standalone driver. Note that we cannot let this replace the
initialization in `LLVMFuzzerInitialize`, as it is required when using
the "real" fuzzers by LLVM without our standalone driver. It's no
problem to call the initialization and deinitialization functions
multiple times, though.
|
|
|
416aafd1
|
2018-10-09T02:33:03
|
|
fuzzers: Port config_file_fuzzer to the new in-memory backend
|
|
|
2d449a11
|
2018-10-09T02:42:14
|
|
config: Refactor `git_config_backend_from_string` to take a length
|
|
|
838a2f29
|
2018-10-07T12:00:48
|
|
Merge pull request #4828 from csware/git_futils_rmdir_r_failing
Add some more tests for git_futils_rmdir_r and some cleanup
|
|
|
0cd976c8
|
2018-10-07T12:00:06
|
|
Merge pull request #4830 from pks-t/pks/diff-stats-rename-common
diff_stats: use git's formatting of renames with common directories
|
|
|
0c973356
|
2018-10-07T11:57:06
|
|
Merge pull request #4839 from palmin/ignore-unsupported-http-auth
ignore unsupported http authentication contexts
|
|
475db39b
|
2018-10-06T12:58:06
|
|
ignore unsupported http authentication schemes
auth_context_match returns 0 instead of -1 for unknown schemes to
not fail in situations where some authentication schemes are supported
and others are not.
apply_credentials is adjusted to handle auth_context_match returning
0 without producing authentication context.
|
|
|
a8d447f6
|
2018-10-05T20:13:34
|
|
Merge pull request #4837 from pks-t/cmn/reject-option-submodule-url-path
submodule: ignore path and url attributes if they look like options
|
|
|
ce8803a2
|
2018-10-05T20:03:38
|
|
Merge pull request #4836 from pks-t/pks/smart-packets
Smart packet security fixes
|
|
|
84d6f439
|
2018-10-05T19:53:22
|
|
Merge pull request #4832 from pks-t/pks/config-includes-null-deref
config_file: properly ignore includes without "path" value
|
|
|
c8ca3cae
|
2018-10-05T11:47:39
|
|
submodule: ignore path and url attributes if they look like options
These can be used to inject options in an implementation which performs a
recursive clone by executing an external command via crafted url and path
attributes such that it triggers a local executable to be run.
The library is not vulnerable as we do not rely on external executables but a
user of the library might be relying on that so we add this protection.
This matches this aspect of git's fix for CVE-2018-17456.
|
|
|
4e0bdaa8
|
2018-10-05T11:42:00
|
|
submodule: add failing test for option-injection protection in url and path
|
|
|
b37a5954
|
2018-10-05T13:24:55
|
|
Merge pull request #4831 from pks-t/pks/int-conversion
int-conversion
|
|
|
ad273718
|
2018-10-04T10:32:07
|
|
tests: sanitize file hierarchy after running rmdir tests
Currently, we do not clean up after ourselves after tests in core::rmdir
have created new files in the directory hierarchy. This may leave stale
files and/or directories after having run tests, confusing subsequent
tests that expect a pristine test environment. Most importantly, it may
cause the test initialization to fail which expects being able to
re-create the testing hierarchy before each test in case where another
test hasn't cleaned up after itself.
Fix the issue by adding a cleanup function that removes the temporary
testing hierarchy after each test if it still exists.
|
|
e886ab46
|
2018-10-02T19:50:29
|
|
tests: Add some more tests for git_futils_rmdir_r
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
|
|
d06d4220
|
2018-10-05T10:56:02
|
|
config_file: properly ignore includes without "path" value
In case a configuration includes a key "include.path=" without any
value, the generated configuration entry will have its value set to
`NULL`. This is unexpected by the logic handling includes, and as soon
as we try to calculate the included path we will unconditionally
dereference that `NULL` pointer and thus segfault.
Fix the issue by returning early in both `parse_include` and
`parse_conditional_include` in case where the `file` argument is `NULL`.
Add a test to avoid future regression.
The issue has been found by the oss-fuzz project, issue 10810.
|
|
|
bf662f7c
|
2018-10-05T10:55:29
|
|
tests: always unlink created config files
While our tests in config::include create a plethora of configuration
files, most of them do not get removed at the end of each test. This can
cause weird interactions with tests that are being run at a later stage
if these later tests try to create files or directories with the same
name as any of the created configuration files.
Fix the issue by unlinking all created files at the end of these tests.
|
|
|
aa0ae59a
|
2018-10-05T10:31:53
|
|
cmake: explicitly enable int-conversion warnings
While GCC enables int-conversion warnings by default, it will currently
only warn about such errors even in case where "-DENABLE_WERROR=ON" has
been passed to CMake. Explicitly enable int-conversion warnings by using
our `ENABLE_WARNINGS` macro, which will automatically use
"-Werror=int-conversions" in case it has been requested by the user.
|
|
|
dbb4a586
|
2018-10-05T10:27:33
|
|
tests: fix warning for implicit conversion of integer to pointer
GCC warns by default when implicitly converting integers to pointers or
the other way round, and commit fa48d2ea7 (vector: do not malloc
0-length vectors on dup, 2018-09-26) introduced such an implicit
conversion into our vector tests. While this is totally fine in this
test, as the pointer's value is never being used in the first place, we
can trivially avoid the warning by instead just inserting a pointer for
a variable allocated on the stack into the vector.
|
|
|
b95c79ab
|
2018-10-04T18:35:11
|
|
Merge pull request #4829 from pks-t/pks/cmake-cmp0054
cmake: enable new quoted argument policy CMP0054
|
|
|
e41a0f7b
|
2018-10-04T11:45:13
|
|
Merge pull request #4824 from palmin/packbuilder-interesting-blob
fix check if blob is uninteresting when inserting tree to packbuilder
|
|
|
e5090ee3
|
2018-10-04T11:19:28
|
|
diff_stats: use git's formatting of renames with common directories
In cases where a file gets renamed such that the directories containing
it previous and after the rename have a common prefix, then git will
avoid printing this prefix twice and instead format the rename as
"prefix/{old => new}". We currently didn't do anything like that, but
simply printed "prefix/old -> prefix/new".
Adjust our behaviour to instead match upstream. Adjust the test for this
behaviour to expect the new format.
|
|
|
3148efd2
|
2018-10-04T11:13:57
|
|
tests: verify diff stats with renames in subdirectory
Until now, we didn't have any tests that verified that our format for
renames in subdirectories is correct. While our current behaviour is no
different than for renames that do not happen with a common prefix
shared between old and new file name, we intend to change the format to
instead match the format that upstream git uses.
Add a test case for this to document our current behaviour and to show
how the next commit will change that format.
|
|
|
633584b5
|
2018-10-04T10:48:12
|
|
cmake: enable new quoted argument policy CMP0054
Quoting from CMP0054's documentation:
Only interpret if() arguments as variables or keywords when
unquoted.
CMake 3.1 and above no longer implicitly dereference variables or
interpret keywords in an if() command argument when it is a Quoted
Argument or a Bracket Argument.
The OLD behavior for this policy is to dereference variables and
interpret keywords even if they are quoted or bracketed. The NEW
behavior is to not dereference variables or interpret keywords that
have been quoted or bracketed.
The previous behaviour could be quite unexpected. Quoted arguments might
be expanded in case where the value of the argument corresponds to a
variable. E.g. `IF("MONKEY" STREQUAL "MONKEY")` would have been expanded
to `IF("1" STREQUAL "1")` iff `SET(MONKEY 1)` was set. This behaviour
was weird, and recent CMake versions have started to complain about this
if they see ambiguous situations. Thus we want to disable it in favor of
the new behaviour.
|
|
|
04d3853f
|
2018-10-04T10:47:29
|
|
cmake: remove spaces between `IF` and `(` for policies
Our CMake coding style dictates that there should be no space between
`IF` and its opening `(`. Adjust our policy statements to honor this
style.
|
|
|
cceefcda
|
2018-10-04T09:50:21
|
|
Merge pull request #4827 from tiennou/fix/documentation-fixups
Documentation fixups
|
|
|
1bc5b05c
|
2018-10-03T16:17:21
|
|
smart_pkt: do not accept callers passing in no line length
Right now, we simply ignore the `linelen` parameter of
`git_pkt_parse_line` in case the caller passed in zero. But in fact, we
never want to assume anything about the provided buffer length and
always want the caller to pass in the available number of bytes.
And in fact, checking all the callers, one can see that the funciton is
never being called in case where the buffer length is zero, and thus we
are safe to remove this check.
|
|
|
c05790a8
|
2018-08-09T11:16:15
|
|
smart_pkt: return parsed length via out-parameter
The `parse_len` function currently directly returns the parsed length of
a packet line or an error code in case there was an error. Instead,
convert this to our usual style of using the return value as error code
only and returning the actual value via an out-parameter. Thus, we can
now convert the output parameter to an unsigned type, as the size of a
packet cannot ever be negative.
While at it, we also move the check whether the input buffer is long
enough into `parse_len` itself. We don't really want to pass around
potentially non-NUL-terminated buffers to functions without also passing
along the length, as this is dangerous in the unlikely case where other
callers for that function get added. Note that we need to make sure
though to not mess with `GIT_EBUFS` error codes, as these indicate not
an error to the caller but that he needs to fetch more data.
|
|
|
0b3dfbf4
|
2018-08-09T11:13:59
|
|
smart_pkt: reorder and rename parameters of `git_pkt_parse_line`
The parameters of the `git_pkt_parse_line` function are quite confusing.
First, there is no real indicator what the `out` parameter is actually
all about, and it's not really clear what the `bufflen` parameter refers
to. Reorder and rename the parameters to make this more obvious.
|
|
|
5fabaca8
|
2018-08-09T11:04:42
|
|
smart_pkt: fix buffer overflow when parsing "unpack" packets
When checking whether an "unpack" packet returned the "ok" status or
not, we use a call to `git__prefixcmp`. In case where the passed line
isn't properly NUL terminated, though, this may overrun the line buffer.
Fix this by using `git__prefixncmp` instead.
|
|
|
b5ba7af2
|
2018-08-09T11:03:37
|
|
smart_pkt: fix "ng" parser accepting non-space character
When parsing "ng" packets, we blindly assume that the character
immediately following the "ng" prefix is a space and skip it. As the
calling function doesn't make sure that this is the case, we can thus
end up blindly accepting an invalid packet line.
Fix the issue by using `git__prefixncmp`, checking whether the line
starts with "ng ".
|
|
|
a9f1ca09
|
2018-08-09T11:01:00
|
|
smart_pkt: fix buffer overflow when parsing "ok" packets
There are two different buffer overflows present when parsing "ok"
packets. First, we never verify whether the line already ends after
"ok", but directly go ahead and also try to skip the expected space
after "ok". Second, we then go ahead and use `strchr` to scan for the
terminating newline character. But in case where the line isn't
terminated correctly, this can overflow the line buffer.
Fix the issues by using `git__prefixncmp` to check for the "ok " prefix
and only checking for a trailing '\n' instead of using `memchr`. This
also fixes the issue of us always requiring a trailing '\n'.
Reported by oss-fuzz, issue 9749:
Crash Type: Heap-buffer-overflow READ {*}
Crash Address: 0x6310000389c0
Crash State:
ok_pkt
git_pkt_parse_line
git_smart__store_refs
Sanitizer: address (ASAN)
|
|
|
bc349045
|
2018-08-09T10:38:10
|
|
smart_pkt: fix buffer overflow when parsing "ACK" packets
We are being quite lenient when parsing "ACK" packets. First, we didn't
correctly verify that we're not overrunning the provided buffer length,
which we fix here by using `git__prefixncmp` instead of
`git__prefixcmp`. Second, we do not verify that the actual contents make
any sense at all, as we simply ignore errors when parsing the ACKs OID
and any unknown status strings. This may result in a parsed packet
structure with invalid contents, which is being silently passed to the
caller. This is being fixed by performing proper input validation and
checking of return codes.
|
|
|
5edcf5d1
|
2018-08-09T10:57:06
|
|
smart_pkt: adjust style of "ref" packet parsing function
While the function parsing ref packets doesn't have any immediately
obvious buffer overflows, it's style is different to all the other
parsing functions. Instead of checking buffer length while we go, it
does a check up-front. This causes the code to seem a lot more magical
than it really is due to some magic constants. Refactor the function to
instead make use of the style of other packet parser and verify buffer
lengths as we go.
|
|
|
786426ea
|
2018-08-09T10:46:58
|
|
smart_pkt: check whether error packets are prefixed with "ERR "
In the `git_pkt_parse_line` function, we determine what kind of packet
a given packet line contains by simply checking for the prefix of that
line. Except for "ERR" packets, we always only check for the immediate
identifier without the trailing space (e.g. we check for an "ACK"
prefix, not for "ACK "). But for "ERR" packets, we do in fact include
the trailing space in our check. This is not really much of a problem at
all, but it is inconsistent with all the other packet types and thus
causes confusion when the `err_pkt` function just immediately skips the
space without checking whether it overflows the line buffer.
Adjust the check in `git_pkt_parse_line` to not include the trailing
space and instead move it into `err_pkt` for consistency.
|
|
|
40fd84cc
|
2018-08-09T10:46:26
|
|
smart_pkt: explicitly avoid integer overflows when parsing packets
When parsing data, progress or error packets, we need to copy the
contents of the rest of the current packet line into the flex-array of
the parsed packet. To keep track of this array's length, we then assign
the remaining length of the packet line to the structure. We do have a
mismatch of types here, as the structure's `len` field is a signed
integer, while the length that we are assigning has type `size_t`.
On nearly all platforms, this shouldn't pose any problems at all. The
line length can at most be 16^4, as the line's length is being encoded
by exactly four hex digits. But on a platforms with 16 bit integers,
this assignment could cause an overflow. While such platforms will
probably only exist in the embedded ecosystem, we still want to avoid
this potential overflow. Thus, we now simply change the structure's
`len` member to be of type `size_t` to avoid any integer promotion.
|
|
|
4a5804c9
|
2018-08-09T10:36:44
|
|
smart_pkt: honor line length when determining packet type
When we parse the packet type of an incoming packet line, we do not
verify that we don't overflow the provided line buffer. Fix this by
using `git__prefixncmp` instead and passing in `len`. As we have
previously already verified that `len <= linelen`, we thus won't ever
overflow the provided buffer length.
|
|
|
365d2720
|
2018-10-03T15:39:40
|
|
tests: verify parsing logic for smart packets
The commits following this commit are about to introduce quite a lot of
refactoring and tightening of the smart packet parser. Unfortunately, we
do not yet have any tests despite our online tests that verify that our
parser does not regress upon changes. This is doubly unfortunate as our
online tests aren't executed by default.
Add new tests that exercise the smart parsing logic directly by
executing `git_pkt_parse_line`.
|
|
25da1acb
|
2018-09-25T14:43:19
|
|
config: fix incorrect filename in documentation comment
The underlying code uses GIT_CONFIG_FILENAME_GLOBAL, which is .gitconfig.
|
|
|
7283daa8
|
2018-10-01T21:00:15
|
|
doc: small fixups & additions
|
|
|
b36cc7a4
|
2018-09-27T11:18:00
|
|
fix check if blob is uninteresting when inserting tree to packbuilder
Blobs that have been marked as uninteresting should not be inserted into packbuilder
when inserting a tree. The check as to whether a blob was uninteresting looked at
the status for the tree itself instead of the blob.
This could cause significantly larger packfiles.
|
|
|
1621a37d
|
2018-09-29T13:22:59
|
|
Merge pull request #4812 from libgit2/ethomson/ci-refactor
CI: refactoring
|
|
|
429c7f11
|
2018-09-17T20:12:59
|
|
ci: don't stop on failure
Don't stop on test failures; run all the tests, even when a test fails.
|
|
|
7c9769d9
|
2018-09-17T19:57:26
|
|
ci: append -r flag to clar on windows
Similar to the way we parse the ctest output on POSIX systems, do the
same on Windows. This allows us to append the `-r` flag to clar after
we've identified the command to run.
|
|
|
0530d7d9
|
2018-09-28T18:04:23
|
|
Merge pull request #4767 from pks-t/pks/config-mem
In-memory configuration
|
|
|
123e5963
|
2018-08-10T18:59:59
|
|
config_entries: abstract away reference counting
Instead of directly calling `git_atomic_inc` in users of the config
entries store, provide a `git_config_entries_incref` function to further
decouple the interfaces. Convert the refcount to a `git_refcount`
structure while at it.
|
|
|
5a7e0b3c
|
2018-08-10T18:49:38
|
|
config_entries: abstract away iteration over entries
The nice thing about our `git_config_iterator` interfaces is that nobody
needs to know anything about the implementation details. All that is
required is to obtain the iterator via any backend and then use it by
executing generic functions. We can thus completely internalize all the
implementation details of how to iterate over entries into the config
entries store and simply create such an iterator in our config file
backend when we want to iterate its entries. This further decouples the
config file backend from the config entries store.
|
|
|
60ebc137
|
2018-08-10T14:53:09
|
|
config_entries: abstract away retrieval of config entries
The code accessing config entries in the `git_config_entries` structure
is still much too intimate with implementation details, directly
accessing the maps and handling indices. Provide two new functions to
get config entries from the internal map structure to decouple the
interfaces and use them in the config file code.
The function `git_config_entries_get` will simply look up the entry by
name and, in the case of a multi-value, return the last occurrence of
that entry. The second function, `git_config_entries_get_unique`, will
only return an entry if it is unique and not included via another
configuration file. This one is required to properly implement write
operations for single entries, as we refuse to write to or delete a
single entry if it is not clear which one was meant.
|
|
|
fb8a87da
|
2018-08-10T14:50:15
|
|
config_entries: rename functions and structure
The previous commit simply moved all code that is required to handle
config entries to a new module without yet adjusting any of the function
and structure names to help readability. We now rename things
accordingly to have a common "git_config_entries" entries instead of the
old "diskfile_entries" one.
|
|
|
04f57d51
|
2018-08-10T13:33:02
|
|
config_entries: pull out implementation of entry store
The configuration entry store that is used for configuration files needs
to keep track of all entries in two different structures:
- a singly linked list is being used to be able to iterate through
configuration files in the order they have been found
- a string map is being used to efficiently look up configuration
entries by their key
This store is thus something that may be used by other, future backends
as well to abstract away implementation details and iteration over the
entries.
Pull out the necessary functions from "config_file.c" and moves them
into their own "config_entries.c" module. For now, this is simply moving
over code without any renames and/or refactorings to help reviewing.
|
|
|
d75bbea1
|
2018-08-10T14:35:23
|
|
config_file: remove unnecessary snapshot indirection
The implementation for config file snapshots has an unnecessary
redirection from `config_snapshot` to `git_config_file__snapshot`.
Inline the call to `git_config_file__snapshot` and remove it.
|
|
|
b944e137
|
2018-08-10T13:03:33
|
|
config: rename "config_file.h" to "config_backend.h"
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.
|
|
|
1aeff5d7
|
2018-08-10T12:52:18
|
|
config: move function normalizing section names into "config.c"
The function `git_config_file_normalize_section` is never being used in
any file different than "config.c", but it is implemented in
"config_file.c". Move it over and make the symbol static.
|
|
|
a5562692
|
2018-08-10T12:49:50
|
|
config: make names backend-agnostic
As a last step to make variables and structures more backend agnostic
for our `git_config` structure, rename local variables to not be called
`file` anymore.
|
|
|
2be39cef
|
2018-08-10T19:38:57
|
|
config: introduce new read-only in-memory backend
Now that we have abstracted away how to store and retrieve config
entries, it became trivial to implement a new in-memory backend by
making use of this. And thus we do so.
This commit implements a new read-only in-memory backend that can parse
a chunk of memory into a `git_config_backend` structure.
|
|
|
b78f4ab0
|
2018-08-16T12:22:03
|
|
config_entries: refactor entries iterator memory ownership
Right now, the config file code requires us to pass in its backend to
the config entry iterator. This is required with the current code, as
the config file backend will first create a read-only snapshot which is
then passed to the iterator just for that purpose. So after the iterator
is getting free'd, the code needs to make sure that the snapshot gets
free'd, as well.
By now, though, we can easily refactor the code to be more efficient and
remove the reverse dependency from iterator to backend. Instead of
creating a read-only snapshot (which also requires us to re-parse the
complete configuration file), we can simply duplicate the config entries
and pass those to the iterator. Like that, the iterator only needs to
make sure to free the duplicated config entries, which is trivial to do
and clears up memory ownership by a lot.
|
|
|
d49b1365
|
2018-08-10T19:01:37
|
|
config_entries: internalize structure declarations
Access to the config entries is now completely done via the modules
function interface and no caller messes with the struct's internals. We
can thus completely move the structure declarations into the
implementation file so that nobody even has a chance to mess with the
members.
|
|
|
ba1cd495
|
2018-09-28T11:10:49
|
|
Merge pull request #4784 from tiennou/fix/warnings
Some warnings
|
|
|
367f6243
|
2018-09-28T11:04:06
|
|
Merge pull request #4803 from tiennou/fix/4802
index: release the snapshot instead of freeing the index
|
|
|
e0afd1c2
|
2018-09-26T21:17:39
|
|
vector: do not realloc 0-size vectors
|
|
|
fa48d2ea
|
2018-09-26T19:15:35
|
|
vector: do not malloc 0-length vectors on dup
|
|
|
be4717d2
|
2018-09-18T12:12:06
|
|
path: fix "comparison always true" warning
|
|
|
21496c30
|
2018-03-30T00:20:23
|
|
stransport: fix a warning on iOS
"warning: values of type 'OSStatus' should not be used as format arguments; add an explicit cast to 'int' instead [-Wformat]"
|
|
|
b3e6ef92
|
2018-09-24T23:59:12
|
|
Merge pull request #4816 from libgit2/ethomson/test_leak
online::clone: free url and username before resetting
|
|
|
e84914fd
|
2018-09-20T20:11:36
|
|
online::clone: free url and username before resetting
Before resetting the url and username, ensure that we free them in case
they were set by environment variables.
|
|
|
a54043b7
|
2018-09-21T15:32:18
|
|
Merge pull request #4794 from marcin-krystianc/mkrystianc/prune_perf
git_remote_prune to be O(n * logn)
|
|
|
83733aeb
|
2018-08-10T12:43:21
|
|
config: rename `file_internal` and its `file` member
Same as with the previous commit, the `file_internal` struct is used to
keep track of all the backends that are added to a `git_config` struct.
Rename it to `backend_internal` and rename its `file` member to
`backend` to make the implementation more backend-agnostic.
|
|
|
633cf40c
|
2018-08-10T12:39:17
|
|
config: rename `files` vector to `backends`
Originally, the `git_config` struct is a collection of all the parsed
configuration files from different scopes (system-wide config,
user-specific config as well as the repo-specific config files).
Historically, we didn't and don't yet have any other configuration
backends than the one for files, which is why the field holding the
config backends is called `files`. But in fact, nothing dictates that
the vector of backends actually holds file backends only, as they are
generic and custom backends can be implemented by users.
Rename the member to be called `backends` to clarify that there is
nothing specific to files here.
|
|
|
b9affa32
|
2018-08-10T19:23:00
|
|
config_parse: avoid unused static declared values
The variables `git_config_escaped` and `git_config_escapes` are both
defined as static const character pointers in "config_parse.h". In case
where "config_parse.h" is included but those two variables are not being
used, the compiler will thus complain about defined but unused
variables. Fix this by declaring them as external and moving the actual
initialization to the C file.
Note that it is not possible to simply make this a #define, as we are
indexing into those arrays.
|
|
|
0b9c68b1
|
2018-08-16T14:10:58
|
|
submodule: fix submodule names depending on config-owned memory
When populating the list of submodule names, we use the submodule
configuration entry's name as the key in the map of submodule names.
This creates a hidden dependency on the liveliness of the configuration
that was used to parse the submodule, which is fragile and unexpected.
Fix the issue by duplicating the string before writing it into the
submodule name map.
|
|
|
df33b43d
|
2018-09-20T08:50:55
|
|
Merge pull request #4813 from libgit2/ethomson/ci-rename
Rename "VSTS" to "Azure DevOps" and "Azure Pipelines"
|
|
|
f8274204
|
2018-09-19T12:31:17
|
|
Merge pull request #4810 from libgit2/cmn/format-security
cmake: enable -Wformat and -Wformat-security
|
|
|
e2613039
|
2018-09-18T13:52:08
|
|
README: rename "VSTS" to "Azure DevOps"
Visual Studio Team Services is now a family of applications named "Azure
DevOps". Update the README to refer to it thusly.
|
|
|
464305b7
|
2018-09-18T13:51:25
|
|
README: update the build badge to Azure Pipelines
VSTS is now a family of components; "Azure Pipelines" is the build and
release pipeline application.
|
|
|
d7d0139e
|
2018-09-18T13:35:25
|
|
ci: rename vsts to azure-pipelines
|
|
|
a8301b0c
|
2018-09-11T15:15:26
|
|
ci: add SKIP_*_TESTS for windows builds
Introduce SKIP_*_TEST variables for Windows builds to match POSIX
builds.
|
|
|
e181a649
|
2018-09-18T03:03:03
|
|
Merge pull request #4809 from libgit2/cmn/revwalk-sign-regression
Fix revwalk limiting regression
|
|
|
744d8388
|
2018-09-18T02:59:45
|
|
Merge pull request #4805 from libgit2/signed_char
path validation: `char` is not signed by default.
|
|
|
2dd88a5f
|
2018-09-18T02:55:31
|
|
Merge pull request #4811 from libgit2/cmn/sorting-modes
revwalk: refer the sorting modes more to git's options
|
|
|
330b10ca
|
2018-09-17T21:53:58
|
|
revwalk: refer the sorting modes more to git's options
Show more directly what the sorting modes correspond to in git's `rev-list` as
that's the reference implementation for what the possible sorting orders are.
|
|
|
f2c1153d
|
2018-09-17T20:38:05
|
|
cmake: enable -Wformat and -Wformat-security
We do not currently have any warnings in this regard, but it's good practice to
have them on in case we introduce something.
|
|
|
12a1790d
|
2018-09-17T14:49:46
|
|
revwalk: only check the first commit in the list for an earlier timestamp
This is not a big deal, but it does make us match git more closely by checking
only the first. The lists are sorted already, so there should be no functional
difference other than removing a possible check from every iteration in the
loop.
|
|
|
46f35127
|
2018-09-17T14:39:58
|
|
revwalk: use the max value for a signed integer
When porting, we overlooked that the difference between git's and our's time
representation and copied their way of getting the max value.
Unfortunately git was using unsigned integers, so `~0ll` does correspond to
their max value, whereas for us it corresponds to `-1`. This means that we
always consider the last date to be smaller than the current commit's and always
think commits are interesting.
Change the initial value to the macro that gives us the maximum value on each
platform so we can accurately consider commits interesting or not.
|
|
|
44291868
|
2018-09-12T10:53:03
|
|
path validation: `char` is not signed by default.
ARM treats its `char` type as `unsigned type` by default; as a result,
testing a `char` value as being `< 0` is always false. This is a
warning on ARM, which is promoted to an error given our use of
`-Werror`.
Per ISO 9899:199, section "6.2.5 Types":
> The three types char, signed char, and unsigned char are collectively
> called the character types. The implementation shall define char to
> have the same range, representation, and behavior as either signed
> char or unsigned char.
>
...
> Irrespective of the choice made, char is a separate type from the other
> two and is not compatible with either.
|
|
|
fff33a1b
|
2018-09-10T14:59:20
|
|
ci: write test result XML
Add the clar flags to produce JUnit-style XML output before invocation.
|