1. 01 Oct, 2016 14 commits
    • git_checkout_tree options fix · e499b13c
      According to the reference the git_checkout_tree and git_checkout_head
      functions should accept NULL in the opts field
      
      This was broken since the opts field was dereferenced and thus lead to a
      crash.
      Stefan Huber committed
    • ignore: allow unignoring basenames in subdirectories · 0dea4299
      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
    • refspec: do not set empty rhs for fetch refspecs · 85addddf
      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
    • Fix repository discovery with ceiling_dirs at current directory · a200dc9e
      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
    • checkout: use empty baseline when no index · ac44d354
      When no index file exists and a baseline is not explicitly provided, use
      an empty baseline instead of trying to load `HEAD`.
      Edward Thomson committed
    • test: ensure we can round-trip a written tree · 8be49681
      Read a tree into an index, write the index, then re-open the index and
      ensure that we are treesame to the original.
      Edward Thomson committed
    • round-trip trees through index_read_index · 6c133a75
      Read a tree into an index using `git_index_read_index` (by reading
      a tree into a new index, then reading that index into the current
      index), then write the index back out, ensuring that our new index
      is treesame to the tree that we read.
      Edward Thomson committed
    • checkout: handle dirty submodules correctly · 70681ff7
      Don't generate conflicts when checking out a modified submodule and the
      submodule is dirty or modified in the workdir.
      Jason Haslam committed
    • test: Fix stat() test to mask out unwanted bits · 26917fd9
      Haiku and Hurd both pass extra bits in struct stat::st_mode.
      François Revol committed
    • tag: ignore extra header fields · 16541b86
      While no extra header fields are defined for tags, git accepts them by
      ignoring them and continuing the search for the message. There are a few
      tags like this in the wild which git parses just fine, so we should do
      the same.
      Carlos Martín Nieto committed
  2. 11 Apr, 2016 21 commits
  3. 04 Mar, 2016 1 commit
  4. 03 Mar, 2016 2 commits
  5. 28 Feb, 2016 2 commits