1. 16 Feb, 2023 1 commit
  2. 14 Jul, 2022 3 commits
  3. 23 Feb, 2022 1 commit
  4. 17 Oct, 2021 1 commit
    • str: introduce `git_str` for internal, `git_buf` is external · f0e693b1
      libgit2 has two distinct requirements that were previously solved by
      `git_buf`.  We require:
      
      1. A general purpose string class that provides a number of utility APIs
         for manipulating data (eg, concatenating, truncating, etc).
      2. A structure that we can use to return strings to callers that they
         can take ownership of.
      
      By using a single class (`git_buf`) for both of these purposes, we have
      confused the API to the point that refactorings are difficult and
      reasoning about correctness is also difficult.
      
      Move the utility class `git_buf` to be called `git_str`: this represents
      its general purpose, as an internal string buffer class.  The name also
      is an homage to Junio Hamano ("gitstr").
      
      The public API remains `git_buf`, and has a much smaller footprint.  It
      is generally only used as an "out" param with strict requirements that
      follow the documentation.  (Exceptions exist for some legacy APIs to
      avoid breaking callers unnecessarily.)
      
      Utility functions exist to convert a user-specified `git_buf` to a
      `git_str` so that we can call internal functions, then converting it
      back again.
      Edward Thomson committed
  5. 09 Sep, 2021 1 commit
  6. 27 Nov, 2020 1 commit
  7. 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
  8. 11 May, 2020 1 commit
  9. 18 Oct, 2019 2 commits
  10. 20 Jul, 2019 1 commit
    • stash: avoid recomputing tree when committing worktree · a7d32d60
      When creating a new stash, we need to create there separate
      commits storing differences stored in the index, untracked
      changes as well as differences in the working directory. The
      first two will only be done conditionally if the equivalent
      options "git stash --keep-index --include-untracked" are being
      passed to `git_stash_save`, but even when only creating a stash
      of worktree changes we're much slower than git.git. Using our new
      stash example:
      
      	$ time git stash
      	Saved working directory and index state WIP on (no branch): 2f7d9d47575e Linux 5.1.7
      
      	real    0m0.528s
      	user    0m0.309s
      	sys     0m0.381s
      
      	$ time lg2 stash
      
      	real    0m27.165s
      	user    0m13.645s
      	sys     0m6.403s
      
      As can be seen, libgit2 is more than 50x slower than git.git!
      
      When creating the stash commit that includes all worktree
      changes, we create a completely new index to prepare for the new
      commit and populate it with the entries contained in the index'
      tree. Here comes the catch: by populating the index with a tree's
      contents, we do not have any stat caches in the index. This means
      that we have to re-validate every single file from the worktree
      and see whether it has changed.
      
      The issue can be fixed by populating the new index with the
      repo's existing index instead of with the tree. This retains all
      stat cache information, and thus we really only need to check
      files that have changed stat information. This is semantically
      equivalent to what we previously did: previously, we used the
      tree of the commit computed from the index. Now we're just using
      the index directly.
      
      And, in fact, the cache is doing wonders:
      
      	time lg2 stash
      
      	real    0m1.836s
      	user    0m1.166s
      	sys     0m0.663s
      
      We're now performing 15x faster than before and are only 3x
      slower than git.git now.
      Patrick Steinhardt committed
  11. 18 Jul, 2019 1 commit
  12. 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
  13. 22 Jan, 2019 1 commit
  14. 29 Jun, 2018 1 commit
    • stash: use _an_ index not _the_ index · 4919e495
      Don't manipulate the repository's index during stash; instead,
      manipulate a temporary index and check it out.
      
      This allows us to use the checkout mechanism to update the workdir and
      the repository's index, and allows checkout to use its common mechanisms
      to write data and handle errors.
      Edward Thomson committed
  15. 10 Jun, 2018 1 commit
  16. 26 Mar, 2018 1 commit
  17. 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
  18. 29 Dec, 2016 1 commit
  19. 26 May, 2016 1 commit
  20. 11 Feb, 2016 1 commit
  21. 28 Aug, 2015 1 commit
  22. 12 Jul, 2015 1 commit
  23. 29 Jun, 2015 1 commit
  24. 25 Jun, 2015 2 commits
  25. 23 Jun, 2015 1 commit
    • stash: save the workdir file when deleted in index · 90177111
      When stashing the workdir tree, examine the index as well.  Using
      a mechanism similar to `git_diff_tree_to_workdir_with_index`
      allows us to determine that a file was added in the index and
      subsequently modified in the working directory.  Without examining
      the index, we would erroneously believe that this file was
      untracked and fail to include it in the working directory tree.
      
      Use a slightly modified `git_diff_tree_to_workdir_with_index` in
      order to avoid some of the behavior custom to `git diff`.  In
      particular, be sure to include the working directory side of a
      file when it was deleted in the index.
      Edward Thomson committed
  26. 21 Jun, 2015 1 commit
  27. 29 May, 2015 1 commit
    • Rename GIT_EMERGECONFLICT to GIT_ECONFLICT · 885b94aa
      We do not error on "merge conflicts"; on the contrary, merge conflicts
      are a normal part of merging.  We only error on "checkout conflicts",
      where a change exists in the index or the working directory that would
      otherwise be overwritten by performing the checkout.
      
      This *may* happen during merge (after the production of the new index
      that we're going to checkout) but it could happen during any checkout.
      Edward Thomson committed
  28. 13 May, 2015 1 commit
  29. 11 May, 2015 8 commits