- 01 Jun, 2018 1 commit
-
-
Right now, there's quite a lot of different function calls to determine whether a path component matches a specific name after normalization from the filesystem. We have a function for each of {gitattributes, gitmodules, gitignore} multiplicated with {generic, NTFS, HFS} checks. In the long time, this is unmaintainable in case there are e.g. new filesystems with specific semantics, blowing up the number of functions we need to implement. Replace all functions with a simple `git_path_is_gitfile` function, which accepts an enum pointing out the filename that is to be checked against as well as the filesystem normalizations to check for. This greatly simplifies implementation at the expense of the caller having to invoke a somewhat longer function call.
Patrick Steinhardt committed
-
- 24 May, 2018 1 commit
-
-
Carlos Martín Nieto committed
-
- 23 May, 2018 1 commit
-
-
Any part of the library which asks the question can pass in the mode to have it checked against `.gitmodules` being a symlink. This is particularly relevant for adding entries to the index from the worktree and for checking out files.
Carlos Martín Nieto committed
-
- 22 May, 2018 1 commit
-
-
We may take in names from the middle of a string so we want the caller to let us know how long the path component is that we should be checking.
Carlos Martín Nieto committed
-
- 18 May, 2018 2 commits
-
-
These can't go into the public API yet as we don't want to introduce API or ABI changes in a security release.
Carlos Martín Nieto committed -
Given a path component it knows what to pass to the filesystem-specific functions so we're protected even from trees which try to use the 8.3 naming rules to get around us matching on the filename exactly. The logic and test strings come from the equivalent git change.
Carlos Martín Nieto committed
-