<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/libgit2.git/src, branch example_general</title>
<subtitle>github.com: libgit2/libgit2.git
</subtitle>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/libgit2.git/'/>
<entry>
<title>Merge pull request #4367 from pks-t/pks/peel-peeled-to-tag</title>
<updated>2017-10-06T23:22:22+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2017-10-06T23:22:22+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/libgit2.git/commit/?id=e2e3943db59e034cfbe082b321fe6205576ce348'/>
<id>e2e3943db59e034cfbe082b321fe6205576ce348</id>
<content type='text'>
refs: do not use peeled OID if peeling to a tag</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
refs: do not use peeled OID if peeling to a tag</pre>
</div>
</content>
</entry>
<entry>
<title>refs: do not use peeled OID if peeling to a tag</title>
<updated>2017-10-06T10:44:00+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2017-10-06T09:24:11+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/libgit2.git/commit/?id=b112b1e9adb6e90f77762aa2cb1eb376f709412f'/>
<id>b112b1e9adb6e90f77762aa2cb1eb376f709412f</id>
<content type='text'>
If a reference stored in a packed-refs file does not directly point to a
commit, tree or blob, the packed-refs file will also will include a
fully-peeled OID pointing to the first underlying object of that type.
If we try to peel a reference to an object, we will use that peeled OID
to speed up resolving the object.

As a reference for an annotated tag does not directly point to a commit,
tree or blob but instead to the tag object, the packed-refs file will
have an accomodating fully-peeled OID pointing to the object referenced
by that tag. When we use the fully-peeled OID pointing to the referenced
object when peeling, we obviously cannot peel that to the tag anymore.

Fix this issue by not using the fully-peeled OID whenever we want to
peel to a tag. Note that this does not include the case where we want to
resolve to _any_ object type. Existing code may make use from the fact
that we resolve those to commit objects instead of tag objects, even
though that behaviour is inconsistent between packed and loose
references. Furthermore, some tests of ours make the assumption that we
in fact resolve those references to a commit.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If a reference stored in a packed-refs file does not directly point to a
commit, tree or blob, the packed-refs file will also will include a
fully-peeled OID pointing to the first underlying object of that type.
If we try to peel a reference to an object, we will use that peeled OID
to speed up resolving the object.

As a reference for an annotated tag does not directly point to a commit,
tree or blob but instead to the tag object, the packed-refs file will
have an accomodating fully-peeled OID pointing to the object referenced
by that tag. When we use the fully-peeled OID pointing to the referenced
object when peeling, we obviously cannot peel that to the tag anymore.

Fix this issue by not using the fully-peeled OID whenever we want to
peel to a tag. Note that this does not include the case where we want to
resolve to _any_ object type. Existing code may make use from the fact
that we resolve those to commit objects instead of tag objects, even
though that behaviour is inconsistent between packed and loose
references. Furthermore, some tests of ours make the assumption that we
in fact resolve those references to a commit.
</pre>
</div>
</content>
</entry>
<entry>
<title>Use SOCK_CLOEXEC when creating sockets</title>
<updated>2017-10-04T03:19:10+00:00</updated>
<author>
<name>Andreas Smas</name>
<email>andreas@lonelycoder.com</email>
</author>
<published>2017-01-20T22:14:19+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/libgit2.git/commit/?id=9fe70c9e46fabae11ed7df8e9f97d3136802ba13'/>
<id>9fe70c9e46fabae11ed7df8e9f97d3136802ba13</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>cmake: fix static linking for bundled deps</title>
<updated>2017-09-20T13:26:26+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2017-09-06T05:38:48+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/libgit2.git/commit/?id=8c19969a88c3b6e72564e812537b15cbc0fb4cc0'/>
<id>8c19969a88c3b6e72564e812537b15cbc0fb4cc0</id>
<content type='text'>
Our bundled deps are being built as simple static libraries which are
then linked into the libgit2 library via `TARGET_LINK_LIBRARIES`. While
this works for a dynamically built libgit2 library, using this function
to link two static libraries does not have the expected outcome of
merging those static libraries into one big library. This leads to
symbols of our bundled deps being undefined in the resulting libgit2
archive.

As we have bumped our minimum CMake version to 2.8.11, we can now easily
make use of object libraries for our bundled dependencies. So build
instructions are still self-contained inside of the dependency
directories and the resulting object libraries can just be added to the
LIBGIT2_OBJECTS list, which will cause them to be linked into the final
resulting static library. This fixes the issue of undefined symbols.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Our bundled deps are being built as simple static libraries which are
then linked into the libgit2 library via `TARGET_LINK_LIBRARIES`. While
this works for a dynamically built libgit2 library, using this function
to link two static libraries does not have the expected outcome of
merging those static libraries into one big library. This leads to
symbols of our bundled deps being undefined in the resulting libgit2
archive.

As we have bumped our minimum CMake version to 2.8.11, we can now easily
make use of object libraries for our bundled dependencies. So build
instructions are still self-contained inside of the dependency
directories and the resulting object libraries can just be added to the
LIBGIT2_OBJECTS list, which will cause them to be linked into the final
resulting static library. This fixes the issue of undefined symbols.
</pre>
</div>
</content>
</entry>
<entry>
<title>cmake: always use object library for git2internal</title>
<updated>2017-09-20T13:26:26+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2017-09-05T13:09:34+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/libgit2.git/commit/?id=172a585f8860f87c80800add5bf6d47470bb0f7e'/>
<id>172a585f8860f87c80800add5bf6d47470bb0f7e</id>
<content type='text'>
As we have bumped our minimum CMake version to 2.8.11, we can now
unconditionally make use of object libraries. So remove the version
check for the git2internal object library and always use it.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As we have bumped our minimum CMake version to 2.8.11, we can now
unconditionally make use of object libraries. So remove the version
check for the git2internal object library and always use it.
</pre>
</div>
</content>
</entry>
<entry>
<title>cmake: distinguish libgit2 objects and sources</title>
<updated>2017-09-20T13:26:26+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2017-09-05T13:06:29+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/libgit2.git/commit/?id=1d9dd882b32cbaa5d4c8b0b39558ce8ac16274fa'/>
<id>1d9dd882b32cbaa5d4c8b0b39558ce8ac16274fa</id>
<content type='text'>
Distinguish variables keeping track of our internal libgit2 sources and
the final objects which shall be linked into the library. This will ease
the transition to use object libraries for our bundled dependencies
instead of linking them in.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Distinguish variables keeping track of our internal libgit2 sources and
the final objects which shall be linked into the library. This will ease
the transition to use object libraries for our bundled dependencies
instead of linking them in.
</pre>
</div>
</content>
</entry>
<entry>
<title>diff: cleanup hash ctx in `git_diff_patchid`</title>
<updated>2017-09-15T08:46:26+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2017-09-15T08:46:26+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/libgit2.git/commit/?id=046b081ab52e5b3f04f0931728099f743ca5a924'/>
<id>046b081ab52e5b3f04f0931728099f743ca5a924</id>
<content type='text'>
After initializing the hash context in `git_diff_patchid`, we never
proceed to call `git_hash_ctx_cleanup` on it. While this doesn't really
matter on most hash implementations, this causes a memory leak on Win32
due to CNG system requiring a `malloc` call.

Fix the memory leak by always calling `git_hash_ctx_cleanup` before
exiting.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After initializing the hash context in `git_diff_patchid`, we never
proceed to call `git_hash_ctx_cleanup` on it. While this doesn't really
matter on most hash implementations, this causes a memory leak on Win32
due to CNG system requiring a `malloc` call.

Fix the memory leak by always calling `git_hash_ctx_cleanup` before
exiting.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge pull request #4344 from slavikus/fix-dirty-buffer-in-git-push-update-tips</title>
<updated>2017-09-12T18:21:27+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2017-09-12T18:21:27+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/libgit2.git/commit/?id=e098b5f5071ca3eeee138785de1b8db3c1152f8d'/>
<id>e098b5f5071ca3eeee138785de1b8db3c1152f8d</id>
<content type='text'>
Clear the remote_ref_name buffer in git_push_update_tips()</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Clear the remote_ref_name buffer in git_push_update_tips()</pre>
</div>
</content>
</entry>
<entry>
<title>features.h: allow building without CMake-generated feature header</title>
<updated>2017-09-12T11:46:42+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2017-09-12T11:35:18+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/libgit2.git/commit/?id=26f531d3a3c00890348660f826df4fd21e53f9c9'/>
<id>26f531d3a3c00890348660f826df4fd21e53f9c9</id>
<content type='text'>
In commit a390a8464 (cmake: move defines into "features.h" header,
2017-07-01), we have introduced a new "features.h" header. This file is
being generated by the CMake build system based on how the libgit2 build
has been configured, replacing the preexisting method of simply setting
the defines inside of the CMake build system. This was done to help
splitting up the build instructions into multiple separate
subdirectories.

An overlooked shortcoming of this approach is that some projects making
use of libgit2 build the library with custom build systems, without
making use of CMake. For those users, the introduction of the
"features.h" file makes their life harder as they would have to also
generate this file.

Fix this issue by guarding all inclusions of the generated header file
by the `LIBGIT2_NO_FEATURES_H` define. Like this, other build systems
can skip the feature header and simply define all used features by
specifying `-D` flags for the compiler again.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In commit a390a8464 (cmake: move defines into "features.h" header,
2017-07-01), we have introduced a new "features.h" header. This file is
being generated by the CMake build system based on how the libgit2 build
has been configured, replacing the preexisting method of simply setting
the defines inside of the CMake build system. This was done to help
splitting up the build instructions into multiple separate
subdirectories.

An overlooked shortcoming of this approach is that some projects making
use of libgit2 build the library with custom build systems, without
making use of CMake. For those users, the introduction of the
"features.h" file makes their life harder as they would have to also
generate this file.

Fix this issue by guarding all inclusions of the generated header file
by the `LIBGIT2_NO_FEATURES_H` define. Like this, other build systems
can skip the feature header and simply define all used features by
specifying `-D` flags for the compiler again.
</pre>
</div>
</content>
</entry>
<entry>
<title>Clear the remote_ref_name buffer in git_push_update_tips()</title>
<updated>2017-09-11T18:34:41+00:00</updated>
<author>
<name>Slava Karpenko</name>
<email>slavikus@gmail.com</email>
</author>
<published>2017-09-11T18:34:41+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/libgit2.git/commit/?id=b34fc3fdf6071365cb5585ed929bd3dc714b67c0'/>
<id>b34fc3fdf6071365cb5585ed929bd3dc714b67c0</id>
<content type='text'>
If fetch_spec was a non-pattern, and it is not the first iteration of push_status vector, then git_refspec_transform would result in the new value appended via git_buf_puts to the previous iteration value.

Forcibly clearing the buffer on each iteration to prevent this behavior.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If fetch_spec was a non-pattern, and it is not the first iteration of push_status vector, then git_refspec_transform would result in the new value appended via git_buf_puts to the previous iteration value.

Forcibly clearing the buffer on each iteration to prevent this behavior.
</pre>
</div>
</content>
</entry>
</feed>
