examples

Branch :

Log

Commit	Date	Message
605f34a0	2026-05-12 23:23:21	sha256: it's what's for breakfast Make the SHA256 support on by default.
f6508bc5	2026-06-06 11:00:26	Add option to filter revwalk based on pathspec This is required in order to later on accelerate the walk by using bloom filters
766d62bc	2026-05-22 13:45:29	examples: don't system() anything
57877524	2026-05-16 20:50:41	Merge pull request #7150 from ambv/rebase-example feat: Add an example for the rebase API
196c4659	2025-12-31 16:30:23	examples: correct `git_commit_time` comment
54d142d9	2025-10-21 16:07:02	remote example: fix problem.strings[] indexing
bc5a7e93	2025-10-21 16:03:55	rebase example: add a new demo of the rebasing API This demonstrates the interesting bits of rebasing, i.e. what happens in the case of a conflict and how to abort.
c26d8a8b	2025-01-01 15:47:43	sha256: further API simplifications for OID parsing Introduce `git_oid_from_string`, `git_oid_from_prefix`, and `git_oid_from_raw`, all of which take a `git_oid_t` that indicates what type of OID should be parsed (SHA1 or SHA256). This allows users to continue to use `git_oid_fromstr` without any code changes, while remaining in a SHA1 world. Note that these are not perfect analogs to the `fromstr` APIs. * `git_oid_from_string` now takes a NUL terminated string, instead of allowing for non-NUL terminated strings. Adding a NUL check feels like an important safety consideration for C strings. * `git_oid_from_prefix` should be used for an OID substring and length. Previous usages of `git_oid_fromstr` with non-NUL terminated strings should move to `git_oid_from_prefix` with the hexsize for the given OID type.
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.
9aa5faa3	2024-12-16 16:58:50	indexer: move oid_type into the opts structure Object ID type should be an option within the options structure; move it there.