|
c6cac733
|
2019-01-20T22:40:38
|
|
blob: validate that blob sizes fit in a size_t
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.
|
|
|
f673e232
|
2018-12-27T13:47:34
|
|
git_error: use new names in internal APIs and usage
Move to the `git_error` name in the internal API for error-related
functions.
|
|
e5090ee3
|
2018-10-04T11:19:28
|
|
diff_stats: use git's formatting of renames with common directories
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.
|
|
|
0c7f49dd
|
2017-06-30T13:39:01
|
|
Make sure to always include "common.h" first
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.
|
|
610cff13
|
2016-10-09T16:05:48
|
|
Merge branch 'pr/3809'
|
|
dc5cfdba
|
2016-06-02T23:18:31
|
|
make git_diff_stats_to_buf not show 0 insertions or 0 deletions
|
|
8d44f8b7
|
2015-11-24T15:19:59
|
|
patch: `patch_diff` -> `patch_generated`
|
|
|
804d5fe9
|
2015-09-11T08:37:12
|
|
patch: abstract patches into diff'ed and parsed
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.
|
|
ce3b71d9
|
2014-05-12T10:28:45
|
|
Don't scale diff stat when not needed
|
|
|
e60883c8
|
2014-04-22T12:59:31
|
|
Replace math fns with simpler integer math
|
|
|
8d09efa2
|
2014-04-22T12:33:27
|
|
Use git_diff_get_stats in example/diff + refactor
This takes the `--stat` and related example options in the example
diff.c program and converts them to use the `git_diff_get_stats`
API which nicely formats stats for you.
I went to add bar-graph scaling to the stats formatter and noticed
that the `git_diff_stats` structure was holding on to all of the
`git_patch` objects. Unfortunately, each of these objects keeps
the full text of the diff in memory, so this is very expensive. I
ended up modifying `git_diff_stats` to keep just the data that it
needs to keep and allowed it to release the patches. Then, I added
width scaling to the output on top of that.
In making the diff example program match 'git diff' output, I ended
up removing an newline from the sumamry output which I then had to
compensate for in the email formatting to match the expectations.
Lastly, I went through and refactored the tests to use a couple of
helper functions and reduce the overall amount of code there.
|
|
360314c9
|
2014-04-11T19:03:29
|
|
Introduce git_diff_get_stats, git_diff_stats_files_changed, git_diff_stats_insertions, git_diff_stats_deletions and git_diff_stats_to_buf
|