delta/libgit2.git/src/diff_stats.c, branch ethomson/github_actions github.com: libgit2/libgit2.git tree-wide: mark local functions as static 2020-06-09T12:57:06+00:00 Patrick Steinhardt ps@pks.im 2020-06-08T10:40:47+00:00 a6c9e0b367c4882ab0f8e78bd0ad4ab2904ac377 We've accumulated quite some functions which are never used outside of their respective code unit, but which are lacking the `static` keyword. Add it to reduce their linkage scope and allow the compiler to optimize better. 
We've accumulated quite some functions which are never used outside of
their respective code unit, but which are lacking the `static` keyword.
Add it to reduce their linkage scope and allow the compiler to optimize
better.
blob: use `git_object_size_t` for object size 2019-11-22T04:10:19+00:00 Edward Thomson ethomson@edwardthomson.com 2019-06-23T14:43:38+00:00 4334b1779f661bf9a77c68c928e970cf9d25b477 Instead of using a signed type (`off_t`) use a new `git_object_size_t` for the sizes of objects. 
Instead of using a signed type (`off_t`) use a new `git_object_size_t`
for the sizes of objects.
blob: validate that blob sizes fit in a size_t 2019-01-25T22:36:38+00:00 Edward Thomson ethomson@edwardthomson.com 2019-01-20T22:40:38+00:00 c6cac733c147ff800f78e7dff81f90d93369ea68 Our blob size is a `git_off_t`, which is a signed 64 bit int. This may be erroneously negative or larger than `SIZE_MAX`. Ensure that the blob size fits into a `size_t` before casting. 
Our blob size is a `git_off_t`, which is a signed 64 bit int.  This may
be erroneously negative or larger than `SIZE_MAX`.  Ensure that the blob
size fits into a `size_t` before casting.
git_error: use new names in internal APIs and usage 2019-01-22T22:30:35+00:00 Edward Thomson ethomson@edwardthomson.com 2018-12-27T19:47:34+00:00 f673e232afe22eb865cdc915e55a2df6493f0fbb Move to the `git_error` name in the internal API for error-related functions. 
Move to the `git_error` name in the internal API for error-related
functions.
diff_stats: use git's formatting of renames with common directories 2018-10-04T09:26:24+00:00 Patrick Steinhardt ps@pks.im 2018-10-04T09:19:28+00:00 e5090ee329aecdc2a298e442868cbf1d4b10d0e9 In cases where a file gets renamed such that the directories containing it previous and after the rename have a common prefix, then git will avoid printing this prefix twice and instead format the rename as "prefix/{old => new}". We currently didn't do anything like that, but simply printed "prefix/old -> prefix/new". Adjust our behaviour to instead match upstream. Adjust the test for this behaviour to expect the new format. 
In cases where a file gets renamed such that the directories containing
it previous and after the rename have a common prefix, then git will
avoid printing this prefix twice and instead format the rename as
"prefix/{old => new}". We currently didn't do anything like that, but
simply printed "prefix/old -> prefix/new".

Adjust our behaviour to instead match upstream. Adjust the test for this
behaviour to expect the new format.
Make sure to always include "common.h" first 2017-07-03T08:51:48+00:00 Patrick Steinhardt ps@pks.im 2017-06-30T11:39:01+00:00 0c7f49dd4316b332f30b4ea72a657bace41e1245 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. 
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 branch 'pr/3809' 2016-10-09T15:05:48+00:00 Edward Thomson ethomson@github.com 2016-10-09T15:05:48+00:00 610cff13a31964eeb2264a452424e1e3d49accc3 






make git_diff_stats_to_buf not show 0 insertions or 0 deletions
2016-10-09T15:03:00+00:00

Sim Domingo
sim@github.com

2016-06-02T15:18:31+00:00

dc5cfdbab957a08f3ddda9889f68c81011eb1900












patch: `patch_diff` -> `patch_generated`
2016-05-26T18:01:08+00:00

Edward Thomson
ethomson@microsoft.com

2015-11-24T20:19:59+00:00

8d44f8b78f7929c86b9e37acfe40fe707815bca6












patch: abstract patches into diff'ed and parsed
2016-05-26T18:01:04+00:00

Edward Thomson
ethomson@edwardthomson.com

2015-09-11T12:37:12+00:00

804d5fe9f59f4d8548da9f650bc43050951f26d7

Patches can now come from a variety of sources - either internally
generated (from diffing two commits) or as the results of parsing
some external data.





Patches can now come from a variety of sources - either internally
generated (from diffing two commits) or as the results of parsing
some external data.