| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
The trace logging callbacks should match the other callback naming
conventions, using the `_cb` suffix instead of a `_callback` suffix.
|
| |
|
|
|
| |
The credential callbacks should match the other callback naming
conventions, using the `_cb` suffix instead of a `_callback` suffix.
|
| |\
| |
| | |
ignore: handle escaped trailing whitespace
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The stripping of trailing spaces currently happens as part of
`git_attr_fnmatch__parse`. As we aren't currently parsing
trailing whitespaces correct in case they're escaped, we'll have
to change that code, though. To make actual behavioural change
easier to review, refactor the code up-front by pulling it out
into its own function that is expected to retain the exact same
functionality as before. Like this, the fix will be trivial to
apply.
|
| |\ \
| |/
|/| |
Ignore: only treat one leading slash as a root identifier
|
| | |
| |
| |
| |
| |
| |
| | |
For compatibility with git, only skip the first leading slash in an
ignore file. That is: `/a.txt` indicates to ignore a file named `a.txt`
at the root. However `//b.txt` does not indicate that a file named
`b.txt` at the root should be ignored.
|
| | | |
|
| |\ \
| | |
| | | |
online tests: use gitlab for auth failures
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| | |
| | | |
Ignore files: don't ignore whitespace
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | | |
When `allow_space` is unset, ensure that leading whitespace is not
skipped.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Comments must have a '#' at the beginning of the line. For
compatibility with git, '#' after a whitespace is a literal part of the
filename.
|
| |/ /
| |
| |
| |
| |
| | |
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.
|
| |\ \
| | |
| | | |
cache: fix cache eviction using deallocated key
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \
| |/ /
|/| | |
SECURITY.md: split out security-relevant bits from readme
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
GitHub has recently introduced a new set of tools that aims to
ease the process around vulnerability reports and security fixes.
Part of those tools is a new security tab for projects that will
display contents from a new SECURITY.md file.
Move relevant parts from README.md to this new file to make use
of this feature.
|
| |\ \ \
| |/ /
|/| | |
Restore NetBSD support
|
| |/ /
| |
| |
| | |
See: https://www.netbsd.org/changes/changes-7.0.html
|
| |\ \
| | |
| | | |
repository: fix garbage return value
|
| |/ /
| |
| | |
error was never initialized and a garbage value returned on success.
|
| |\ \
| | |
| | | |
cmake: disable fallthrough warnings for PCRE
|
| |/ /
| |
| |
| |
| | |
Our PCRE dependency has uncommented fallthroughs in switch statements.
Turn off warnings for those in the PCRE code.
|
| |\ \
| | |
| | | |
Configuration parsing: validate section headers with quotes
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The `parse_section_header_ext` name suggests that it as an extended
function for parsing the section header. It is not. Rename it to
`parse_subsection_header` to better reflect its true mission.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | | |
When we don't specify a particular column, don't write it in the error
message. (column "0" is unhelpful.)
|
| |/ /
| |
| |
| |
| | |
Update the configuration parsing error messages to be lower-cased for
consistency with the rest of the library.
|
| |\ \
| | |
| | | |
Loosen restriction on wildcard "*" refspecs
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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".
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Use PCRE for our fallback regex engine when regcomp_l is unavailable
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Explicitly enable the `builtin` regex backend and the PCRE backend for
some Linux builds.
|
| | | | |
| | | |
| | | |
| | | | |
This avoids any misunderstanding with the REGEX keyword in cmake.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Use PCRE2 and its POSIX compatibility layer if requested by the user.
Although PCRE2 is adequate for our needs, the PCRE2 POSIX layer as
installed on Debian and Ubuntu systems is broken, so we do not opt-in to
it by default to avoid breaking users on those platforms.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Attempt to locate a system-installed version of PCRE and use its POSIX
compatibility layer, if possible.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Users can now select which regex implementation they want to use: one of
the system `regcomp_l`, the system PCRE, the builtin PCRE or the
system's `regcomp`.
By default the system `regcomp_l` will be used if it exists, otherwise
the system PCRE will be used. If neither of those exist, then the
builtin PCRE implementation will be used.
The system's `regcomp` is not used by default due to problems with
locales.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Move some win32 type definitions to a standalone file so that they can
be included before other header files try to use the definitions.
|
| | | | |
| | | |
| | | |
| | | | |
PCRE includes compatibility functions that may go unused. Don't warn.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The '[[:digit:]]' and '[[:alpha:]]' classes require double brackets, not
single.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The regex functions return nonzero (not necessarily negative values) on
failure.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
While the test asserts that the error value indcates a non-value, it is
actually never getting assigned to. Fix this.
|
