- 13 Jul, 2018 1 commit
-
-
C++ style comment ("//") are not specified by the ISO C90 standard and thus do not conform to it. While libgit2 aims to conform to C90, we did not enforce it until now, which is why quite a lot of these non-conforming comments have snuck into our codebase. Do a tree-wide conversion of all C++ style comments to the supported C style comments to allow us enforcing strict C90 compliance in a later commit.
Patrick Steinhardt committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 04 Feb, 2018 3 commits
-
-
Edward Thomson committed
-
Virtual base building: ensure that the virtual base is created and revwalked in the same way as git.
Edward Thomson committed -
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
-
- 21 Jan, 2018 1 commit
-
-
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
-
- 09 Feb, 2017 1 commit
-
-
Test that shows that submodules are incorrectly considered in renames, and `git_merge_trees` will fail to lookup the submodule as a blob.
Edward Thomson committed
-
- 01 Jan, 2017 1 commit
-
-
When `GIT_MERGE_FIND_RENAMES` is set, provide a default for `rename_threshold` when it is unset.
Edward Thomson committed
-
- 26 May, 2016 1 commit
-
-
Edward Thomson committed
-
- 25 Nov, 2015 11 commits
-
-
Edward Thomson committed
-
When building a recursive merge base, allow conflicts to occur. Use the file (with conflict markers) as the common ancestor. The user has already seen and dealt with this conflict by virtue of having a criss-cross merge. If they resolved this conflict identically in both branches, then there will be no conflict in the result. This is the best case scenario. If they did not resolve the conflict identically in the two branches, then we will generate a new conflict. If the user is simply using standard conflict output then the results will be fairly sensible. But if the user is using a mergetool or using diff3 output, then the common ancestor will be a conflict file (itself with diff3 output, haha!). This is quite terrible, but it matches git's behavior.
Edward Thomson committed -
Edward Thomson committed
-
Edward Thomson committed
-
Edward Thomson committed
-
Edward Thomson committed
-
Edward Thomson committed
-
Edward Thomson committed
-
Edward Thomson committed
-
Add a simple recursive test - where multiple ancestors exist and creating a virtual merge base from them would prevent a conflict.
Edward Thomson committed -
Edward Thomson committed
-
- 22 Oct, 2015 1 commit
-
-
Provide a new merge option, GIT_MERGE_TREE_FAIL_ON_CONFLICT, which will stop on the first conflict and fail the merge operation with GIT_EMERGECONFLICT.
Edward Thomson committed
-
- 28 Aug, 2015 1 commit
-
-
Edward Thomson committed
-
- 28 May, 2015 1 commit
-
-
It's not always obvious the mapping between stage level and conflict-ness. More importantly, this can lead otherwise sane people to write constructs like `if (!git_index_entry_stage(entry))`, which (while technically correct) is unreadable. Provide a nice method to help avoid such messy thinking.
Edward Thomson committed
-
- 11 May, 2015 1 commit
-
-
Edward Thomson committed
-
- 16 Mar, 2015 3 commits
-
-
Jacques Germishuys committed
-
Jacques Germishuys committed
-
Jacques Germishuys committed
-
- 01 Oct, 2014 1 commit
-
-
Vicent Marti committed
-
- 01 Jul, 2014 1 commit
-
-
Edward Thomson committed
-
- 20 Mar, 2014 2 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
- 25 Jan, 2014 1 commit
-
-
This was not converted when we converted the rest, so do it now.
Carlos Martín Nieto committed
-
- 20 Jan, 2014 2 commits
-
-
The "merge none" (don't automerge) flag was only to aide in merge trivial tests. We can easily determine whether merge trivial resulted in a trivial merge or an automerge by examining the REUC after automerge has completed.
Edward Thomson committed -
The default merge_file level was XDL_MERGE_MINIMAL, which will produce conflicts where there should not be in the case where both sides were changed identically. Change the defaults to be more aggressive (XDL_MERGE_ZEALOUS) which will more aggressively compress non-conflicts. This matches git.git's defaults. Increase testing around reverting a previously reverted commit to illustrate this problem.
Edward Thomson committed
-
- 09 Dec, 2013 1 commit
-
-
Edward Thomson committed
-
- 03 Dec, 2013 1 commit
-
-
Edward Thomson committed
-
- 14 Nov, 2013 1 commit
-
-
Ben Straub committed
-