- 22 Jul, 2021 3 commits
-
-
Allow more advanced attribute queries using a `git_attr_options`, and extended functions to use it. Presently there is no additional configuration in a `git_attr_options` beyond the flags, but this is for future growth.
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
-
- 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
-
- 12 Dec, 2019 1 commit
-
-
Laurence McGlashan committed
-
- 20 Jul, 2019 1 commit
-
-
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
-
- 12 Jul, 2019 4 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 -
Add some tests to ensure that the `git_attr_add_macro` function works as expected.
Patrick Steinhardt committed -
Implement some tests that verify that we are correctly updating gitattributes when rewriting or unlinking the corresponding files.
Patrick Steinhardt committed -
As macros are a specific functionality in the gitattributes code, it makes sense to extract them into their own test suite, too. This makes finding macro-related tests easier.
Patrick Steinhardt committed
-
- 04 Jul, 2019 1 commit
-
-
There were no tests that verified that system-level gitattributes files get handled correctly. In fact, we have recently introduced a regression that caused us to abort if there was a system-level gitattributes file available. Add two tests that verify that we're able to handle system-level gitattributes files. The test attr::repo::sysdir_with_session would've failed without the fix to the described regression.
Patrick Steinhardt committed
-
- 16 Jun, 2019 1 commit
-
-
Our enumeration values are not generally suffixed with `T`. Further, our enumeration names are generally more descriptive.
Edward Thomson committed
-
- 07 Jun, 2019 1 commit
-
-
We had several occasions where tests for the gitignore had been added to status::ignore instead of the easier-to-handle attr::ignore test suite. This most likely resulted from the fact that the attr::ignore test suite is not easy to discover inside of the attr folder. Furthermore, ignore being part of the attributes code is an implementation detail, only, and thus shouldn't be stressed as much. Improve this by moving both attr::ignore and status::ignore tests into a new ignore test suite.
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
-
- 24 May, 2019 1 commit
-
-
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
-
- 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
-
- 20 Mar, 2019 1 commit
-
-
Steven King Jr committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 12 Apr, 2018 1 commit
-
-
When comparing whether a path matches a directory rule, we pass the both the path and directory name to `fnmatch` with `GIT_ATTR_FNMATCH_DIRECTORY` being set. `fnmatch` expects the pattern to contain no trailing directory '/', which is why we try to always strip patterns of trailing slashes. We do not handle that case correctly though when the pattern itself has trailing spaces, causing the match to fail. Fix the issue by stripping trailing spaces and tabs for a rule previous to checking whether the pattern is a directory pattern with a trailing '/'. This replaces the whitespace-stripping in our ignore file parsing code, which was stripping whitespaces too late. Add a test to catch future breakage.
Patrick Steinhardt committed
-
- 29 Oct, 2017 1 commit
-
-
David Turner committed
-
- 25 Aug, 2017 2 commits
-
-
When computing negative ignores, we throw away any rule which does not undo a previous rule to optimize. But on case insensitive file systems, we need to keep in mind that a negative ignore can also undo a previous rule with different case, which we did not yet honor while determining whether a rule undoes a previous one. So in the following example, we fail to unignore the "/Case" directory: /case !/Case Make both paths checking whether a plain- or wildcard-based rule undo a previous rule aware of case-insensitivity. This fixes the described issue.
Patrick Steinhardt committed -
Ignore rules allow for reverting a previously ignored rule by prefixing it with an exclamation mark. As such, a negative rule can only override previously ignored files. While computing all ignore patterns, we try to use this fact to optimize away some negative rules which do not override any previous patterns, as they won't change the outcome anyway. In some cases, though, this optimization causes us to get the actual ignores wrong for some files. This may happen whenever the pattern contains a wildcard, as we are unable to reason about whether a pattern overrides a previous pattern in a sane way. This happens for example in the case where a gitignore file contains "*.c" and "!src/*.c", where we wouldn't un-ignore files inside of the "src/" subdirectory. In this case, the first solution coming to mind may be to just strip the "src/" prefix and simply compare the basenames. While that would work here, it would stop working as soon as the basename pattern itself is different, like for example with "*x.c" and "!src/*.c. As such, we settle for the easier fix of just not optimizing away rules that contain a wildcard.
Patrick Steinhardt committed
-
- 17 May, 2017 1 commit
-
-
Robert Gay 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
-
- 19 Apr, 2016 1 commit
-
-
In order to match the star-star, we disable the flag that's looking for a single path element, but that leads to searching for the pattern in the middle of elements in the input string. Mark when we're handing a star-star so we jump over the elements in our attempt to match the part of the pattern that comes after the star-star. While here, tighten up the check so we don't allow invalid rules through.
Carlos Martín Nieto committed
-
- 18 Apr, 2016 1 commit
-
-
Antonio Scandurra committed
-
- 02 Apr, 2016 1 commit
-
-
If we're looking for a symlink, realpath will give us the resolved path, which is not what we're after, but a canonicalized version of the path the user asked for.
Carlos Martín Nieto committed
-
- 13 May, 2015 1 commit
-
-
Edward Thomson committed
-
- 12 May, 2015 3 commits
-
-
Edward Thomson committed
-
When a .gitignore specifies some folder "foo/", ensure that a file with the same name "foo" is not ignored.
Edward Thomson committed -
Ensure that when examining a .gitignore in a subdirectory, we do not erroneously apply the paths contained therein to the root of the repository. (Fixed in c02a0e46).
Edward Thomson committed
-
- 28 Apr, 2015 1 commit
-
-
Minimizing the number directory and file opens, minimizes the amount of IO thus reducing the overall cost of performing ignore operations.
J Wyman committed
-
- 23 Apr, 2015 1 commit
-
-
Mike McQuaid committed
-
- 17 Sep, 2014 1 commit
-
-
The rugged tests are fragile committed
-
- 16 Sep, 2014 1 commit
-
-
When using a bare repo with an index, libgit2 attempts to read files from the index. It caches those files based on the path to the file, specifically the path to the directory that contains the file. If there is no working directory, we use `git_path_dirname_r` to get the path to the containing directory. However, for the `.gitattributes` file in the root of the repository, this ends up normalizing the containing path to `"."` instead of the empty string and the lookup the `.gitattributes` data fails. This adds a test of attribute lookups on bare repos and also fixes the problem by simply rewriting `"."` to be `""`.
Russell Belfer committed
-
- 02 May, 2014 2 commits
-
-
Trying to find other issues where tests may not clean up quite properly when they are through...
Russell Belfer committed -
There are a few tests that set up a fake home directory and a fake GLOBAL search path so that we can test things in global ignore or attribute or config files. This cleans up that code to work more robustly even if there is a test failure. This also fixes some valgrind warnings where scanning search paths for separators could end up doing a little bit of sketchy data access when coming to the end of search list.
Russell Belfer committed
-
- 01 May, 2014 1 commit
-
-
This allows "foo/**/*.html" to match "foo/file.html"
Russell Belfer committed
-
- 18 Apr, 2014 1 commit
-
-
There was a latent bug where files that use macro definitions could be parsed before the macro definitions were loaded. Because of attribute file caching, preloading files that are going to be used doesn't add a significant amount of overhead, so let's always preload any files that could contain macros before we assemble the actual vector of files to scan for attributes.
Russell Belfer committed
-