1. 23 Feb, 2022 1 commit
  2. 08 Feb, 2022 1 commit
  3. 07 Feb, 2022 1 commit
    • push: Prepare pack before sending pack header. · 19ec5923
      For large pushes, preparing the pack can take a while. Currently we
      send the pack header first, followed by preparing the pack and then
      finally sending the pack. Unfortunately github.com will terminate
      a git-receive-pack command over http if it is idle for more than 10
      seconds. This is easily exceeded for a large push, and so the push is
      rejected with a Broken Pipe error.
      
      This patch moves the pack preparation ahead of sending the pack header,
      so that the timeout is avoided.
      
      prepare_pack() can be called multiple times but will only do the work
      once, so the original PREPARE_PACK call inside git_packbuilder_foreach()
      remains.
      Colin Stolley committed
  4. 06 Feb, 2022 1 commit
  5. 30 Jan, 2022 1 commit
  6. 06 Jan, 2022 1 commit
    • remote: introduce `git_remote_connect_options` · 6fc6eeb6
      The existing mechanism for providing options to remote fetch/push calls,
      and subsequently to transports, is unsatisfactory.  It requires an
      options structure to avoid breaking the API and callback signatures.
      
      1. Introduce `git_remote_connect_options` to satisfy those needs.
      
      2. Add a new remote connection API, `git_remote_connect_ext` that will
         take this new options structure.  Existing `git_remote_connect` calls
         will proxy to that.  `git_remote_fetch` and `git_remote_push` will
         proxy their fetch/push options to that as well.
      
      3. Define the interaction between `git_remote_connect` and fetch/push.
         Connect _may_ be called before fetch/push, but _need not_ be.  The
         semantics of which options would be used for these operations was
         not specified if you specify options for both connect _and_ fetch.
         Now these are defined that the fetch or push options will be used
         _if_ they were specified.  Otherwise, the connect options will be
         used if they were specified.  Otherwise, the library's defaults will
         be used.
      
      4. Update the transports to understand `git_remote_connect_options`.
         This is a breaking change to the systems API.
      Edward Thomson committed
  7. 05 Jan, 2022 1 commit
  8. 17 Oct, 2021 1 commit
    • str: introduce `git_str` for internal, `git_buf` is external · f0e693b1
      libgit2 has two distinct requirements that were previously solved by
      `git_buf`.  We require:
      
      1. A general purpose string class that provides a number of utility APIs
         for manipulating data (eg, concatenating, truncating, etc).
      2. A structure that we can use to return strings to callers that they
         can take ownership of.
      
      By using a single class (`git_buf`) for both of these purposes, we have
      confused the API to the point that refactorings are difficult and
      reasoning about correctness is also difficult.
      
      Move the utility class `git_buf` to be called `git_str`: this represents
      its general purpose, as an internal string buffer class.  The name also
      is an homage to Junio Hamano ("gitstr").
      
      The public API remains `git_buf`, and has a much smaller footprint.  It
      is generally only used as an "out" param with strict requirements that
      follow the documentation.  (Exceptions exist for some legacy APIs to
      avoid breaking callers unnecessarily.)
      
      Utility functions exist to convert a user-specified `git_buf` to a
      `git_str` so that we can call internal functions, then converting it
      back again.
      Edward Thomson committed
  9. 15 Jul, 2021 1 commit
  10. 06 Dec, 2020 1 commit
  11. 27 Nov, 2020 1 commit
  12. 24 Jan, 2020 1 commit
  13. 23 Aug, 2019 1 commit
  14. 21 Aug, 2019 1 commit
    • smart: use push_glob instead of manual filtering · 39d18fe6
      The code worked under the assumption that anything under `refs/tags` are
      tag objects, and all the rest would be peelable to a commit. As it is
      completely valid to have tags to blobs under a non `refs/tags` ref, this
      would cause failures when trying to peel a tag to a commit.
      
      Fix the broken filtering by switching to `git_revwalk_push_glob`, which
      already handles this case.
      Etienne Samson committed
  15. 24 Jun, 2019 1 commit
  16. 15 Jun, 2019 1 commit
  17. 22 Feb, 2019 2 commits
  18. 22 Jan, 2019 1 commit
  19. 17 Jan, 2019 1 commit
  20. 03 Oct, 2018 1 commit
  21. 06 Jul, 2018 1 commit
  22. 29 Jun, 2018 2 commits
  23. 26 Jun, 2018 1 commit
  24. 25 Jun, 2018 3 commits
  25. 24 Jun, 2018 1 commit
  26. 10 Jun, 2018 1 commit
  27. 11 Apr, 2018 4 commits
  28. 09 Oct, 2017 1 commit
    • transports: smart: fix memory leak when skipping symbolic refs · 7cb705cb
      When we setup the revision walk for negotiating references with a
      remote, we iterate over all references, ignoring tags and symbolic
      references. While skipping over symbolic references, we forget to free
      the looked up reference, resulting in a memory leak when the next
      iteration simply overwrites the variable.
      
      Fix that issue by freeing the reference at the beginning of each
      iteration and collapsing return paths for error and success.
      Patrick Steinhardt committed
  29. 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
  30. 10 Jun, 2017 1 commit
  31. 10 Feb, 2017 1 commit
  32. 06 Jan, 2017 1 commit
    • smart_pkt: treat empty packet lines as error · 2fdef641
      The Git protocol does not specify what should happen in the case
      of an empty packet line (that is a packet line "0004"). We
      currently indicate success, but do not return a packet in the
      case where we hit an empty line. The smart protocol was not
      prepared to handle such packets in all cases, though, resulting
      in a `NULL` pointer dereference.
      
      Fix the issue by returning an error instead. As such kind of
      packets is not even specified by upstream, this is the right
      thing to do.
      Patrick Steinhardt committed
  33. 29 Dec, 2016 1 commit