1. 06 Jun, 2017 4 commits
    • index: set last written index entry in foreach-entry-loop · 8ceb890b
      The last written disk entry is currently being written inside of the
      function `write_disk_entry`. Make behavior a bit more obviously by
      instead setting it inside of `write_entries` while iterating all
      entries.
      Patrick Steinhardt committed
    • index: set last entry when reading compressed entries · 11d0be23
      To calculate the path of a compressed index entry, we need to know the
      preceding entry's path. While we do actually set the first predecessor
      correctly to "", we fail to update this while reading the entries.
      
      Fix the issue by updating `last` inside of the loop. Previously, we've
      been passing a double-pointer to `read_entry`, which it didn't update.
      As it is more obvious to update the pointer inside the loop itself,
      though, we can simply convert it to a normal pointer.
      Patrick Steinhardt committed
    • index: fix confusion with shared prefix in compressed path names · febe8c14
      The index version 4 introduced compressed path names for the entries.
      From the git.git index-format documentation:
      
          At the beginning of an entry, an integer N in the variable width
          encoding [...] is stored, followed by a NUL-terminated string S.
          Removing N bytes from the end of the path name for the previous
          entry, and replacing it with the string S yields the path name for
          this entry.
      
      But instead of stripping N bytes from the previous path's string and
      using the remaining prefix, we were instead simply concatenating the
      previous path with the current entry path, which is obviously wrong.
      
      Fix the issue by correctly copying the first N bytes of the previous
      entry only and concatenating the result with our current entry's path.
      Patrick Steinhardt committed
    • varint: fix computation for remaining buffer space · 8a5e7aae
      When encoding varints to a buffer, we want to remain sure that the
      required buffer space does not exceed what is actually available. Our
      current check does not do the right thing, though, in that it does not
      honor that our `pos` variable counts the position down instead of up. As
      such, we will require too much memory for small varints and not enough
      memory for big varints.
      
      Fix the issue by correctly calculating the required size as
      `(sizeof(varint) - pos)`. Add a test which failed before.
      Patrick Steinhardt committed
  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