1. 22 Feb, 2019 2 commits
  2. 21 Feb, 2019 12 commits
  3. 20 Feb, 2019 4 commits
  4. 17 Feb, 2019 8 commits
  5. 16 Feb, 2019 1 commit
  6. 15 Feb, 2019 11 commits
    • examples: create common lg2 executable · ead10785
      Inside of our networking example code, we have a git2 executable
      that acts as an entry point to all the different network
      examples. As such, it is kind of the same like the normal git(1)
      executable in that it simply arbitrates to the respective
      subcommands.
      
      Let's extend this approach and merge all examples into a single
      standalone lg2 executable. Instead of building an executable
      for all the existing examples we have, we now bundle them all
      inside of the lg2 one and let them be callable via subcommands.
      
      In the process, we can get rid of duplicated library
      initialization, deinitialization and repository discovery code.
      Instead of having each subcommand handle these on its own, we
      simply do it inside of the single main function now.
      Patrick Steinhardt committed
    • examples: merge common network code · 7562422a
      Right now, we have two sets of "common" code, one containing
      general common code and one containing network common code. As we
      intend to get rid of the network subdirectory and instead merge
      all examples into a single standalone executable, this
      distinction doesn't make a lot of sense now. Furthermore, the
      common network code is not that big.
      
      Let's get rid of the common network code by merging it into the
      general common code.
      Patrick Steinhardt committed
    • examples: remove unused Makefile · c4271314
      This Makefile isn't used anymore and probably won't work anyway.
      Remove it in favor of the existing CMake build instructions.
      Patrick Steinhardt committed
    • examples: remove test script · a540e6bb
      In commit 2e233285 (examples: a test, for rev-list, 2013-03-20),
      a script was introduced with the intention of testing our
      rev-list example code. Nobody uses that script, and in fact it
      doesn't even properly work due to the not-so-recent addition
      out-of-source builds.
      
      Remove the script.
      Patrick Steinhardt committed
    • 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
  7. 14 Feb, 2019 2 commits