- 10 Sep, 2019 1 commit
-
-
Laurence McGlashan committed
-
- 20 Jul, 2019 2 commits
-
-
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.
Patrick Steinhardt committed -
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.
Patrick Steinhardt committed
-
- 19 Jul, 2019 4 commits
-
-
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.
Patrick Steinhardt committed -
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.
Patrick Steinhardt committed -
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.
Patrick Steinhardt committed -
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.
Patrick Steinhardt committed
-
- 18 Jul, 2019 1 commit
-
-
`cvar` is an unhelpful name. Refactor its usage to `configmap` for more clarity.
Patrick Steinhardt committed
-
- 11 Jul, 2019 1 commit
-
-
In commit 45f24e78 (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.
Patrick Steinhardt committed
-
- 17 Apr, 2019 1 commit
-
-
Stop traversing the filesystem at the Windows directory root. We were calculating the filesystem root for the given directory to create, and walking up the filesystem hierarchy. We intended to stop when the traversal path length is equal to the root path length (ie, stopping at the root, since no path may be shorter than the root path). However, on Windows, the root path may be specified in two different ways, as either `Z:` or `Z:\`, where `Z:` is the current drive letter. `git_path_dirname_r` returns the path _without_ a trailing slash, even for the Windows root. As a result, during traversal, we need to test that the traversal path is _less than or equal to_ the root path length to determine if we've hit the root to ensure that we stop when our traversal path is `Z:` and our calculated root path was `Z:\`.
Edward Thomson committed
-
- 29 Mar, 2019 1 commit
-
-
We've got reports that users are unable to open repos when their global configuration ("~/.gitconfig") is a symlink. Add a test to verify that we are in fact able to do so as expected.
Patrick Steinhardt committed
-
- 22 Jan, 2019 1 commit
-
-
Move to the `git_error` name in the internal API for error-related functions.
Edward Thomson committed
-
- 17 Jan, 2019 1 commit
-
-
Update internal usage to use the `git_reference` names for constants.
Edward Thomson committed
-
- 01 Dec, 2018 1 commit
-
-
Use the new object_type enumeration names within the codebase.
Edward Thomson committed
-
- 20 Oct, 2018 4 commits
-
-
Test updated symbolic link creation on Windows. Ensure that we emulate Git for Windows behavior. Ensure that when `core.symlinks=true` is set in a global configuration that new repositories are created without a `core.symlinks` setting, and that when `core.symlinks` is unset that `core.symlinks=false` in set in the repository. Further ensure that checkout honors the expected `core.symlinks` defaults on Windows.
Edward Thomson committed -
Provide a function that allows tests to set up a bespoke global configuration path.
Edward Thomson committed -
Edward Thomson committed
-
Ensure that `core.symlinks` is set correctly. By default, it is unset, but it is explicitly set to `false` if the platform was detected to not support symlinks during repository initialization.
Edward Thomson committed
-
- 13 Jul, 2018 1 commit
-
-
C++ style comment ("//") are not specified by the ISO C90 standard and thus do not conform to it. While libgit2 aims to conform to C90, we did not enforce it until now, which is why quite a lot of these non-conforming comments have snuck into our codebase. Do a tree-wide conversion of all C++ style comments to the supported C style comments to allow us enforcing strict C90 compliance in a later commit.
Patrick Steinhardt committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 03 Jan, 2018 1 commit
-
-
Some function bodies of tests which are not applicable to the Win32 platform are completely #ifdef'd out instead of calling `cl_skip()`. This leaves us with no indication that these tests are not being executed at all and may thus cause decreased scrutiny when investigating skipped tests. Improve the situation by calling `cl_skip()` instead of just doing nothing.
Patrick Steinhardt committed
-
- 14 Nov, 2017 1 commit
-
-
Etienne Samson committed
-
- 12 Nov, 2017 1 commit
-
-
Christine Poerschke committed
-
- 17 Jun, 2017 1 commit
-
-
Ariel Davis committed
-
- 03 May, 2017 1 commit
-
-
Debian and Ubuntu often use schroot to build their DEB packages in a controlled environment. Depending on how schroot is configured, our tests regarding repository discovery break due to not being able to find the repositories anymore. It turns out that these errors occur when the schroot is configured to use an overlayfs on the directory structures. The reason for this failure is that we usually refrain from discovering repositories across devices. But unfortunately, overlayfs does not have consistent device identifiers for all its files but will instead use the device number of the filesystem the file stems from. So whenever we cross boundaries between the upper and lower layer of the overlay, we will fail to properly detect the repository and bail out. This commit fixes the issue by enabling cross-device discovery in our tests. While it would be preferable to have this turned off, it probably won't do much harm anyway as we set up our tests in a temporary location outside of the parent repository.
Patrick Steinhardt committed
-
- 02 Apr, 2017 1 commit
-
-
When `git_repository_set_head` is provided a remote reference, update the reflog with the tag name, like we do with a branch. This helps consumers match the semantics of `git checkout remote`.
Edward Thomson committed
-
- 21 Mar, 2017 1 commit
-
-
When `git_repository_set_head` is provided a tag reference, update the reflog with the tag name, like we do with a branch. This helps consumers match the semantics of `git checkout tag`.
Edward Thomson committed
-
- 17 Feb, 2017 2 commits
-
-
Edward Thomson committed
-
Provide more detailed messages when conditions pass or fail unexpectedly. In particular, this provides the error messages when a test fails with a different error code than was expected.
Edward Thomson committed
-
- 08 Feb, 2017 1 commit
-
-
As of recently, we failed to correctly discover repositories at a Win32 system root. Instead of aborting the upwards-traversal of the file system, we were looping infinitely when traversal started at either a Win32 drive prefix ("C:/") or a network path ("//somehost"). The issue has been fixed, so add a test to catch regressions.
Patrick Steinhardt committed
-
- 14 Nov, 2016 5 commits
-
-
When trying to find a discovery, we walk up the directory structure checking if there is a ".git" file or directory and, if so, check its validity. But in the case that we've got a ".git" file, we do not want to unconditionally assume that the file is in fact a ".git" file and treat it as such, as we would error out if it is not. Fix the issue by only treating a file as a gitlink file if it ends with "/.git". This allows users of the function to discover a repository by handing in any path contained inside of a git repository.
Patrick Steinhardt committed -
Patrick Steinhardt committed
-
Patrick Steinhardt committed
-
Patrick Steinhardt committed
-
Patrick Steinhardt committed
-
- 24 Jul, 2016 1 commit
-
-
Edward Thomson committed
-
- 24 Jun, 2016 3 commits
-
-
git_repository_open_ext provides parameters for the start path, whether to search across filesystems, and what ceiling directories to stop at. git commands have standard environment variables and defaults for each of those, as well as various other parameters of the repository. To avoid duplicate environment variable handling in users of libgit2, add a GIT_REPOSITORY_OPEN_FROM_ENV flag, which makes git_repository_open_ext automatically handle the appropriate environment variables. Commands that intend to act just like those built into git itself can use this flag to get the expected default behavior. git_repository_open_ext with the GIT_REPOSITORY_OPEN_FROM_ENV flag respects $GIT_DIR, $GIT_DISCOVERY_ACROSS_FILESYSTEM, $GIT_CEILING_DIRECTORIES, $GIT_INDEX_FILE, $GIT_NAMESPACE, $GIT_OBJECT_DIRECTORY, and $GIT_ALTERNATE_OBJECT_DIRECTORIES. In the future, when libgit2 gets worktree support, git_repository_open_env will also respect $GIT_WORK_TREE and $GIT_COMMON_DIR; until then, git_repository_open_ext with this flag will error out if either $GIT_WORK_TREE or $GIT_COMMON_DIR is set.
Josh Triplett committed -
GIT_REPOSITORY_OPEN_NO_SEARCH does not search up through parent directories, but still tries the specified path both directly and with /.git appended. GIT_REPOSITORY_OPEN_BARE avoids appending /.git, but opens the repository in bare mode even if it has a working directory. To support the semantics git uses when given $GIT_DIR in the environment, provide a new GIT_REPOSITORY_OPEN_NO_DOTGIT flag to not try appending /.git.
Josh Triplett committed -
git only checks ceiling directories when its search ascends to a parent directory. A ceiling directory matching the starting directory will not prevent git from finding a repository in the starting directory or a parent directory. libgit2 handled the former case correctly, but differed from git in the latter case: given a ceiling directory matching the starting directory, but no repository at the starting directory, libgit2 would stop the search at that point rather than finding a repository in a parent directory. Test case using git command-line tools: /tmp$ git init x Initialized empty Git repository in /tmp/x/.git/ /tmp$ cd x/ /tmp/x$ mkdir subdir /tmp/x$ cd subdir/ /tmp/x/subdir$ GIT_CEILING_DIRECTORIES=/tmp/x git rev-parse --git-dir fatal: Not a git repository (or any of the parent directories): .git /tmp/x/subdir$ GIT_CEILING_DIRECTORIES=/tmp/x/subdir git rev-parse --git-dir /tmp/x/.git Fix the testsuite to test this case (in one case fixing a test that depended on the current behavior), and then fix find_repo to handle this case correctly. In the process, simplify and document the logic in find_repo(): - Separate the concepts of "currently checking a .git directory" and "number of iterations left before going further counts as a search" into two separate variables, in_dot_git and min_iterations. - Move the logic to handle in_dot_git and append /.git to the top of the loop. - Only search ceiling_dirs and find ceiling_offset after running out of min_iterations; since ceiling_offset only tracks the longest matching ceiling directory, if ceiling_dirs contained both the current directory and a parent directory, this change makes find_repo stop the search at the parent directory.
Josh Triplett committed
-
- 24 Mar, 2016 1 commit
-
-
Iterator tests were split over repo::iterator and diff::iterator, with duplication between the two. Move them to iterator::index, iterator::tree, and iterator::workdir.
Edward Thomson committed
-