1. 22 Jan, 2019 1 commit
  2. 20 Jan, 2019 1 commit
  3. 17 Jan, 2019 1 commit
  4. 01 Dec, 2018 2 commits
  5. 25 Nov, 2018 1 commit
  6. 20 Oct, 2018 2 commits
    • repository: load_config for non-repo configs · 820e1e93
      Teach `load_config` how to load all the configurations except
      (optionally) the repository configuration.  This allows the new
      repository codepath to load the global/xdg/system configuration paths so
      that they can be inspected during repository initialization.
      Edward Thomson committed
    • win32: emulate Git for Windows in symlink support · b433a22a
      Emulate the Git for Windows `core.symlinks` support.  Since symbolic
      links are generally enabled for Administrator (and _may_ be enabled due
      to enabling Developer mode) but symbolic links are still sufficiently
      uncommon on Windows that Git users are expected to explicitly opt-in to
      symbolic links by enabling `core.symlinks=true` in a global (or xdg or
      system) configuration.
      
      When `core.symlinks=true` is set globally _and_ symbolic links support
      is detected then new repositories created will not have a
      `core.symlinks` set.  If `core.symlinks` is _not_ set then no detection
      will be performed, and `core.symlinks=false` will be set in the
      repository configuration.
      Edward Thomson committed
  7. 16 Oct, 2018 1 commit
  8. 10 Jun, 2018 1 commit
  9. 07 May, 2018 1 commit
  10. 18 Nov, 2017 1 commit
    • refcount: make refcounting conform to aliasing rules · 585b5dac
      Strict aliasing rules dictate that for most data types, you are not
      allowed to cast them to another data type and then access the casted
      pointers. While this works just fine for most compilers, technically we
      end up in undefined behaviour when we hurt that rule.
      
      Our current refcounting code makes heavy use of casting and thus
      violates that rule. While we didn't have any problems with that code,
      Travis started spitting out a lot of warnings due to a change in their
      toolchain. In the refcounting case, the code is also easy to fix:
      as all refcounting-statements are actually macros, we can just access
      the `rc` field directly instead of casting.
      
      There are two outliers in our code where that doesn't work. Both the
      `git_diff` and `git_patch` structures have specializations for generated
      and parsed diffs/patches, which directly inherit from them. Because of
      that, the refcounting code is only part of the base structure and not of
      the children themselves. We can help that by instead passing their base
      into `GIT_REFCOUNT_INC`, though.
      Patrick Steinhardt committed
  11. 09 Oct, 2017 2 commits
    • config: pass repository when opening config files · 529e873c
      Our current configuration logic is completely oblivious of any
      repository, but only cares for actual file paths. Unfortunately, we are
      forced to break this assumption by the introduction of conditional
      includes, which are evaluated in the context of a repository. Right now,
      only one conditional exists with "gitdir:" -- it will only include the
      configuration if the current repository's git directory matches the
      value passed to "gitdir:".
      
      To support these conditionals, we have to break our API and make the
      repository available when opening a configuration file. This commit
      extends the `open` call of configuration backends to include another
      repository and adjusts existing code to have it available. This includes
      the user-visible functions `git_config_add_file_ondisk` and
      `git_config_add_backend`.
      Patrick Steinhardt committed
    • repository: constify several repo parameters for getters · d02cf564
      Several functions to retrieve variables from a repository only return
      immutable values, which allows us to actually constify the passed-in
      repository parameter. Do so to help a later patch, which will only have
      access to a constant repository.
      Patrick Steinhardt committed
  12. 03 Jul, 2017 1 commit
    • Make sure to always include "common.h" first · 0c7f49dd
      Next to including several files, our "common.h" header also declares
      various macros which are then used throughout the project. As such, we
      have to make sure to always include this file first in all
      implementation files. Otherwise, we might encounter problems or even
      silent behavioural differences due to macros or defines not being
      defined as they should be. So in fact, our header and implementation
      files should make sure to always include "common.h" first.
      
      This commit does so by establishing a common include pattern. Header
      files inside of "src" will now always include "common.h" as its first
      other file, separated by a newline from all the other includes to make
      it stand out as special. There are two cases for the implementation
      files. If they do have a matching header file, they will always include
      this one first, leading to "common.h" being transitively included as
      first file. If they do not have a matching header file, they instead
      include "common.h" as first file themselves.
      
      This fixes the outlined problems and will become our standard practice
      for header and source files inside of the "src/" from now on.
      Patrick Steinhardt committed
  13. 19 Jun, 2017 2 commits
  14. 12 Jun, 2017 3 commits
  15. 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
  16. 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
  17. 01 May, 2017 1 commit
  18. 05 Apr, 2017 4 commits
  19. 02 Apr, 2017 1 commit
  20. 21 Mar, 2017 1 commit
  21. 02 Mar, 2017 1 commit
  22. 17 Feb, 2017 1 commit
  23. 13 Feb, 2017 6 commits
    • worktree: compute workdir for worktrees opened via their gitdir · 39abd3ad
      When opening a worktree via the gitdir of its parent repository
      we fail to correctly set up the worktree's working directory. The
      problem here is two-fold: we first fail to see that the gitdir
      actually is a gitdir of a working tree and then subsequently
      fail to determine the working tree location from the gitdir.
      
      The first problem of not noticing a gitdir belongs to a worktree
      can be solved by checking for the existence of a `gitdir` file in
      the gitdir. This file points back to the gitlink file located in
      the working tree's working directory. As this file only exists
      for worktrees, it should be sufficient indication of the gitdir
      belonging to a worktree.
      
      The second problem, that is determining the location of the
      worktree's working directory, can then be solved by reading the
      `gitdir` file in the working directory's gitdir. When we now
      resolve relative paths and strip the final `.git` component, we
      have the actual worktree's working directory location.
      Patrick Steinhardt committed
    • repository: rename `path_repository` and `path_gitlink` · 84f56cb0
      The `path_repository` variable is actually confusing to think
      about, as it is not always clear what the repository actually is.
      It may either be the path to the folder containing worktree and
      .git directory, the path to .git itself, a worktree or something
      entirely different. Actually, the intent of the variable is to
      hold the path to the gitdir, which is either the .git directory
      or the bare repository.
      
      Rename the variable to `gitdir` to avoid confusion. While at it,
      also rename `path_gitlink` to `gitlink` to improve consistency.
      Patrick Steinhardt committed
    • repository: restrict checking out checked out branches · 384518d0
      If a branch is already checked out in a working tree we are not
      allowed to check out that branch in another repository. Introduce
      this restriction when setting a repository's HEAD.
      Patrick Steinhardt committed
    • worktree: implement functions reading HEAD · 04fb12ab
      Implement `git_repository_head_for_worktree` and
      `git_repository_head_detached_for_worktree` for directly accessing a
      worktree's HEAD without opening it as a `git_repository` first.
      Patrick Steinhardt committed
    • worktree: implement `git_repository_open_from_worktree` · 8c8d726e
      Add function `git_repository_open_from_worktree`, which allows to open a
      `git_worktree` as repository.
      Patrick Steinhardt committed
    • repository: expose `repo_init_create_head` · 854b5c70
      Expose the function `repo_init_create_head` as
      `git_repository_create_head`.
      Patrick Steinhardt committed