- 10 Jan, 2021 1 commit
-
-
This change introduces `git_commit_graph_entry_find()` and `git_commit_graph_entry_parent()`. These two functions allow a much faster lookup of commits by ID, since the ODB does not need to be consulted, the commit object does not need to be inflated, and the contents of the commit object do not need to be parsed. Part of: #5757
lhchavez committed
-
- 05 Nov, 2018 1 commit
-
-
Patch application need not be on an unmodified file; applying to an already changed file is supported provided the patch still applies cleanly. Add tests that modifies the contents of a file then applies the patch and ensures that the patch applies cleanly, and the original changes are also kept.
Edward Thomson committed
-
- 04 Feb, 2018 2 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
- 25 Nov, 2015 7 commits
-
-
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
-
Add a simple recursive test - where multiple ancestors exist and creating a virtual merge base from them would prevent a conflict.
Edward Thomson committed
-