- 06 Jan, 2019 1 commit
-
-
It seems like MingW64's size_t is defined differently than in Linux.
lhchavez committed
-
- 28 Nov, 2018 1 commit
-
-
The function `test_canonicalize` is only used on Win32 platforms. It will thus result in an unused function warning if these warnings are enabled and one is on a platform different than Win32. Fix the issue by only compiling in the function on Win32 platforms.
Patrick Steinhardt committed
-
- 19 Oct, 2018 2 commits
-
-
Edward Thomson committed
-
The internal API `git_win32__canonicalize_path` is far, far too easily confused with the internal API `git_win32_path_canonicalize`. The former removes the namespace prefix from a path (eg, given `\\?\C:\Temp\foo`, it returns `C:\Temp\foo`, and given `\\?\UNC\server\share`, it returns `\\server\share`). As such, rename it to `git_win32_path_remove_namespace`. `git_win32_path_canonicalize` remains unchanged.
Edward Thomson committed
-
- 04 Oct, 2018 1 commit
-
-
Gabriel DeBacker committed
-
- 30 Sep, 2018 1 commit
-
-
Gabriel DeBacker committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 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
-
- 17 Feb, 2016 1 commit
-
-
Allow `git_index_read` to handle reading existing indexes with illegal entries. Allow the low-level `git_index_add` to add properly formed `git_index_entry`s even if they contain paths that would be illegal for the current filesystem (eg, `AUX`). Continue to disallow `git_index_add_bypath` from adding entries that are illegal universally illegal (eg, `.git`, `foo/../bar`).
Edward Thomson committed
-
- 04 Feb, 2015 1 commit
-
-
Edward Thomson committed
-
- 03 Feb, 2015 1 commit
-
-
Edward Thomson committed
-
- 30 Jan, 2015 1 commit
-
-
Linquize committed
-
- 20 Jan, 2015 1 commit
-
-
The documentation for `git_path_join_unrooted` states that the base length will be returned, so that consumers like checkout know where to start creating directories instead of always creating directories at the directory root.
Edward Thomson committed
-
- 19 Dec, 2014 2 commits
- 17 Dec, 2014 1 commit
-
-
Validate HFS ignored char ".git" paths when `core.protectHFS` is specified. Validate NTFS invalid ".git" paths when `core.protectNTFS` is specified.
Edward Thomson committed
-
- 16 Dec, 2014 3 commits
-
-
HFS filesystems ignore some characters like U+200C. When these characters are included in a path, they will be ignored for the purposes of comparison with other paths. Thus, if you have a ".git" folder, a folder of ".git<U+200C>" will also match. Protect our ".git" folder by ensuring that ".git<U+200C>" and friends do not match it.
Edward Thomson committed -
Disallow: 1. paths with trailing dot 2. paths with trailing space 3. paths with trailing colon 4. paths that are 8.3 short names of .git folders ("GIT~1") 5. paths that are reserved path names (COM1, LPT1, etc). 6. paths with reserved DOS characters (colons, asterisks, etc) These paths would (without \\?\ syntax) be elided to other paths - for example, ".git." would be written as ".git". As a result, writing these paths literally (using \\?\ syntax) makes them hard to operate with from the shell, Windows Explorer or other tools. Disallow these.
Edward Thomson committed -
When turning UTF-8 paths into UCS-2 paths for Windows, always use the \\?\-prefixed paths. Because this bypasses the system's path canonicalization, handle the canonicalization functions ourselves. We must: 1. always use a backslash as a directory separator 2. only use a single backslash between directories 3. not rely on the system to translate "." and ".." in paths 4. remove trailing backslashes, except at the drive root (C:\)
Edward Thomson committed
-
- 17 Sep, 2014 1 commit
-
-
The rugged tests are fragile committed
-
- 16 Sep, 2014 1 commit
-
-
Ciro Santilli committed
-
- 08 Sep, 2014 1 commit
-
-
The compiler was generating a bunch of warnings for git_mutex_init and git_mutex_lock when GIT_THREADS was not defined (i.e. when not using -DTHREADSAFE=ON). Also remove an unused variable from tests/path/core.c.
Sam Clegg committed
-
- 03 Sep, 2014 1 commit
-
-
Edward Thomson committed
-