1. 24 Jun, 2016 1 commit
    • Fix repository discovery with ceiling_dirs at current directory · ed577134
      git only checks ceiling directories when its search ascends to a parent
      directory.  A ceiling directory matching the starting directory will not
      prevent git from finding a repository in the starting directory or a
      parent directory.  libgit2 handled the former case correctly, but
      differed from git in the latter case: given a ceiling directory matching
      the starting directory, but no repository at the starting directory,
      libgit2 would stop the search at that point rather than finding a
      repository in a parent directory.
      
      Test case using git command-line tools:
      
      /tmp$ git init x
      Initialized empty Git repository in /tmp/x/.git/
      /tmp$ cd x/
      /tmp/x$ mkdir subdir
      /tmp/x$ cd subdir/
      /tmp/x/subdir$ GIT_CEILING_DIRECTORIES=/tmp/x git rev-parse --git-dir
      fatal: Not a git repository (or any of the parent directories): .git
      /tmp/x/subdir$ GIT_CEILING_DIRECTORIES=/tmp/x/subdir git rev-parse --git-dir
      /tmp/x/.git
      
      Fix the testsuite to test this case (in one case fixing a test that
      depended on the current behavior), and then fix find_repo to handle this
      case correctly.
      
      In the process, simplify and document the logic in find_repo():
      - Separate the concepts of "currently checking a .git directory" and
        "number of iterations left before going further counts as a search"
        into two separate variables, in_dot_git and min_iterations.
      - Move the logic to handle in_dot_git and append /.git to the top of the
        loop.
      - Only search ceiling_dirs and find ceiling_offset after running out of
        min_iterations; since ceiling_offset only tracks the longest matching
        ceiling directory, if ceiling_dirs contained both the current
        directory and a parent directory, this change makes find_repo stop the
        search at the parent directory.
      Josh Triplett committed
  2. 21 Jun, 2016 6 commits
  3. 20 Jun, 2016 12 commits
  4. 19 Jun, 2016 1 commit
  5. 17 Jun, 2016 1 commit
  6. 16 Jun, 2016 1 commit
  7. 15 Jun, 2016 2 commits
  8. 14 Jun, 2016 4 commits
  9. 07 Jun, 2016 5 commits
    • global: clean up crt only after freeing tls data · 432af52b
      The thread local storage is used to hold some global state that
      is dynamically allocated and should be freed upon exit. On
      Windows, we clean up the C run-time right after execution of
      registered shutdown callbacks and before cleaning up the TLS.
      
      When we clean up the CRT, we also cause it to analyze for memory
      leaks. As we did not free the TLS yet this will lead to false
      positives.
      
      Fix the issue by first freeing the TLS and cleaning up the CRT
      only afterwards.
      Patrick Steinhardt committed
    • index: fix NULL pointer access in index_remove_entry · 13deb874
      When removing an entry from the index by its position, we first
      retrieve the position from the index's entries and then try to
      remove the retrieved value from the index map with
      `DELETE_IN_MAP`. When `index_remove_entry` returns `NULL` we try
      to feed it into the `DELETE_IN_MAP` macro, which will
      unconditionally call `idxentry_hash` and then happily dereference
      the `NULL` entry pointer.
      
      Fix the issue by not passing a `NULL` entry into `DELETE_IN_MAP`.
      Patrick Steinhardt committed
    • transports: smart: fix potential invalid memory dereferences · 7d02019a
      When we receive a packet of exactly four bytes encoding its
      length as those four bytes it can be treated as an empty line.
      While it is not really specified how those empty lines should be
      treated, we currently ignore them and do not return an error when
      trying to parse it but simply advance the data pointer.
      
      Callers invoking `git_pkt_parse_line` are currently not prepared
      to handle this case as they do not explicitly check this case.
      While they could always reset the passed out-pointer to `NULL`
      before calling `git_pkt_parse_line` and determine if the pointer
      has been set afterwards, it makes more sense to update
      `git_pkt_parse_line` to set the out-pointer to `NULL` itself when
      it encounters such an empty packet. Like this it is guaranteed
      that there will be no invalid memory references to free'd
      pointers.
      
      As such, the issue has been fixed such that `git_pkt_parse_line`
      always sets the packet out pointer to `NULL` when an empty packet
      has been received and callers check for this condition, skipping
      such packets.
      Patrick Steinhardt committed
  10. 02 Jun, 2016 7 commits