1. 15 Jun, 2019 2 commits
    • global: convert trivial `fnmatch` users to use `wildcard` · de70bb46
      Upstream git.git has converted its codebase to use wildcard in
      favor of fnmatch in commit 70a8fc999d (stop using fnmatch (either
      native or compat), 2014-02-15). To keep our own regex-matching in
      line with what git does, convert all trivial instances of
      `fnmatch` usage to use `wildcard`, instead. Trivial usage is
      defined to be use of `fnmatch` with either no flags or flags that
      have a 1:1 equivalent in wildmatch (PATHNAME, IGNORECASE).
      Patrick Steinhardt committed
    • posix: remove implicit include of "fnmatch.h" · 451df793
      We're about to phase out our bundled fnmatch implementation as
      git.git has moved to wildmatch long ago in 2014. To make it
      easier to spot which files are stilll using fnmatch, remove the
      implicit "fnmatch.h" include in "posix.h" and instead include it
      explicitly.
      Patrick Steinhardt committed
  2. 16 Apr, 2019 1 commit
  3. 15 Feb, 2019 5 commits
    • refdb_fs: fix race when migrating loose to packed refs in iteration · 94743daf
      Right now, we first load the packed refs cache and only afterwards load the
      loose references. This is susceptible to a race when the loose ref is being
      migrated to a packed cache by e.g. git-pack-refs(1):
      
                      libgit2                             git-pack-refs
      
         1. We load the packed ref, which
            does not yet have the migrated
            reference.
      
                                            2. git-pack-refs updates the packed ref
                                               file to have the migrated ref.
      
                                            3. git-pack-refs deletes the old loose
                                               ref.
      
         4. We look up the loose ref.
      
      So we now do not find the reference at all and will never iterate over it.
      
      Fix the issue by reversing the order: instead of first loading the packed refs,
      we will now look up the loose reference first. If it has already been deleted,
      then it must already be present in the packed-refs by definition, as git.git
      will only delete the reference after updating the packed refs file.
      Patrick Steinhardt committed
    • refdb_fs: remove ordering dependency on loose/packed refs loading · 3ff0e3b5
      Right now, loading loose refs has the side-effect of setting the
      `PACKREF_SHADOWED` flag for references that exist both in the loose and the
      packed refs. Because of this, we are force do first look up packed refs and only
      afterwards loading the packed refs. This is susceptible to a race, though, when
      refs are being repacked: when first loading the packed cache, then it may not
      yet have the migrated loose ref. But when now trying to look up the loose
      reference afterwards, then it may already have been migrated. Thus, we would
      fail to find this reference in this scenario.
      
      Remove this ordering dependency to allow fixing the above race. Instead of
      setting the flag when loading loose refs, we will now instead set it lazily when
      iterating over the loose refs. This even has the added benefit of not requiring
      us to lock the packed refs cache, as we already have an owned copy of it.
      Patrick Steinhardt committed
    • refdb_fs: do not lazily copy packed ref cache · 83333814
      When creating a new iterator, we eagerly load loose refs but only lazily create
      a copy of packed refs. The lazy load only happens as soon as we have iterated
      over all loose refs, opening up a potentially wide window for races. This
      may lead to an inconsistent view e.g. when the caller decides to reload packed
      references somewhen between iterating the loose refs, which is unexpected.
      
      Fix the issue by eagerly copying the sorted cache. Note that right now, we are
      heavily dependent on ordering here: we first need to reload packed refs, then we
      have to load loose refs and only as a last step are we allowed to copy the
      cache. This is because loading loose refs has the side-effect of setting the
      `PACKED_SHADOWED` flag in the packed refs cache, which we require to avoid
      outputting packed refs that already exist as loose refs.
      Patrick Steinhardt committed
    • refdb_fs: refactor error handling in iterator creation · 32063d82
      Refactor the error handling in `refdb_fs_backend__iterator` to always return the
      correct error code returned by the failing function.
      Patrick Steinhardt committed
    • refdb_fs: fix potential race with ref repacking in `exists` callback · 8c773438
      When repacking references, git.git will first update the packed refs and only
      afterwards delete any existing loose references that have now been moved to the
      new packed refs file. Due to this, there is a potential for racing if one first
      reads the packfile (which has not been updated yet) and only then trying to read
      the loose reference (which has just been deleted). In this case, one will
      incorrectly fail to lookup the reference and it will be reported as missing.
      Naturally, this is exactly what we've been doing in `refdb_fs_backend__exists`.
      
      Fix the race by reversing the lookup: we will now first check if the loose
      reference exists and only afterwards refresh the packed file.
      Patrick Steinhardt committed
  4. 22 Jan, 2019 1 commit
  5. 17 Jan, 2019 1 commit
  6. 19 Dec, 2018 1 commit
    • refdb_fs: refactor error handling in `refdb_reflog_fs__delete` · 8dde7e11
      The function `refdb_reflog_fs__delete` uses the `if (!error && foobar())`
      pattern of checking, where error conditions are being checked by following calls
      to different code. This does not match our current style, where the call-site of
      a function is usually directly responsible for checking the return value.
      
      Convert the function to use `if ((error = foobar()) < 0) goto out;` style. Note
      that this changes the code flow a bit: previously, we were always trying to
      delete empty reference hierarchies even if deleting the reflog entry has failed.
      This wasn't much of a problem -- if deletion failed, the hierarchy will still
      contain at least one file and thus the function call was an expensive no-op.
      Now, we will only perform this deletion if we have successfully removed the
      reflog.
      Patrick Steinhardt committed
  7. 01 Dec, 2018 1 commit
  8. 18 Nov, 2018 1 commit
  9. 13 Oct, 2018 1 commit
  10. 10 Jun, 2018 1 commit
  11. 01 Jun, 2018 1 commit
    • refdb_fs: test whether the base directory exists when globbing · 05e891f1
      This commit fixes a regression introduced by
      
              20a2b02d
      
      The commit introduced an optimization for finding references using a
      glob: rather than iterating over all references and matching each one
      against the glob, we would iterate only over references within the
      directory common to all possible references which may match against the
      glob.
      
      However, contrary to the `ref/` directory, which was the previous entry
      point for the iteration, this directory may not exist. In this case, the
      optimization causes an error (`ENOENT`) rather than the iterator simply
      yielding no references.
      
      This patch fixes the regression by checkign for this specific case.
      Julian Ganz committed
  12. 23 May, 2018 1 commit
  13. 27 Apr, 2018 2 commits
  14. 20 Apr, 2018 1 commit
  15. 27 Mar, 2018 1 commit
  16. 30 Dec, 2017 1 commit
  17. 29 Dec, 2017 1 commit
  18. 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
  19. 08 Jun, 2017 2 commits
  20. 17 Mar, 2017 1 commit
    • refdb: create references in commondir · 097f0105
      References for a repository are usually created inside of its gitdir.
      When using worktrees, though, these references are not to be created
      inside the worktree gitdir, but instead inside the gitdir of its parent
      repository, which is the commondir. Like this, branches will still be
      available after the worktree itself has been deleted.
      
      The filesystem refdb currently still creates new references inside of
      the gitdir. Fix this and have it create references in commondir.
      Patrick Steinhardt committed
  21. 06 Mar, 2017 1 commit
  22. 02 Mar, 2017 1 commit
  23. 28 Feb, 2017 3 commits
  24. 17 Feb, 2017 1 commit
  25. 15 Feb, 2017 1 commit
    • refdb: catch additional per-worktree refs · 6da6b425
      The upstream git.git project currently identifies all references inside
      of `refs/bisect/` as well as `HEAD` as per-worktree references. This is
      already incorrect and is currently being fixed by an in-flight topic
      [1]. The new behavior will be to match all pseudo-references outside of
      the `refs/` hierarchy as well as `refs/bisect/`.
      
      Our current behavior is to mark a selection of pseudo-references as
      per-worktree, only. This matches more pseudo-references than current
      git, but forgets about `refs/bisect/`. Adjust behavior to match the
      in-flight topic, that is classify the following references as
      per-worktree:
      
      - everything outside of `refs/`
      - everything inside of `refs/bisect/`
      
      [1]: <20170213152011.12050-1-pclouds@gmail.com>
      Patrick Steinhardt committed
  26. 13 Feb, 2017 4 commits
    • repository: rename `path_repository` and `path_gitlink` · 84f56cb0
      The `path_repository` variable is actually confusing to think
      about, as it is not always clear what the repository actually is.
      It may either be the path to the folder containing worktree and
      .git directory, the path to .git itself, a worktree or something
      entirely different. Actually, the intent of the variable is to
      hold the path to the gitdir, which is either the .git directory
      or the bare repository.
      
      Rename the variable to `gitdir` to avoid confusion. While at it,
      also rename `path_gitlink` to `gitlink` to improve consistency.
      Patrick Steinhardt committed
    • refdb: introduce commondir awareness · e0a6c28e
      The refdb_fs_backend is not aware of the git commondir, which
      stores common objects like the o bject database and packed/loose
      refereensces when worktrees are used.
      
      Make refdb_fs_backend aware of the common directory by
      introducing a new commonpath variable that points to the actual
      common path of the database and using it instead of the gitdir
      for the mentioned objects.
      Patrick Steinhardt committed
    • refdb: rename refdb_fs_backend's .path to .gitpath · 71dd0861
      The variable '.path' of the refdb_fs_backend struct becomes
      confusing regarding the introduction of the git commondir. It
      does not immediatly become obvious what it should point to.
      
      Fix this problem by renaming the variable to `gitpath`,
      clarifying that it acutally points to the `.git` directory of the
      repository, in contrast to the commonpath directory, which points
      to the directory containing shared objects like references and
      the object store.
      Patrick Steinhardt committed
  27. 29 Dec, 2016 1 commit
  28. 16 Dec, 2016 1 commit