diff.c

Branch :

Log

Commit	Date	Message
56e2a856	2024-12-23 11:53:23	sha256: simplify API changes for sha256 support There are several places where users may want to specify the type of object IDs (sha1 or sha256) that should be used, for example, when dealing with repositories, indexes, etc. However, given that sha256 support remains disappointingly uncommon in the wild, we should avoid hard API breaks when possible. Instead, update these APIs to have an "extended" format (eg, `git_odb_open_ext`) that provides an options structure with oid type information. This allows callers who do care about sha256 to use it, and callers who do not to avoid gratuitous API breakage.
db2a794d	2023-04-07 15:28:58	diff: parse patches with sha256
f0e693b1	2021-09-07 17: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.
313908f9	2019-11-06 11:08:49	examples: normalize decls and usage of options structs
3be09b6c	2019-06-18 08:31:31	Compare buffers in diff example
ead10785	2019-01-24 11:31:49	examples: create common lg2 executable Inside of our networking example code, we have a git2 executable that acts as an entry point to all the different network examples. As such, it is kind of the same like the normal git(1) executable in that it simply arbitrates to the respective subcommands. Let's extend this approach and merge all examples into a single standalone lg2 executable. Instead of building an executable for all the existing examples we have, we now bundle them all inside of the lg2 one and let them be callable via subcommands. In the process, we can get rid of duplicated library initialization, deinitialization and repository discovery code. Instead of having each subcommand handle these on its own, we simply do it inside of the single main function now.
ecf4f33a	2018-02-08 11:14:48	Convert usage of `git_buf_free` to new `git_buf_dispose`
5c2a8361	2016-08-16 11:01:09	examples: diff: parse correct types for line-diffopts
799e22ea	2014-10-23 17:34:41	Rename git_threads_ to git_libgit2_ This describes their purpose better, as we now initialize ssl and some other global stuff in there. Calling the init function is not something which has been optional for a while now.
8d09efa2	2014-04-22 12: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.