|
de7659cc
|
2019-11-10T18:44:56
|
|
patch_parse: use paths from "---"/"+++" lines for binary patches
For some patches, it is not possible to derive the old and new file
paths from the patch header's first line, most importantly when they
contain spaces. In such a case, we derive both paths from the "---" and
"+++" lines, which allow for non-ambiguous parsing. We fail to use these
paths when parsing binary patches without data, though, as we always
expect the header paths to be filled in.
Fix this by using the "---"/"+++" paths by default and only fall back to
header paths if they aren't set. If neither of those paths are set, we
just return an error. Add two tests to verify this behaviour, one of
which would have previously caused a segfault.
|
|
01ea911b
|
2019-11-06T06:04:55
|
|
Merge pull request #5299 from pks-t/pks/config-mem-snapshots
config_mem: implement support for snapshots
|
|
|
146e5bf7
|
2019-11-06T07:27:35
|
|
config_mem: implement support for snapshots
Similar as in commit dadbb33b6 (Fix crash if snapshotting a
config_snapshot, 2019-11-01), let's implement snapshots for in-memory
configuration entries. As this deletes more code than it adds, it
doesn't make any sense to not allow for this and allows users to treat
config backends mostly the same.
|
|
|
de543e29
|
2019-11-05T22:44:27
|
|
patch_parse: fix segfault when header path contains whitespace only
When parsing header paths from a patch, we reject any patches with empty
paths as malformed patches. We perform the check whether a path is empty
before sanitizing it, though, which may lead to a path becoming empty
after the check, e.g. if we have trimmed whitespace. This may lead to a
segfault later when any part of our patching logic actually references
such a path, which may then be a `NULL` pointer.
Fix the issue by performing the check after sanitizing. Add tests to
catch the issue as they would have produced a segfault previosuly.
|
|
|
82d7a114
|
2019-11-05T11:18:14
|
|
Merge pull request #5293 from csware/config_snapshot-snapshot
Fix crash if snapshotting a config_snapshot
|
|
|
bf2911d7
|
2019-11-02T07:30:32
|
|
Merge pull request #5275 from pks-t/pks/reflogs-with-newlines
reflogs: fix behaviour around reflogs with newlines
|
|
dadbb33b
|
2019-11-01T18:55:54
|
|
Fix crash if snapshotting a config_snapshot
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
|
0974e02f
|
2019-10-30T20:35:48
|
|
commit: add failing tests for object checking for git_commit_with_signature
There can be a significant difference between the system where we created the
buffer (if at all) and when the caller provides us with the contents of a
commit.
Provide some test cases (we have to adapt the existing ones because they refer
to trees and commits which do not exist).
|
|
|
2a7d6de3
|
2019-10-29T07:52:31
|
|
Merge pull request #5276 from pks-t/pks/patch-fuzzing-fixes
patch_parse: fixes for fuzzing errors
|
|
|
a31f4c4b
|
2019-10-24T13:16:03
|
|
Merge pull request #5227 from ddevault/check
apply: add GIT_APPLY_CHECK
|
|
|
c405f231
|
2019-10-24T10:26:43
|
|
Merge pull request #5264 from henkesn/refs-unlock-on-commit
refs: unlock unmodified refs on transaction commit
|
|
02af1fcb
|
2019-09-14T14:03:36
|
|
apply: add GIT_APPLY_CHECK
This adds an option which will check if a diff is applicable without
actually applying it; equivalent to git apply --check.
|
|
|
37141ff7
|
2019-10-21T18:56:59
|
|
patch_parse: detect overflow when calculating old/new line position
When the patch contains lines close to INT_MAX, then it may happen that
we end up with an integer overflow when calculating the line of the
current diff hunk. Reject such patches as unreasonable to avoid the
integer overflow.
As the calculation is performed on integers, we introduce two new
helpers `git__add_int_overflow` and `git__sub_int_overflow` that perform
the integer overflow check in a generic way.
|
|
|
468e3ddc
|
2019-10-19T16:48:11
|
|
patch_parse: fix out-of-bounds read with No-NL lines
We've got two locations where we copy lines into the patch. The first
one is when copying normal " ", "-" or "+" lines, while the second
location gets executed when we copy "\ No newline at end of file" lines.
While the first one correctly uses `git__strndup` to copy only until the
newline, the other one doesn't. Thus, if the line occurs at the end of
the patch and if there is no terminating NUL character, then it may
result in an out-of-bounds read.
Fix the issue by using `git__strndup`, as was already done in the other
location. Furthermore, add allocation checks to both locations to detect
out-of-memory situations.
|
|
|
6c6c15e9
|
2019-10-19T15:52:35
|
|
patch_parse: reject empty path names
When parsing patch headers, we currently accept empty path names just
fine, e.g. a line "--- \n" would be parsed as the empty filename. This
is not a valid patch format and may cause `NULL` pointer accesses at a
later place as `git_buf_detach` will return `NULL` in that case.
Reject such patches as malformed with a nice error message.
|
|
|
223e7e43
|
2019-10-19T15:42:54
|
|
patch_parse: reject patches with multiple old/new paths
It's currently possible to have patches with multiple old path name
headers. As we didn't check for this case, this resulted in a memory
leak when overwriting the old old path with the new old path because we
simply discarded the old pointer.
Instead of fixing this by free'ing the old pointer, we should reject
such patches altogether. It doesn't make any sense for the "---" or
"+++" markers to occur multiple times within a patch n the first place.
This also implicitly fixes the memory leak.
|
|
|
7968e90f
|
2019-10-18T12:33:07
|
|
refdb_fs: properly parse corrupted reflogs
In previous versions, libgit2 could be coerced into writing reflog
messages with embedded newlines into the reflog by using
`git_stash_save` with a message containing newlines. While the root
cause is fixed now, it was noticed that upstream git is in fact able to
read such corrupted reflog messages just fine.
Make the reflog parser more lenient in order to just skip over
malformatted reflog lines to bring us in line with git. This requires us
to change an existing test that verified that we do indeed _fail_ to
parse such logs.
|
|
|
d8233feb
|
2019-10-18T09:24:14
|
|
reflog: allow adding entries with newlines in their message
Currently, the reflog disallows any entries that have a message with
newlines, as that would effectively break the reflog format, which may
contain a single line per entry, only. Upstream git behaves a bit
differently, though, especially when considering stashes: instead of
rejecting any reflog entry with newlines, git will simply replace
newlines with spaces. E.g. executing 'git stash push -m "foo\nbar"' will
create a reflog entry with "foo bar" as entry message.
This commit adjusts our own logic to stop rejecting commit messages with
newlines. Previously, this logic was part of `git_reflog_append`, only.
There is a second place though where we add reflog entries, which is the
serialization code in the filesystem refdb. As it didn't contain any
sanity checks whatsoever, the refdb would have been perfectly happy to
write malformatted reflog entries to the disk. This is being fixed with
the same logic as for the reflog itself.
|
|
|
c9464bf7
|
2019-10-17T18:33:12
|
|
Merge pull request #5273 from dlax/parse-diff-without-extended-headers
patch_parse: handle patches without extended headers
|
|
|
73e9535d
|
2019-10-17T13:43:26
|
|
tests: submodule: test cloning edge cases
Add two more tests that verify our behaviour in some edge cases, notably
when cloning into a non-empty directory and when cloning the same
submodule twice.
|
|
|
de412fc2
|
2019-10-17T13:36:22
|
|
tests: submodule: make use of sandboxes to clean repos
The test submodule::add::submodule_clone doesn't use a sandbox, and thus
the created repo will not get deleted after the test has finished.
Convert the test to use the empty standard repo sandbox instead to fix
this.
|
|
|
09b1ac11
|
2019-10-17T13:32:22
|
|
tests: submodule: fix tests for cloning submodules
The test submodule::add::homemade_clone unfortunately doesn't test
what's expected, but does instead clone the submodule to a directory
that is outside of the parent repository. Fixing this by cloning to the
correct location isn't possible, though, as `git_submodule_add_setup`
will have pre-created a ".git" file already, which will cause
`git_clone` to error out.
As it's not possible to perform the clone without fiddling around with
the repo's layout, let's just remove this test as that is in fact what
the new `git_submodule_clone` function is for.
|
|
47531f47
|
2019-10-11T12:44:09
|
|
refs: unlock unmodified refs on transaction commit
Refs which are locked in a transaction without an altered target,
still should to be unlocked on `git_transaction_commit`.
`git_transaction_free` also unlocks refs but the moment of calling of `git_transaction_free`
cannot be controlled in all situations.
Some binding libs call `git_transaction_free` on garbage collection or not at all if the
application exits before and don't provide public access to `git_transaction_free`.
It is better to release locks as soon as possible.
|
|
3c5d78bd
|
2019-05-01T16:16:26
|
|
submodule: provide a wrapper for simple submodule clone steps
|
|
11de594f
|
2019-10-16T22:11:33
|
|
patch_parse: handle patches without extended headers
Extended header lines (especially the "index <hash>..<hash> <mode>") are
not required by "git apply" so it import patches. So we allow the
from-file/to-file lines (--- a/file\n+++ b/file) to directly follow the
git diff header.
This fixes #5267.
|
|
|
ef5a3851
|
2019-10-11T07:47:17
|
|
Merge pull request #5257 from henkesn/master
Fix file locking on POSIX OS
|
|
|
1f9b4970
|
2019-10-11T07:44:10
|
|
Merge pull request #5260 from pks-t/pks/cmake3
cmake: update minimum CMake version to v3.5.1
|
|
|
3335a034
|
2019-10-10T15:28:46
|
|
refs: fix locks getting forcibly removed
The flag GIT_FILEBUF_FORCE currently does two things:
1. It will cause the filebuf to create non-existing leading
directories for the file that is about to be written.
2. It will forcibly remove any pre-existing locks.
While most call sites actually do want (1), they do not want to
remove pre-existing locks, as that renders the locking mechanisms
effectively useless.
Introduce a new flag `GIT_FILEBUF_CREATE_LEADING_DIRS` to
separate both behaviours cleanly from each other and convert
callers to use it instead of `GIT_FILEBUF_FORCE` to have them
honor locked files correctly.
As this conversion removes all current users of `GIT_FILEBUF_FORCE`,
this commit removes the flag altogether.
|
|
|
6716e2f3
|
2019-10-10T12:34:45
|
|
Merge pull request #5248 from dlax/parse-patch-empty-files
patch_parse: handle patches with new empty files
|
|
|
ebabb88f
|
2019-10-10T09:25:32
|
|
cmake: update minimum CMake version to v3.5.1
Back in commit cf9f34521 (cmake: bump minimum version to 2.8.11,
2017-09-06), we have bumped the minimum CMake version to require at
least v2.8.11. The main hold-backs back then were distributions like
RHEL/CentOS as well as Ubuntu Trusty, which caused us to not target a
more modern version. Nowadays, Ubuntu Trusty has been EOL'd and CentOS 6
has CMake v3.6.1 available via the EPEL6 repository, and thus it seems
fair to upgrade to a more recent version.
Going through repology [1], one can see that all supported mainstream
distributions do in fact have CMake 3 available. Going through the list,
the minimum version that is supported by all mainstream distros is in
fact v3.5.1:
- CentOS 6 via EPEL6: 3.6.1
- Debian Oldstable: 3.7.2
- Fedora 26: 3.8.2
- OpenMandriva 3.x: 3.5.1
- Slackware 14.2: 3.5.2
- Ubuntu 16.04: 3.5.1
Consequentally, let's upgrade CMake to the minimum version of 3.5.1 and
remove all the version CMake checks that aren't required anymore.
[1]: https://repology.org/project/cmake/versions
|
|
|
63307cba
|
2019-09-28T17:32:18
|
|
Merge pull request #5226 from pks-t/pks/regexp-api
regexp: implement a new regular expression API
|
|
|
b61810bf
|
2019-09-28T15:52:25
|
|
patch_parse: handle patches with new empty files
Patches containing additions of empty files will not contain diff data
but will end with the index header line followed by the terminating
sequence "-- ". We follow the same logic as in cc4c44a and allow "-- "
to immediately follow the index header.
|
|
|
f585b129
|
2019-09-12T14:29:28
|
|
posix: remove superseded POSIX regex wrappers
The old POSIX regex wrappers have been superseded by our own regexp API
that provides a higher-level abstraction. Remove the POSIX wrappers in
favor of the new one.
|
|
|
d77378eb
|
2019-09-13T08:54:26
|
|
regexp: implement new regular expression API
We currently support a set of different regular expression backends with
PCRE, PCRE2, regcomp(3P) and regcomp_l(3). The current implementation of
this is done via a simple POSIX wrapper that either directly uses
supplied functions or that is a very small wrapper.
To support PCRE and PCRE2, we use their provided <pcreposix.h> and
<pcre2posix.h> wrappers. These wrappers are implemented in such a way
that the accompanying libraries pcre-posix and pcre2-posix provide the
same symbols as the libc ones, namely regcomp(3P) et al. This works out
on some systems just fine, most importantly on glibc-based ones, where
the regular expression functions are implemented as weak aliases and
thus get overridden by linking in the pcre{,2}-posix library. On other
systems we depend on the linking order of libc and pcre library, and as
libc always comes first we will end up with the functions of the libc
implementation. As a result, we may use the structures `regex_t` and
`regmatch_t` declared by <pcre{,2}posix.h>, but use functions defined by
the libc, leading to segfaults.
The issue is not easily solvable. Somed distributions like Debian have
resolved this by patching PCRE and PCRE2 to carry custom prefixes to all
the POSIX function wrappers. But this is not supported by upstream and
thus inherently unportable between distributions. We could instead try
to modify linking order, but this starts becoming fragile and will not
work e.g. when libgit2 is loaded via dlopen(3P) or similar ways. In the
end, this means that we simply cannot use the POSIX wrappers provided by
the PCRE libraries at all.
Thus, this commit introduces a new regular expression API. The new API
is on a tad higher level than the previous POSIX abstraction layer, as
it tries to abstract away any non-portable flags like e.g. REG_EXTENDED,
which has no equivalents in all of our supported backends. As there are
no users of POSIX regular expressions that do _not_ reguest REG_EXTENDED
this is fine to be abstracted away, though. Due to the API being
higher-level than before, it should generally be a tad easier to use
than the previous one.
Note: ideally, the new API would've been called `git_regex_foobar` with
a file "regex.h" and "regex.c". Unfortunately, this is currently
impossible to implement due to naming clashes between the then-existing
"regex.h" and <regex.h> provided by the libc. As we add the source
directory of libgit2 to the header search path, an include of <regex.h>
would always find our own "regex.h". Thus, we have to take the bitter
pill of adding one more character to all the functions to disambiguate
the includes.
To improve guarantees around cross-backend compatibility, this commit
also brings along an improved regular expression test suite
core::regexp.
|
|
|
174b7a32
|
2019-09-19T12:24:06
|
|
buffer: fix printing into out-of-memory buffer
Before printing into a `git_buf` structure, we always call `ENSURE_SIZE`
first. This macro will reallocate the buffer as-needed depending on
whether the current amount of allocated bytes is sufficient or not. If
`asize` is big enough, then it will just do nothing, otherwise it will
call out to `git_buf_try_grow`. But in fact, it is insufficient to only
check `asize`.
When we fail to allocate any more bytes e.g. via `git_buf_try_grow`,
then we set the buffer's pointer to `git_buf__oom`. Note that we touch
neither `asize` nor `size`. So if we just check `asize > targetsize`,
then we will happily let the caller of `ENSURE_SIZE` proceed with an
out-of-memory buffer. As a result, we will print all bytes into the
out-of-memory buffer instead, resulting in an out-of-bounds write.
Fix the issue by having `ENSURE_SIZE` verify that the buffer is not
marked as OOM. Add a test to verify that we're not writing into the OOM
buffer.
|
|
|
208f1d7a
|
2019-09-19T12:46:37
|
|
buffer: fix infinite loop when growing buffers
When growing buffers, we repeatedly multiply the currently allocated
number of bytes by 1.5 until it exceeds the requested number of bytes.
This has two major problems:
1. If the current number of bytes is tiny and one wishes to resize
to a comparatively huge number of bytes, then we may need to loop
thousands of times.
2. If resizing to a value close to `SIZE_MAX` (which would fail
anyway), then we probably hit an infinite loop as multiplying the
current amount of bytes will repeatedly result in integer
overflows.
When reallocating buffers, one typically chooses values close to 1.5 to
enable re-use of resulting memory holes in later reallocations. But
because of this, it really only makes sense to use a factor of 1.5
_once_, but not looping until we finally are able to fit it. Thus, we
can completely avoid the loop and just opt for the much simpler
algorithm of multiplying with 1.5 once and, if the result doesn't fit,
just use the target size. This avoids both problems of looping
extensively and hitting overflows.
This commit also adds a test that would've previously resulted in an
infinite loop.
|
|
|
8bf0f7eb
|
2019-09-09T13:00:27
|
|
cred: separate public interface from low-level details
|
|
|
5d8a4659
|
2019-09-13T10:31:49
|
|
Merge pull request #5195 from tiennou/fix/commitish-smart-push
smart: use push_glob instead of manual filtering
|
|
b545be3d
|
2019-09-10T11:14:36
|
|
open:fix memory leak when passing NULL to git_repository_open_ext
|
|
|
c3a7892f
|
2019-09-09T13:10:24
|
|
Merge pull request #5209 from mkostyuk/apply-wrong-patch
apply: Fix a patch corruption related to EOFNL handling
|
|
|
17d6cd45
|
2019-09-09T13:06:22
|
|
Merge pull request #5210 from buddyspike/master
ignore: correct handling of nested rules overriding wild card unignore
|
|
585fbd74
|
2019-08-28T23:18:31
|
|
apply: Test for EOFNL mishandling when several hunks are processed
Introduce an unit test to validate that git_apply__patch() properly
handles EOFNL changes in case of patches with several hunks.
|
|
a7b4b639
|
2019-08-24T12:14:31
|
|
ignore: correct handling of nested rules overriding wild card unignore
problem:
filesystem_iterator loads .gitignore files in top-down order.
subsequently, ignore module evaluates them in the order they are loaded.
this creates a problem if we have unignored a rule (using a wild card)
in a sub dir and ignored it again in a level further below (see the test
included in this patch).
solution:
process ignores in reverse order.
closes #4963
|
|
|
5fc27aac
|
2019-08-27T13:38:08
|
|
Merge pull request #5208 from mkostyuk/apply-removed-new-file
apply: git_apply_to_tree fails to apply patches that add new files
|
|
|
5498c318
|
2019-08-27T13:10:53
|
|
apply: free test data
|
|
|
6de48085
|
2019-08-27T11:29:24
|
|
Merge pull request #5189 from libgit2/ethomson/attrs_from_head
Optionally read `.gitattributes` from HEAD
|
|
|
aaa48d06
|
2019-08-27T11:26:50
|
|
Merge pull request #5196 from pks-t/pks/config-include-onbranch
config: implement "onbranch" conditional
|
|
|
8cbef12d
|
2019-08-08T11:52:54
|
|
util: do not perform allocations in insertsort
Our hand-rolled fallback sorting function `git__insertsort_r` does an
in-place sort of the given array. As elements may not necessarily be
pointers, it needs a way of swapping two values of arbitrary size, which
is currently implemented by allocating a temporary buffer of the
element's size. This is problematic, though, as the emulated `qsort`
interface doesn't provide any return values and thus cannot signal an
error if allocation of that temporary buffer has failed.
Convert the function to swap via a temporary buffer allocated on the
stack. Like this, it can `memcpy` contents of both elements in small
batches without requiring a heap allocation. The buffer size has been
chosen such that in most cases, a single iteration of copying will
suffice. Most importantly, it can fully contain `git_oid` structures and
pointers.
Add a bunch of tests for the `git__qsort_r` interface to verify nothing
breaks. Furthermore, this removes the declaration of `git__insertsort_r`
and makes it static as it is not used anywhere else.
|
|
|
dceedbb8
|
2019-08-21T15:03:50
|
|
apply: Test for git_apply_to_tree failures when new files are added
Introduce an unit test to validate if git_apply_to_tree() fails when an
applied patch adds new files.
|
|
|
39d18fe6
|
2019-07-31T08:37:10
|
|
smart: use push_glob instead of manual filtering
The code worked under the assumption that anything under `refs/tags` are
tag objects, and all the rest would be peelable to a commit. As it is
completely valid to have tags to blobs under a non `refs/tags` ref, this
would cause failures when trying to peel a tag to a commit.
Fix the broken filtering by switching to `git_revwalk_push_glob`, which
already handles this case.
|
|
071750a3
|
2019-08-15T14:18:26
|
|
cmake: move _WIN32_WINNT definitions to root
|
|
|
0f40e68e
|
2019-08-14T09:05:07
|
|
Merge pull request #5187 from ianhattendorf/fix/clone-whitespace
clone: don't decode URL percent encodings
|
|
62b80138
|
2019-08-13T09:10:10
|
|
clone: Remove whitespace ssh test
Will add later when infrastructure is configured
|
|
|
b15e7f2d
|
2019-08-12T09:56:51
|
|
clone: Update whitespace test url
|
|
|
cdbbb364
|
2019-07-21T16:25:41
|
|
filter: test second-level in-repo `.gitattributes`
Ensure that a `.gitattributes` file that is deeper in the tree is
honored, not just an attributes file at the root.
|
|
|
ff25ec83
|
2019-07-21T16:25:11
|
|
tests: add a subdirectory to crlf tests
Add a subdirectory in the crlf.git bare repository that has a
second-level .gitattribute file.
|
|
|
3661e35e
|
2019-06-23T23:52:24
|
|
filter: test we can filter a blob in a bare repo
|
|
|
e7fc8601
|
2019-07-21T11:53:29
|
|
filter: test that system attributes can be ignored
Test that we can optionally ignore system attributes when filtering a
blob.
|
|
|
c66f7605
|
2019-07-21T11:44:11
|
|
filter: ensure system attributes are read
By default, `/etc/gitattributes` (or the system equivalent) is read to
provide attributes. Ensure that, by default, this is read when
filtering blobs.
|
|
|
a008ceea
|
2019-07-21T11:01:36
|
|
blob: convert users of git_blob_filtered_content
Move users of `git_blob_filtered_content` to `git_blob_filter`.
|
|
|
b0692d6b
|
2019-08-09T09:01:56
|
|
Merge pull request #4913 from implausible/feature/signing-rebase-commits
Add sign capability to git_rebase_commit
|
|
|
722ba93f
|
2019-08-01T15:14:06
|
|
config: implement "onbranch" conditional
With Git v2.23.0, the conditional include mechanism gained another new
conditional "onbranch". As the name says, it will cause a file to be
included if the "onbranch" pattern matches the currently checked out
branch.
Implement this new condition and add a bunch of tests.
|
|
|
e208b195
|
2019-08-01T13:42:19
|
|
tests: config: catch OOM when assembling conditional config
When assembling contents of the conditionally including file, we use
`git_buf_printf` and `git_buf_puts` without checking for error returns.
Add `cl_git_pass` to fix this.
|
|
|
835211dc
|
2019-08-01T13:23:16
|
|
tests: config: assert behaviour around includes
Add a few tests that verify some behaviour centered around includes. The
first set of tests verifies that we correctly override values depending
on the order of includes and other keys, the second set asserts that we
can correctly snapshot configuration files with includes.
|
|
|
304e58c0
|
2019-08-01T13:20:17
|
|
tests: config::snapshot: modernize tests
Modernize the tests in config::snapshot to make them easier to
understand. Most important, include a cleanup function that frees config
and snapshot and unlink config files at the end of each test.
|
|
|
75cc755f
|
2019-07-29T18:05:35
|
|
cmake: fix _WIN32_WINNT for MinGW
|
|
|
42ea2f95
|
2019-07-25T13:15:10
|
|
clone: whitespace in url ssh test
|
|
|
1748f92c
|
2019-07-24T16:36:45
|
|
clone: whitespace in url test
|
|
fdd10839
|
2019-06-30T00:41:10
|
|
Implement test for graph ahead and behind
|
|
|
c0290e27
|
2019-06-23T23:52:52
|
|
filter: add a crlf blob test
Add a LF->CRLF conversion test to the blob filter.
|
|
a213fec6
|
2019-07-21T15:12:40
|
|
tests: remote: add test suite to test listing remotes
There was a bug when calling `git_remote_list` that caused us to not
re-read modified configurations when using `git_config_iterator`. This
bug also impacted `git_remote_list`, which thus failed to provide an
up-to-date list of remotes. Add a test suite remote::list with a single
test that verifies we do the right thing.
|
|
|
2766b92d
|
2019-07-21T15:10:34
|
|
config_file: refresh when creating an iterator
When creating a new iterator for a config file backend, then we should
always make sure that we're up to date by calling `config_refresh`.
Otherwise, we might not notice when another process has modified the
configuration file and thus will represent outdated values.
Add two tests to config::stress that verify that we get up-to-date
values when reading configuration entries via `git_config_iterator`.
|
|
|
82b1d1da
|
2019-07-21T12:25:10
|
|
Merge pull request #5141 from pks-t/pks/azure-drop-powershell
azure: drop powershell
|
|
|
50194dcd
|
2019-07-11T15:14:42
|
|
win32: fix symlinks to relative file targets
When creating a symlink in Windows, one needs to tell Windows whether
the symlink should be a file or directory symlink. To determine which
flag to pass, we call `GetFileAttributesW` on the target file to see
whether it is a directory and then pass the flag accordingly. The
problem though is if create a symlink with a relative target path, then
we will check that relative path while not necessarily being inside of
the working directory where the symlink is to be created. Thus, getting
its attributes will either fail or return attributes of the wrong
target.
Fix this by resolving the target path relative to the directory in which
the symlink is to be created.
|
|
|
93d37a1d
|
2019-06-29T09:59:36
|
|
tests: core: improve symlink test coverage
Add two more tests to verify that we're not deleting symlink targets,
but the symlinks themselves. Furthermore, convert several `cl_skip`s on
Win32 to conditional skips depending on whether the clar sandbox
supports symlinks or not. Windows is grown up now and may allow
unprivileged symlinks if the machine has been configured accordingly.
|
|
|
683ea2b0
|
2019-06-29T09:10:57
|
|
tests: core: add missing asserts for several function calls
Several function calls to `p_stat` and `p_close` have no verification if
they actually succeeded. As these functions _may_ fail and as we also
want to make sure that we're not doing anything dumb, let's check them,
too.
|
|
|
ded77bb1
|
2019-06-29T09:58:34
|
|
path: extract function to check whether a path supports symlinks
When initializing a repository, we need to check whether its working
directory supports symlinks to correctly set the initial value of the
"core.symlinks" config variable. The code to check the filesystem is
reusable in other parts of our codebase, like for example in our tests
to determine whether certain tests can be expected to succeed or not.
Extract the code into a new function `git_path_supports_symlinks` to
avoid duplicate implementations. Remove a duplicate implementation in
the repo test helper code.
|
|
|
e54343a4
|
2019-06-29T09:17:32
|
|
fileops: rename to "futils.h" to match function signatures
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.
|
|
|
d827b11b
|
2019-06-28T13:20:54
|
|
tests: execute leak checker via CTest directly
Right now, we have an awful hack in our test CI setup that extracts the
test command from CTest's output and then prepends the leak checker.
This is dependent on non-machine-parseable output from CMake and also
breaks on various ocassions, like for example when we have spaces in the
current path or when the path contains backslashes. Both conditions may
easily be triggered on Win32 systems, and in fact they do break our
Azure Pipelines builds.
Remove the awful hack in favour of a new CMake build option
"USE_LEAK_CHECKER". If specifying e.g. "-DUSE_LEAK_CHECKER=valgrind",
then we will set up all tests to be run under valgrind. Like this, we
can again simply execute ctest without needing to rely on evil sourcery.
|
|
|
fe3b5da3
|
2019-07-19T12:43:55
|
|
clar: provide ability to set summary file via environment
As different test suites for our CI are mostly defined via CMake, it's
hard to run those tests with a summary file path as that'd require us to
add another parameter to all unit tests. As we do not want to
unconditionally run unit tests with a summary file, we would have to add
another CMake build parameter for test execution, which is ugly.
Instead, implement a way to provide a summary file path via the
environment.
|
|
|
e07dbc92
|
2019-07-20T11:26:00
|
|
Merge pull request #5173 from pks-t/pks/gitignore-wildmatch-error
ignore: fix determining whether a shorter pattern negates another
|
|
|
fd7a384b
|
2019-07-20T11:24:37
|
|
Merge pull request #5159 from pks-t/pks/patch-parse-old-missing-nl
patch_parse: handle missing newline indicator in old file
|
|
|
f33ca472
|
2019-07-20T11:06:23
|
|
Merge pull request #5158 from pks-t/pks/patch-parsed-lifetime
patch_parse: do not depend on parsed buffer's lifetime
|
|
|
964c1c60
|
2019-07-20T11:02:30
|
|
Merge pull request #5176 from pks-t/pks/repo-template-head
repository: do not initialize HEAD if it's provided by templates
|
|
|
9d46f167
|
2019-07-19T10:50:51
|
|
repository: do not initialize HEAD if it's provided by templates
When using templates to initialize a git repository, then git-init(1)
will copy over all contents of the template directory. These will be
preferred over the default ones created by git-init(1). While we mostly
do the same, there is the exception of "HEAD". While we do copy over the
template's HEAD file, afterwards we'll immediately re-initialize its
contents with either the default "ref: refs/origin/master" or the init
option's `initial_head` field.
Let's fix the inconsistency with upstream git-init(1) by not overwriting
the template HEAD, but only if the user hasn't set `opts.initial_head`.
If the `initial_head` field has been supplied, we should use that
indifferent from whether the template contained a HEAD file or not. Add
tests to verify we correctly use the template directory's HEAD file and
that `initial_head` overrides the template.
|
|
|
0d12b8dd
|
2019-07-19T09:43:34
|
|
tests: repo: refactor setup of templates and repos
All tests in repo::template have a common pattern of first setting up
templates, then settung up the repository that makes use of those
templates via several init options. Refactor this pattern into two
functions `setup_templates` and `setup_repo` that handle most of that
logic to make it easier to spot what a test actually wants to check.
Furthermore, this also refactors how we clean up after the tests.
Previously, it was a combination of manually calling
`cl_fixture_cleanup` and `cl_set_cleanup`, which really is kind of hard
to read. This commit refactors this to instead provide the cleaning
parameters in the setup functions. All cleanups are then performed in
the suite's cleanup function.
|
|
|
3b79ceaf
|
2019-07-19T08:58:12
|
|
tests: repo: refactor template path handling
The repo::template test suite makes use of quite a few local variables
that could be consolidated. Do so to make the code easier to read.
|
|
|
ee193480
|
2019-07-19T08:45:45
|
|
tests: repo: move template tests into their own suite
There's quite a lot of supporting code for our templates and they are an
obvious standalone feature. Thus, let's extract those tests into their
own suite to also make refactoring of them easier.
|
|
|
3424c210
|
2019-07-19T08:00:13
|
|
Merge pull request #5138 from libgit2/ethomson/cvar
configuration: cvar -> configmap
|
|
|
92109976
|
2019-07-18T14:20:18
|
|
tests: fix undercounting of suites
With the introduction of data variants for suites, we started
undercounting the number of suites as we didn't account for those that
were executed twice. This was then adjusted to count the number of
initializers instead, but this fails to account for suites without any
initializers at all.
Fix the suite count by counting either the number of initializers or, if
there is no initializer, count it as a single suite, only.
|
|
|
658022c4
|
2019-07-18T13:53:41
|
|
configuration: cvar -> configmap
`cvar` is an unhelpful name. Refactor its usage to `configmap` for more
clarity.
|
|
|
343fb83a
|
2019-07-18T13:50:47
|
|
Merge pull request #5156 from pks-t/pks/attr-macros-in-subdir
gitattributes: ignore macros defined in subdirectories
|
|
|
6f6340af
|
2019-07-18T11:57:55
|
|
ignore: fix determining whether a shorter pattern negates another
When computing whether we need to store a negative pattern, we iterate
through all previously known patterns and check whether the negative
pattern undoes any of the previous ones. In doing so we call `wildmatch`
and check it's return for any negative error values. If there was a
negative return, we will abort and bubble up that error to the caller.
In fact, this check for negative values stems from the time where we
still used `fnmatch` instead of `wildmatch`. For `fnmatch`, negative
values indicate a "real" error, while for `wildmatch` a negative value
may be returned if the matching was prematurely aborted. A premature
abort may for example also happen if the pattern matches a prefix of the
haystack if the pattern is shorter. Returning an error in that case is
the wrong thing to do.
Fix the code to compare for equality with `WM_MATCH`, only. Negative
values returned by `wildmatch` are perfectly fine and thus should be
ignored. Add a test that verifies we do not see the error.
|
|
|
4cd8dfaa
|
2019-07-16T20:20:55
|
|
clar: correctly account for "data" suites when counting
Failing to do that makes clar miss the last of the suites, as all
duplicated "data" would have not been accounted for.
|
|
|
f8346905
|
2019-07-12T09:03:33
|
|
attr_file: ignore macros defined in subdirectories
Right now, we are unconditionally applying all macros found in a
gitatttributes file. But quoting gitattributes(5):
Custom macro attributes can be defined only in top-level
gitattributes files ($GIT_DIR/info/attributes, the .gitattributes
file at the top level of the working tree, or the global or
system-wide gitattributes files), not in .gitattributes files in
working tree subdirectories. The built-in macro attribute "binary"
is equivalent to:
So gitattribute files in subdirectories of the working tree may
explicitly _not_ contain macro definitions, but we do not currently
enforce this limitation.
This patch introduces a new parameter to the gitattributes parser that
tells whether macros are allowed in the current file or not. If set to
`false`, we will still parse macros, but silently ignore them instead of
adding them to the list of defined macros. Update all callers to
correctly determine whether the to-be-parsed file may contain macros or
not. Most importantly, when walking up the directory hierarchy, we will
only set it to `true` once it reaches the root directory of the repo
itself.
Add a test that verifies that we are indeed not applying macros from
subdirectories. Previous to these changes, the test would've failed.
|
|
|
df417a43
|
2019-07-12T09:02:16
|
|
tests: attr: verify that in-memory macros are respected
Add some tests to ensure that the `git_attr_add_macro` function works as
expected.
|
|
|
4a7f704f
|
2019-07-05T08:10:33
|
|
tests: attr: implement tests to verify attribute rewriting behaviour
Implement some tests that verify that we are correctly updating
gitattributes when rewriting or unlinking the corresponding files.
|
|
|
ed854aa0
|
2019-07-05T07:45:22
|
|
tests: attr: extract macro tests into their own suite
As macros are a specific functionality in the gitattributes code, it
makes sense to extract them into their own test suite, too. This makes
finding macro-related tests easier.
|
|
|
5ae22a63
|
2019-06-21T08:13:31
|
|
fileops: fix creation of directory in filesystem root
In commit 45f24e787 (git_repository_init: stop traversing at
windows root, 2019-04-12), we have fixed `git_futils_mkdir` to
correctly handle the case where we create a directory in
Windows-style filesystem roots like "C:\repo".
The problem here is an off-by-one: previously, to that commit,
we've been checking wether the parent directory's length is equal
to the root directory's length incremented by one. When we call
the function with "/example", then the parent directory's length
("/") is 1, but the root directory offset is 0 as the path is
directly rooted without a drive prefix. This resulted in `1 == 0 +
1`, which was true. With the change, we've stopped incrementing
the root directory length, and thus now compare `1 <= 0`, which
is false.
The previous way of doing it was kind of finicky any non-obvious,
which is also why the error was introduced. So instead of just
re-adding the increment, let's explicitly add a condition that
aborts finding the parent if the current parent path is "/".
Making this change causes Azure Pipelines to fail the testcase
repo::init::nonexistent_paths on Unix-based systems. This is because we
have just fixed creating directories in the filesystem root, which
previously didn't work. As Docker-based tests are running as root user,
we are thus able to create the non-existing path and will now succeed to
create the repository that was expected to actually fail.
Let's split this up into three different tests:
- A test to verify that we do not create repos in a non-existing parent
directoy if the flag `GIT_REPOSITORY_INIT_MKPATH` is not set.
- A test to verify that we fail if the root directory does not exist. As
there is a common root directory on Unix-based systems that always
exist, we can only test for this on Windows-based systems.
- A test to verify that we fail if trying to create a repository in an
unwriteable parent directory. We can only test this if not running
tests as root user, as CAP_DAC_OVERRIDE will cause us to ignore
permissions when creating files.
|
|
b0893282
|
2019-07-11T12:12:04
|
|
patch_parse: ensure valid patch output with EOFNL
|