1. 23 Feb, 2022 2 commits
  2. 18 Jan, 2022 1 commit
  3. 09 Aug, 2021 1 commit
    • Get Win32 builds to build · b060080e
      Previously, the location of `GIT_WARN_UNUSED_RESULT` was causing it to
      be included _after_ a bunch of other headers (namely `src/vector.h`),
      which broke the build.
      
      This change does two things:
      
      * Moves the `GIT_WARN_UNUSED_RESULT` above most of the `$include`s in
        `src/common.h`.
      * Stops including `vector.h` from `src/win32/path_w32.c` since the
        header itself does not use it.
      lhchavez committed
  4. 10 Mar, 2020 1 commit
  5. 08 Mar, 2020 1 commit
    • win32: clarify usage of path canonicalization funcs · fb7da154
      The path canonicalization functions on win32 are intended to
      canonicalize absolute paths; those with prefixes.  In other words,
      things start with drive letters (`C:\`), share names (`\\server\share`),
      or other prefixes (`\\?\`).
      
      This function removes leading `..` that occur after the prefix but
      before the directory/file portion (eg, turning `C:\..\..\..\foo` into
      `C:\foo`).  This translation is not appropriate for local paths.
      Edward Thomson committed
  6. 19 May, 2019 1 commit
  7. 19 Oct, 2018 1 commit
    • win32: rename `git_win32__canonicalize_path` · b2e85f98
      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
  8. 01 Feb, 2018 1 commit
  9. 03 Jul, 2017 1 commit
    • Make sure to always include "common.h" first · 0c7f49dd
      Next to including several files, our "common.h" header also declares
      various macros which are then used throughout the project. As such, we
      have to make sure to always include this file first in all
      implementation files. Otherwise, we might encounter problems or even
      silent behavioural differences due to macros or defines not being
      defined as they should be. So in fact, our header and implementation
      files should make sure to always include "common.h" first.
      
      This commit does so by establishing a common include pattern. Header
      files inside of "src" will now always include "common.h" as its first
      other file, separated by a newline from all the other includes to make
      it stand out as special. There are two cases for the implementation
      files. If they do have a matching header file, they will always include
      this one first, leading to "common.h" being transitively included as
      first file. If they do not have a matching header file, they instead
      include "common.h" as first file themselves.
      
      This fixes the outlined problems and will become our standard practice
      for header and source files inside of the "src/" from now on.
      Patrick Steinhardt committed
  10. 01 May, 2015 1 commit
  11. 28 Apr, 2015 1 commit
    • Improvements to status performance on Windows. · 1920ee4e
      Changed win32/path_w32.c to utilize NTFS' FindFirst..FindNext data instead of doing an lstat per file. Avoiding unnecessary directory opens and file scans reduces IO, improving overall performance. Effect is magnified due to NTFS being a kernel mode file system (as opposed to user mode).
      J Wyman committed
  12. 19 Dec, 2014 1 commit
  13. 16 Dec, 2014 2 commits
    • checkout: disallow bad paths on win32 · a64119e3
      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
    • win32: use NT-prefixed "\\?\" paths · cceae9a2
      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