1. 09 Nov, 2021 1 commit
  2. 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
  3. 09 Sep, 2021 1 commit
  4. 15 Feb, 2021 1 commit
  5. 27 Nov, 2020 1 commit
  6. 25 Nov, 2020 1 commit
  7. 25 Oct, 2020 4 commits
  8. 18 Sep, 2020 1 commit
  9. 12 Jul, 2020 5 commits
    • refs: remove function to read HEAD directly · 5434f9a3
      With the last user of `git_reference__read_head` gone, let's remove it
      as it's been reading references without consulting the refdb backends.
      Patrick Steinhardt committed
    • refs: update HEAD references via refdb · 7216b048
      When renaming a reference, we need to iterate over every HEAD and
      potentially update it in case it is a symbolic reference pointing to the
      previous name of the renamed reference. Most importantly, this doesn't
      only include HEADs from the repo we're renaming the reference in, but we
      also need to iterate over HEADs from linked worktrees.
      
      In order to update the HEADs, we directly read them from the worktree's
      gitdir and thus assume that both repository and worktrees use the
      filesystem-based reference backend. But this breaks as soon as one got a
      repository with a different refdb and breaks our own abstractions. So
      let's instead update HEAD references via the refdb by first opening each
      worktree as a repository and then using the usual functions to read and
      update HEADs. This is a lot less efficient than the current code, but
      it's not like we can really help this: going via the refdb is mandatory.
      Patrick Steinhardt committed
    • refs: replace reimplementation of reference resolver · b895547c
      The refs code currently has a second implementation that resolves
      references in order to find any final symbolic reference pointing to a
      nonexistent target branch. As we've just extended `git_refdb_resolve` to
      also return such references, let's use that one instead in order to
      reduce code duplication.
      Patrick Steinhardt committed
    • refdb: return resolved symbolic refs pointing to nonexistent refs · cf7dd05b
      In some cases, resolving references requires us to also know about the
      final symbolic reference that's pointing to a nonexistent branch, e.g.
      in an empty repository where the main branch is yet unborn but HEAD
      already points to it. Right now, the resolving logic is thus split up
      into two, where one is the new refdb implementation and the second one
      is an ad-hoc implementation inside "refs.c".
      
      Let's extend `git_refdb_resolve` to also return such final dangling
      references pointing to nonexistent branches so we can deduplicate the
      resolving logic.
      Patrick Steinhardt committed
    • refs: move resolving of references into the refdb · c54f40e4
      Resolving of symbolic references is currently implemented inside the
      "refs" layer. As a result, it's hard to call this function from
      low-level parts that only have a refdb available, but no repository, as
      the "refs" layer always operates on the repository-level. So let's move
      the function into the generic "refdb" implementation to lift this
      restriction.
      Patrick Steinhardt committed
  10. 09 Jun, 2020 1 commit
  11. 15 Jan, 2020 1 commit
    • refs: refuse to delete HEAD · 852c83ee
      This requires adding a new symbolic ref to the testrepo fixture.
      Some of the existing tests attempt to delete HEAD, expecting a different failure. Introduce and use a non-HEAD symbolic ref instead.
      Adjust a few other tests as needed.
      
      Fixes #5357
      Josh Bleecher Snyder committed
  12. 13 Dec, 2019 1 commit
    • refs: rename git_reference__set_name to git_reference__realloc · 97b8491b
      As git_reference__name will reallocate storage to account for longer
      names (it's actually allocator-dependent), it will cause all existing
      pointers to the old object to become dangling, as they now point to
      freed memory.
      
      Fix the issue by renaming to a more descriptive name, and pass a pointer
      to the actual reference that can safely be invalidated if the realloc
      succeeds.
      Etienne Samson committed
  13. 20 Jul, 2019 1 commit
  14. 18 Jul, 2019 1 commit
  15. 15 Jun, 2019 1 commit
  16. 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
  17. 14 Feb, 2019 1 commit
  18. 22 Jan, 2019 1 commit
  19. 17 Jan, 2019 1 commit
  20. 04 Jan, 2019 1 commit
  21. 14 Dec, 2018 1 commit
    • refs: constify git_reference_peel · 5bd78c48
      We have no need to take a non-const reference. This does involve some other work
      to make sure we don't mix const and non-const variables, but by splitting what
      we want each variable to do we can also simplify the logic for when we do want
      to free a new reference we might have allocated.
      Carlos Martín Nieto committed
  22. 01 Dec, 2018 1 commit
  23. 19 Oct, 2018 1 commit
  24. 10 Jun, 2018 1 commit
  25. 10 Apr, 2018 1 commit
  26. 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
  27. 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
  28. 08 Jun, 2017 1 commit
  29. 01 May, 2017 1 commit
  30. 05 Apr, 2017 2 commits
    • refs: update worktree HEADs when renaming branches · 2a485dab
      Whenever we rename a branch, we update the repository's symbolic HEAD
      reference if it currently points to the branch that is to be renamed.
      But with the introduction of worktrees, we also have to iterate over all
      HEADs of linked worktrees to adjust them. Do so.
      Patrick Steinhardt committed
    • refs: implement function to read references from file · 5b65ac25
      Currently, we only provide functions to read references directly from a
      repository's reference store via e.g. `git_reference_lookup`. But in
      some cases, we may want to read files not connected to the current
      repository, e.g. when looking up HEAD of connected work trees. This
      commit implements `git_reference__read_head`, which will read out and
      allocate a reference at an arbitrary path.
      Patrick Steinhardt committed
  31. 27 Feb, 2017 1 commit
  32. 17 Feb, 2017 1 commit