1. 25 Nov, 2019 1 commit
  2. 20 Jul, 2019 1 commit
  3. 15 Feb, 2019 4 commits
    • offmap: introduce high-level setter for key/value pairs · b9d0b664
      Currently, there is only one caller that adds entries into an offset map, and
      this caller first uses `git_offmap_put` to add a key and then set the value at
      the returned index by using `git_offmap_set_value_at`. This is just too tighlty
      coupled with implementation details of the map as it exposes the index of
      inserted entries, which we really do not care about at all.
      
      Introduce a new function `git_offmap_set`, which takes as parameters the map,
      key and value and directly returns an error code. Convert the caller to make use
      of it instead.
      Patrick Steinhardt committed
    • offmap: introduce high-level getter for values · aa245623
      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 a new high-level function `git_offmap_get` that takes a map and a key
      and returns 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
    • oidmap: introduce high-level getter for values · 9694ef20
      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 a new high-level function `git_oidmap_get` that takes a map and a key
      and returns 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
  4. 02 Feb, 2019 1 commit
  5. 22 Jan, 2019 1 commit
  6. 17 Jan, 2019 1 commit
  7. 01 Dec, 2018 1 commit
  8. 28 Nov, 2018 1 commit
  9. 10 Jun, 2018 2 commits
  10. 23 Dec, 2017 1 commit
    • Fix unpack double free · c3514b0b
      If an element has been cached, but then the call to
      packfile_unpack_compressed() fails, the very next thing that happens is
      that its data is freed and then the element is not removed from the
      cache, which frees the data again.
      
      This change sets obj->data to NULL to avoid the double-free. It also
      stops trying to resolve deltas after two continuous failed rounds of
      resolution, and adds a test for this.
      lhchavez committed
  11. 15 Dec, 2017 1 commit
  12. 09 Dec, 2017 1 commit
  13. 08 Dec, 2017 1 commit
    • libFuzzer: Prevent a potential shift overflow · 28662c13
      The type of |base_offset| in get_delta_base() is `git_off_t`, which is a
      signed `long`. That means that we need to make sure that the 8 most
      significant bits are zero (instead of 7) to avoid an overflow when it is
      shifted by 7 bits.
      
      Found using libFuzzer.
      lhchavez committed
  14. 09 Aug, 2017 1 commit
    • sha1_lookup: drop sha1_entry_pos function · 9842b327
      This was pulled over from git.git, and is an experiment in
      making binary-searching lists of sha1s faster. It was never
      compiled by default (nor was it used upstream by default
      without a special environment variable).
      
      Unfortunately, it is actually slower in practice, and
      upstream is planning to drop it in
      git/git@f1068efefe6dd3beaa89484db5e2db730b094e0b (which has
      some timing results). It's worth doing the same here for
      simplicity.
      Jeff King committed
  15. 03 Jul, 2017 1 commit
    • Make sure to always include "common.h" first · 0c7f49dd
      Next to including several files, our "common.h" header also declares
      various macros which are then used throughout the project. As such, we
      have to make sure to always include this file first in all
      implementation files. Otherwise, we might encounter problems or even
      silent behavioural differences due to macros or defines not being
      defined as they should be. So in fact, our header and implementation
      files should make sure to always include "common.h" first.
      
      This commit does so by establishing a common include pattern. Header
      files inside of "src" will now always include "common.h" as its first
      other file, separated by a newline from all the other includes to make
      it stand out as special. There are two cases for the implementation
      files. If they do have a matching header file, they will always include
      this one first, leading to "common.h" being transitively included as
      first file. If they do not have a matching header file, they instead
      include "common.h" as first file themselves.
      
      This fixes the outlined problems and will become our standard practice
      for header and source files inside of the "src/" from now on.
      Patrick Steinhardt committed
  16. 08 Jun, 2017 2 commits
    • buffer: use `git_buf_init` with length · a693b873
      The `git_buf_init` function has an optional length parameter, which will
      cause the buffer to be initialized and allocated in one step. This can
      be used instead of static initialization with `GIT_BUF_INIT` followed by
      a `git_buf_grow`. This patch does so for two functions where it is
      applicable.
      Patrick Steinhardt committed
    • buffer: rely on `GITERR_OOM` set by `git_buf_try_grow` · 97eb5ef0
      The function `git_buf_try_grow` consistently calls `giterr_set_oom`
      whenever growing the buffer fails due to insufficient memory being
      available. So in fact, we do not have to do this ourselves when a call
      to any buffer-growing function has failed due to an OOM situation. But
      we still do so in two functions, which this patch cleans up.
      Patrick Steinhardt committed
  17. 22 Feb, 2017 1 commit
    • pack: fix looping over cache entries · 685f2251
      Fixes a regression from #4092. This is a crash on 32-bit and I assume that
      it doesn't do the right thing on 64-bit either. MSVC emits a warning for this,
      but of course, it's easy to get lost among all of the similar 'possible loss
      of data' warnings.
      Jason Haslam committed
  18. 17 Feb, 2017 10 commits
  19. 21 Jan, 2017 1 commit
  20. 29 Dec, 2016 1 commit
  21. 12 Dec, 2016 2 commits
  22. 02 Nov, 2016 1 commit
    • pack: fix race in pack_entry_find_offset · 0cf15e39
      In `pack_entry_find_offset`, we try to find the offset of a
      certain object in the pack file. To do so, we first assert if the
      packfile has already been opened and open it if not. Opening the
      packfile is guarded with a mutex, so concurrent access to this is
      in fact safe.
      
      What is not thread-safe though is our calculation of offsets
      inside the packfile. Assume two threads calling
      `pack_entry_find_offset` at the same time. We first calculate the
      offset and index location and only then determine if the pack has
      already been opened. If so, we re-calculate the offset and index
      address.
      
      Now the case for two threads: thread 1 first calculates the
      addresses and is subsequently suspended. The second thread will
      now call `pack_index_open` and initialize the pack file,
      calculating its addresses correctly. When the first thread is
      resumed now, he'll see that the pack file has already been
      initialized and will happily proceed with the addresses it has
      already calculated before the check. As the pack file was not
      initialized before, these addresses are bogus.
      
      Fix the issue by only calculating the addresses after having
      checked if the pack file is open.
      Patrick Steinhardt committed
  23. 26 May, 2016 1 commit
  24. 02 May, 2016 1 commit
    • odb: avoid inflating the full delta to read the header · a97b769a
      When we read the header, we want to know the size and type of the
      object. We're currently inflating the full delta in order to read the
      first few bytes. This can mean hundreds of kB needlessly inflated for
      large objects.
      
      Instead use a packfile stream to read just enough so we can read the two
      varints in the header and avoid inflating most of the delta.
      Carlos Martín Nieto committed
  25. 07 Mar, 2016 1 commit