1. 22 Jan, 2019 1 commit
  2. 17 Jan, 2019 1 commit
  3. 01 Dec, 2018 1 commit
  4. 18 Nov, 2018 1 commit
  5. 13 Oct, 2018 1 commit
  6. 13 Jul, 2018 1 commit
    • treewide: remove use of C++ style comments · 9994cd3f
      C++ style comment ("//") are not specified by the ISO C90 standard and
      thus do not conform to it. While libgit2 aims to conform to C90, we did
      not enforce it until now, which is why quite a lot of these
      non-conforming comments have snuck into our codebase. Do a tree-wide
      conversion of all C++ style comments to the supported C style comments
      to allow us enforcing strict C90 compliance in a later commit.
      Patrick Steinhardt committed
  7. 10 Jun, 2018 1 commit
  8. 01 Jun, 2018 1 commit
  9. 04 May, 2018 1 commit
  10. 10 Apr, 2018 1 commit
  11. 24 Feb, 2018 1 commit
  12. 12 Jan, 2018 1 commit
  13. 30 Dec, 2017 1 commit
  14. 22 Nov, 2017 1 commit
  15. 14 Nov, 2017 4 commits
  16. 06 Oct, 2017 1 commit
    • refs: do not use peeled OID if peeling to a tag · b112b1e9
      If a reference stored in a packed-refs file does not directly point to a
      commit, tree or blob, the packed-refs file will also will include a
      fully-peeled OID pointing to the first underlying object of that type.
      If we try to peel a reference to an object, we will use that peeled OID
      to speed up resolving the object.
      
      As a reference for an annotated tag does not directly point to a commit,
      tree or blob but instead to the tag object, the packed-refs file will
      have an accomodating fully-peeled OID pointing to the object referenced
      by that tag. When we use the fully-peeled OID pointing to the referenced
      object when peeling, we obviously cannot peel that to the tag anymore.
      
      Fix this issue by not using the fully-peeled OID whenever we want to
      peel to a tag. Note that this does not include the case where we want to
      resolve to _any_ object type. Existing code may make use from the fact
      that we resolve those to commit objects instead of tag objects, even
      though that behaviour is inconsistent between packed and loose
      references. Furthermore, some tests of ours make the assumption that we
      in fact resolve those references to a commit.
      Patrick Steinhardt committed
  17. 23 Jun, 2017 1 commit
  18. 08 Jun, 2017 1 commit
    • settings: rename `GIT_OPT_ENABLE_SYNCHRONOUS_OBJECT_CREATION` · 6c23704d
      Initially, the setting has been solely used to enable the use of
      `fsync()` when creating objects. Since then, the use has been extended
      to also cover references and index files. As the option is not yet part
      of any release, we can still correct this by renaming the option to
      something more sensible, indicating not only correlation to objects.
      
      This commit renames the option to `GIT_OPT_ENABLE_FSYNC_GITDIR`. We also
      move the variable from the object to repository source code.
      Patrick Steinhardt committed
  19. 05 May, 2017 1 commit
  20. 06 Mar, 2017 1 commit
  21. 02 Mar, 2017 1 commit
  22. 01 Mar, 2017 1 commit
  23. 28 Feb, 2017 6 commits
  24. 25 Feb, 2017 2 commits
  25. 13 Feb, 2017 2 commits
  26. 29 Dec, 2016 1 commit
  27. 04 Nov, 2016 1 commit
    • branch: fix forced branch creation on HEAD of a bare repo · f9793884
      The code correctly detects that forced creation of a branch on a
      nonbare repo should not be able to overwrite a branch which is
      the HEAD reference.  But there's no reason to prevent this on
      a bare repo, and in fact, git allows this.  I.e.,
      
         git branch -f master new_sha
      
      works on a bare repo with HEAD set to master.  This change fixes
      that problem, and updates tests so that, for this case, both the
      bare and nonbare cases are checked for correct behavior.
      John Fultz committed
  28. 22 Apr, 2016 1 commit
  29. 11 Apr, 2016 2 commits