1. 11 Dec, 2013 5 commits
    • Further callback error check style fixes · f10d7a36
      Okay, I've decided I like the readability of this style much
      better so I used it everywhere.
      Russell Belfer committed
    • 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
    • Improve GIT_EUSER handling · 96869a4e
      This adds giterr_user_cancel to return GIT_EUSER and clear any
      error message that is sitting around.  As a result of using that
      in places, we need to be more thorough with capturing errors that
      happen inside a callback when used internally.  To help with that,
      this also adds giterr_capture and giterr_restore so that when we
      internally use a foreach-type function that clears errors and
      converts them to GIT_EUSER, it is easier to restore not just the
      return value, but the actual error message text.
      Russell Belfer committed
    • Add config read fns with controlled error behavior · 9f77b3f6
      This adds `git_config__lookup_entry` which will look up a key in
      a config and return either the entry or NULL if the key was not
      present.  Optionally, it can either suppress all errors or can
      return them (although not finding the key is not an error for this
      function).  Unlike other accessors, this does not normalize the
      config key string, so it must only be used when the key is known
      to be in normalized form (i.e. all lower-case before the first dot
      and after the last dot, with no invalid characters).
      
      This also adds three high-level helper functions to look up config
      values with no errors and a fallback value.  The three functions
      are for string, bool, and int values, and will resort to the
      fallback value for any error that arises.  They are:
      
      * `git_config__get_string_force`
      * `git_config__get_bool_force`
      * `git_config__get_int_force`
      
      None of them normalize the config `key` either, so they can only
      be used for internal cases where the key is known to be in normal
      format.
      Russell Belfer committed
  2. 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
  3. 13 Aug, 2013 1 commit
  4. 12 Aug, 2013 5 commits
  5. 08 Aug, 2013 10 commits
  6. 09 Jul, 2013 2 commits
  7. 12 Jun, 2013 2 commits
  8. 07 Jun, 2013 1 commit
  9. 31 May, 2013 1 commit
  10. 24 May, 2013 1 commit
  11. 23 May, 2013 2 commits
  12. 15 May, 2013 1 commit
  13. 07 May, 2013 2 commits
    • config: convenience function to open global/xdg · 5d831887
      The rules for which one to open is a bit silly, so let's make it
      easier for our users.
      Carlos Martín Nieto committed
    • repo: unconditionally create a global config backend · a4b75dcf
      When a repository is initialised, we need to probe to see if there is
      a global config to load. If this is not the case, the user isn't able
      to write to the global config without creating the backend and adding
      it themselves, which is inconvenient and overly complex.
      
      Unconditionally create and add a backend for the global config file
      regardless of whether it exists as a convenience for users.
      
      To enable this, we allow creating backends to files that do not exist
      yet, changing the semantics somewhat, and making some tests invalid.
      Carlos Martín Nieto committed
  14. 01 May, 2013 1 commit
  15. 30 Apr, 2013 1 commit
  16. 23 Apr, 2013 2 commits
    • Clear repo config cache when cfgs are set · 6be368bf
      This is a conservative change, but it seemed like the only safe
      thing to do -- i.e. clear the cvar cache when a config gets set.
      Russell Belfer committed
    • Add configs to repo config cache · ab01cbd4
      This adds a bunch of additional config values to the repository
      config value cache and makes it easier to add a simple boolean
      config without creating enum values for each possible setting.
      
      Also, this fixes a bug in git_config_refresh where the config
      cache was not being cleared which could lead to potential
      incorrect values.
      
      The work to start using the new cached configs will come in the
      next couple of commits...
      Russell Belfer committed
  17. 21 Apr, 2013 1 commit
  18. 18 Mar, 2013 1 commit
    • Switch search paths to classic delimited strings · 41954a49
      This switches the APIs for setting and getting the global/system
      search paths from using git_strarray to using a simple string with
      GIT_PATH_LIST_SEPARATOR delimited paths, just as the environment
      PATH variable would contain.  This makes it simpler to get and set
      the value.
      
      I also added code to expand "$PATH" when setting a new value to
      embed the old value of the path.  This means that I no longer
      require separate actions to PREPEND to the value.
      Russell Belfer committed