1. 13 Aug, 2019 1 commit
    • config: validate ownership of C:\ProgramData\Git\config before using it · cb1439c9
      When the VirtualStore feature is in effect, it is safe to let random
      users write into C:\ProgramData because other users won't see those
      files. This seemed to be the case when we introduced support for
      C:\ProgramData\Git\config.
      
      However, when that feature is not in effect (which seems to be the case
      in newer Windows 10 versions), we'd rather not use those files unless
      they come from a trusted source, such as an administrator.
      
      This change imitates the strategy chosen by PowerShell's native OpenSSH
      port to Windows regarding host key files: if a system file is owned
      neither by an administrator, a system account, or the current user, it
      is ignored.
      Johannes Schindelin committed
  2. 20 Jul, 2019 1 commit
    • path: extract function to check whether a path supports symlinks · ded77bb1
      When initializing a repository, we need to check whether its working
      directory supports symlinks to correctly set the initial value of the
      "core.symlinks" config variable. The code to check the filesystem is
      reusable in other parts of our codebase, like for example in our tests
      to determine whether certain tests can be expected to succeed or not.
      
      Extract the code into a new function `git_path_supports_symlinks` to
      avoid duplicate implementations. Remove a duplicate implementation in
      the repo test helper code.
      Patrick Steinhardt committed
  3. 15 Oct, 2018 1 commit
  4. 01 Jun, 2018 1 commit
    • path: unify `git_path_is_*` APIs · 92159bd4
      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
  5. 23 May, 2018 1 commit
  6. 22 May, 2018 2 commits
  7. 18 May, 2018 1 commit
  8. 09 Oct, 2017 2 commits
  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. 26 May, 2016 1 commit
  11. 24 Mar, 2016 1 commit
  12. 17 Feb, 2016 1 commit
    • index: allow read of index w/ illegal entries · 318b825e
      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
  13. 17 Sep, 2015 2 commits
  14. 28 Jul, 2015 1 commit
  15. 13 Jul, 2015 1 commit
  16. 15 Jun, 2015 1 commit
  17. 01 May, 2015 6 commits
  18. 20 Jan, 2015 1 commit
  19. 17 Dec, 2014 1 commit
  20. 16 Dec, 2014 2 commits
    • checkout: disallow bad paths on HFS · 11d67b75
      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
    • 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
  21. 05 Dec, 2014 1 commit
  22. 17 Sep, 2014 1 commit
  23. 03 Sep, 2014 1 commit
  24. 08 Aug, 2014 1 commit
  25. 05 Aug, 2014 1 commit
  26. 11 Jul, 2014 1 commit
  27. 03 Jun, 2014 1 commit
  28. 08 May, 2014 1 commit
    • Pass unconverted data when iconv doesn't like it · 43a04135
      When using Iconv to convert unicode data and iconv doesn't like
      the source data (because it thinks that it's not actual UTF-8),
      instead of stopping the operation, just use the unconverted data.
      This will generally do the right thing on the filesystem, since
      that is the source of the non-UTF-8 path data anyhow.
      
      This adds some tests for creating and looking up branches with
      messy Unicode names.  Also, this takes the helper function that
      was previously internal to `git_repository_init` and makes it
      into `git_path_does_fs_decompose_unicode` which is a useful in
      tests to understand what the expected results should be.
      Russell Belfer committed
  29. 01 Apr, 2014 1 commit
  30. 11 Dec, 2013 1 commit
    • Remove converting user error to GIT_EUSER · 25e0b157
      This changes the behavior of callbacks so that the callback error
      code is not converted into GIT_EUSER and instead we propagate the
      return value through to the caller.  Instead of using the
      giterr_capture and giterr_restore functions, we now rely on all
      functions to pass back the return value from a callback.
      
      To avoid having a return value with no error message, the user
      can call the public giterr_set_str or some such function to set
      an error message.  There is a new helper 'giterr_set_callback'
      that functions can invoke after making a callback which ensures
      that some error message was set in case the callback did not set
      one.
      
      In places where the sign of the callback return value is
      meaningful (e.g. positive to skip, negative to abort), only the
      negative values are returned back to the caller, obviously, since
      the other values allow for continuing the loop.
      
      The hardest parts of this were in the checkout code where positive
      return values were overloaded as meaningful values for checkout.
      I fixed this by adding an output parameter to many of the internal
      checkout functions and removing the overload.  This added some
      code, but it is probably a better implementation.
      
      There is some funkiness in the network code where user provided
      callbacks could be returning a positive or a negative value and
      we want to rely on that to cancel the loop.  There are still a
      couple places where an user error might get turned into GIT_EUSER
      there, I think, though none exercised by the tests.
      Russell Belfer committed
  31. 01 Nov, 2013 1 commit