kmx git

Commit	Date	Message
18e71e6d	2018-11-28T13:31:06	index: use new enum and structure names Use the new-style index names throughout our own codebase.
3be73011	2018-06-11T18:26:22	Merge pull request #4436 from pks-t/pks/packfile-stream-free pack: rename `git_packfile_stream_free`
ecf4f33a	2018-02-08T11:14:48	Convert usage of `git_buf_free` to new `git_buf_dispose`
20b4c175	2018-06-05T16:12:58	ignore: fix negative leading directory rules unignoring subdirectory files 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.
9beb73ed	2018-06-05T16:45:23	tests: status::ignore: fix style of a test
38b44c3b	2017-07-07T17:10:57	tests: status: additional test for negative ignores with pattern This test is by Carlos Martín Nieto.
c3b8e8b3	2017-05-14T10:28:05	Fix issue with directory glob ignore in subdirectories
c52480fd	2017-02-17T13:01:49	`cl_git_exec` -> `cl_git_expect`
a1dcc830	2017-02-17T12:13:35	tests: provide better pass/failure error messages 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.
fcb2c1c8	2016-08-12T09:06:15	ignore: allow unignoring basenames in subdirectories The .gitignore file allows for patterns which unignore previous ignore patterns. When unignoring a previous pattern, there are basically three cases how this is matched when no globbing is used: 1. when a previous file has been ignored, it can be unignored by using its exact name, e.g. foo/bar !foo/bar 2. when a file in a subdirectory has been ignored, it can be unignored by using its basename, e.g. foo/bar !bar 3. when all files with a basename are ignored, a specific file can be unignored again by specifying its path in a subdirectory, e.g. bar !foo/bar The first problem in libgit2 is that we did not correctly treat the second case. While we verified that the negative pattern matches the tail of the positive one, we did not verify if it only matches the basename of the positive pattern. So e.g. we would have also negated a pattern like foo/fruz_bar !bar Furthermore, we did not check for the third case, where a basename is being unignored in a certain subdirectory again. Both issues are fixed with this commit.
ac2fba0e	2015-09-16T15:07:27	git_futils_mkdir_*: make a relative-to-base mkdir Untangle git_futils_mkdir from git_futils_mkdir_ext - the latter assumes that we own everything beneath the base, as if it were being called with a base of the repository or working directory, and is tailored towards checkout and ensuring that there is no bogosity beneath the base that must be cleaned up. This is (at best) slow and (at worst) unsafe in the larger context of a filesystem where we do not own things and cannot do things like unlink symlinks that are in our way.
657afd35	2015-09-13T06:18:49	ignore: add test and adjust style and comment for dir with wildmatch The previous commit left the comment referencing the earlier state of the code, change it to explain the current logic. While here, change the logic to avoid repeating the copy of the base pattern.
2c57114f	2015-05-20T21:18:25	ignore: clear the error when matching a pattern negation When we discover that we want to keep a negative rule, make sure to clear the error variable, as it we otherwise return whatever was left by the previous loop iteration.
4f358603	2015-03-24T16:33:50	ignore: fix negative ignores without wildcards.
e0a97416	2014-12-05T16:31:14	ignore: adjust test for negating inside a dir Given top !top/foo in an ignore file, we should not unignore top/foo. This is an implementation detail of the git code leaking, but that's the behaviour we should show. A negation rule can only negate an exact rule it has seen before.
f7fcb18f	2014-11-23T14:12:54	Plug leaks Valgrind is now clean except for libssl and libgcrypt.
0798b014	2014-10-04T11:48:50	ignore: add failing test for a file mentioning the parent When we mention "src" in src/.gitignore, we wrongly consider src/ itself to be ignored.
5c54e216	2014-11-05T16:07:07	ignore: consider files with a CR in their names We currently consider CR to start the end of the line, but that means that we miss cases with CR CR LF which can be used with git to match files whose names have CR at the end of their names. The fix from the patch comes from Russell's comment in the issue. This fixes #2536.
bbe13802	2014-06-12T14:19:34	Demonstrate a trailing slash failure. `git help ignore` has this to say about trailing slashes: > If the pattern ends with a slash, it is removed for the purpose of > the following description, but it would only find a match with a > directory. In other words, foo/ will match a directory foo and > paths underneath it, but will not match a regular file or a > symbolic link foo (this is consistent with the way how pathspec > works in general in Git). Sure enough, having manually performed the same steps as this test, `git status` tells us the following: # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached <file>..." to unstage) # # new file: force.txt # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # ../.gitignore # child1/ # child2/ i.e. neither child1 nor child2 is ignored.
aa5cdf63	2014-06-04T11:57:53	status: failing test with slash-star When writing 'bin/*' in the rules, this means we ignore very file inside bin/ individually, but do not ignore the directory itself. Thus the status listing should list both files under bin/, one untracked and one ignored.
f554611a	2014-05-06T12:41:26	Improve checks for ignore containment The diff code was using an "ignored_prefix" directory to track if a parent directory was ignored that contained untracked files alongside tracked files. Unfortunately, when negative ignore rules were used for directories inside ignored parents, the wrong rules were applied to untracked files inside the negatively ignored child directories. This commit moves the logic for ignore containment into the workdir iterator (which is a better place for it), so the ignored-ness of a directory is contained in the frame stack during traversal. This allows a child directory to override with a negative ignore and yet still restore the ignored state of the parent when we traverse out of the child. Along with this, there are some problems with "directory only" ignore rules on container directories. Given "a/*" and "!a/b/c/" (where the second rule is a directory rule but the first rule is just a generic prefix rule), then the directory only constraint was having "a/b/c/d/file" match the first rule and not the second. This was fixed by having ignore directory-only rules test a rule against the prefix of a file with LEADINGDIR enabled. Lastly, spot checks for ignores using `git_ignore_path_is_ignored` were tested from the top directory down to the bottom to deal with the containment problem, but this is wrong. We have to test bottom to top so that negative subdirectory rules will be checked before parent ignore rules. This does change the behavior of some existing tests, but it seems only to bring us more in line with core Git, so I think those changes are acceptable.
0f603132	2014-05-01T14:47:33	Improve handling of fake home directory 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.
916fcbd6	2014-04-18T14:42:40	Fix ignore difference from git with trailing /* Ignore patterns that ended with a trailing '/' were still needing to match against another actual '/' character in the full path. This is not the same behavior as core Git. Instead, we strip a trailing '/' off of any patterns that were matching and just take it to imply the FNM_LEADING_DIR behavior.
50e46d60	2014-04-18T10:58:01	Cleanup tests with helper functions
6a0956e5	2014-04-18T10:32:35	Pop ignore only if whole relative path matches When traversing the directory structure, the iterator pushes and pops ignore files using a vector. Some directories don't have ignore files, so it uses a path comparison to decide when it is right to actually pop the last ignore file. This was only comparing directory suffixes, though, so a subdirectory with the same name as a parent could result in the parent's .gitignore being popped off the list ignores too early. This changes the logic to compare the entire relative path of the ignore file.
823c0e9c	2014-04-17T11:53:13	Fix broken logic for attr cache invalidation The checks to see if files were out of date in the attibute cache was wrong because the cache-breaker data wasn't getting stored correctly. Additionally, when the cache-breaker triggered, the old file data was being leaked.
a9528b8f	2014-04-14T15:59:48	Fix core.excludesfile named .gitignore Ignore rules with slashes in them are matched using FNM_PATHNAME and use the path to the .gitignore file from the root of the repository along with the path fragment (including slashes) in the ignore file itself. Unfortunately, the relative path to the .gitignore file was being applied to the global core.excludesfile if that was also named ".gitignore". This fixes that with more precise matching and includes test for ignore rules with leading slashes (which were the primary example of this being broken in the real world). This also backports an improvement to the file context logic from the threadsafe-iterators branch where we don't rely on mutating the key of the attribute file name to generate the context path.
8f7bc646	2014-04-10T16:33:39	Fix bug popping ignore files during wd iteration There were a couple bugs in popping ignore files during iteration that could result in incorrect decisions be made and thus ignore files below the root either not being loaded correctly or not being popped at the right time. One bug was an off-by-one in comparing the path of the gitignore file with the path being exited during iteration. The second bug was not correctly truncating the path being tracked during traversal if there were no ignores on the list (i.e. when you have no .gitignore at the root, but do have some in contained directories).
17820381	2013-11-14T14:05:52	Rename tests-clar to tests

18e71e6d

2018-11-28T13:31:06

index: use new enum and structure names Use the new-style index names throughout our own codebase.

3be73011

2018-06-11T18:26:22

Merge pull request #4436 from pks-t/pks/packfile-stream-free pack: rename `git_packfile_stream_free`

ecf4f33a

2018-02-08T11:14:48

Convert usage of `git_buf_free` to new `git_buf_dispose`

20b4c175

2018-06-05T16:12:58

ignore: fix negative leading directory rules unignoring subdirectory files 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.

9beb73ed

2018-06-05T16:45:23

tests: status::ignore: fix style of a test

38b44c3b

2017-07-07T17:10:57

tests: status: additional test for negative ignores with pattern This test is by Carlos Martín Nieto.

c3b8e8b3

2017-05-14T10:28:05

Fix issue with directory glob ignore in subdirectories

c52480fd

2017-02-17T13:01:49

`cl_git_exec` -> `cl_git_expect`

a1dcc830

2017-02-17T12:13:35

tests: provide better pass/failure error messages 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.

fcb2c1c8

2016-08-12T09:06:15

ignore: allow unignoring basenames in subdirectories The .gitignore file allows for patterns which unignore previous ignore patterns. When unignoring a previous pattern, there are basically three cases how this is matched when no globbing is used: 1. when a previous file has been ignored, it can be unignored by using its exact name, e.g. foo/bar !foo/bar 2. when a file in a subdirectory has been ignored, it can be unignored by using its basename, e.g. foo/bar !bar 3. when all files with a basename are ignored, a specific file can be unignored again by specifying its path in a subdirectory, e.g. bar !foo/bar The first problem in libgit2 is that we did not correctly treat the second case. While we verified that the negative pattern matches the tail of the positive one, we did not verify if it only matches the basename of the positive pattern. So e.g. we would have also negated a pattern like foo/fruz_bar !bar Furthermore, we did not check for the third case, where a basename is being unignored in a certain subdirectory again. Both issues are fixed with this commit.

ac2fba0e

2015-09-16T15:07:27

git_futils_mkdir_*: make a relative-to-base mkdir Untangle git_futils_mkdir from git_futils_mkdir_ext - the latter assumes that we own everything beneath the base, as if it were being called with a base of the repository or working directory, and is tailored towards checkout and ensuring that there is no bogosity beneath the base that must be cleaned up. This is (at best) slow and (at worst) unsafe in the larger context of a filesystem where we do not own things and cannot do things like unlink symlinks that are in our way.

657afd35

2015-09-13T06:18:49

ignore: add test and adjust style and comment for dir with wildmatch The previous commit left the comment referencing the earlier state of the code, change it to explain the current logic. While here, change the logic to avoid repeating the copy of the base pattern.

2c57114f

2015-05-20T21:18:25

ignore: clear the error when matching a pattern negation When we discover that we want to keep a negative rule, make sure to clear the error variable, as it we otherwise return whatever was left by the previous loop iteration.

4f358603

2015-03-24T16:33:50

ignore: fix negative ignores without wildcards.

e0a97416

2014-12-05T16:31:14

ignore: adjust test for negating inside a dir Given top !top/foo in an ignore file, we should not unignore top/foo. This is an implementation detail of the git code leaking, but that's the behaviour we should show. A negation rule can only negate an exact rule it has seen before.

f7fcb18f

2014-11-23T14:12:54

Plug leaks Valgrind is now clean except for libssl and libgcrypt.

0798b014

2014-10-04T11:48:50

ignore: add failing test for a file mentioning the parent When we mention "src" in src/.gitignore, we wrongly consider src/ itself to be ignored.

5c54e216

2014-11-05T16:07:07

ignore: consider files with a CR in their names We currently consider CR to start the end of the line, but that means that we miss cases with CR CR LF which can be used with git to match files whose names have CR at the end of their names. The fix from the patch comes from Russell's comment in the issue. This fixes #2536.

bbe13802

2014-06-12T14:19:34

Demonstrate a trailing slash failure. `git help ignore` has this to say about trailing slashes: > If the pattern ends with a slash, it is removed for the purpose of > the following description, but it would only find a match with a > directory. In other words, foo/ will match a directory foo and > paths underneath it, but will not match a regular file or a > symbolic link foo (this is consistent with the way how pathspec > works in general in Git). Sure enough, having manually performed the same steps as this test, `git status` tells us the following: # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached <file>..." to unstage) # # new file: force.txt # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # ../.gitignore # child1/ # child2/ i.e. neither child1 nor child2 is ignored.

aa5cdf63

2014-06-04T11:57:53

status: failing test with slash-star When writing 'bin/*' in the rules, this means we ignore very file inside bin/ individually, but do not ignore the directory itself. Thus the status listing should list both files under bin/, one untracked and one ignored.

f554611a

2014-05-06T12:41:26

Improve checks for ignore containment The diff code was using an "ignored_prefix" directory to track if a parent directory was ignored that contained untracked files alongside tracked files. Unfortunately, when negative ignore rules were used for directories inside ignored parents, the wrong rules were applied to untracked files inside the negatively ignored child directories. This commit moves the logic for ignore containment into the workdir iterator (which is a better place for it), so the ignored-ness of a directory is contained in the frame stack during traversal. This allows a child directory to override with a negative ignore and yet still restore the ignored state of the parent when we traverse out of the child. Along with this, there are some problems with "directory only" ignore rules on container directories. Given "a/*" and "!a/b/c/" (where the second rule is a directory rule but the first rule is just a generic prefix rule), then the directory only constraint was having "a/b/c/d/file" match the first rule and not the second. This was fixed by having ignore directory-only rules test a rule against the prefix of a file with LEADINGDIR enabled. Lastly, spot checks for ignores using `git_ignore_path_is_ignored` were tested from the top directory down to the bottom to deal with the containment problem, but this is wrong. We have to test bottom to top so that negative subdirectory rules will be checked before parent ignore rules. This does change the behavior of some existing tests, but it seems only to bring us more in line with core Git, so I think those changes are acceptable.

0f603132

2014-05-01T14:47:33

Improve handling of fake home directory 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.

916fcbd6

2014-04-18T14:42:40

Fix ignore difference from git with trailing /* Ignore patterns that ended with a trailing '/*' were still needing to match against another actual '/' character in the full path. This is not the same behavior as core Git. Instead, we strip a trailing '/*' off of any patterns that were matching and just take it to imply the FNM_LEADING_DIR behavior.

50e46d60

2014-04-18T10:58:01

Cleanup tests with helper functions

6a0956e5

2014-04-18T10:32:35

Pop ignore only if whole relative path matches When traversing the directory structure, the iterator pushes and pops ignore files using a vector. Some directories don't have ignore files, so it uses a path comparison to decide when it is right to actually pop the last ignore file. This was only comparing directory suffixes, though, so a subdirectory with the same name as a parent could result in the parent's .gitignore being popped off the list ignores too early. This changes the logic to compare the entire relative path of the ignore file.

823c0e9c

2014-04-17T11:53:13

Fix broken logic for attr cache invalidation The checks to see if files were out of date in the attibute cache was wrong because the cache-breaker data wasn't getting stored correctly. Additionally, when the cache-breaker triggered, the old file data was being leaked.

a9528b8f

2014-04-14T15:59:48

Fix core.excludesfile named .gitignore Ignore rules with slashes in them are matched using FNM_PATHNAME and use the path to the .gitignore file from the root of the repository along with the path fragment (including slashes) in the ignore file itself. Unfortunately, the relative path to the .gitignore file was being applied to the global core.excludesfile if that was also named ".gitignore". This fixes that with more precise matching and includes test for ignore rules with leading slashes (which were the primary example of this being broken in the real world). This also backports an improvement to the file context logic from the threadsafe-iterators branch where we don't rely on mutating the key of the attribute file name to generate the context path.

8f7bc646

2014-04-10T16:33:39

Fix bug popping ignore files during wd iteration There were a couple bugs in popping ignore files during iteration that could result in incorrect decisions be made and thus ignore files below the root either not being loaded correctly or not being popped at the right time. One bug was an off-by-one in comparing the path of the gitignore file with the path being exited during iteration. The second bug was not correctly truncating the path being tracked during traversal if there were no ignores on the list (i.e. when you have no .gitignore at the root, but do have some in contained directories).

17820381

2013-11-14T14:05:52

Rename tests-clar to tests

thodg/libgit2/tests/status/ignore.c

tests/status/ignore.c

Log