1. 08 Jun, 2017 4 commits
  2. 04 Jun, 2017 4 commits
  3. 20 May, 2017 4 commits
  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. 17 May, 2017 2 commits
  6. 16 May, 2017 1 commit
  7. 15 May, 2017 5 commits
  8. 11 May, 2017 2 commits
  9. 05 May, 2017 3 commits
    • revparse: support open-ended ranges · 8b107dc5
      Support '..' and '...' ranges where one side is not specified.
      The unspecified side defaults to HEAD.
      
      Closes #4223
      William Bain committed
    • worktree: switch over worktree pruning to an opts structure · 883eeb5f
      The current signature of `git_worktree_prune` accepts a flags field to
      alter its behavior. This is not as flexible as we'd like it to be when
      we want to enable passing additional options in the future. As the
      function has not been part of any release yet, we are still free to
      alter its current signature. This commit does so by using our usual
      pattern of an options structure, which is easily extendable without
      breaking the API.
      Patrick Steinhardt committed
    • worktree: support creating locked worktrees · 8264a30f
      When creating a new worktree, we do have a potential race with us
      creating the worktree and another process trying to delete the same
      worktree as it is being created. As such, the upstream git project has
      introduced a flag `git worktree add --locked`, which will cause the
      newly created worktree to be locked immediately after its creation. This
      mitigates the race condition.
      
      We want to be able to mirror the same behavior. As such, a new flag
      `locked` is added to the options structure of `git_worktree_add` which
      allows the user to enable this behavior.
      Patrick Steinhardt committed
  10. 04 May, 2017 1 commit
  11. 03 May, 2017 1 commit
    • tests: repo: fix repo discovery tests on overlayfs · ffd264d9
      Debian and Ubuntu often use schroot to build their DEB packages in a
      controlled environment. Depending on how schroot is configured, our
      tests regarding repository discovery break due to not being able to find
      the repositories anymore. It turns out that these errors occur when the
      schroot is configured to use an overlayfs on the directory structures.
      
      The reason for this failure is that we usually refrain from discovering
      repositories across devices. But unfortunately, overlayfs does not have
      consistent device identifiers for all its files but will instead use the
      device number of the filesystem the file stems from. So whenever we
      cross boundaries between the upper and lower layer of the overlay, we
      will fail to properly detect the repository and bail out.
      
      This commit fixes the issue by enabling cross-device discovery in our
      tests. While it would be preferable to have this turned off, it probably
      won't do much harm anyway as we set up our tests in a temporary location
      outside of the parent repository.
      Patrick Steinhardt committed
  12. 02 May, 2017 5 commits
  13. 01 May, 2017 4 commits