- 20 Jun, 2022 1 commit
-
-
`git_oid`s now have a type, and we require the oid type when creating the object id from creation functions.
Edward Thomson committed
-
- 23 Feb, 2022 1 commit
-
-
Edward Thomson committed
-
- 09 Nov, 2021 1 commit
-
-
Introduce `git_fs_path`, which operates on generic filesystem paths. `git_path` will be kept for only git-specific path functionality (for example, checking for `.git` in a path).
Edward Thomson committed
-
- 17 Oct, 2021 1 commit
-
-
libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
Edward Thomson committed
-
- 26 Sep, 2021 2 commits
-
-
The `repo` argument is now unnecessary. Remove it.
Edward Thomson committed -
When looking up attributes for a file, we construct an absolute path to the queried file within the working directory so that we can accept both absolute paths and working directory relative paths. We then trim the leading working directory path to give us an in-repo path. Since we only want the in-repo path to look up attributes - and not to read it from disk - we don't need to validate its length.
Edward Thomson committed
-
- 21 Sep, 2021 1 commit
-
-
Using a `git_oid *` in filter options was a mistake; it is a deviation from our typical pattern, and callers in some languages that GC may need very special treatment in order to pass both an options structure and a pointer outside of it.
Edward Thomson committed
-
- 22 Jul, 2021 5 commits
-
-
Introduce `GIT_ATTR_CHECK_INCLUDE_COMMIT`, which like 4fd5748c allows attribute information to be read from files in the repository. 4fd5748c always reads the information from HEAD, while `GIT_ATTR_CHECK_INCLUDE_COMMIT` allows users to provide the commit to read the attributes from.
Edward Thomson committed -
When looking up an attribute file in a commit, we can cache a nonexistent attribute file indefinitely (since a commit could not somehow later contain an attribute file). Cache an empty buffer when an attribute file does not exist in a given commit.
Edward Thomson committed -
The attribute source object is now the type and the path.
Edward Thomson committed -
We may want to extend the attribute source; use a structure instead of an enum.
Edward Thomson committed -
The enum `git_attr_file_source` is better suffixed with a `_t` since it's a type-of source. Similarly, its members should have a matching name.
Edward Thomson committed
-
- 11 May, 2021 2 commits
-
-
Instead of a `git_bom_t` that a `git_buf` function returns, let's keep it `git_buf_bom_t`.
Edward Thomson committed -
The `git_buf_text` namespace is unnecessary and strange. Remove it, just keep the functions prefixed with `git_buf`.
Edward Thomson committed
-
- 28 Apr, 2021 1 commit
-
-
We should allow attribute files - inside working directories - to have names longer than MAX_PATH when core.longpaths is set. `git_attr_path__init` takes a repository to validate the path with.
Edward Thomson committed
-
- 06 Dec, 2020 1 commit
-
-
Clarify the `git_atomic` type and functions now that we have a 64 bit version as well (`git_atomic64`).
Edward Thomson committed
-
- 25 Nov, 2020 1 commit
-
-
Edward Thomson committed
-
- 01 Jun, 2020 1 commit
-
-
Propagate failures caused by pool initialization errors.
Edward Thomson committed
-
- 22 Nov, 2019 1 commit
-
-
Instead of using a signed type (`off_t`) use a new `git_object_size_t` for the sizes of objects.
Edward Thomson committed
-
- 11 Aug, 2019 1 commit
-
-
When `GIT_ATTR_CHECK_INCLUDE_HEAD` is specified, read `gitattribute` files that are checked into the repository at the HEAD revision.
Edward Thomson committed
-
- 12 Jul, 2019 3 commits
-
-
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.
Patrick Steinhardt committed -
The gitattributes code is one of our oldest and most-untouched codebases in libgit2, and as such its code style doesn't quite match our current best practices. Refactor the function `git_attr_file__parse_buffer` to better match them.
Patrick Steinhardt committed -
The gitattributes code is one of our oldest and most-untouched codebases in libgit2, and as such its code style doesn't quite match our current best practices. Refactor the function `git_attr_file__lookup_standalone` to better match them.
Patrick Steinhardt committed
-
- 04 Jul, 2019 1 commit
-
-
The function `git_attr_session__init` is currently only initializing setting up the attribute's session key by incrementing the repo-global key by one. Most notably, all other members of the `git_attr_session` struct are not getting initialized at all. So if one is to allocate a session on the stack and then calls `git_attr_session__init`, the session will still not be fully initialized. We have fared just fine with that until now as all users of the function have allocated the session structure as part of bigger structs with `calloc`, and thus its contents have been zero-initialized implicitly already. Fix this by explicitly zeroing out the session to enable allocation of sessions on the stack.
Patrick Steinhardt committed
-
- 15 Jun, 2019 2 commits
-
-
Upstream git has converted to use `wildmatch` instead of `fnmatch`. Convert our gitattributes logic to use `wildmatch` as the last user of `fnmatch`. Please, don't expect I know what I'm doing here: the fnmatch parser is one of the most fun things to play around with as it has a sh*tload of weird cases. In all honesty, I'm simply relying on our tests that are by now rather comprehensive in that area. The conversion actually fixes compatibility with how git.git parser "**" patterns when the given path does not contain any directory separators. Previously, a pattern "**.foo" erroneously wouldn't match a file "x.foo", while git.git would match. Remove the new-unused LEADINGDIR/NOLEADINGDIR flags for `git_attr_fnmatch`.
Patrick Steinhardt committed -
We're about to phase out our bundled fnmatch implementation as git.git has moved to wildmatch long ago in 2014. To make it easier to spot which files are stilll using fnmatch, remove the implicit "fnmatch.h" include in "posix.h" and instead include it explicitly.
Patrick Steinhardt committed
-
- 13 Jun, 2019 4 commits
-
-
In our attributes pattern parsing code, we have a comment that states we might have to convert '\' characters to '/' to have proper POSIX paths. But in fact, '\' characters are valid inside the string and act as escape mechanism for various characters, which is why we never want to convert those to POSIX directory separators. Furthermore, gitignore patterns are specified to only treat '/' as directory separators. Remove the comment to avoid future confusion.
Patrick Steinhardt committed -
When determining the trailing space length, we need to honor whether spaces are escaped or not. Currently, we do not check whether the escape itself is escaped, though, which might generate an off-by-one in that case as we will simply treat the space as escaped. Fix this by checking whether the backslashes preceding the space are themselves escaped.
Patrick Steinhardt committed -
When parsing attribute patterns, we will eventually unescape the parsed pattern. This is required because we require custom escapes for whitespace characters, as normally they are used to terminate the current pattern. Thing is, we don't only unescape those whitespace characters, but in fact all escaped sequences. So for example if the pattern was "\*", we unescape that to "*". As this is directly passed to fnmatch(3) later, fnmatch would treat it as a simple glob matching all files where it should instead only match a file with name "*". Fix the issue by unescaping spaces, only. Add a bunch of tests to exercise escape parsing.
Patrick Steinhardt committed -
When parsing attributes, we need to search for the first unescaped whitespace character to determine where the pattern is to be cut off. The scan fails to account for the case where the escaping '\' character is itself escaped, though, and thus we would not recognize the cut-off point in patterns like "\\ ". Refactor the scanning loop to remember whether the last character was an escape character. If it was and the next character is a '\', too, then we will reset to non-escaped mode again. Thus, we now handle escaped whitespaces as well as escaped wildcards correctly.
Patrick Steinhardt committed
-
- 06 Jun, 2019 2 commits
-
-
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 -
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.
Patrick Steinhardt committed
-
- 24 May, 2019 1 commit
-
-
When `allow_space` is unset, ensure that leading whitespace is not skipped.
Edward Thomson committed
-
- 19 May, 2019 2 commits
-
-
Edward Thomson committed
-
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.
Edward Thomson 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
-
- 25 Jan, 2019 1 commit
-
-
Our blob size is a `git_off_t`, which is a signed 64 bit int. This may be erroneously negative or larger than `SIZE_MAX`. Ensure that the blob size fits into a `size_t` before casting.
Edward Thomson committed
-
- 22 Jan, 2019 1 commit
-
-
Move to the `git_error` name in the internal API for error-related functions.
Edward Thomson committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 06 Jun, 2018 1 commit
-
-
When computing whether a file is ignored, we simply search for the first matching rule and return whether it is a positive ignore rule (the file is really ignored) or whether it is a negative ignore rule (the file is being unignored). Each rule has a set of flags which are being passed to `fnmatch`, depending on what kind of rule it is. E.g. in case it is a negative ignore we add a flag `GIT_ATTR_FNMATCH_NEGATIVE`, in case it contains a glob we set the `GIT_ATTR_FNMATCH_HASGLOB` flag. One of these flags is the `GIT_ATTR_FNMATCH_LEADINGDIR` flag, which is always set in case the pattern has a trailing "/*" or in case the pattern is negative. The flag causes the `fnmatch` function to return a match in case a string is a leading directory of another, e.g. "dir/" matches "dir/foo/bar.c". In case of negative patterns, this is wrong in certain cases. Take the following simple example of a gitignore: dir/ !dir/ The `LEADINGDIR` flag causes "!dir/" to match "dir/foo/bar.c", and we correctly unignore the directory. But take this example: *.test !dir/* We expect everything in "dir/" to be unignored, but e.g. a file in a subdirectory of dir should be ignored, as the "*" does not cross directory hierarchies. With `LEADINGDIR`, though, we would just see that "dir/" matches and return that the file is unignored, even if it is contained in a subdirectory. Instead, we want to ignore leading directories here and check "*.test". Afterwards, we have to iterate up to the parent directory and do the same checks. To fix the issue, disallow matching against leading directories in gitignore files. This can be trivially done by just adding the `GIT_ATTR_FNMATCH_NOLEADINGDIR` to the spec passed to `git_attr_fnmatch__parse`. Due to a bug in that function, though, this flag is being ignored for negative patterns, which is fixed in this commit, as well. As a last fix, we need to ignore rules that are supposed to match a directory when our path itself is a file. All together, these changes fix the described error case.
Patrick Steinhardt committed
-