summaryrefslogtreecommitdiff
path: root/tests
Commit message (Collapse)AuthorAgeFilesLines
* diff::workdir: actually test the buffersethomson/difftestEdward Thomson2020-05-231-3/+3
| | | | | | The static test data is erroneously initialized with a length of 0 for three of the strings. This means the tests are not actually examining those strings. Provide the length.
* checkout::index: free the indexEdward Thomson2020-05-231-0/+2
|
* tests: checkout: fix stylistic issues and static variablePatrick Steinhardt2020-05-161-19/+13
| | | | | | | | The test case checkout::index::can_disable_pathspec_match has some shortcomings when it comes to coding style, which didn't fit our own coding style. Furthermore, it had an unnecessary static local variable. The test has been refactored to address these issues.
* tests: merge: fix printf formatter on 32 bit archesPatrick Steinhardt2020-05-121-1/+1
| | | | | | | | | We currently use `PRIuMAX` to print an integer of type `size_t` in merge::trees::rename::cache_recomputation. While this works just fine on 64 bit arches, it doesn't on 32 bit ones. As a result, our nightly builds on x86 and arm32 fail. Fix the issue by using `PRIuZ` instead.
* assert: allow non-int returning functions to assertethomson/assert_macrosEdward Thomson2020-05-111-0/+53
| | | | | | | | | | Include GIT_ASSERT_WITH_RETVAL and GIT_ASSERT_ARG_WITH_RETVAL so that functions that do not return int (or more precisely, where `-1` would not be an error code) can assert. This allows functions that return, eg, NULL on an error code to do that by passing the return value (in this example, `NULL`) as a second parameter to the GIT_ASSERT_WITH_RETVAL functions.
* assert: optionally fall-back to assert(3)Edward Thomson2020-05-111-0/+2
| | | | | | | | | Fall back to the system assert(3) in debug builds, which may aide in debugging. "Safe" assertions can be enabled in debug builds by setting GIT_ASSERT_HARD=0. Similarly, hard assertions can be enabled in release builds by setting GIT_ASSERT_HARD to nonzero.
* Introduce GIT_ASSERT macrosEdward Thomson2020-05-111-0/+39
| | | | | | | | | | | | Provide macros to replace usages of `assert`. A true `assert` is punishing as a library. Instead we should do our best to not crash. GIT_ASSERT_ARG(x) will now assert that the given argument complies to some format and sets an error message and returns `-1` if it does not. GIT_ASSERT(x) is for internal usage, and available as an internal consistency check. It will set an error message and return `-1` in the event of failure.
* checkout: Fix removing untracked files by path in subdirectoriesSegev Finer2020-05-111-0/+26
| | | | | | | | The checkout code didn't iterate into a subdir if it didn't match the pathspec, but since the pathspec might match files in the subdir we should recurse into it (In contrast to gitignore handling). Fixes #5089
* tests::checkout: only examine test10 and test11.txtEdward Thomson2020-05-101-2/+2
| | | | | | | The checkout::index::can_disable_pathspec_match test attempts to set a path filter of `test11.txt` and `test12.txt`, but then validates that `test10.txt` and `test11.txt` were left unmodified. Update the test's path filter to match the expectation.
* Create test case demonstrating checkout bug w/ pathspec match disabledFelix Lapalme2020-05-101-0/+59
|
* blame: add option to ignore whitespace changesCarl Schwan2020-04-1426-1/+23
|
* Merge pull request #5480 from libgit2/ethomson/coverityPatrick Steinhardt2020-04-041-2/+2
|\ | | | | repo::open: ensure we can open the repository
| * repo::open: ensure we can open the repositoryethomson/coverityEdward Thomson2020-04-031-2/+2
| | | | | | | | Update the test cases to check the `git_repository_open` return code.
* | Merge pull request #5477 from pks-t/pks/rename-detection-negative-cachesPatrick Steinhardt2020-04-041-0/+77
|\ \ | |/ |/| merge: cache negative cache results for similarity metrics
| * merge: cache negative cache results for similarity metricsPatrick Steinhardt2020-04-011-0/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When computing renames, we cache the hash signatures for each of the potentially conflicting entries so that we do not need to repeatedly read the file and can at least halfway efficiently determine whether two files are similar enough to be deemed a rename. In order to make the hash signatures meaningful, we require at least four lines of data to be present, resulting in at least four different hashes that can be compared. Files that are deemed too small are not cached at all and will thus be repeatedly re-hashed, which is usually not a huge issue. The issue with above heuristic is in case a file does _not_ have at least four lines, where a line is anything separated by a consecutive run of "\n" or "\0" characters. For example "a\nb" is two lines, but "a\0\0b" is also just two lines. Taken to the extreme, a file that has megabytes of consecutive space- or NUL-only may also be deemed as too small and thus not get cached. As a result, we will repeatedly load its blob, calculate its hash signature just to finally throw it away as we notice it's not of any value. When you've got a comparitively big file that you compare against a big set of potentially renamed files, then the cost simply expodes. The issue can be trivially fixed by introducing negative cache entries. Whenever we determine that a given blob does not have a meaningful representation via a hash signature, we store this negative cache marker and will from then on not hash it again, but also ignore it as a potential rename target. This should help the "normal" case already where you have a lot of small files as rename candidates, but in the above scenario it's savings are extraordinarily high. To verify we do not hit the issue anymore with described solution, this commit adds a test that uses the exact same setup described above with one 50 megabyte blob of '\0' characters and 1000 other files that get renamed. Without the negative cache: $ time ./libgit2_clar -smerge::trees::renames::cache_recomputation >/dev/null real 11m48.377s user 11m11.576s sys 0m35.187s And with the negative cache: $ time ./libgit2_clar -smerge::trees::renames::cache_recomputation >/dev/null real 0m1.972s user 0m1.851s sys 0m0.118s So this represents a ~350-fold performance improvement, but it obviously depends on how many files you have and how big the blob is. The test number were chosen in a way that one will immediately notice as soon as the bug resurfaces.
* | Merge pull request #5388 from bk2204/repo-format-v1Patrick Steinhardt2020-04-021-0/+46
|\ \ | | | | | | Handle repository format v1
| * | repository: handle format v1brian m. carlson2020-02-111-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Git has supported repository format version 1 for some time. This format is just like version 0, but it supports extensions. Implementations must reject extensions that they don't support. Add support for this format version and reject any extensions but extensions.noop, which is the only extension we currently support. While we're at it, also clean up an error message.
* | | patch: correctly handle mode changes for renamesPatrick Steinhardt2020-03-262-0/+14
| |/ |/| | | | | | | | | | | | | | | | | | | When generating a patch for a renamed file whose mode bits have changed in addition to the rename, then we currently fail to parse the generated patch. Furthermore, when generating a diff we output mode bits after the similarity metric, which is different to how upstream git handles it. Fix both issues by adding another state transition that allows similarity indices after mode changes and by printing mode changes before the similarity index.
* | Fix segfault when calling git_blame_buffer()lhchavez2020-03-235-1/+31
| | | | | | | | | | | | | | | | This change makes sure that the hunk is not null before trying to dereference it. This avoids segfaults, especially when blaming against a modified buffer (i.e. the index). Fixes: #5443
* | win32: test relative symlinksethomson/canonicalPatrick Steinhardt2020-03-101-0/+20
| | | | | | | | Ensure that we don't canonicalize symlink targets.
* | win32: introduce relative path handling functionEdward Thomson2020-03-101-0/+40
| | | | | | | | | | | | | | Add a function that takes a (possibly) relative UTF-8 path and emits a UTF-16 path with forward slashes translated to backslashes. If the given path is, in fact, absolute, it will be translated to absolute path handling rules.
* | win32: clarify usage of path canonicalization funcsEdward Thomson2020-03-081-10/+0
| | | | | | | | | | | | | | | | | | | | | | The path canonicalization functions on win32 are intended to canonicalize absolute paths; those with prefixes. In other words, things start with drive letters (`C:\`), share names (`\\server\share`), or other prefixes (`\\?\`). This function removes leading `..` that occur after the prefix but before the directory/file portion (eg, turning `C:\..\..\..\foo` into `C:\foo`). This translation is not appropriate for local paths.
* | Merge pull request #5374 from pks-t/pks/diff-with-empty-subtreePatrick Steinhardt2020-02-192-0/+92
|\ \ | | | | | | tests: diff: verify that we are able to diff with empty subtrees
| * | tests: diff: add test to verify behaviour with empty dir orderingPatrick Steinhardt2020-02-071-0/+43
| | | | | | | | | | | | | | | | | | | | | It was reported that, given a file "abc.txt", a diff will be shown if an empty directory "abb/" is created, but not if "abd/" is created. Add a test to verify that we do the right thing here and do not depend on any ordering.
| * | tests: diff: verify that we are able to diff with empty subtreesPatrick Steinhardt2020-02-071-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While it is not allowed for a tree to have an empty tree as child (e.g. an empty directory), libgit2's tree builder makes it easy to create such trees. As a result, some applications may inadvertently end up with such an invalid tree, and we should try our best and handle them. One such case is when diffing two trees, where one of both trees has such an empty subtree. It was reported that this will cause our diff code to fail. While I wasn't able to reproduce this error, let's still add a test that verifies we continue to handle them correctly.
* | | Merge pull request #5391 from pks-t/pks/coverity-fixesPatrick Steinhardt2020-02-199-20/+14
|\ \ \ | | | | | | | | Coverity fixes
| * | | tests: add missing error checksPatrick Steinhardt2020-02-077-17/+11
| | | | | | | | | | | | | | | | | | | | | | | | We should always verify error codes returned by function calls in our test suite to not accidentally miss any weird results. Coverity reported missing checks in several locations, which this commit fixes.
| * | | tests: blame: fix conversion specifiers in format stringPatrick Steinhardt2020-02-072-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While the blame helper function `hunk_message` accepts a printf-style format string, we didn't add a compiler attribute to let the compiler check for correct conversion specifiers. As a result, some users of the function used wrong specifiers. Add the GIT_FORMAT_PRINTF attribute to the function and fix resulting warnings by using the correct specifiers.
* | | | tests: object: decrease number of concurrent cache accessesPatrick Steinhardt2020-02-181-4/+4
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | In our test case object::cache::fast_thread_rush, we're creating 100 concurrent threads opening a repository and reading objects from it. This test actually fails on ARM32 with an out-of-memory error, which isn't entirely unexpected. Work around the issue by halving the number of threads.
* | | tests: iterator: fix iterator expecting too few itemsPatrick Steinhardt2020-02-071-9/+9
| |/ |/| | | | | | | | | | | | | | | | | | | The testcase iterator::workdir::filesystem_gunk sets up quite a lot of directories, which is why it only runs in case GITTEST_INVASIVE_SPEED is set in the environment. Because we do not run our default CI with this variable, we didn't notice commit 852c83ee4 (refs: refuse to delete HEAD, 2020-01-15) breaking the test as it introduced a new reference to the "testrepo" repository. Fix the oversight by increasing the number of expected iterator items.
* | transports: http: fix custom headers not being appliedPatrick Steinhardt2020-02-071-0/+15
|/ | | | | | | | | | | | | | In commit b9c5b15a7 (http: use the new httpclient, 2019-12-22), the HTTP code got refactored to extract a generic HTTP client that operates independently of the Git protocol. Part of refactoring was the creation of a new `git_http_request` struct that encapsulates the generation of requests. Our Git-specific HTTP transport was converted to use that in `generate_request`, but during the process we forgot to set up custom headers for the `git_http_request` and as a result we do not send out these headers anymore. Fix the issue by correctly setting up the request's custom headers and add a test to verify we correctly send them.
* fetchhead: strip credentials from remote URLPatrick Steinhardt2020-01-312-1/+36
| | | | | | | | | | | | | | | | | | | | If fetching from an anonymous remote via its URL, then the URL gets written into the FETCH_HEAD reference. This is mainly done to give valuable context to some commands, like for example git-merge(1), which will put the URL into the generated MERGE_MSG. As a result, what gets written into FETCH_HEAD may become public in some cases. This is especially important considering that URLs may contain credentials, e.g. when cloning 'https://foo:bar@example.com/repo' we persist the complete URL into FETCH_HEAD and put it without any kind of sanitization into the MERGE_MSG. This is obviously bad, as your login data has now just leaked as soon as you do git-push(1). When writing the URL into FETCH_HEAD, upstream git does strip credentials first. Let's do the same by trying to parse the remote URL as a "real" URL, removing any credentials and then re-formatting the URL. In case this fails, e.g. when it's a file path or not a valid URL, we just fall back to using the URL as-is without any sanitization. Add tests to verify our behaviour.
* credential: change git_cred to git_credentialethomson/credtypeEdward Thomson2020-01-263-65/+65
| | | | | | | | | | | | | | | | We avoid abbreviations where possible; rename git_cred to git_credential. In addition, we have standardized on a trailing `_t` for enum types, instead of using "type" in the name. So `git_credtype_t` has become `git_credential_t` and its members have become `GIT_CREDENTIAL` instead of `GIT_CREDTYPE`. Finally, the source and header files have been renamed to `credential` instead of `cred`. Keep previous name and values as deprecated, and include the new header files from the previous ones.
* ci: add NTLM testsEdward Thomson2020-01-241-7/+8
| | | | | | Download poxygit, a debugging git server, and clone from it using NTLM, both IIS-style (with connection affinity) and Apache-style ("broken", requiring constant reauthentication).
* tests: allow users to use expect/continueEdward Thomson2020-01-242-0/+14
|
* tests: support CLAR_TRACE_LEVELEdward Thomson2020-01-241-15/+0
| | | | | | The CLAR_TRACE_LEVEL environment variable was supported when building with GIT_TRACE. Now we always build with GIT_TRACE, but that variable is not provided to tests. Simply support clar tracing always.
* net: introduce git_net_url_joinpathEdward Thomson2020-01-241-0/+194
| | | | | | Provide a mechanism to add a path and query string to an existing url so that we can easily append `/info/refs?...` type url segments to a url given to us by a user.
* net: refactor gitno redirect handlingEdward Thomson2020-01-241-10/+10
| | | | Move the redirect handling into `git_net_url` for consistency.
* tests: test that clone returns 4321Edward Thomson2020-01-241-2/+2
| | | | | This conditional was backwards. We should instead test that clone returns 4321, not that 4321 returns clone.
* ci: perform SPNEGO testsEdward Thomson2020-01-241-6/+7
| | | | | Attempt to obtain a Kerberos ticket from LIBGIT2.ORG and then clone the Negotiate-protected site at test.libgit2.org with that ticket.
* merge: update enum type name for consistencyEdward Thomson2020-01-181-1/+1
| | | | | libgit2 does not use `type_t` suffixes as it's redundant; thus, rename `git_merge_diff_type_t` to `git_merge_diff_t` for consistency.
* Merge pull request #5361 from csware/no-return-freed_objectPatrick Steinhardt2020-01-171-0/+2
|\ | | | | Do not return free'd git_repository object on error
| * Do not return free'd git_repository object on errorSven Strickroth2020-01-161-0/+2
| | | | | | | | | | | | | | | | Regression introduced in commit dde6d9c706bf1ecab545da55ab874a016587af1f. This issue causes lots of crashes in TortoiseGit. Signed-off-by: Sven Strickroth <email@cs-ware.de>
* | refs: refuse to delete HEADJosh Bleecher Snyder2020-01-155-10/+23
|/ | | | | | | This requires adding a new symbolic ref to the testrepo fixture. Some of the existing tests attempt to delete HEAD, expecting a different failure. Introduce and use a non-HEAD symbolic ref instead. Adjust a few other tests as needed. Fixes #5357
* win32: fix relative symlinks pointing into dirsPatrick Steinhardt2020-01-101-0/+27
| | | | | | | | | | | | | | | | | | On Windows platforms, we need some logic to emulate symlink(3P) defined by POSIX. As unprivileged symlinks on Windows are a rather new feature, our current implementation is comparatively new and still has some rough edges in special cases. One such case is relative symlinks. While relative symlinks to files in the same directory work as expected, libgit2 currently fails to create reltaive symlinks pointing into other directories. This is due to the fact that we forgot to translate the Unix-style target path to Windows-style. Most importantly, we are currently not converting directory separators from "/" to "\". Fix the issue by calling `git_win32_path_canonicalize` on the target. Add a test that verifies our ability to create such relative links across directories.
* netops: handle intact query parameters in service_suffix removalJosh Bleecher Snyder2020-01-091-0/+16
| | | | | | | | | | | | | Some servers leave the query parameters intact in the Location header when responding with a redirect. The service_suffix removal check as written assumed that the server removed them. Handle both cases. Along with PR #5325, this fixes #5321. There are two new tests. The first already passed; the second previously failed.
* tests: pack: add missing asserts around `git_packbuilder_write`Patrick Steinhardt2020-01-091-5/+5
|
* tests: submodule: verify setup of relative URLsPatrick Steinhardt2020-01-061-0/+21
| | | | | | | When setting up relative URLs for a submodule, then we resolve it to the actual location and write that into ".git/config" instead of writing the relative value. We do not yet have a test to nail down this behaviour, which is now being added by this commit.
* Merge pull request #5300 from tiennou/fix/branch-documentationPatrick Steinhardt2019-12-131-0/+44
|\ | | | | branch: clarify documentation around branches
| * refs: rename git_reference__set_name to git_reference__reallocEtienne Samson2019-12-131-0/+44
| | | | | | | | | | | | | | | | | | | | | | As git_reference__name will reallocate storage to account for longer names (it's actually allocator-dependent), it will cause all existing pointers to the old object to become dangling, as they now point to freed memory. Fix the issue by renaming to a more descriptive name, and pass a pointer to the actual reference that can safely be invalidated if the realloc succeeds.
View Lorry Controller Status