1. 28 Apr, 2021 1 commit
  2. 14 Apr, 2021 1 commit
  3. 19 Feb, 2021 1 commit
  4. 17 Feb, 2021 1 commit
  5. 06 Dec, 2020 2 commits
  6. 27 Nov, 2020 1 commit
  7. 30 Jun, 2020 1 commit
    • Make the tests run cleanly under UndefinedBehaviorSanitizer · d0656ac8
      This change makes the tests run cleanly under
      `-fsanitize=undefined,nullability` and comprises of:
      
      * Avoids some arithmetic with NULL pointers (which UBSan does not like).
      * Avoids an overflow in a shift, due to an uint8_t being implicitly
        converted to a signed 32-bit signed integer after being shifted by a
        32-bit signed integer.
      * Avoids a unaligned read in libgit2.
      * Ignores unaligned reads in the SHA1 library, since it only happens on
        Intel processors, where it is _still_ undefined behavior, but the
        semantics are moderately well-understood.
      
      Of notable omission is `-fsanitize=integer`, since there are lots of
      warnings in zlib and the SHA1 library which probably don't make sense to
      fix and I could not figure out how to silence easily. libgit2 itself
      also has ~100s of warnings which are mostly innocuous (e.g. use of enum
      constants that only fit on an `uint32_t`, but there is no way to do that
      in a simple fashion because the data type chosen for enumerated types is
      implementation-defined), and investigating whether there are worrying
      warnings would need reducing the noise significantly.
      lhchavez committed
  8. 09 Jun, 2020 1 commit
    • tree-wide: do not compile deprecated functions with hard deprecation · c6184f0c
      When compiling libgit2 with -DDEPRECATE_HARD, we add a preprocessor
      definition `GIT_DEPRECATE_HARD` which causes the "git2/deprecated.h"
      header to be empty. As a result, no function declarations are made
      available to callers, but the implementations are still available to
      link against. This has the problem that function declarations also
      aren't visible to the implementations, meaning that the symbol's
      visibility will not be set up correctly. As a result, the resulting
      library may not expose those deprecated symbols at all on some platforms
      and thus cause linking errors.
      
      Fix the issue by conditionally compiling deprecated functions, only.
      While it becomes impossible to link against such a library in case one
      uses deprecated functions, distributors of libgit2 aren't expected to
      pass -DDEPRECATE_HARD anyway. Instead, users of libgit2 should manually
      define GIT_DEPRECATE_HARD to hide deprecated functions. Using "real"
      hard deprecation still makes sense in the context of CI to test we don't
      use deprecated symbols ourselves and in case a dependant uses libgit2 in
      a vendored way and knows it won't ever use any of the deprecated symbols
      anyway.
      Patrick Steinhardt committed
  9. 01 Jun, 2020 1 commit
  10. 25 May, 2020 1 commit
  11. 24 Jan, 2020 1 commit
  12. 14 Jan, 2020 2 commits
    • index: fix resizing index map twice on case-insensitive systems · 7fc97eb3
      Depending on whether the index map is case-sensitive or insensitive, we
      need to call either `git_idxmap_icase_resize` or `git_idxmap_resize`.
      There are multiple locations where we thus use the following pattern:
      
      	if (index->ignore_case &&
      	    git_idxmap_icase_resize(map, length) < 0)
      		return -1;
      	else if (git_idxmap_resize(map, length) < 0)
      		return -1;
      
      The funny thing is: on case-insensitive systems, we will try to resize
      the map twice in case where `git_idxmap_icase_resize()` doesn't error.
      While this will still use the correct hashing function as both map types
      use the same, this bug will at least cause us to resize the map twice in
      a row.
      
      Fix the issue by introducing a new function `index_map_resize` that
      handles case-sensitivity, similar to how `index_map_set` and
      `index_map_delete`. Convert all call sites where we were previously
      resizing the map to use that new function.
      Patrick Steinhardt committed
    • index: replace map macros with inline functions · ab45887f
      Traditionally, our maps were mostly implemented via macros that had
      weird call semantics. This shows in our index code, where we have macros
      that insert into an index map case-sensitively or insensitively, as they
      still return error codes via an error parameter. This is unwieldy and,
      most importantly, not necessary anymore, due to the introduction of our
      high-level map API and removal of macros.
      
      Replace them with inlined functions to make code easier to read.
      Patrick Steinhardt committed
  13. 18 Jul, 2019 1 commit
  14. 24 Jun, 2019 1 commit
  15. 15 Jun, 2019 2 commits
  16. 15 Feb, 2019 4 commits
    • idxmap: have `resize` functions return proper error code · 8da93944
      The currently existing function `git_idxmap_resize` and
      `git_idxmap_icase_resize` do not return any error codes at all due to their
      previous implementation making use of a macro. Due to that, it is impossible to
      see whether the resize operation might have failed due to an out-of-memory
      situation.
      
      Fix this by providing a proper error code. Adjust callers to make use of it.
      Patrick Steinhardt committed
    • idxmap: introduce high-level setter for key/value pairs · 661fc57b
      Currently, one would use the function `git_idxmap_insert` to insert key/value
      pairs into a map. This function has historically been a macro, which is why its
      syntax is kind of weird: instead of returning an error code directly, it instead
      has to be passed a pointer to where the return value shall be stored. This does
      not match libgit2's common idiom of directly returning error codes.
      
      Introduce a new function `git_idxmap_set`, which takes as parameters the map,
      key and value and directly returns an error code. Convert all callers of
      `git_idxmap_insert` to make use of it.
      Patrick Steinhardt committed
    • idxmap: introduce high-level getter for values · d00c24a9
      The current way of looking up an entry from a map is tightly coupled with the
      map implementation, as one first has to look up the index of the key and then
      retrieve the associated value by using the index. As a caller, you usually do
      not care about any indices at all, though, so this is more complicated than
      really necessary. Furthermore, it invites for errors to happen if the correct
      error checking sequence is not being followed.
      
      Introduce new high-level functions `git_idxmap_get` and `git_idxmap_icase_get`
      that take a map and a key and return a pointer to the associated value if such a
      key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can
      trivially be converted.
      Patrick Steinhardt committed
    • maps: use uniform lifecycle management functions · 351eeff3
      Currently, the lifecycle functions for maps (allocation, deallocation, resize)
      are not named in a uniform way and do not have a uniform function signature.
      Rename the functions to fix that, and stick to libgit2's naming scheme of saying
      `git_foo_new`. This results in the following new interface for allocation:
      
      - `int git_<t>map_new(git_<t>map **out)` to allocate a new map, returning an
        error code if we ran out of memory
      
      - `void git_<t>map_free(git_<t>map *map)` to free a map
      
      - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map
      
      This commit also fixes all existing callers.
      Patrick Steinhardt committed
  17. 25 Jan, 2019 1 commit
  18. 24 Jan, 2019 1 commit
    • index: preserve extension parsing errors · 0bf7e043
      Previously, we would clobber any extension-specific error message with
      an "extension is truncated" message. This makes `read_extension`
      correctly preserve those errors, takes responsibility for truncation
      errors, and adds a new message with the actual extension signature for
      unsupported mandatory extensions.
      Etienne Samson committed
  19. 22 Jan, 2019 1 commit
  20. 01 Dec, 2018 1 commit
  21. 28 Nov, 2018 1 commit
  22. 14 Nov, 2018 1 commit
  23. 19 Oct, 2018 2 commits
    • index: fix adding index entries with conflicting files · 8b6e2895
      When adding an index entry "a/b/c" while an index entry "a/b" already
      exists, git will happily remove "a/b/c" and only add the new index
      entry:
      
          $ git init test
          Initialized empty Git repository in /tmp/test.repo/test/.git/
          $ touch x
          $ git add x
          $ rm x
          $ mkdir x
          $ touch x/y
          $ git add x/y
          $ git status
          A x/y
      
      The other way round, adding an index entry "a/b" with an entry "a/b/c"
      already existing is equivalent, where git will remove "a/b/c" and add
      "a/b".
      
      In contrast, libgit2 will currently fail to add these properly and
      instead complain about the entry appearing as both a file and a
      directory. This is a programming error, though: our current code already
      tries to detect and, in the case of `git_index_add`, to automatically
      replace such index entries. Funnily enough, we already remove the
      conflicting index entries, but instead of adding the new entry we then
      bail out afterwards. This leaves callers with the worst of both worlds:
      we both remove the old entry but fail to add the new one.
      
      The root cause is weird semantics of the `has_file_name` and
      `has_dir_name` functions. While these functions only sound like they are
      responsible for detecting such conflicts, they will also already remove
      them in case where its `ok_to_replace` parameter is set. But even if we
      tell it to replace such entries, it will return an error code.
      
      Fix the error by returning success in case where the entries have been
      replaced. Fix an already existing test which tested for wrong behaviour.
      Note that the test didn't notice that the resulting tree had no entries.
      Thus it is fine to change existing behaviour here, as the previous
      result could've let to silently loosing data. Also add a new test that
      verifies behaviour in the reverse conflicting case.
      Patrick Steinhardt committed
    • index: modernize error handling of `index_insert` · 923317db
      The current error hanling of the function `index_insert` is currently
      very fragile. Instead of erroring out in case an error has happened, it
      will instead verify that no error has happened for each statement. This
      makes adding new code to that function an adventurous task.
      
      Improve the situation by converting the function to use our typical
      `goto out` pattern.
      Patrick Steinhardt committed
  24. 18 Oct, 2018 1 commit
    • index: avoid out-of-bounds read when reading reuc entry stage · 600ceadd
      We use `git__strtol64` to parse file modes of the index entries, which
      does not limit the parsed buffer length. As the index can be essentially
      treated as "untrusted" in that the data stems from the file system, it
      may be misformatted and may not contain terminating `NUL` bytes. This
      may lead to out-of-bounds reads when trying to parse index entries with
      such malformatted modes.
      
      Fix the issue by using `git__strntol64` instead.
      Patrick Steinhardt committed
  25. 11 Sep, 2018 1 commit
  26. 16 Aug, 2018 1 commit
  27. 29 Jun, 2018 4 commits
    • settings: optional unsaved index safety · bfa1f022
      Add the `GIT_OPT_ENABLE_UNSAVED_INDEX_SAFETY` option, which will cause
      commands that reload the on-disk index to fail if the current
      `git_index` has changed that have not been saved.  This will prevent
      users from - for example - adding a file to the index then calling a
      function like `git_checkout` and having that file be silently removed
      from the index since it was re-read from disk.
      
      Now calls that would re-read the index will fail if the index is
      "dirty", meaning changes have been made to it but have not been written.
      Users can either `git_index_read` to discard those changes explicitly,
      or `git_index_write` to write them.
      Edward Thomson committed
    • index: return a unique error code on dirty index · 787768c2
      When the index is dirty, return GIT_EINDEXDIRTY so that consumers can
      identify the exact problem programatically.
      Edward Thomson committed
    • index: commit the changes to the index properly · b242cdbf
      Now that the index has a "dirty" state, where it has changes that have
      not yet been committed or rolled back, our tests need to be adapted to
      actually commit or rollback the changes instead of assuming that the
      index can be operated on in its indeterminate state.
      Edward Thomson committed
    • index: add a dirty bit reflecting unsaved changes · 7c56c49b
      Teach the index when it is "dirty", and has unsaved changes.  Consider
      the index dirty whenever a caller has added or removed an entry from the
      main index, REUC or NAME section, including when the index is completely
      cleared.  Similarly, consider the index _not_ dirty immediately after it
      is written, or when it is read from the on-disk index.
      
      This allows us to ensure that unsaved changes are not lost when we
      automatically refresh the index.
      Edward Thomson committed
  28. 10 Jun, 2018 1 commit
  29. 01 Jun, 2018 1 commit
  30. 23 May, 2018 1 commit