| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Use the new object_type enumeration names within the codebase.
|
|\
| |
| | |
Allow merge analysis against any reference
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| | |
Adds a test case for the issue #4203, when diverging indexes
on memory and disk cause git merge to abort with GIT_ECONFLICT
|
|\ \
| | |
| | | |
Assorted Coverity fixes
|
| | |
| | |
| | | |
Reported by Coverity, CID 1393678-1393697.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Virtual base building: ensure that the virtual base is created and
revwalked in the same way as git.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | | |
Conflict markers should match EOL style in conflicting files
|
| | |
| | |
| | |
| | |
| | |
| | | |
Ensure that when the files being merged have CR/LF line endings that the
conflict markers produced in the conflict file also have CR/LF line
endings.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
| |
modify/deltete conflict
|
|
|
|
|
| |
Test that shows that submodules are incorrectly considered in renames,
and `git_merge_trees` will fail to lookup the submodule as a blob.
|
|
|
|
|
| |
When `GIT_MERGE_FIND_RENAMES` is set, provide a default for
`rename_threshold` when it is unset.
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Ensure that setting the merge attribute forces the built-in default
`text` driver and does *not* honor the `merge.default` configuration
option. Further ensure that unsetting the merge attribute forces
a conflict (the `binary` driver).
|
| |
|
|
|
|
|
| |
When a `check` or `apply` callback function returns `GIT_EMERGECONFLICT`
stop and product a conflict.
|
|
|
|
|
| |
When a `check` or `apply` callback function returns `GIT_PASSTHROUGH`,
move on to the default merge driver.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Update unit test to use newfangled `st_ctime_nsec`, which provides
indirection to the platform-correct name.
|
|
|
|
|
| |
Windows defines `timeval` with `long`, which we cannot
sanely cope with. Instead, use a custom timeval struct.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Add a simple recursive test - where multiple ancestors exist and
creating a virtual merge base from them would prevent a conflict.
|
| |
|
|\
| |
| | |
git_index_entry__init_from_stat: set nsec fields in entry stats
|
| |
| |
| |
| |
| |
| | |
This allows us to remove OS checks from source code, instead relying
on CMake to detect whether or not `struct stat` has the nanoseconds
members we rely on.
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
|/
|
|
|
|
|
|
| |
xdiff craps the bed on large files. Treat very large files as binary,
so that it doesn't even have to try.
Refactor our merge binary handling to better match git.git, which
looks for a NUL in the first 8000 bytes.
|
| |
|