- 10 Jun, 2019 2 commits
-
-
There's no reason a git repository couldn't be at the root of a server, and URLs should have an implicit path of '/' when one is not specified.
Edward Thomson committed -
"Connection data" is an imprecise and largely incorrect name; these structures are actually parsed URLs. Provide a parser that takes a URL string and produces a URL structure (if it is valid). Separate the HTTP redirect handling logic from URL parsing, keeping a `gitno_connection_data_handle_redirect` whose only job is redirect handling logic and does not parse URLs itself.
Edward Thomson committed
-
- 07 Jun, 2019 1 commit
-
-
The function `populate_symlink_workdir` creates a new "symlink.git" repository with a relative path "../symlink.git". As the current working directory is the sandbox, the new repository will be created just outside of the sandbox. Fix this by using `clar_sandbox_path`.
Patrick Steinhardt committed
-
- 06 Jun, 2019 1 commit
-
-
The gitignore's pattern format specifies that "Trailing spaces are ignored unless they are quoted with backslash ("\")". We do not honor this currently and will treat a pattern "foo\ " as if it was "foo\" only and a pattern "foo\ \ " as "foo\ \". Fix our code to handle those special cases and add tests to avoid regressions.
Patrick Steinhardt committed
-
- 05 Jun, 2019 1 commit
-
-
GitHub recently changed their behavior from returning 401s for private or nonexistent repositories on a clone to returning 404s. For our tests that require an auth failure (and 401), move to GitLab to request a missing repository. This lets us continue to test our auth failure case, at least until they decide to mimic that decision.
Edward Thomson committed
-
- 24 May, 2019 4 commits
-
-
Unlike ignore files, gitattribute files can have flexible whitespace at the beginning of the line. Ensure that by adding new ignore rules that we have not impeded correct parsing of attribute files.
Edward Thomson committed -
Comments must have a '#' at the beginning of the line. For compatibility with git, '#' after a whitespace is a literal part of the filename.
Edward Thomson committed -
Ensure that leading whitespace is treated as being part of the filename, eg ` foo` in an ignore file indicates that a file literally named ` foo` is ignored.
Edward Thomson committed -
When evicting cache entries, we first retrieve the object that is to be evicted, delete the object and then finally delete the key from the cache. In case where the cache eviction caused us to free the cached object, though, its key will point to invalid memory now when trying to remove it from the cache map. On my system, this causes us to not properly remove the key from the map, as its memory has been overwritten already and thus the key lookup it will fail and we cannot delete it. Fix this by only decrementing the refcount of the evictee after we have removed it from our cache map. Add a test that caused a segfault previous to that change.
Patrick Steinhardt committed
-
- 22 May, 2019 1 commit
-
-
When we reach a whitespace after a section name, we assume that what will follow will be a quoted subsection name. Pass the current position of the line being parsed to the subsection parser, so that it can validate that subsequent characters are additional whitespace or a single quote. Previously we would begin parsing after the section name, looking for the first quotation mark. This allows invalid characters to embed themselves between the end of the section name and the first quotation mark, eg `[section foo "subsection"]`, which is illegal.
Edward Thomson committed
-
- 21 May, 2019 1 commit
-
-
Since libssh2 doesn't read host configuration from the config file, this callback can be used to hand over URL resolving to the client without touching the SSH implementation itself.
Erik Aigner committed
-
- 19 May, 2019 10 commits
-
-
Ensure that we can read and parse an ignore file with a UTF8 BOM.
Edward Thomson committed -
Edward Thomson committed
-
Edward Thomson committed
-
The '[[:digit:]]' and '[[:alpha:]]' classes require double brackets, not single.
Edward Thomson committed -
The regex functions return nonzero (not necessarily negative values) on failure.
Edward Thomson committed -
In order to avoid us being unable to match characters which are part of the normal US alphabet in certain weird languages, add two tests to catch this behavior.
Patrick Steinhardt committed -
In order to make it easier adding more locale-related tests, add a generalized framework handling initial setup of languages as well as the cleanup of them afterwards.
Patrick Steinhardt committed -
While we already have a test for `p_regexec` with `LC_CTYPE` being modified, `regexec` also alters behavior as soon as `LC_COLLATE` is being modified. Most importantly, `LC_COLLATE` changes the way how ranges are interpreted to just not handling them at all. Thus, ensure that either we use `regcomp_l` to avoid this, or that we've fallen back to our builtin regex functionality which also behaves properly.
Edward Thomson committed -
While the test asserts that the error value indcates a non-value, it is actually never getting assigned to. Fix this.
Patrick Steinhardt committed -
Prefix all the calls to the the regexec family of functions with `p_`. This allows us to swap out all the regular expression functions with our own implementation. Move the declarations to `posix_regex.h` for simpler inclusion.
Edward Thomson committed
-
- 10 May, 2019 1 commit
-
-
This is not implemented and should fail, but it should also not leak. To allow the memory debugger to find leaks and fix this one we test this.
Heiko Voigt committed
-
- 03 May, 2019 1 commit
-
-
If someone passes just one ref (i.e. "master") and misses passing the range we should be nice and return an error code instead of crashing.
Heiko Voigt committed
-
- 30 Apr, 2019 1 commit
-
-
Opening a default config when ~/.gitconfig doesn't exist, locking it, and attempting to write to it causes an assertion failure. Treat non-existent global config file content as an empty string.
Ian Hattendorf committed
-
- 26 Apr, 2019 3 commits
-
-
When we transform a refspec with a component containing a glob, then we simply copy over the component until the next separator from the matching ref. E.g. if we have a ref "refs/heads/foo/bar" and a refspec "refs/heads/*/bar:refs/remotes/origin/*/bar", we: 1. Copy over everything until hitting the glob from the <dst> part: "refs/remotes/origin/". 2. Strip the common prefix of ref and <src> part until the glob, which is "refs/heads/". This leaves us with a ref of "foo/bar". 3. Copy from the ref until the next "/" separator, resulting in "refs/remotes/origin/foo". 4. Copy over the remaining part of the <dst> spec, which is "bar": "refs/remotes/origin/foo/bar". This worked just fine in a world where globs in refspecs were restricted such that a globbing component may only contain a single "*", only. But this restriction has been lifted, so that a glob component may be nested between other characters, causing the above algorithm to fail. Most notably the third step, where we copy until hitting the next "/" separator, might result in a wrong transformation. Given e.g. a ref "refs/gbranchg/head" and a refspec "refs/g*g/head:refs/remotes/origin/*", we'd also be copying the "g" between "branch" and "/" and end up with the wrong transformed ref "refs/remotes/origin/branchg". Instead of copying until the next component separator, we should copy until we hit the pattern after the "*". So in the above example, we'd copy until hitting the string "g/head".
Patrick Steinhardt committed -
In commit cd377f45c9 (refs: loosen restriction on wildcard "*" refspecs, 2015-07-22) in git.git, the restrictions on wildcard "*" refspecs has been loosened. While wildcards were previously only allowed if the component is a single "*", this was changed to also accept other patterns as part of the component. We never adapted to that change and still reject any wildcard patterns that aren't a single "*" only. Update our tests to reflect the upstream change and adjust our own code accordingly.
Patrick Steinhardt committed -
Patrick Steinhardt committed
-
- 21 Apr, 2019 1 commit
-
-
The rebase struct stores fields with information about the current rebase process, which were not accessible via a public interface. Accessors for getting the `orig_head` and `onto` branch names and object ids have been added.
Erik Aigner 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
-
- 06 Apr, 2019 1 commit
-
-
Drew DeVault committed
-
- 05 Apr, 2019 1 commit
-
-
The function `git_ignore_path_is_ignored` is there to test the ignore status of paths that need not necessarily exist inside of a repository. This has the implication that for a given path, we cannot always decide whether it references a directory or a file, and we need to distinguish those cases because ignore rules may treat those differently. E.g. given the following gitignore file: * !/**/ we'd only want to unignore directories, while keeping files ignored. But still, calling `git_ignore_path_is_ignored("dir/")` will say that this directory is ignored because it treats "dir/" as a file path. As said, the `is_ignored` function cannot always decide whether the given path is a file or directory, and thus it may produce wrong results in some cases. While this is unfixable in the general case, we can do better when we are being passed a path name with a trailing path separator (e.g. "dir/") and always treat them as directories.
Patrick Steinhardt committed
-
- 04 Apr, 2019 1 commit
-
-
Edward Thomson committed
-
- 29 Mar, 2019 5 commits
-
-
According to reports, libgit2 is unable to read a global configuration file that is simply a symlink to the real configuration. Write a (succeeding) test that shows that libgit2 _is_ correctly able to do so.
Patrick Steinhardt committed -
While we do verify that we are able to open the global ".gitconfig" file in config::global::open_global, we never verify that we it is in fact readable. Do so by writing the global configuration file and verifying that reading from it produces the expected values.
Patrick Steinhardt committed -
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 -
Add a test that verifies that we are able to parse patches which add a new file that has spaces in its path.
Erik Aigner committed -
The config::global test suite creates various different directories and files which are being populated with pretend-global files. Unfortunately, the tests do not clean up after themselves, which may cause subsequent tests to fail due to cruft left behind. Fix this by always removing created directories and their contents.
Patrick Steinhardt committed
-
- 20 Mar, 2019 1 commit
-
-
Steven King Jr committed
-
- 15 Mar, 2019 1 commit
-
-
Steven King Jr committed
-
- 14 Mar, 2019 1 commit
-
-
Matching on the prefix of a negated pattern was triggering false negatives on siblings of that pattern. e.g. Given the .gitignore: dir/* !dir/sub1/sub2/** The path `dir/a.text` would not be ignored.
Steve King Jr committed
-