<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/libgit2.git/src/patch_generate.c, branch ethomson/proxy</title>
<subtitle>github.com: libgit2/libgit2.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/'/>
<entry>
<title>Convert usage of `git_buf_free` to new `git_buf_dispose`</title>
<updated>2018-06-10T17:34:37+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2018-02-08T11:14:48+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=ecf4f33a4e327a91496f72816f9f02d923e5af05'/>
<id>ecf4f33a4e327a91496f72816f9f02d923e5af05</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>refcount: make refcounting conform to aliasing rules</title>
<updated>2017-11-18T16:06:14+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2017-11-18T15:43:11+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=585b5dacc7f440a163c20117cfa35fb714a7ba7b'/>
<id>585b5dacc7f440a163c20117cfa35fb714a7ba7b</id>
<content type='text'>
Strict aliasing rules dictate that for most data types, you are not
allowed to cast them to another data type and then access the casted
pointers. While this works just fine for most compilers, technically we
end up in undefined behaviour when we hurt that rule.

Our current refcounting code makes heavy use of casting and thus
violates that rule. While we didn't have any problems with that code,
Travis started spitting out a lot of warnings due to a change in their
toolchain. In the refcounting case, the code is also easy to fix:
as all refcounting-statements are actually macros, we can just access
the `rc` field directly instead of casting.

There are two outliers in our code where that doesn't work. Both the
`git_diff` and `git_patch` structures have specializations for generated
and parsed diffs/patches, which directly inherit from them. Because of
that, the refcounting code is only part of the base structure and not of
the children themselves. We can help that by instead passing their base
into `GIT_REFCOUNT_INC`, though.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Strict aliasing rules dictate that for most data types, you are not
allowed to cast them to another data type and then access the casted
pointers. While this works just fine for most compilers, technically we
end up in undefined behaviour when we hurt that rule.

Our current refcounting code makes heavy use of casting and thus
violates that rule. While we didn't have any problems with that code,
Travis started spitting out a lot of warnings due to a change in their
toolchain. In the refcounting case, the code is also easy to fix:
as all refcounting-statements are actually macros, we can just access
the `rc` field directly instead of casting.

There are two outliers in our code where that doesn't work. Both the
`git_diff` and `git_patch` structures have specializations for generated
and parsed diffs/patches, which directly inherit from them. Because of
that, the refcounting code is only part of the base structure and not of
the children themselves. We can help that by instead passing their base
into `GIT_REFCOUNT_INC`, though.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge pull request #4288 from pks-t/pks/include-fixups</title>
<updated>2017-08-15T17:35:47+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2017-08-15T17:35:47+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=1560b5808e71af170d3a0c09f35cab7e973df5a5'/>
<id>1560b5808e71af170d3a0c09f35cab7e973df5a5</id>
<content type='text'>
Include fixups</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Include fixups</pre>
</div>
</content>
</entry>
<entry>
<title>patch_generate: represent buffers as void pointers</title>
<updated>2017-07-10T09:46:25+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2017-07-10T09:42:26+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=9093ced6a10a050c6eee31a4ef3b9251f58ce561'/>
<id>9093ced6a10a050c6eee31a4ef3b9251f58ce561</id>
<content type='text'>
Pointers to general data should usually be used as a void pointer such
that it is possible to hand in variables of a different pointer type
without the need to cast. This is the same when creating patches from
buffers, where the buffers may contain arbitrary data. Instead of
requiring the caller to care whether his buffer is e.g. `char *` or
`unsigned char *`, we should instead just accept a `void *`. This is
also consistent in how we tread other types like for example `git_blob`,
which also just has a void pointer as its raw contents.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pointers to general data should usually be used as a void pointer such
that it is possible to hand in variables of a different pointer type
without the need to cast. This is the same when creating patches from
buffers, where the buffers may contain arbitrary data. Instead of
requiring the caller to care whether his buffer is e.g. `char *` or
`unsigned char *`, we should instead just accept a `void *`. This is
also consistent in how we tread other types like for example `git_blob`,
which also just has a void pointer as its raw contents.
</pre>
</div>
</content>
</entry>
<entry>
<title>Make sure to always include "common.h" first</title>
<updated>2017-07-03T08:51:48+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2017-06-30T11:39:01+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=0c7f49dd4316b332f30b4ea72a657bace41e1245'/>
<id>0c7f49dd4316b332f30b4ea72a657bace41e1245</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>patch_generate: move `git_diff_foreach` to diff.c</title>
<updated>2017-03-14T12:08:51+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2017-03-14T12:06:25+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=62a2fc06d4af781c456bf753d6ada16df682df55'/>
<id>62a2fc06d4af781c456bf753d6ada16df682df55</id>
<content type='text'>
Now that the `git_diff_foreach` function does not depend on internals of
the `git_patch_generated` structure anymore, we can easily move it to
the actual diff code.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now that the `git_diff_foreach` function does not depend on internals of
the `git_patch_generated` structure anymore, we can easily move it to
the actual diff code.
</pre>
</div>
</content>
</entry>
<entry>
<title>patch_generate: fix `git_diff_foreach` only working with generated diffs</title>
<updated>2017-03-14T12:08:28+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2017-03-14T09:37:47+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=ace3508f4c2ad7f821bc79d0b34e7ac55fac4d12'/>
<id>ace3508f4c2ad7f821bc79d0b34e7ac55fac4d12</id>
<content type='text'>
The current logic of `git_diff_foreach` makes the assumption that all
diffs passed in are actually derived from generated diffs. With these
assumptions we try to derive the actual diff by inspecting either the
working directory files or blobs of a repository. This obviously cannot
work for diffs parsed from a file, where we do not necessarily have a
repository at hand.

Since the introduced split of parsed and generated patches, there are
multiple functions which help us to handle patches generically, being
indifferent from where they stem from. Use these functions and remove
the old logic specific to generated patches. This allows re-using the
same code for invoking the callbacks on the deltas.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The current logic of `git_diff_foreach` makes the assumption that all
diffs passed in are actually derived from generated diffs. With these
assumptions we try to derive the actual diff by inspecting either the
working directory files or blobs of a repository. This obviously cannot
work for diffs parsed from a file, where we do not necessarily have a
repository at hand.

Since the introduced split of parsed and generated patches, there are
multiple functions which help us to handle patches generically, being
indifferent from where they stem from. Use these functions and remove
the old logic specific to generated patches. This allows re-using the
same code for invoking the callbacks on the deltas.
</pre>
</div>
</content>
</entry>
<entry>
<title>patch_generate: remove duplicated logic</title>
<updated>2017-03-14T11:04:04+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2017-03-14T09:01:56+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=41019152a03815be27139764ceed05fd5a0e4b58'/>
<id>41019152a03815be27139764ceed05fd5a0e4b58</id>
<content type='text'>
Under the existing logic, we try to load patch contents differently,
depending on whether the patch files stem from the working directory or
not. But actually, the executed code paths are completely equal to each
other -- so we were always the code despite the condition.

Remove the condition altogether and conflate both code paths.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Under the existing logic, we try to load patch contents differently,
depending on whether the patch files stem from the working directory or
not. But actually, the executed code paths are completely equal to each
other -- so we were always the code despite the condition.

Remove the condition altogether and conflate both code paths.
</pre>
</div>
</content>
</entry>
<entry>
<title>patch: memory leak of patch.base.diff_opts.new|old_prefix</title>
<updated>2017-01-13T20:48:20+00:00</updated>
<author>
<name>Etienne Samson</name>
<email>samson.etienne@gmail.com</email>
</author>
<published>2016-12-26T21:13:35+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=b0014063b229132b358e56b40892807d1ee5df9d'/>
<id>b0014063b229132b358e56b40892807d1ee5df9d</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>giterr_set: consistent error messages</title>
<updated>2016-12-29T12:26:03+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@github.com</email>
</author>
<published>2016-12-29T12:25:15+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=909d5494368a00809bc42f4780e86f4dd66e4422'/>
<id>909d5494368a00809bc42f4780e86f4dd66e4422</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
</feed>
