1. 02 Aug, 2016 1 commit
  2. 24 Jul, 2016 13 commits
  3. 23 Jul, 2016 1 commit
  4. 15 Jul, 2016 1 commit
    • remote: Handle missing config values when deleting a remote · d81cb2e4
      Somehow I ended up with the following in my ~/.gitconfig:
      [branch "master"]
      remote = origin
      merge = master
      rebase = true
      
      I assume something went crazy while I was running the git.git tests
      some time ago, and that I never noticed until now.
      
      This is not a good configuration, but it shouldn't cause problems. But
      it does. Specifically, if you have this in your config, and you
      perform the following set of actions:
      
      create a remote
      fetch from that remote
      create a branch off of the remote master branch called "master"
      delete the branch
      delete the remote
      
      The remote delete fails with the message "Could not find key
      'branch.master.rebase' to delete". This is because it's iterating over
      the config entries (including the ones in the global config) and
      believes that there is a master branch which must therefore have these
      config keys.
      
      https://github.com/libgit2/libgit2/issues/3856
      David Turner committed
  5. 05 Jul, 2016 3 commits
  6. 01 Jul, 2016 2 commits
  7. 30 Jun, 2016 3 commits
  8. 29 Jun, 2016 6 commits
  9. 28 Jun, 2016 1 commit
  10. 26 Jun, 2016 7 commits
  11. 24 Jun, 2016 2 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