1. 29 May, 2015 1 commit
    • git__tolower: a tolower() that isn't dumb · 75a4636f
      Some brain damaged tolower() implementations appear to want to
      take the locale into account, and this may require taking some
      insanely aggressive lock on the locale and slowing down what should
      be the most trivial of trivial calls for people who just want to
      downcase ASCII.
      Edward Thomson committed
  2. 05 May, 2015 1 commit
  3. 04 May, 2015 4 commits
    • config: lock the file for write before reading · 9c26de0f
      When writing a configuration file, we want to take a lock on the
      new file (eg, `config.lock`) before opening the configuration file
      (`config`) for reading so that we can prevent somebody from changing
      the contents underneath us.
      Edward Thomson committed
    • config: write existing lines as-is when rewriting · 2a950c94
      When updating a configuration file, we want to copy the old data
      from the file to preserve comments and funny whitespace, instead
      of writing it in some "canonical" format.  Thus, we keep a
      pointer to the start of the line and the line length to preserve
      these things we don't care to rewrite.
      Edward Thomson committed
    • config: examine whole file when writing · bf99390e
      Previously we would try to be clever when writing the configuration
      file and try to stop parsing (and simply copy the rest of the old
      file) when we either found the value we were trying to write,
      or when we left the section that value was in, the assumption being
      that there was no more work to do.
      
      Regrettably, you can have another section with the same name later
      in the file, and we must cope with that gracefully, thus we read the
      whole file in order to write a new file.
      
      Now, writing a file looks even more than reading.  Pull the config
      parsing out into its own function that can be used by both reading
      and writing the configuration.
      Edward Thomson committed
  4. 23 Apr, 2015 2 commits
  5. 21 Apr, 2015 1 commit
    • git_config_delete: search until last section. · 9a810c5e
      If git_config_delete is to work properly in the presence of duplicate section
      headers, it cannot stop searching at the end of the first matching section, as
      there may be another matching section later.
      When config_write is used for deletion (value = NULL), it may only terminate
      when the desired key is found or there are no sections left to parse.
      Ryan Roden-Corrent committed
  6. 20 Apr, 2015 2 commits
  7. 10 Apr, 2015 1 commit
    • Fix checking of return value for regcomp. · 129022ee
      The regcomp function returns a non-zero value if compilation of
      a regular expression fails. In most places we only check for
      negative values, but positive values indicate an error, as well.
      Fix this tree-wide, fixing a segmentation fault when calling
      git_config_iterator_glob_new with an invalid regexp.
      Patrick Steinhardt committed
  8. 03 Mar, 2015 1 commit
    • config: borrow refcounted references · 9a97f49e
      This changes the get_entry() method to return a refcounted version of
      the config entry, which you have to free when you're done.
      
      This allows us to avoid freeing the memory in which the entry is stored
      on a refresh, which may happen at any time for a live config.
      
      For this reason, get_string() has been forbidden on live configs and a
      new function get_string_buf() has been added, which stores the string in
      a git_buf which the user then owns.
      
      The functions which parse the string value takea advantage of the
      borrowing to parse safely and then release the entry.
      Carlos Martín Nieto committed
  9. 15 Feb, 2015 1 commit
  10. 13 Feb, 2015 3 commits
  11. 12 Feb, 2015 1 commit
  12. 29 Dec, 2014 1 commit
  13. 05 Dec, 2014 1 commit
  14. 03 Nov, 2014 1 commit
  15. 01 Nov, 2014 1 commit
  16. 23 Oct, 2014 2 commits
  17. 04 Oct, 2014 1 commit
  18. 09 Aug, 2014 1 commit
    • config: a multiline var can start immediately · 9dac1f95
      In the check for multiline, we traverse the backslashes from the end
      backwards and int the end assert that we haven't gone past the beginning
      of the line. We make sure of this in the loop condition, but we also
      check in the return value.
      
      However, for certain configurations, a line in a multiline variable
      might be empty to aid formatting. In that case, 'end' == 'start', since
      we ended up looking at the first char which made it a multiline.
      
      There is no need for the (end > start) check in the return, since the
      loop guarantees we won't go further back than the first char in the
      line, and we do accept the first char to be the final backslash.
      
      This fixes #2483.
      Carlos Martín Nieto committed
  19. 16 Jul, 2014 1 commit
  20. 15 May, 2014 1 commit
  21. 13 May, 2014 1 commit
  22. 12 May, 2014 1 commit
  23. 18 Apr, 2014 9 commits
  24. 17 Apr, 2014 1 commit