|
f0e693b1
|
2021-09-07T17:53:49
|
|
str: introduce `git_str` for internal, `git_buf` is external
libgit2 has two distinct requirements that were previously solved by
`git_buf`. We require:
1. A general purpose string class that provides a number of utility APIs
for manipulating data (eg, concatenating, truncating, etc).
2. A structure that we can use to return strings to callers that they
can take ownership of.
By using a single class (`git_buf`) for both of these purposes, we have
confused the API to the point that refactorings are difficult and
reasoning about correctness is also difficult.
Move the utility class `git_buf` to be called `git_str`: this represents
its general purpose, as an internal string buffer class. The name also
is an homage to Junio Hamano ("gitstr").
The public API remains `git_buf`, and has a much smaller footprint. It
is generally only used as an "out" param with strict requirements that
follow the documentation. (Exceptions exist for some legacy APIs to
avoid breaking callers unnecessarily.)
Utility functions exist to convert a user-specified `git_buf` to a
`git_str` so that we can call internal functions, then converting it
back again.
|
|
|
ba3595af
|
2021-09-13T16:25:00
|
|
diff: deprecate diff_format_email
`git_diff_format_email` is deprecated in favor of `git_email_create`.
|
|
|
3f13d2e8
|
2021-09-13T10:36:48
|
|
email: allow `git_diff_commit_as_email` to take 0 as patch index
Allow a `0` patch index and `0` patch count; in this case, simply don't
display these in the email.
|
|
e72ade87
|
2020-04-18T11:32:56
|
|
Fix binary diff showing /dev/null
Fixes issue where a changed binary file's content in the working
tree isn't displayed correctly, instead showing an oid of zero,
and with its path being reported incorrectly as "/dev/null".
|
|
ecf4f33a
|
2018-02-08T11:14:48
|
|
Convert usage of `git_buf_free` to new `git_buf_dispose`
|
|
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
|
|
|
1a79cd95
|
2016-04-26T01:18:01
|
|
patch: show copy information for identical copies
When showing copy information because we are duplicating contents,
for example, when performing a `diff --find-copies-harder -M100 -B100`,
then show copy from/to lines in a patch, and do not show context.
Ensure that we can also parse such patches.
|
|
|
9be638ec
|
2016-04-19T15:12:18
|
|
git_diff_generated: abstract generated diffs
|
|
e23efa6d
|
2016-03-03T21:03:10
|
|
tests: take the version from our define
|
|
|
254e0a33
|
2015-11-24T13:43:43
|
|
diff: include commit message when formatting patch
When formatting a patch as email we do not include the commit's
message in the formatted patch output. Implement this and add a
test that verifies behavior.
|
|
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.
|
|
d8cc1fb6
|
2014-04-11T19:15:15
|
|
Introduce git_diff_format_email and git_diff_commit_as_email
|
|
|
39206ca2
|
2014-04-14T17:12:56
|
|
Added a test case for formatting a binary patch e-mail
|
|
|
a56b418d
|
2014-04-11T22:57:15
|
|
Sanitize git_diff_format_email_options' summary parameter
It will form part of the subject line and should thus be one line.
|