1. 12 Jul, 2020 3 commits
    • repository: retrieve worktree HEAD via refdb · 65895410
      The function `git_repository_head_for_worktree` currently uses
      `git_reference__read_head` to directly read a given worktree's HEAD from
      the filesystem. This is broken in case the repository uses a different
      refdb implementation than the filesystem-based one, so let's instead
      open the worktree as a real repository and use `git_reference_lookup`.
      This also fixes the case where the worktree's HEAD is not a symref, but
      a detached HEAD, which would have resulted in an error previously.
      Patrick Steinhardt committed
    • repository: remove function to iterate over HEADs · d1f210fc
      The function `git_repository_foreach_head` is broken, as it directly
      interacts with the on-disk representation of the reference database,
      thus assuming that no other refdb is used for the given repository. As
      this is an internal function only and all users have been replaced,
      let's remove this function.
      Patrick Steinhardt committed
    • repository: introduce new function to iterate over all worktrees · 2fcb4f28
      Given a Git repository, it's non-trivial to iterate over all worktrees
      that are associated with it, including the "main" repository. This
      commit adds a new internal function `git_repository_foreach_worktree`
      that does this for us.
      Patrick Steinhardt committed
  2. 09 Jun, 2020 1 commit
    • tree-wide: do not compile deprecated functions with hard deprecation · c6184f0c
      When compiling libgit2 with -DDEPRECATE_HARD, we add a preprocessor
      definition `GIT_DEPRECATE_HARD` which causes the "git2/deprecated.h"
      header to be empty. As a result, no function declarations are made
      available to callers, but the implementations are still available to
      link against. This has the problem that function declarations also
      aren't visible to the implementations, meaning that the symbol's
      visibility will not be set up correctly. As a result, the resulting
      library may not expose those deprecated symbols at all on some platforms
      and thus cause linking errors.
      
      Fix the issue by conditionally compiling deprecated functions, only.
      While it becomes impossible to link against such a library in case one
      uses deprecated functions, distributors of libgit2 aren't expected to
      pass -DDEPRECATE_HARD anyway. Instead, users of libgit2 should manually
      define GIT_DEPRECATE_HARD to hide deprecated functions. Using "real"
      hard deprecation still makes sense in the context of CI to test we don't
      use deprecated symbols ourselves and in case a dependant uses libgit2 in
      a vendored way and knows it won't ever use any of the deprecated symbols
      anyway.
      Patrick Steinhardt committed
  3. 01 Jun, 2020 1 commit
  4. 11 Feb, 2020 1 commit
    • repository: handle format v1 · 06f02300
      Git has supported repository format version 1 for some time.  This
      format is just like version 0, but it supports extensions.
      Implementations must reject extensions that they don't support.
      
      Add support for this format version and reject any extensions but
      extensions.noop, which is the only extension we currently support.
      
      While we're at it, also clean up an error message.
      brian m. carlson committed
  5. 07 Feb, 2020 1 commit
    • repository: check error codes when reading common link · 2288a713
      When checking whether a path is a valid repository path, we try to read
      the "commondir" link file. In the process, we neither confirm that
      constructing the file's path succeeded nor do we verify that reading the
      file succeeded, which might cause us to verify repositories on an empty
      or bogus path later on.
      
      Fix this by checking return values. As the function to verify repos
      doesn't currently support returning errors, this commit also refactors
      the function to return an error code, passing validity of the repo via
      an out parameter instead, and adjusts all existing callers.
      Patrick Steinhardt committed
  6. 24 Jan, 2020 1 commit
  7. 16 Jan, 2020 1 commit
  8. 22 Nov, 2019 1 commit
  9. 10 Oct, 2019 1 commit
    • refs: fix locks getting forcibly removed · 3335a034
      The flag GIT_FILEBUF_FORCE currently does two things:
           1. It will cause the filebuf to create non-existing leading
              directories for the file that is about to be written.
           2. It will forcibly remove any pre-existing locks.
      While most call sites actually do want (1), they do not want to
      remove pre-existing locks, as that renders the locking mechanisms
      effectively useless.
      Introduce a new flag `GIT_FILEBUF_CREATE_LEADING_DIRS` to
      separate both behaviours cleanly from each other and convert
      callers to use it instead of `GIT_FILEBUF_FORCE` to have them
      honor locked files correctly.
      
      As this conversion removes all current users of `GIT_FILEBUF_FORCE`,
      this commit removes the flag altogether.
      Sebastian Henke committed
  10. 10 Sep, 2019 2 commits
  11. 20 Jul, 2019 2 commits
    • path: extract function to check whether a path supports symlinks · ded77bb1
      When initializing a repository, we need to check whether its working
      directory supports symlinks to correctly set the initial value of the
      "core.symlinks" config variable. The code to check the filesystem is
      reusable in other parts of our codebase, like for example in our tests
      to determine whether certain tests can be expected to succeed or not.
      
      Extract the code into a new function `git_path_supports_symlinks` to
      avoid duplicate implementations. Remove a duplicate implementation in
      the repo test helper code.
      Patrick Steinhardt committed
    • fileops: rename to "futils.h" to match function signatures · e54343a4
      Our file utils functions all have a "futils" prefix, e.g.
      `git_futils_touch`. One would thus naturally guess that their
      definitions and implementation would live in files "futils.h" and
      "futils.c", respectively, but in fact they live in "fileops.h".
      
      Rename the files to match expectations.
      Patrick Steinhardt committed
  12. 19 Jul, 2019 3 commits
    • repository: do not initialize HEAD if it's provided by templates · 9d46f167
      When using templates to initialize a git repository, then git-init(1)
      will copy over all contents of the template directory. These will be
      preferred over the default ones created by git-init(1). While we mostly
      do the same, there is the exception of "HEAD". While we do copy over the
      template's HEAD file, afterwards we'll immediately re-initialize its
      contents with either the default "ref: refs/origin/master" or the init
      option's `initial_head` field.
      
      Let's fix the inconsistency with upstream git-init(1) by not overwriting
      the template HEAD, but only if the user hasn't set `opts.initial_head`.
      If the `initial_head` field has been supplied, we should use that
      indifferent from whether the template contained a HEAD file or not. Add
      tests to verify we correctly use the template directory's HEAD file and
      that `initial_head` overrides the template.
      Patrick Steinhardt committed
    • repository: update error handling in `init_ext` · f3134a84
      Update `git_repository_init_ext` to use our typical style of error
      handling. The function had multiple statements which didn't `goto out`
      immediately but instead deferred it to later calls combined with `if`
      statements.
      Patrick Steinhardt committed
    • repository: avoid swallowing error codes in `create_head` · 869ae5a3
      The error handling in `git_repository_create_head` completely swallows
      all error codes. While probably not too much of a problem, this also
      violates our usual coding style.
      
      Refactor the code to use a local `error` variable with the typical `goto
      out` statements.
      Patrick Steinhardt committed
  13. 18 Jul, 2019 1 commit
  14. 26 Jun, 2019 1 commit
  15. 24 Jun, 2019 1 commit
  16. 14 Jun, 2019 1 commit
    • Rename opt init functions to `options_init` · 0b5ba0d7
      In libgit2 nomenclature, when we need to verb a direct object, we name
      a function `git_directobject_verb`.  Thus, if we need to init an options
      structure named `git_foo_options`, then the name of the function that
      does that should be `git_foo_options_init`.
      
      The previous names of `git_foo_init_options` is close - it _sounds_ as
      if it's initializing the options of a `foo`, but in fact
      `git_foo_options` is its own noun that should be respected.
      
      Deprecate the old names; they'll now call directly to the new ones.
      Edward Thomson committed
  17. 23 May, 2019 1 commit
  18. 21 Feb, 2019 1 commit
    • cache: fix misnaming of `git_cache_free` · bbdcd450
      Functions that free a structure's contents but not the structure
      itself shall be named `dispose` in the libgit2 project, but the
      function `git_cache_free` does not follow this naming pattern.
      
      Fix this by renaming it to `git_cache_dispose` and adjusting all
      callers to make use of the new name.
      Patrick Steinhardt committed
  19. 15 Feb, 2019 1 commit
    • maps: use uniform lifecycle management functions · 351eeff3
      Currently, the lifecycle functions for maps (allocation, deallocation, resize)
      are not named in a uniform way and do not have a uniform function signature.
      Rename the functions to fix that, and stick to libgit2's naming scheme of saying
      `git_foo_new`. This results in the following new interface for allocation:
      
      - `int git_<t>map_new(git_<t>map **out)` to allocate a new map, returning an
        error code if we ran out of memory
      
      - `void git_<t>map_free(git_<t>map *map)` to free a map
      
      - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map
      
      This commit also fixes all existing callers.
      Patrick Steinhardt committed
  20. 14 Feb, 2019 1 commit
  21. 22 Jan, 2019 1 commit
  22. 20 Jan, 2019 1 commit
  23. 17 Jan, 2019 1 commit
  24. 01 Dec, 2018 2 commits
  25. 25 Nov, 2018 1 commit
  26. 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
  27. 16 Oct, 2018 1 commit
  28. 10 Jun, 2018 1 commit
  29. 07 May, 2018 1 commit
  30. 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
  31. 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