1. 10 Jun, 2018 1 commit
  2. 04 Feb, 2018 2 commits
    • merge: virtual commit should be last argument to merge-base · 1403c612
      Our virtual commit must be the last argument to merge-base: since our
      algorithm pushes _both_ parents of the virtual commit, it needs to be
      the last argument, since merge-base:
      
      > Given three commits A, B and C, git merge-base A B C will compute the
      > merge base between A and a hypothetical commit M
      
      We want to calculate the merge base between the actual commit ("two")
      and the virtual commit ("one") - since one actually pushes its parents
      to the merge-base calculation, we need to calculate the merge base of
      "two" and the parents of one.
      Tyrie Vella committed
    • merge: reverse merge bases for recursive merge · b924df1e
      When the commits being merged have multiple merge bases, reverse the
      order when creating the virtual merge base.  This is for compatibility
      with git's merge-recursive algorithm, and ensures that we build
      identical trees.
      
      Git does this to try to use older merge bases first.  Per 8918b0c:
      
      > It seems to be the only sane way to do it: when a two-head merge is
      > done, and the merge-base and one of the two branches agree, the
      > merge assumes that the other branch has something new.
      >
      > If we start creating virtual commits from newer merge-bases, and go
      > back to older merge-bases, and then merge with newer commits again,
      > chances are that a patch is lost, _because_ the merge-base and the
      > head agree on it. Unlikely, yes, but it happened to me.
      Edward Thomson committed
  3. 21 Jan, 2018 1 commit
    • merge: recursive uses larger conflict markers · 185b0d08
      Git uses longer conflict markers in the recursive merge base - two more
      than the default (thus, 9 character long conflict markers).  This allows
      users to tell the difference between the recursive merge conflicts and
      conflicts between the ours and theirs branches.
      
      This was introduced in git d694a17986a28bbc19e2a6c32404ca24572e400f.
      
      Update our tests to expect this as well.
      Edward Thomson committed
  4. 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
  5. 21 Jun, 2017 1 commit
    • merge: fix potential free of uninitialized memory · 4dc87e72
      The function `merge_diff_mark_similarity_exact` may error our early and,
      when it does so, free the `ours_deletes_by_oid` and
      `theirs_deletes_by_oid` variables. While the first one can never be
      uninitialized due to the first call actually assigning to it, the second
      variable can be freed without being initialized.
      
      Fix the issue by initializing both variables to `NULL`.
      Patrick Steinhardt committed
  6. 17 May, 2017 1 commit
  7. 23 Mar, 2017 1 commit
  8. 13 Feb, 2017 1 commit
    • 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
  9. 09 Feb, 2017 1 commit
  10. 01 Jan, 2017 1 commit
  11. 29 Dec, 2016 1 commit
  12. 14 Nov, 2016 1 commit
  13. 18 Oct, 2016 1 commit
  14. 26 May, 2016 2 commits
  15. 17 Mar, 2016 9 commits
  16. 11 Feb, 2016 1 commit
  17. 08 Feb, 2016 1 commit
  18. 16 Dec, 2015 1 commit
    • merge: Use `git_index__fill` to populate the index · 879ebab3
      Instead of calling `git_index_add` in a loop, use the new
      `git_index_fill` internal API to fill the index with the initial staged
      entries.
      
      The new `fill` helper assumes that all the entries will be unique and
      valid, so it can append them at the end of the entries vector and only
      sort it once at the end. It performs no validation checks.
      
      This prevents the quadratic behavior caused by having to sort the
      entries list once after every insertion.
      Vicent Marti committed
  19. 25 Nov, 2015 8 commits
  20. 02 Nov, 2015 3 commits
  21. 28 Oct, 2015 1 commit