1. 05 May, 2017 2 commits
    • worktree: switch over worktree pruning to an opts structure · 883eeb5f
      The current signature of `git_worktree_prune` accepts a flags field to
      alter its behavior. This is not as flexible as we'd like it to be when
      we want to enable passing additional options in the future. As the
      function has not been part of any release yet, we are still free to
      alter its current signature. This commit does so by using our usual
      pattern of an options structure, which is easily extendable without
      breaking the API.
      Patrick Steinhardt committed
    • worktree: support creating locked worktrees · 8264a30f
      When creating a new worktree, we do have a potential race with us
      creating the worktree and another process trying to delete the same
      worktree as it is being created. As such, the upstream git project has
      introduced a flag `git worktree add --locked`, which will cause the
      newly created worktree to be locked immediately after its creation. This
      mitigates the race condition.
      
      We want to be able to mirror the same behavior. As such, a new flag
      `locked` is added to the options structure of `git_worktree_add` which
      allows the user to enable this behavior.
      Patrick Steinhardt committed
  2. 02 May, 2017 1 commit
    • worktree: introduce git_worktree_add options · a7aa73a5
      The `git_worktree_add` function currently accepts only a path and name
      for the new work tree. As we may want to expand these parameters in
      future versions without adding additional parameters to the function for
      every option, this commit introduces our typical pattern of an options
      struct. Right now, this structure is still empty, which will change with
      the next commit.
      Patrick Steinhardt committed
  3. 28 Apr, 2017 1 commit
  4. 26 Apr, 2017 5 commits
  5. 25 Apr, 2017 3 commits
  6. 21 Apr, 2017 3 commits
  7. 17 Apr, 2017 2 commits
  8. 12 Apr, 2017 2 commits
  9. 11 Apr, 2017 4 commits
  10. 10 Apr, 2017 2 commits
    • openssl_stream: use new initialization function on OpenSSL version >=1.1 · 88520151
      Previous to OpenSSL version 1.1, the user had to initialize at least the error
      strings as well as the SSL algorithms by himself. OpenSSL version 1.1 instead
      provides a new function `OPENSSL_init_ssl`, which handles initialization of all
      subsystems. As the new API call will by default load error strings and
      initialize the SSL algorithms, we can safely replace these calls when compiling
      against version 1.1 or later.
      
      This fixes a compiler error when compiling against OpenSSL version 1.1 which has
      been built without stubs for deprecated syntax.
      Patrick Steinhardt committed
    • openssl_stream: remove locking initialization on OpenSSL version >=1.1 · 29081c2f
      Up to version 1.0, OpenSSL required us to provide a callback which implements
      a locking mechanism. Due to problems in the API design though this mechanism was
      inherently broken, especially regarding that the locking callback cannot report
      errors in an obvious way. Due to this shortcoming, the locking initialization
      has been completely removed in OpenSSL version 1.1. As the library has also been
      refactored to not make any use of these callback functions, we can safely remove
      all initialization of the locking subsystem if compiling against OpenSSL version
      1.1 or higher.
      
      This fixes a compilation error when compiling against OpenSSL version 1.1 which
      has been built without stubs for deprecated syntax.
      Patrick Steinhardt committed
  11. 07 Apr, 2017 3 commits
    • filter: only close filter if it's been initialized correctly · cf07db2f
      In the function `git_filter_list_stream_data`, we initialize, write and
      subesquently close the stream which should receive content processed by
      the filter. While we skip writing to the stream if its initialization
      failed, we still try to close it unconditionally -- even if the
      initialization failed, where the stream might not be set at all, leading
      us to segfault.
      
      Semantics in this code is not really clear. The function handling the
      same logic for files instead of data seems to do the right thing here in
      only closing the stream when initialization succeeded. When stepping
      back a bit, this is only reasonable: if a stream cannot be initialized,
      the caller would not expect it to be closed again. So actually, both
      callers of `stream_list_init` fail to do so. The data streaming function
      will always close the stream and the file streaming function will not
      close the stream if writing to it has failed.
      
      The fix is thus two-fold:
      
      - callers of `stream_list_init` now close the stream iff it has been
        initialized
      - `stream_list_init` now closes the lastly initialized stream if
        the current stream in the chain failed to initialize
      
      Add a test which segfaulted previous to these changes.
      Patrick Steinhardt committed
    • Merge pull request #4193 from pks-t/pks/libdir · 44998cdb
      pkgconfig: fix handling of prefixes containing whitespaces
      Edward Thomson committed
  12. 05 Apr, 2017 11 commits
  13. 04 Apr, 2017 1 commit
    • fileops: do not overwrite correct error message on mmap · 9daba9f4
      When executing `git_futils_mmap_ro_file`, we first try to guess whether
      the file is mmapable at all. Part of this check is whether the file is
      too large to be mmaped, which can be true on systems with 32 bit
      `size_t` types.
      
      The check is performed by first getting the file size wtih
      `git_futils_filesize` and then checking whether the returned size can be
      represented as `size_t`, returning an error if so. While this test also
      catches the case where the function returned an error (as `-1` is not
      representable by `size_t`), we will set the misleading error message
      "file too large to mmap". But in fact, a negative return value from
      `git_futils_filesize` will be caused by the inability to fstat the file.
      
      Fix the error message by handling negative return values separately and
      not overwriting the error message in that case.
      Patrick Steinhardt committed