1. 31 Oct, 2017 1 commit
  2. 30 Oct, 2017 1 commit
  3. 09 Oct, 2017 3 commits
    • config_file: implement "gitdir/i" conditional · f7d837c8
      Next to the "gitdir" conditional for including other configuration
      files, there's also a "gitdir/i" conditional. In contrast to the former
      one, path matching with "gitdir/i" is done case-insensitively. This
      commit implements the case-insensitive condition.
      Patrick Steinhardt committed
    • config_file: implement conditional "gitdir" includes · 071b6c06
      Upstream git.git has implemented the ability to include other
      configuration files based on conditions. Right now, this only includes
      the ability to include a file based on the gitdir-location of the
      repository the currently parsed configuration file belongs to. This
      commit implements handling these conditional includes for the
      case-sensitive "gitdir" condition.
      Patrick Steinhardt committed
    • config: pass repository when opening config files · 529e873c
      Our current configuration logic is completely oblivious of any
      repository, but only cares for actual file paths. Unfortunately, we are
      forced to break this assumption by the introduction of conditional
      includes, which are evaluated in the context of a repository. Right now,
      only one conditional exists with "gitdir:" -- it will only include the
      configuration if the current repository's git directory matches the
      value passed to "gitdir:".
      
      To support these conditionals, we have to break our API and make the
      repository available when opening a configuration file. This commit
      extends the `open` call of configuration backends to include another
      repository and adjusts existing code to have it available. This includes
      the user-visible functions `git_config_add_file_ondisk` and
      `git_config_add_backend`.
      Patrick Steinhardt committed
  4. 15 Jul, 2017 4 commits
    • config_file: refuse modifying included variables · 1b329089
      Modifying variables pulled in by an included file currently succeeds,
      but it doesn't actually do what one would expect, as refreshing the
      configuration will cause the values to reappear. As we are currently not
      really able to support this use case, we will instead just return an
      error for deleting and setting variables which were included via an
      include.
      Patrick Steinhardt committed
    • config_file: move reader into `config_read` only · 28c2cc3d
      Right now, we have multiple call sites which initialize a `reader`
      structure. As the structure is only actually used inside of
      `config_read`, we can instead just move the reader inside of the
      `config_read` function. Instead, we can just pass in the configuration
      file into `config_read`, which eases code readability.
      Patrick Steinhardt committed
    • config_file: refresh all files if includes were modified · 83bcd3a1
      Currently, we only re-parse the top-level configuration file when it has
      changed itself. This can cause problems when an include is changed, as
      we were not updating all values correctly.
      
      Instead of conditionally reparsing only refreshed files, the logic
      becomes much clearer and easier to follow if we always re-parse the
      top-level configuration file when either the file itself or one of its
      included configuration files has changed on disk. This commit implements
      this logic.
      
      Note that this might impact performance in some cases, as we need to
      re-read all configuration files whenever any of the included files
      changed. It could increase performance to just re-parse include files
      which have actually changed, but this would compromise maintainability
      of the code without much gain. The only case where we will gain anything
      is when we actually use includes and when only these includes are
      updated, which will probably be quite an unusual scenario to actually be
      worthwhile to optimize.
      Patrick Steinhardt committed
  5. 05 Jul, 2017 1 commit
    • tests: config: fix missing declaration causing error · 1f7af277
      On systems where we pull in our distributed version of the regex
      library, all tests in config::readonly fail. This error is actually
      quite interesting: the test suite is unable to find the declaration of
      `git_path_exists` and assumes it has a signature of `int
      git_path_exists(const char *)`. But actually, it has a `bool` return
      value. Due to this confusion, some wrong conversion is done by the
      compiler and the `cl_assert(!git_path_exists("file"))` checks
      erroneously fail, even when the function does in fact return the correct
      value.
      
      The error is actually introduced by 56893bb9 (cmake: consistently use
      TARGET_INCLUDE_DIRECTORIES if available, 2017-06-28), unfortunately
      introduced by myself. Due to the delayed addition of include
      directories, we will now find the "config.h" header inside of the
      "deps/regex" directory instead of inside the "src/" directory, where it
      should be. As such, we are missing definitions for the
      `git_config_file__ondisk` and `git_path_exists` symbols.
      
      The correct fix here would be to fix the order in which include search
      directories are added. But due to the current restructuring of
      CMakeBuild.txt, I'm refraining from doing so and delay the proper fix a
      bit. Instead, we paper over the issue by explicitly including "path.h"
      to fix its prototype. This ignores the issue that
      `git_config_file__ondisk` is undeclared, as its signature is correctly
      identified by the compiler.
      Patrick Steinhardt committed
  6. 26 Apr, 2017 1 commit
  7. 23 Mar, 2017 2 commits
  8. 31 Mar, 2016 1 commit
  9. 28 Mar, 2016 2 commits
  10. 21 Mar, 2016 1 commit
  11. 24 Nov, 2015 2 commits
  12. 17 Nov, 2015 1 commit
  13. 30 Oct, 2015 1 commit
  14. 21 Oct, 2015 1 commit
  15. 18 Sep, 2015 1 commit
  16. 17 Sep, 2015 1 commit
    • git_futils_mkdir_*: make a relative-to-base mkdir · ac2fba0e
      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.
      Edward Thomson committed
  17. 13 Sep, 2015 1 commit
  18. 12 Aug, 2015 3 commits
  19. 04 May, 2015 7 commits
  20. 23 Apr, 2015 2 commits
  21. 21 Apr, 2015 2 commits
  22. 20 Apr, 2015 1 commit