delta/libgit2.git/tests/merge/workdir, branch ethomson/https_proxy github.com: libgit2/libgit2.git object_type: use new enumeration names 2018-12-01T11:54:57+00:00 Edward Thomson ethomson@edwardthomson.com 2018-11-28T14:26:57+00:00 168fe39bea3368972a8b1a33d5908e73bc790c18 Use the new object_type enumeration names within the codebase. 
Use the new object_type enumeration names within the codebase.
Merge pull request #4770 from tiennou/feature/merge-analysis-any-branch 2018-11-30T08:46:14+00:00 Patrick Steinhardt ps@pks.im 2018-11-30T08:46:14+00:00 0ddc60944ca4727246414e8bcf3170fe8286f854 Allow merge analysis against any reference 
Allow merge analysis against any reference
 Merge branch 'issue-4203' 2018-10-20T19:18:04+00:00 Edward Thomson ethomson@edwardthomson.com 2018-10-20T19:18:04+00:00 a2f9f94bbd2ae6d3a8e7273daa16fe77803f0c99 






merge: make analysis possible against a non-HEAD reference
2018-10-19T18:39:17+00:00

Etienne Samson
samson.etienne@gmail.com

2018-08-25T01:47:39+00:00

6e9fb040d9ea521f855257736369f42463cc45e8

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.





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.







Merge pull request #4702 from tiennou/fix/coverity
2018-07-20T10:56:49+00:00

Patrick Steinhardt
ps@pks.im

2018-07-20T10:56:49+00:00

0652abaaeaff768e78a65464e59bd1896ce2f6ce

Assorted Coverity fixes




Assorted Coverity fixes






treewide: remove use of C++ style comments
2018-07-13T06:25:12+00:00

Patrick Steinhardt
ps@pks.im

2018-06-25T09:56:52+00:00

9994cd3f0ffcd7b28d26c82ecb6564bc4072dc2a

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.





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.







tests: add missing cl_git_pass to tests
2018-07-06T20:24:21+00:00

Etienne Samson
samson.etienne@gmail.com

2018-07-01T10:04:27+00:00

8455a2709f8c2fabf0df775a193b9ef72bb21e43

Reported by Coverity, CID 1393678-1393697.




Reported by Coverity, CID 1393678-1393697.






Convert usage of `git_buf_free` to new `git_buf_dispose`
2018-06-10T17:34:37+00:00

Patrick Steinhardt
ps@pks.im

2018-02-08T11:14:48+00:00

ecf4f33a4e327a91496f72816f9f02d923e5af05












merge: reverse merge bases for recursive merge
2018-02-04T10:29:41+00:00

Edward Thomson
ethomson@edwardthomson.com

2018-01-21T18:05:45+00:00

b924df1eadfaf33285d8020c50cb18ddde1a8165

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.





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 markers
2018-01-21T11:47:43+00:00

Edward Thomson
ethomson@edwardthomson.com

2018-01-20T19:41:28+00:00

185b0d0823869bf180bb1d3541dd1dc0ca2447fe

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.





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.