1. 13 Sep, 2019 1 commit
  2. 10 Sep, 2019 1 commit
  3. 28 Aug, 2019 1 commit
  4. 27 Aug, 2019 2 commits
  5. 23 Aug, 2019 1 commit
    • util: do not perform allocations in insertsort · 8cbef12d
      Our hand-rolled fallback sorting function `git__insertsort_r` does an
      in-place sort of the given array. As elements may not necessarily be
      pointers, it needs a way of swapping two values of arbitrary size, which
      is currently implemented by allocating a temporary buffer of the
      element's size. This is problematic, though, as the emulated `qsort`
      interface doesn't provide any return values and thus cannot signal an
      error if allocation of that temporary buffer has failed.
      
      Convert the function to swap via a temporary buffer allocated on the
      stack. Like this, it can `memcpy` contents of both elements in small
      batches without requiring a heap allocation. The buffer size has been
      chosen such that in most cases, a single iteration of copying will
      suffice. Most importantly, it can fully contain `git_oid` structures and
      pointers.
      
      Add a bunch of tests for the `git__qsort_r` interface to verify nothing
      breaks. Furthermore, this removes the declaration of `git__insertsort_r`
      and makes it static as it is not used anywhere else.
      Patrick Steinhardt committed
  6. 21 Aug, 2019 2 commits
  7. 17 Aug, 2019 1 commit
  8. 13 Aug, 2019 1 commit
  9. 12 Aug, 2019 1 commit
  10. 11 Aug, 2019 6 commits
  11. 01 Aug, 2019 4 commits
  12. 29 Jul, 2019 1 commit
  13. 25 Jul, 2019 1 commit
  14. 24 Jul, 2019 1 commit
  15. 22 Jul, 2019 1 commit
  16. 21 Jul, 2019 3 commits
  17. 20 Jul, 2019 7 commits
    • win32: fix symlinks to relative file targets · 50194dcd
      When creating a symlink in Windows, one needs to tell Windows whether
      the symlink should be a file or directory symlink. To determine which
      flag to pass, we call `GetFileAttributesW` on the target file to see
      whether it is a directory and then pass the flag accordingly. The
      problem though is if create a symlink with a relative target path, then
      we will check that relative path while not necessarily being inside of
      the working directory where the symlink is to be created. Thus, getting
      its attributes will either fail or return attributes of the wrong
      target.
      
      Fix this by resolving the target path relative to the directory in which
      the symlink is to be created.
      Patrick Steinhardt committed
    • tests: core: improve symlink test coverage · 93d37a1d
      Add two more tests to verify that we're not deleting symlink targets,
      but the symlinks themselves. Furthermore, convert several `cl_skip`s on
      Win32 to conditional skips depending on whether the clar sandbox
      supports symlinks or not. Windows is grown up now and may allow
      unprivileged symlinks if the machine has been configured accordingly.
      Patrick Steinhardt committed
    • tests: core: add missing asserts for several function calls · 683ea2b0
      Several function calls to `p_stat` and `p_close` have no verification if
      they actually succeeded. As these functions _may_ fail and as we also
      want to make sure that we're not doing anything dumb, let's check them,
      too.
      Patrick Steinhardt committed
    • 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
    • tests: execute leak checker via CTest directly · d827b11b
      Right now, we have an awful hack in our test CI setup that extracts the
      test command from CTest's output and then prepends the leak checker.
      This is dependent on non-machine-parseable output from CMake and also
      breaks on various ocassions, like for example when we have spaces in the
      current path or when the path contains backslashes. Both conditions may
      easily be triggered on Win32 systems, and in fact they do break our
      Azure Pipelines builds.
      
      Remove the awful hack in favour of a new CMake build option
      "USE_LEAK_CHECKER". If specifying e.g. "-DUSE_LEAK_CHECKER=valgrind",
      then we will set up all tests to be run under valgrind. Like this, we
      can again simply execute ctest without needing to rely on evil sourcery.
      Patrick Steinhardt committed
    • clar: provide ability to set summary file via environment · fe3b5da3
      As different test suites for our CI are mostly defined via CMake, it's
      hard to run those tests with a summary file path as that'd require us to
      add another parameter to all unit tests. As we do not want to
      unconditionally run unit tests with a summary file, we would have to add
      another CMake build parameter for test execution, which is ugly.
      
      Instead, implement a way to provide a summary file path via the
      environment.
      Patrick Steinhardt committed
  18. 19 Jul, 2019 4 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
    • tests: repo: refactor setup of templates and repos · 0d12b8dd
      All tests in repo::template have a common pattern of first setting up
      templates, then settung up the repository that makes use of those
      templates via several init options. Refactor this pattern into two
      functions `setup_templates` and `setup_repo` that handle most of that
      logic to make it easier to spot what a test actually wants to check.
      
      Furthermore, this also refactors how we clean up after the tests.
      Previously, it was a combination of manually calling
      `cl_fixture_cleanup` and `cl_set_cleanup`, which really is kind of hard
      to read. This commit refactors this to instead provide the cleaning
      parameters in the setup functions. All cleanups are then performed in
      the suite's cleanup function.
      Patrick Steinhardt committed
    • tests: repo: refactor template path handling · 3b79ceaf
      The repo::template test suite makes use of quite a few local variables
      that could be consolidated. Do so to make the code easier to read.
      Patrick Steinhardt committed
    • tests: repo: move template tests into their own suite · ee193480
      There's quite a lot of supporting code for our templates and they are an
      obvious standalone feature. Thus, let's extract those tests into their
      own suite to also make refactoring of them easier.
      Patrick Steinhardt committed
  19. 18 Jul, 2019 1 commit
    • tests: fix undercounting of suites · 92109976
      With the introduction of data variants for suites, we started
      undercounting the number of suites as we didn't account for those that
      were executed twice. This was then adjusted to count the number of
      initializers instead, but this fails to account for suites without any
      initializers at all.
      
      Fix the suite count by counting either the number of initializers or, if
      there is no initializer, count it as a single suite, only.
      Patrick Steinhardt committed