summaryrefslogtreecommitdiff
path: root/src/merge.c
Commit message (Collapse)AuthorAgeFilesLines
* oidmap: introduce high-level setter for key/value pairsPatrick Steinhardt2019-02-151-3/+1
| | | | | | | | | | | | | | | Currently, one would use either `git_oidmap_insert` to insert key/value pairs into a map or `git_oidmap_put` to insert a key only. These function have historically been macros, which is why their syntax is kind of weird: instead of returning an error code directly, they instead have to be passed a pointer to where the return value shall be stored. This does not match libgit2's common idiom of directly returning error codes.Furthermore, `git_oidmap_put` is tightly coupled with implementation details of the map as it exposes the index of inserted entries. Introduce a new function `git_oidmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert all trivial callers of `git_oidmap_insert` and `git_oidmap_put` to make use of it.
* oidmap: introduce high-level getter for valuesPatrick Steinhardt2019-02-151-12/+6
| | | | | | | | | | | | | | The current way of looking up an entry from a map is tightly coupled with the map implementation, as one first has to look up the index of the key and then retrieve the associated value by using the index. As a caller, you usually do not care about any indices at all, though, so this is more complicated than really necessary. Furthermore, it invites for errors to happen if the correct error checking sequence is not being followed. Introduce a new high-level function `git_oidmap_get` that takes a map and a key and returns a pointer to the associated value if such a key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can trivially be converted.
* maps: use uniform lifecycle management functionsPatrick Steinhardt2019-02-151-2/+2
| | | | | | | | | | | | | | | | Currently, the lifecycle functions for maps (allocation, deallocation, resize) are not named in a uniform way and do not have a uniform function signature. Rename the functions to fix that, and stick to libgit2's naming scheme of saying `git_foo_new`. This results in the following new interface for allocation: - `int git_<t>map_new(git_<t>map **out)` to allocate a new map, returning an error code if we ran out of memory - `void git_<t>map_free(git_<t>map *map)` to free a map - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map This commit also fixes all existing callers.
* git_error: use new names in internal APIs and usageEdward Thomson2019-01-221-37/+37
| | | | | Move to the `git_error` name in the internal API for error-related functions.
* object_type: use new enumeration namesethomson/index_fixesEdward Thomson2018-12-011-3/+3
| | | | Use the new object_type enumeration names within the codebase.
* Merge pull request #4770 from tiennou/feature/merge-analysis-any-branchPatrick Steinhardt2018-11-301-10/+35
|\ | | | | Allow merge analysis against any reference
| * merge: assert that we're passed sane parametersEtienne Samson2018-10-191-2/+2
| |
| * merge: make analysis possible against a non-HEAD referenceEtienne Samson2018-10-191-8/+33
| | | | | | | | | | | | | | This moves the current merge analysis code into a more generic version that can work against any reference. Also change the tests to check returned analysis values exactly.
* | khash: remove intricate knowledge of khash typesPatrick Steinhardt2018-11-281-2/+2
| | | | | | | | | | | | | | Instead of using the `khiter_t`, `git_strmap_iter` and `khint_t` types, simply use `size_t` instead. This decouples code from the khash stuff and makes it possible to move the khash includes into the implementation files.
* | Merge branch 'issue-4203'Edward Thomson2018-10-201-1/+6
|\ \ | |/ |/|
| * merge: don't leak the index during reloadsethomson/issue-4203Edward Thomson2018-10-201-3/+4
| |
| * merge: add error handling for index reloadEtiene Dalcol2017-11-111-3/+4
| | | | | | | | Cleans up should git_repository_index or git_index_read fail
| * merge: reload index before git_mergeGreg Collinge2017-11-111-0/+3
| | | | | | | | | | | | | | | | If the index in memory is different from the index on the disk, previously merge would abort with GIT_ECONFLICT. Reload the index before merging to fix this. Fixes #4203
* | Convert usage of `git_buf_free` to new `git_buf_dispose`Patrick Steinhardt2018-06-101-7/+7
| |
* | merge: virtual commit should be last argument to merge-baseethomson/recursiveTyrie Vella2018-02-041-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | merge: reverse merge bases for recursive mergeEdward Thomson2018-02-041-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | merge: recursive uses larger conflict markersEdward Thomson2018-01-211-0/+1
|/ | | | | | | | | | | 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.
* Make sure to always include "common.h" firstPatrick Steinhardt2017-07-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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.
* merge: fix potential free of uninitialized memoryPatrick Steinhardt2017-06-211-1/+1
| | | | | | | | | | 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`.
* merge: perform exact rename detection in linear timeMichael Tesch2017-05-171-31/+152
| | | | | | | | | The current exact rename detection has order n^2 complexity. We can do better by using a map to first aggregate deletes and using that to match deletes to adds. This results in a substantial performance improvement for merges with a large quantity of adds and deletes.
* Merge branch 'pr/3957'Edward Thomson2017-03-231-0/+20
|\
| * merge: indentation fixupEdward Thomson2017-03-231-1/+1
| |
| * Perf: Don't perform merge operations for trivial merges.Arthur Schreiber2016-10-181-0/+20
| | | | | | | | When one side of a merge is treesame to the ancestor, we can take the other side and skip all the expensive merge operations. This optimization can only be performed when the generation of REUC extension data is skipped.
* | repository: rename `path_repository` and `path_gitlink`Patrick Steinhardt2017-02-131-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | merge: don't do rename detection on submodulesEdward Thomson2017-02-091-1/+1
| |
* | Merge pull request #4061 from libgit2/ethomson/merge_optsCarlos Martín Nieto2017-01-141-4/+4
|\ \ | | | | | | merge: set default rename threshold
| * | merge: set default rename thresholdEdward Thomson2017-01-011-4/+4
| | | | | | | | | | | | | | | When `GIT_MERGE_FIND_RENAMES` is set, provide a default for `rename_threshold` when it is unset.
* | | giterr_set: consistent error messagesEdward Thomson2016-12-291-8/+8
|/ / | | | | | | | | | | | | | | Error messages should be sentence fragments, and therefore: 1. Should not begin with a capital letter, 2. Should not conclude with punctuation, and 3. Should not end a sentence and begin a new one
* | common: use PRIuZ for size_t in `giterr_set` callsPatrick Steinhardt2016-11-141-1/+1
|/
* git_diff_generated: abstract generated diffsEdward Thomson2016-05-261-0/+2
|
* Ignore submodules when checking for merge conflicts in the workdir.Jason Haslam2016-05-261-0/+1
|
* merge drivers: handle configured but not found driverEdward Thomson2016-03-171-4/+13
|
* merge driver: remove `check` callbackEdward Thomson2016-03-171-19/+18
| | | | | | Since the `apply` callback can defer, the `check` callback is not necessary. Removing the `check` callback further makes the `payload` unnecessary along with the `cleanup` callback.
* merge driver: correct global initializationEdward Thomson2016-03-171-0/+1
|
* merge driver: get a pointer to favorEdward Thomson2016-03-171-1/+1
|
* merge driver: correct indentationEdward Thomson2016-03-171-13/+13
|
* merge driver: allow custom default driverEdward Thomson2016-03-171-6/+34
| | | | | | Allow merge users to configure a custom default merge driver via `git_merge_options`. Similarly, honor the `merge.default` configuration option.
* merge driver: introduce custom merge driversEdward Thomson2016-03-171-78/+112
| | | | | | | | Consumers can now register custom merged drivers with `git_merge_driver_register`. This allows consumers to support the merge drivers, as configured in `.gitattributes`. Consumers will be asked to perform the file-level merge when a custom driver is configured.
* Fix rebase bug and include test for merge=unionStan Hu2016-03-171-1/+1
|
* Support union merges via .gitattributes fileStan Hu2016-03-171-0/+26
|
* Horrible fix for #3173.Arthur Schreiber2016-02-111-7/+7
|
* merge: fix memory leakPatrick Steinhardt2016-02-081-3/+2
|
* merge: Use `git_index__fill` to populate the indexvmg/index-fillVicent Marti2015-12-161-5/+2
| | | | | | | | | | | | | 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.
* recursive merge: add a recursion limitEdward Thomson2015-11-251-3/+10
|
* merge: handle conflicts in recursive base buildingEdward Thomson2015-11-251-19/+48
| | | | | | | | | | | | | | | | | 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.
* merge: use annotated commits for recursionEdward Thomson2015-11-251-59/+83
| | | | | | | Use annotated commits to act as our virtual bases, instead of regular commits, to avoid polluting the odb with virtual base commits and trees. Instead, build an annotated commit with an index and pointers to the commits that it was merged from.
* merge: merge annotated commits instead of regular commitsEdward Thomson2015-11-251-156/+125
|
* merge: octopus merge common ancestors when >2Edward Thomson2015-11-251-119/+165
| | | | | | When there are more than two common ancestors, continue merging the virtual base with the additional common ancestors, effectively octopus merging a new virtual base.
* merge: compute octopus merge basesEdward Thomson2015-11-251-89/+100
|
* merge: build virtual base of multiple merge basesEdward Thomson2015-11-251-10/+123
| | | | | When the commits to merge have multiple common ancestors, build a "virtual" base tree by merging the common ancestors.
View Lorry Controller Status