1. 09 Oct, 2016 1 commit
    • commit: always initialize commit message · a719ef5e
      When parsing a commit, we will treat all bytes left after parsing
      the headers as the commit message. When no bytes are left, we
      leave the commit's message uninitialized. While uncommon to have
      a commit without message, this is the right behavior as Git
      unfortunately allows for empty commit messages.
      
      Given that this scenario is so uncommon, most programs acting on
      the commit message will never check if the message is actually
      set, which may lead to errors. To work around the error and not
      lay the burden of checking for empty commit messages to the
      developer, initialize the commit message with an empty string
      when no commit message is given.
      Patrick Steinhardt committed
  2. 07 Oct, 2016 1 commit
  3. 06 Oct, 2016 12 commits
  4. 14 Sep, 2016 1 commit
    • checkout: don't try to calculate oid for directories · 955c99c2
      When trying to determine if we can safely overwrite an existing workdir
      item, we may need to calculate the oid for the workdir item to determine
      if its identical to the old side (and eligible for removal).
      
      We previously did this regardless of the type of entry in the workdir;
      if it was a directory, we would open(2) it and then try to read(2).
      The read(2) of a directory fails on many platforms, so we would treat it
      as if it were unmodified and continue to perform the checkout.
      
      On FreeBSD, you _can_ read(2) a directory, so this pattern failed.  We
      would calculate an oid from the data read and determine that the
      directory was modified and would therefore generate a checkout conflict.
      
      This reliance on read(2) is silly (and was most likely accidentally
      giving us the behavior we wanted), we should be explicit about the
      directory test.
      Edward Thomson committed
  5. 13 Sep, 2016 1 commit
  6. 05 Sep, 2016 1 commit
  7. 02 Sep, 2016 2 commits
  8. 01 Sep, 2016 1 commit
    • patch_generate: only calculate binary diffs if requested · 4b34f687
      When generating diffs for binary files, we load and decompress
      the blobs in order to generate the actual diff, which can be very
      costly. While we cannot avoid this for the case when we are
      called with the `GIT_DIFF_SHOW_BINARY` flag, we do not have to
      load the blobs in the case where this flag is not set, as the
      caller is expected to have no interest in the actual content of
      binary files.
      
      Fix the issue by only generating a binary diff when the caller is
      actually interested in the diff. As libgit2 uses heuristics to
      determine that a blob contains binary data by inspecting its size
      without loading from the ODB, this saves us quite some time when
      diffing in a repository with binary files.
      Patrick Steinhardt committed
  9. 30 Aug, 2016 1 commit
  10. 24 Aug, 2016 1 commit
  11. 22 Aug, 2016 1 commit
  12. 17 Aug, 2016 2 commits
  13. 12 Aug, 2016 1 commit
    • ignore: allow unignoring basenames in subdirectories · fcb2c1c8
      The .gitignore file allows for patterns which unignore previous
      ignore patterns. When unignoring a previous pattern, there are
      basically three cases how this is matched when no globbing is
      used:
      
      1. when a previous file has been ignored, it can be unignored by
         using its exact name, e.g.
      
         foo/bar
         !foo/bar
      
      2. when a file in a subdirectory has been ignored, it can be
         unignored by using its basename, e.g.
      
         foo/bar
         !bar
      
      3. when all files with a basename are ignored, a specific file
         can be unignored again by specifying its path in a
         subdirectory, e.g.
      
         bar
         !foo/bar
      
      The first problem in libgit2 is that we did not correctly treat
      the second case. While we verified that the negative pattern
      matches the tail of the positive one, we did not verify if it
      only matches the basename of the positive pattern. So e.g. we
      would have also negated a pattern like
      
          foo/fruz_bar
          !bar
      
      Furthermore, we did not check for the third case, where a
      basename is being unignored in a certain subdirectory again.
      
      Both issues are fixed with this commit.
      Patrick Steinhardt committed
  14. 10 Aug, 2016 2 commits
  15. 09 Aug, 2016 1 commit
  16. 08 Aug, 2016 1 commit
  17. 05 Aug, 2016 4 commits
  18. 04 Aug, 2016 5 commits
    • odb: only freshen pack files every 2 seconds · 27051d4e
      Since writing multiple objects may all already exist in a single
      packfile, avoid freshening that packfile repeatedly in a tight loop.
      Instead, only freshen pack files every 2 seconds.
      Edward Thomson committed
    • odb: freshen existing objects when writing · 8f09a98e
      When writing an object, we calculate its OID and see if it exists in the
      object database.  If it does, we need to freshen the file that contains
      it.
      Edward Thomson committed
    • sysdir: use the standard `init` pattern · 031d34b7
      Don't try to determine when sysdirs are uninitialized.  Instead, simply
      initialize them all at `git_libgit2_init` time and never try to
      reinitialize, except when consumers explicitly call `git_sysdir_set`.
      
      Looking at the buffer length is especially problematic, since there may
      no appropriate path for that value.  (For example, the Windows-specific
      programdata directory has no value on non-Windows machines.)
      
      Previously we would continually trying to re-lookup these values,
      which could get racy if two different threads are each calling
      `git_sysdir_get` and trying to lookup / clear the value simultaneously.
      Edward Thomson committed
    • refspec: do not set empty rhs for fetch refspecs · 1eee631d
      According to git-fetch(1), "[t]he colon can be omitted when <dst>
      is empty." So according to git, the refspec "refs/heads/master"
      is the same as the refspec "refs/heads/master:" when fetching
      changes. When trying to fetch from a remote with a trailing
      colon with libgit2, though, the fetch actually fails while it
      works when the trailing colon is left out. So obviously, libgit2
      does _not_ treat these two refspec formats the same for fetches.
      
      The problem results from parsing refspecs, where the resulting
      refspec has its destination set to an empty string in the case of
      a trailing colon and to a `NULL` pointer in the case of no
      trailing colon. When passing this to our DWIM machinery, the
      empty string gets translated to "refs/heads/", which is simply
      wrong.
      
      Fix the problem by having the parsing machinery treat both cases
      the same for fetch refspecs.
      Patrick Steinhardt committed
  19. 03 Aug, 2016 1 commit