1. 10 Mar, 2018 2 commits
  2. 12 Jun, 2017 3 commits
  3. 08 Jun, 2017 1 commit
    • settings: rename `GIT_OPT_ENABLE_SYNCHRONOUS_OBJECT_CREATION` · 6c23704d
      Initially, the setting has been solely used to enable the use of
      `fsync()` when creating objects. Since then, the use has been extended
      to also cover references and index files. As the option is not yet part
      of any release, we can still correct this by renaming the option to
      something more sensible, indicating not only correlation to objects.
      
      This commit renames the option to `GIT_OPT_ENABLE_FSYNC_GITDIR`. We also
      move the variable from the object to repository source code.
      Patrick Steinhardt committed
  4. 19 May, 2017 4 commits
    • repository: make check if repo is a worktree more strict · 2696c5c3
      To determine if a repository is a worktree or not, we currently check
      for the existence of a "gitdir" file inside of the repository's gitdir.
      While this is sufficient for non-broken repositories, we have at least
      one case of a subtly broken repository where there exists a gitdir file
      inside of a gitmodule. This will cause us to misidentify the submodule
      as a worktree.
      
      While this is not really a fault of ours, we can do better here by
      observing that a repository can only ever be a worktree iff its common
      directory and dotgit directory are different. This allows us to make our
      check whether a repo is a worktree or not more strict by doing a simple
      string comparison of these two directories. This will also allow us to
      do the right thing in the above case of a broken repository, as for
      submodules these directories will be the same. At the same time, this
      allows us to skip the `stat` check for the "gitdir" file for most
      repositories.
      Patrick Steinhardt committed
    • repository: factor out worktree check · 9f9fd05f
      The check whether a repository is a worktree or not is currently done
      inside of `git_repository_open_ext`. As we want to extend this function
      later on, pull it out into its own function `repo_is_worktree` to ease
      working on it.
      Patrick Steinhardt committed
    • repository: improve parameter names for `find_repo` · 32841973
      The out-parameters of `find_repo` containing found paths of a repository
      are a tad confusing, as they are not as obvious as they could be. Rename
      them like following to ease reading the code:
      
      - `repo_path` -> `gitdir_path`
      - `parent_path` -> `workdir_path`
      - `link_path` -> `gitlink_path`
      - `common_path` -> `commondir_path`
      Patrick Steinhardt committed
    • repository: clear out-parameter instead of freeing it · 57121a23
      The `path` out-parameter of `find_repo` is being sanitized initially
      such that we do not try to append to existing content. The sanitization
      is done via `git_buf_free`, though, which forces us to needlessly
      reallocate the buffer later in the function. Fix this by using
      `git_buf_clear` instead.
      Patrick Steinhardt committed
  5. 01 May, 2017 1 commit
  6. 05 Apr, 2017 4 commits
  7. 02 Apr, 2017 1 commit
  8. 21 Mar, 2017 1 commit
  9. 02 Mar, 2017 1 commit
  10. 17 Feb, 2017 1 commit
  11. 13 Feb, 2017 11 commits
  12. 20 Jan, 2017 1 commit
    • Allow for caching of submodules. · 4d99c4cf
      Added `git_repository_submodule_cache_all` to initialze a cache of
      submodules on the repository so that operations looking up N
      submodules are O(N) and not O(N^2).  Added a
      `git_repository_submodule_cache_clear` function to remove the cache.
      
      Also optimized the function that loads all submodules as it was itself
      O(N^2) w.r.t the number of submodules, having to loop through the
      `.gitmodules` file once per submodule.  I changed it to process the
      `.gitmodules` file once, into a map.
      
      Signed-off-by: David Turner <dturner@twosigma.com>
      Brock Peabody committed
  13. 29 Dec, 2016 1 commit
  14. 14 Nov, 2016 1 commit
    • repository: do not interpret all files as gitlinks in discovery · 0f316096
      When trying to find a discovery, we walk up the directory
      structure checking if there is a ".git" file or directory and, if
      so, check its validity. But in the case that we've got a ".git"
      file, we do not want to unconditionally assume that the file is
      in fact a ".git" file and treat it as such, as we would error out
      if it is not.
      
      Fix the issue by only treating a file as a gitlink file if it
      ends with "/.git". This allows users of the function to discover
      a repository by handing in any path contained inside of a git
      repository.
      Patrick Steinhardt committed
  15. 11 Nov, 2016 1 commit
    • git_repository_open_ext: fix handling of $GIT_NAMESPACE · c9e967a1
      The existing code would set a namespace of "" (empty string) with
      GIT_NAMESPACE unset.  In a repository where refs/heads/namespaces/
      exists, that can produce incorrect results.  Detect that case and avoid
      setting the namespace at all.
      
      Since that makes the last assignment to error conditional, and the
      previous assignment can potentially get GIT_ENOTFOUND, set error to 0
      explicitly to prevent the call from incorrectly failing with
      GIT_ENOTFOUND.
      Josh Triplett committed
  16. 24 Jul, 2016 1 commit
  17. 24 Jun, 2016 4 commits
    • find_repo: Clean up and simplify logic · 2b490284
      find_repo had a complex loop and heavily nested conditionals, making it
      difficult to follow.  Simplify this as much as possible:
      
      - Separate assignments from conditionals.
      - Check the complex loop condition in the only place it can change.
      - Break out of the loop on error, rather than going through the rest of
        the loop body first.
      - Handle error cases by immediately breaking, rather than nesting
        conditionals.
      - Free repo_link unconditionally on the way out of the function, rather
        than in multiple places.
      - Add more comments on the remaining complex steps.
      Josh Triplett committed
    • Add GIT_REPOSITORY_OPEN_FROM_ENV flag to respect $GIT_* environment vars · 0dd98b69
      git_repository_open_ext provides parameters for the start path, whether
      to search across filesystems, and what ceiling directories to stop at.
      git commands have standard environment variables and defaults for each
      of those, as well as various other parameters of the repository. To
      avoid duplicate environment variable handling in users of libgit2, add a
      GIT_REPOSITORY_OPEN_FROM_ENV flag, which makes git_repository_open_ext
      automatically handle the appropriate environment variables. Commands
      that intend to act just like those built into git itself can use this
      flag to get the expected default behavior.
      
      git_repository_open_ext with the GIT_REPOSITORY_OPEN_FROM_ENV flag
      respects $GIT_DIR, $GIT_DISCOVERY_ACROSS_FILESYSTEM,
      $GIT_CEILING_DIRECTORIES, $GIT_INDEX_FILE, $GIT_NAMESPACE,
      $GIT_OBJECT_DIRECTORY, and $GIT_ALTERNATE_OBJECT_DIRECTORIES.  In the
      future, when libgit2 gets worktree support, git_repository_open_env will
      also respect $GIT_WORK_TREE and $GIT_COMMON_DIR; until then,
      git_repository_open_ext with this flag will error out if either
      $GIT_WORK_TREE or $GIT_COMMON_DIR is set.
      Josh Triplett committed
    • Add GIT_REPOSITORY_OPEN_NO_DOTGIT flag to avoid appending /.git · 39c6fca3
      GIT_REPOSITORY_OPEN_NO_SEARCH does not search up through parent
      directories, but still tries the specified path both directly and with
      /.git appended.  GIT_REPOSITORY_OPEN_BARE avoids appending /.git, but
      opens the repository in bare mode even if it has a working directory.
      To support the semantics git uses when given $GIT_DIR in the
      environment, provide a new GIT_REPOSITORY_OPEN_NO_DOTGIT flag to not try
      appending /.git.
      Josh Triplett committed
    • 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
  18. 26 Apr, 2016 1 commit
    • annotated_commit: provide refs and description · d5592378
      Differentiate between the ref_name used to create an annotated_commit
      (that can subsequently be used to look up the reference) and the
      description that we resolved this with (which _cannot_ be looked up).
      
      The description is used for things like reflogs (and may be a ref name,
      and ID something that we revparsed to get here), while the ref name must
      actually be a reference name, and is used for things like rebase to
      return to the initial branch.
      Edward Thomson committed