1. 18 Oct, 2019 2 commits
    • refdb_fs: properly parse corrupted reflogs · 7968e90f
      In previous versions, libgit2 could be coerced into writing reflog
      messages with embedded newlines into the reflog by using
      `git_stash_save` with a message containing newlines. While the root
      cause is fixed now, it was noticed that upstream git is in fact able to
      read such corrupted reflog messages just fine.
      
      Make the reflog parser more lenient in order to just skip over
      malformatted reflog lines to bring us in line with git. This requires us
      to change an existing test that verified that we do indeed _fail_ to
      parse such logs.
      Patrick Steinhardt committed
    • reflog: allow adding entries with newlines in their message · d8233feb
      Currently, the reflog disallows any entries that have a message with
      newlines, as that would effectively break the reflog format, which may
      contain a single line per entry, only. Upstream git behaves a bit
      differently, though, especially when considering stashes: instead of
      rejecting any reflog entry with newlines, git will simply replace
      newlines with spaces. E.g. executing 'git stash push -m "foo\nbar"' will
      create a reflog entry with "foo bar" as entry message.
      
      This commit adjusts our own logic to stop rejecting commit messages with
      newlines. Previously, this logic was part of `git_reflog_append`, only.
      There is a second place though where we add reflog entries, which is the
      serialization code in the filesystem refdb. As it didn't contain any
      sanity checks whatsoever, the refdb would have been perfectly happy to
      write malformatted reflog entries to the disk. This is being fixed with
      the same logic as for the reflog itself.
      Patrick Steinhardt committed
  2. 17 Oct, 2019 1 commit
    • refs: unlock unmodified refs on transaction commit · 47531f47
      Refs which are locked in a transaction without an altered target,
      still should to be unlocked on `git_transaction_commit`.
      `git_transaction_free` also unlocks refs but the moment of calling of `git_transaction_free`
      cannot be controlled in all situations.
      Some binding libs call `git_transaction_free` on garbage collection or not at all if the
      application exits before and don't provide public access to `git_transaction_free`.
      It is better to release locks as soon as possible.
      Sebastian Henke committed
  3. 10 Oct, 2019 1 commit
    • refs: fix locks getting forcibly removed · 3335a034
      The flag GIT_FILEBUF_FORCE currently does two things:
           1. It will cause the filebuf to create non-existing leading
              directories for the file that is about to be written.
           2. It will forcibly remove any pre-existing locks.
      While most call sites actually do want (1), they do not want to
      remove pre-existing locks, as that renders the locking mechanisms
      effectively useless.
      Introduce a new flag `GIT_FILEBUF_CREATE_LEADING_DIRS` to
      separate both behaviours cleanly from each other and convert
      callers to use it instead of `GIT_FILEBUF_FORCE` to have them
      honor locked files correctly.
      
      As this conversion removes all current users of `GIT_FILEBUF_FORCE`,
      this commit removes the flag altogether.
      Sebastian Henke committed
  4. 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
  5. 20 Jul, 2019 1 commit
  6. 26 Apr, 2019 1 commit
    • refs: loosen restriction on wildcard "*" refspecs · 51214b85
      In commit cd377f45c9 (refs: loosen restriction on wildcard "*"
      refspecs, 2015-07-22) in git.git, the restrictions on wildcard
      "*" refspecs has been loosened. While wildcards were previously
      only allowed if the component is a single "*", this was changed
      to also accept other patterns as part of the component.
      
      We never adapted to that change and still reject any wildcard
      patterns that aren't a single "*" only. Update our tests to
      reflect the upstream change and adjust our own code accordingly.
      Patrick Steinhardt committed
  7. 22 Feb, 2019 1 commit
  8. 14 Feb, 2019 3 commits
    • branch: fix `branch_is_checked_out` with bare repos · bf013fc0
      In a bare repository, HEAD usually points to the branch that is
      considered the "default" branch. As the current implementation for
      `git_branch_is_checked_out` only does a comparison of HEAD with the
      branch that is to be checked, it will say that the branch pointed to by
      HEAD in such a bare repo is checked out.
      
      Fix this by skipping the main repo's HEAD when it is bare.
      Patrick Steinhardt committed
    • branches: do not assert that the given ref is a branch · 788cd2d5
      Libraries should use assert(3P) only very scarcely. First, we usually
      shouldn't cause the caller of our library to abort in case where the
      assert fails. Second, if code is compiled with -DNDEBUG, then the assert
      will not be included at all.
      
      In our `git_branch_is_checked_out` function, we have an assert that
      verifies that the given reference parameter is non-NULL and in fact a
      branch. While the first check is fine, the second is not. E.g. when
      compiled with -DNDEBUG, we'd proceed and treat the given reference as a
      branch in all cases.
      
      Fix the issue by instead treating a non-branch reference as not being
      checked out. This is the obvious solution, as references other than
      branches cannot be directly checked out.
      Patrick Steinhardt committed
    • branches: add tests for `git_branch_is_checked_out` · a0f87e16
      We currently do not have any tests at all for the
      `git_branch_is_checked_out` function. Add some basic ones.
      Patrick Steinhardt committed
  9. 22 Jan, 2019 1 commit
  10. 17 Jan, 2019 1 commit
  11. 01 Dec, 2018 1 commit
  12. 18 Nov, 2018 1 commit
  13. 13 Oct, 2018 1 commit
  14. 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
  15. 10 Jun, 2018 1 commit
  16. 01 Jun, 2018 1 commit
  17. 04 May, 2018 1 commit
  18. 10 Apr, 2018 1 commit
  19. 24 Feb, 2018 1 commit
  20. 12 Jan, 2018 1 commit
  21. 30 Dec, 2017 1 commit
  22. 22 Nov, 2017 1 commit
  23. 14 Nov, 2017 4 commits
  24. 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
  25. 23 Jun, 2017 1 commit
  26. 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
  27. 05 May, 2017 1 commit
  28. 06 Mar, 2017 1 commit
  29. 02 Mar, 2017 1 commit
  30. 01 Mar, 2017 1 commit
  31. 28 Feb, 2017 4 commits