1. 23 Feb, 2022 1 commit
  2. 05 Jan, 2022 1 commit
  3. 09 Oct, 2017 1 commit
    • 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. 21 Mar, 2016 1 commit
  5. 18 Apr, 2014 1 commit
    • config: refresh on delete · 8c1f4ab4
      When we delete an entry, we also want to refresh the configuration to
      catch any changes that happened externally.
      
      This allows us to simplify the logic, as we no longer need to delete
      these variables internally. The whole state will be refreshed and the
      deleted entries won't be there.
      Carlos Martín Nieto committed
  6. 14 Nov, 2013 1 commit
  7. 31 Oct, 2013 1 commit
    • Fix saving remotes with several fetch/push ref specs. · 3793fa9b
      At some moment git_config_delete_entry lost the ability to delete one entry of
      a multivar configuration. The moment you had more than one fetch or push
      ref spec for a remote you will not be able to save that remote anymore. The
      changes in network::remote::remotes::save show that problem.
      
      I needed to create a new git_config_delete_multivar because I was not able to
      remove one or several entries of a multivar config with the current API.
      Several tries modifying how git_config_set_multivar(..., NULL) behaved were
      not successful.
      
      git_config_delete_multivar is very similar to git_config_set_multivar, and
      delegates into config_delete_multivar of config_file. This function search
      for the cvar_t that will be deleted, storing them in a temporal array, and
      rebuilding the linked list. After calling config_write to delete the entries,
      the cvar_t stored in the temporal array are freed.
      
      There is a little fix in config_write, it avoids an infinite loop when using
      a regular expression (case for the multivars). This error was found by the
      test network::remote::remotes::tagopt.
      Daniel Rodríguez Troitiño committed
  8. 13 Aug, 2013 1 commit
  9. 08 Aug, 2013 3 commits
  10. 09 Jul, 2013 1 commit
  11. 20 Apr, 2013 1 commit
  12. 23 Oct, 2012 1 commit
    • Add config level support in the config API · a1abe66a
      Added `struct git_config_entry`: a git_config_entry contains the key, the value, and the config file level from which a config element was found.
      Added `git_config_open_level`: build a single-level focused config object from a multi-level one.
      
      We are now storing `git_config_entry`s in the khash of the config_file
      yorah committed
  13. 17 May, 2012 1 commit
  14. 01 Apr, 2012 1 commit
  15. 02 Mar, 2012 2 commits
    • Fixing memory leaks indicated by valgrind · c19bc93c
      This clears up the memory leaks that valgrind seems to find on
      my machine.
      Russell Belfer committed
    • Clean up GIT_UNUSED macros on all platforms · 854eccbb
      It turns out that commit 31e9cfc4cbcaf1b38cdd3dbe3282a8f57e5366a5
      did not fix the GIT_USUSED behavior on all platforms.  This commit
      walks through and really cleans things up more thoroughly, getting
      rid of the unnecessary stuff.
      
      To remove the use of some GIT_UNUSED, I ended up adding a couple
      of new iterators for hashtables that allow you to iterator just
      over keys or just over values.
      
      In making this change, I found a bug in the clar tests (where we
      were doing *count++ but meant to do (*count)++ to increment the
      value).  I fixed that but then found the test failing because it
      was not really using an empty repo.  So, I took some of the code
      that I wrote for iterator testing and moved it to clar_helpers.c,
      then made use of that to make it easier to open fixtures on a
      per test basis even within a single test file.
      Russell Belfer committed
  16. 25 Feb, 2012 1 commit
  17. 17 Feb, 2012 3 commits