1. 12 Oct, 2020 1 commit
  2. 28 Mar, 2020 1 commit
  3. 19 Feb, 2020 1 commit
  4. 10 Dec, 2019 1 commit
  5. 04 Dec, 2019 1 commit
    • changelog: add more newly-accepted urls · 611e5d28
      I encountered some problematic URLs,
      and was delighted to see that they were already fixed.
      I figured I may as well add them to the changelog.
      
      For the record, URLs with no path used to be rejected.
      That is arguably correct, but command line git accepts them.
      
      URLs with a path of / and a non-standard port
      used to have their port completely ignored!
      Josh Bleecher Snyder committed
  6. 13 Sep, 2019 1 commit
  7. 13 Aug, 2019 1 commit
  8. 14 Jun, 2019 1 commit
    • cmake: Modulize our TLS & hash detection · 94fc83b6
      The interactions between `USE_HTTPS` and `SHA1_BACKEND` have been
      streamlined. Previously we would have accepted not quite working
      configurations (like, `-DUSE_HTTPS=OFF -DSHA1_BACKEND=OpenSSL`) and, as
      the OpenSSL detection only ran with `USE_HTTPS`, the link would fail.
      
      The detection was moved to a new `USE_SHA1`, modeled after `USE_HTTPS`,
      which takes the values "CollisionDetection/Backend/Generic", to better
      match how the "hashing backend" is selected, the default (ON) being
      "CollisionDetection".
      
      Note that, as `SHA1_BACKEND` is still used internally, you might need to
      check what customization you're using it for.
      Etienne Samson committed
  9. 13 Jun, 2019 1 commit
    • http-parser: use our bundled http-parser by default · fb529a01
      Our bundled http-parser includes bugfixes, therefore we should prefer
      our http-parser until such time as we can identify that the system
      http-parser has these bugfixes (using a version check).
      
      Since these bugs are - at present - minor, retain the ability for users
      to force that they want to use the system http-parser anyway.  This does
      change the cmake specification so that people _must_ opt-in to the new
      behavior knowingly.
      Edward Thomson committed
  10. 31 Jan, 2019 1 commit
  11. 25 Jan, 2019 1 commit
  12. 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
  13. 17 Jan, 2019 6 commits
  14. 29 Jun, 2018 1 commit
  15. 30 May, 2018 1 commit
    • docs: reorganize documents · 68a3c0b1
      Our non-technical documents are currently floating around loosely in our
      project's root, making it harden than necessary to discover what one is
      searching for. We do have a "docs/" directory, though, which serves
      exactly that purpose of hosting documentation.
      
      Move our non-technical documentation into the "docs/" directory. Adjust
      all links to these documents.
      Patrick Steinhardt committed
  16. 29 May, 2018 1 commit
  17. 17 Apr, 2018 2 commits
  18. 26 Mar, 2018 1 commit
  19. 02 Mar, 2018 1 commit
  20. 20 Feb, 2018 2 commits
  21. 09 Feb, 2018 2 commits
  22. 21 Jan, 2018 1 commit
  23. 19 Nov, 2017 1 commit
  24. 04 Nov, 2017 1 commit
  25. 30 Oct, 2017 1 commit
  26. 30 Jul, 2017 1 commit
  27. 26 Jul, 2017 1 commit
  28. 14 Jun, 2017 1 commit
  29. 11 Jun, 2017 2 commits
  30. 09 Jun, 2017 1 commit
  31. 05 May, 2017 1 commit
    • remote: add function to create detached remotes · 4bc16c37
      Right now it is only possible to create remotes from a repository. While
      this is probably the most common use-case, there are commands which make
      sense even without a repository, e.g. the equivalence of `git
      ls-remote`. Add a new function `git_remote_create_detached`, which
      simply accepts a URL.
      Eric Myhre committed