]> git.proxmox.com Git - libgit2.git/blame - examples/general.c
Merge pull request #1342 from ghedo/development
[libgit2.git] / examples / general.c
CommitLineData
388f37b3
SC
1// [**libgit2**][lg] is a portable, pure C implementation of the Git core methods
2// provided as a re-entrant linkable library with a solid API, allowing you
932d1baf
KS
3// to write native speed custom Git applications in any language which
4// supports C bindings.
388f37b3 5//
2e6d8ec4
SC
6// This file is an example of using that API in a real, compilable C file.
7// As the API is updated, this file will be updated to demonstrate the
8// new functionality.
388f37b3
SC
9//
10// If you're trying to write something in C using [libgit2][lg], you will also want
ef41ab88 11// to check out the generated [API documentation][ap]. We've
388f37b3
SC
12// tried to link to the relevant sections of the API docs in each section in this file.
13//
14// **libgit2** only implements the core plumbing functions, not really the higher
15// level porcelain stuff. For a primer on Git Internals that you will need to know
16// to work with Git at this level, check out [Chapter 9][pg] of the Pro Git book.
17//
18// [lg]: http://libgit2.github.com
2e6d8ec4 19// [ap]: http://libgit2.github.com/libgit2
388f37b3 20// [pg]: http://progit.org/book/ch9-0.html
388f37b3
SC
21
22// ### Includes
23
24// Including the `git2.h` header will include all the other libgit2 headers that you need.
25// It should be the only thing you need to include in order to compile properly and get
26// all the libgit2 API.
27#include <git2.h>
28#include <stdio.h>
29
30int main (int argc, char** argv)
31{
32 // ### Opening the Repository
33
34 // There are a couple of methods for opening a repository, this being the simplest.
35 // There are also [methods][me] for specifying the index file and work tree locations, here
36 // we are assuming they are in the normal places.
37 //
2e6d8ec4 38 // [me]: http://libgit2.github.com/libgit2/#HEAD/group/repository
388f37b3 39 git_repository *repo;
0251733e 40 if (argc > 1) {
784b3b49 41 git_repository_open(&repo, argv[1]);
0251733e 42 } else {
784b3b49 43 git_repository_open(&repo, "/opt/libgit2-test/.git");
0251733e 44 }
388f37b3
SC
45
46 // ### SHA-1 Value Conversions
47
48 // For our first example, we will convert a 40 character hex value to the 20 byte raw SHA1 value.
49 printf("*Hex to Raw*\n");
50 char hex[] = "fd6e612585290339ea8bf39c692a7ff6a29cb7c3";
51
52 // The `git_oid` is the structure that keeps the SHA value. We will use this throughout the example
53 // for storing the value of the current SHA key we're working with.
54 git_oid oid;
784b3b49 55 git_oid_fromstr(&oid, hex);
388f37b3
SC
56
57 // Once we've converted the string into the oid value, we can get the raw value of the SHA.
0251733e 58 printf("Raw 20 bytes: [%.20s]\n", (&oid)->id);
388f37b3
SC
59
60 // Next we will convert the 20 byte raw SHA1 value to a human readable 40 char hex value.
61 printf("\n*Raw to Hex*\n");
62 char out[41];
63 out[40] = '\0';
64
65 // If you have a oid, you can easily get the hex value of the SHA as well.
66 git_oid_fmt(out, &oid);
67 printf("SHA hex string: %s\n", out);
68
69 // ### Working with the Object Database
70 // **libgit2** provides [direct access][odb] to the object database.
932d1baf
KS
71 // The object database is where the actual objects are stored in Git. For
72 // working with raw objects, we'll need to get this structure from the
388f37b3 73 // repository.
2e6d8ec4 74 // [odb]: http://libgit2.github.com/libgit2/#HEAD/group/odb
388f37b3 75 git_odb *odb;
2866c016 76 git_repository_odb(&odb, repo);
388f37b3
SC
77
78 // #### Raw Object Reading
79
80 printf("\n*Raw Object Read*\n");
81 git_odb_object *obj;
82 git_otype otype;
83 const unsigned char *data;
84 const char *str_type;
784b3b49 85 int error;
388f37b3
SC
86
87 // We can read raw objects directly from the object database if we have the oid (SHA)
88 // of the object. This allows us to access objects without knowing thier type and inspect
89 // the raw bytes unparsed.
784b3b49 90 error = git_odb_read(&obj, odb, &oid);
388f37b3
SC
91
92 // A raw object only has three properties - the type (commit, blob, tree or tag), the size
93 // of the raw data and the raw, unparsed data itself. For a commit or tag, that raw data
94 // is human readable plain ASCII text. For a blob it is just file contents, so it could be
95 // text or binary data. For a tree it is a special binary format, so it's unlikely to be
96 // hugely helpful as a raw object.
97 data = (const unsigned char *)git_odb_object_data(obj);
98 otype = git_odb_object_type(obj);
99
932d1baf 100 // We provide methods to convert from the object type which is an enum, to a string
388f37b3
SC
101 // representation of that value (and vice-versa).
102 str_type = git_object_type2string(otype);
932d1baf 103 printf("object length and type: %d, %s\n",
388f37b3
SC
104 (int)git_odb_object_size(obj),
105 str_type);
106
107 // For proper memory management, close the object when you are done with it or it will leak
108 // memory.
45e79e37 109 git_odb_object_free(obj);
388f37b3
SC
110
111 // #### Raw Object Writing
112
113 printf("\n*Raw Object Write*\n");
114
115 // You can also write raw object data to Git. This is pretty cool because it gives you
116 // direct access to the key/value properties of Git. Here we'll write a new blob object
117 // that just contains a simple string. Notice that we have to specify the object type as
118 // the `git_otype` enum.
784b3b49 119 git_odb_write(&oid, odb, "test data", sizeof("test data") - 1, GIT_OBJ_BLOB);
388f37b3
SC
120
121 // Now that we've written the object, we can check out what SHA1 was generated when the
122 // object was written to our database.
123 git_oid_fmt(out, &oid);
124 printf("Written Object: %s\n", out);
125
126 // ### Object Parsing
127 // libgit2 has methods to parse every object type in Git so you don't have to work directly
128 // with the raw data. This is much faster and simpler than trying to deal with the raw data
129 // yourself.
130
131 // #### Commit Parsing
932d1baf 132 // [Parsing commit objects][pco] is simple and gives you access to all the data in the commit
388f37b3 133 // - the // author (name, email, datetime), committer (same), tree, message, encoding and parent(s).
2e6d8ec4 134 // [pco]: http://libgit2.github.com/libgit2/#HEAD/group/commit
388f37b3
SC
135
136 printf("\n*Commit Parsing*\n");
137
138 git_commit *commit;
784b3b49 139 git_oid_fromstr(&oid, "f0877d0b841d75172ec404fc9370173dfffc20d1");
388f37b3 140
784b3b49 141 error = git_commit_lookup(&commit, repo, &oid);
388f37b3
SC
142
143 const git_signature *author, *cmtter;
0251733e 144 const char *message;
388f37b3
SC
145 time_t ctime;
146 unsigned int parents, p;
147
148 // Each of the properties of the commit object are accessible via methods, including commonly
0251733e
DB
149 // needed variations, such as `git_commit_time` which returns the author time and `_message`
150 // which gives you the commit message.
388f37b3 151 message = git_commit_message(commit);
388f37b3
SC
152 author = git_commit_author(commit);
153 cmtter = git_commit_committer(commit);
154 ctime = git_commit_time(commit);
155
156 // The author and committer methods return [git_signature] structures, which give you name, email
157 // and `when`, which is a `git_time` structure, giving you a timestamp and timezone offset.
158 printf("Author: %s (%s)\n", author->name, author->email);
159
160 // Commits can have zero or more parents. The first (root) commit will have no parents, most commits
932d1baf 161 // will have one, which is the commit it was based on, and merge commits will have two or more.
388f37b3
SC
162 // Commits can technically have any number, though it's pretty rare to have more than two.
163 parents = git_commit_parentcount(commit);
164 for (p = 0;p < parents;p++) {
165 git_commit *parent;
784b3b49 166 git_commit_parent(&parent, commit, p);
388f37b3
SC
167 git_oid_fmt(out, git_commit_id(parent));
168 printf("Parent: %s\n", out);
45e79e37 169 git_commit_free(parent);
388f37b3
SC
170 }
171
172 // Don't forget to close the object to prevent memory leaks. You will have to do this for
173 // all the objects you open and parse.
45e79e37 174 git_commit_free(commit);
388f37b3
SC
175
176 // #### Writing Commits
177 //
178 // libgit2 provides a couple of methods to create commit objects easily as well. There are four
179 // different create signatures, we'll just show one of them here. You can read about the other
180 // ones in the [commit API docs][cd].
2e6d8ec4 181 // [cd]: http://libgit2.github.com/libgit2/#HEAD/group/commit
388f37b3
SC
182
183 printf("\n*Commit Writing*\n");
184 git_oid tree_id, parent_id, commit_id;
51cc50a3
KS
185 git_tree *tree;
186 git_commit *parent;
388f37b3
SC
187
188 // Creating signatures for an authoring identity and time is pretty simple - you will need to have
189 // this to create a commit in order to specify who created it and when. Default values for the name
190 // and email should be found in the `user.name` and `user.email` configuration options. See the `config`
191 // section of this example file to see how to access config values.
784b3b49
DB
192 git_signature_new((git_signature **)&author, "Scott Chacon", "schacon@gmail.com",
193 123456789, 60);
194 git_signature_new((git_signature **)&cmtter, "Scott A Chacon", "scott@github.com",
195 987654321, 90);
388f37b3
SC
196
197 // Commit objects need a tree to point to and optionally one or more parents. Here we're creating oid
932d1baf 198 // objects to create the commit with, but you can also use
784b3b49
DB
199 git_oid_fromstr(&tree_id, "28873d96b4e8f4e33ea30f4c682fd325f7ba56ac");
200 git_tree_lookup(&tree, repo, &tree_id);
201 git_oid_fromstr(&parent_id, "f0877d0b841d75172ec404fc9370173dfffc20d1");
202 git_commit_lookup(&parent, repo, &parent_id);
388f37b3
SC
203
204 // Here we actually create the commit object with a single call with all the values we need to create
205 // the commit. The SHA key is written to the `commit_id` variable here.
206 git_commit_create_v(
207 &commit_id, /* out id */
208 repo,
209 NULL, /* do not update the HEAD */
210 author,
211 cmtter,
0251733e 212 NULL, /* use default message encoding */
388f37b3 213 "example commit",
51cc50a3
KS
214 tree,
215 1, parent);
388f37b3
SC
216
217 // Now we can take a look at the commit SHA we've generated.
218 git_oid_fmt(out, &commit_id);
219 printf("New Commit: %s\n", out);
220
221 // #### Tag Parsing
222 // You can parse and create tags with the [tag management API][tm], which functions very similarly
223 // to the commit lookup, parsing and creation methods, since the objects themselves are very similar.
2e6d8ec4 224 // [tm]: http://libgit2.github.com/libgit2/#HEAD/group/tag
388f37b3
SC
225 printf("\n*Tag Parsing*\n");
226 git_tag *tag;
227 const char *tmessage, *tname;
228 git_otype ttype;
229
230 // We create an oid for the tag object if we know the SHA and look it up in the repository the same
231 // way that we would a commit (or any other) object.
784b3b49 232 git_oid_fromstr(&oid, "bc422d45275aca289c51d79830b45cecebff7c3a");
388f37b3 233
784b3b49 234 error = git_tag_lookup(&tag, repo, &oid);
388f37b3
SC
235
236 // Now that we have the tag object, we can extract the information it generally contains: the target
932d1baf 237 // (usually a commit object), the type of the target object (usually 'commit'), the name ('v1.0'),
388f37b3 238 // the tagger (a git_signature - name, email, timestamp), and the tag message.
784b3b49 239 git_tag_target((git_object **)&commit, tag);
388f37b3 240 tname = git_tag_name(tag); // "test"
aa8a76ef 241 ttype = git_tag_target_type(tag); // GIT_OBJ_COMMIT (otype enum)
388f37b3
SC
242 tmessage = git_tag_message(tag); // "tag message\n"
243 printf("Tag Message: %s\n", tmessage);
244
45e79e37 245 git_commit_free(commit);
388f37b3
SC
246
247 // #### Tree Parsing
248 // [Tree parsing][tp] is a bit different than the other objects, in that we have a subtype which is the
249 // tree entry. This is not an actual object type in Git, but a useful structure for parsing and
250 // traversing tree entries.
251 //
2e6d8ec4 252 // [tp]: http://libgit2.github.com/libgit2/#HEAD/group/tree
388f37b3
SC
253 printf("\n*Tree Parsing*\n");
254
96da90ae 255 const git_tree_entry *entry;
388f37b3
SC
256 git_object *objt;
257
258 // Create the oid and lookup the tree object just like the other objects.
784b3b49
DB
259 git_oid_fromstr(&oid, "2a741c18ac5ff082a7caaec6e74db3075a1906b5");
260 git_tree_lookup(&tree, repo, &oid);
388f37b3
SC
261
262 // Getting the count of entries in the tree so you can iterate over them if you want to.
e120123e
RB
263 size_t cnt = git_tree_entrycount(tree); // 3
264 printf("tree entries: %d\n", (int)cnt);
388f37b3 265
784b3b49 266 entry = git_tree_entry_byindex(tree, 0);
388f37b3
SC
267 printf("Entry name: %s\n", git_tree_entry_name(entry)); // "hello.c"
268
269 // You can also access tree entries by name if you know the name of the entry you're looking for.
784b3b49 270 entry = git_tree_entry_byname(tree, "hello.c");
388f37b3
SC
271 git_tree_entry_name(entry); // "hello.c"
272
273 // Once you have the entry object, you can access the content or subtree (or commit, in the case
274 // of submodules) that it points to. You can also get the mode if you want.
706a9974 275 git_tree_entry_to_object(&objt, repo, entry); // blob
388f37b3
SC
276
277 // Remember to close the looked-up object once you are done using it
45e79e37 278 git_object_free(objt);
388f37b3
SC
279
280 // #### Blob Parsing
281 //
282 // The last object type is the simplest and requires the least parsing help. Blobs are just file
283 // contents and can contain anything, there is no structure to it. The main advantage to using the
932d1baf 284 // [simple blob api][ba] is that when you're creating blobs you don't have to calculate the size
388f37b3
SC
285 // of the content. There is also a helper for reading a file from disk and writing it to the db and
286 // getting the oid back so you don't have to do all those steps yourself.
287 //
2e6d8ec4 288 // [ba]: http://libgit2.github.com/libgit2/#HEAD/group/blob
388f37b3
SC
289
290 printf("\n*Blob Parsing*\n");
291 git_blob *blob;
292
784b3b49
DB
293 git_oid_fromstr(&oid, "af7574ea73f7b166f869ef1a39be126d9a186ae0");
294 git_blob_lookup(&blob, repo, &oid);
388f37b3
SC
295
296 // You can access a buffer with the raw contents of the blob directly.
297 // Note that this buffer may not be contain ASCII data for certain blobs (e.g. binary files):
298 // do not consider the buffer a NULL-terminated string, and use the `git_blob_rawsize` attribute to
299 // find out its exact size in bytes
793c4385 300 printf("Blob Size: %ld\n", (long)git_blob_rawsize(blob)); // 8
784b3b49 301 git_blob_rawcontent(blob); // "content"
388f37b3
SC
302
303 // ### Revwalking
304 //
305 // The libgit2 [revision walking api][rw] provides methods to traverse the directed graph created
306 // by the parent pointers of the commit objects. Since all commits point back to the commit that
307 // came directly before them, you can walk this parentage as a graph and find all the commits that
308 // were ancestors of (reachable from) a given starting point. This can allow you to create `git log`
309 // type functionality.
310 //
2e6d8ec4 311 // [rw]: http://libgit2.github.com/libgit2/#HEAD/group/revwalk
388f37b3
SC
312
313 printf("\n*Revwalking*\n");
314 git_revwalk *walk;
315 git_commit *wcommit;
316
784b3b49 317 git_oid_fromstr(&oid, "f0877d0b841d75172ec404fc9370173dfffc20d1");
388f37b3
SC
318
319 // To use the revwalker, create a new walker, tell it how you want to sort the output and then push
320 // one or more starting points onto the walker. If you want to emulate the output of `git log` you
321 // would push the SHA of the commit that HEAD points to into the walker and then start traversing them.
322 // You can also 'hide' commits that you want to stop at or not see any of their ancestors. So if you
323 // want to emulate `git log branch1..branch2`, you would push the oid of `branch2` and hide the oid
324 // of `branch1`.
784b3b49 325 git_revwalk_new(&walk, repo);
388f37b3 326 git_revwalk_sorting(walk, GIT_SORT_TOPOLOGICAL | GIT_SORT_REVERSE);
784b3b49 327 git_revwalk_push(walk, &oid);
388f37b3
SC
328
329 const git_signature *cauth;
330 const char *cmsg;
331
332 // Now that we have the starting point pushed onto the walker, we can start asking for ancestors. It
333 // will return them in the sorting order we asked for as commit oids.
334 // We can then lookup and parse the commited pointed at by the returned OID;
335 // note that this operation is specially fast since the raw contents of the commit object will
336 // be cached in memory
e172cf08 337 while ((git_revwalk_next(&oid, walk)) == 0) {
784b3b49 338 error = git_commit_lookup(&wcommit, repo, &oid);
0251733e 339 cmsg = git_commit_message(wcommit);
388f37b3
SC
340 cauth = git_commit_author(wcommit);
341 printf("%s (%s)\n", cmsg, cauth->email);
45e79e37 342 git_commit_free(wcommit);
388f37b3
SC
343 }
344
345 // Like the other objects, be sure to free the revwalker when you're done to prevent memory leaks.
346 // Also, make sure that the repository being walked it not deallocated while the walk is in
347 // progress, or it will result in undefined behavior
348 git_revwalk_free(walk);
349
350 // ### Index File Manipulation
351 //
932d1baf 352 // The [index file API][gi] allows you to read, traverse, update and write the Git index file
388f37b3
SC
353 // (sometimes thought of as the staging area).
354 //
2e6d8ec4 355 // [gi]: http://libgit2.github.com/libgit2/#HEAD/group/index
388f37b3
SC
356
357 printf("\n*Index Walking*\n");
358
359 git_index *index;
6f2b0a3a 360 unsigned int i, ecount;
388f37b3
SC
361
362 // You can either open the index from the standard location in an open repository, as we're doing
363 // here, or you can open and manipulate any index file with `git_index_open_bare()`. The index
364 // for the repository will be located and loaded from disk.
784b3b49 365 git_repository_index(&index, repo);
388f37b3
SC
366
367 // For each entry in the index, you can get a bunch of information including the SHA (oid), path
368 // and mode which map to the tree objects that are written out. It also has filesystem properties
369 // to help determine what to inspect for changes (ctime, mtime, dev, ino, uid, gid, file_size and flags)
370 // All these properties are exported publicly in the `git_index_entry` struct
371 ecount = git_index_entrycount(index);
372 for (i = 0; i < ecount; ++i) {
f45d51ff 373 const git_index_entry *e = git_index_get_byindex(index, i);
388f37b3
SC
374
375 printf("path: %s\n", e->path);
376 printf("mtime: %d\n", (int)e->mtime.seconds);
377 printf("fs: %d\n", (int)e->file_size);
378 }
379
380 git_index_free(index);
381
382 // ### References
383 //
384 // The [reference API][ref] allows you to list, resolve, create and update references such as
385 // branches, tags and remote references (everything in the .git/refs directory).
386 //
2e6d8ec4 387 // [ref]: http://libgit2.github.com/libgit2/#HEAD/group/reference
388f37b3
SC
388
389 printf("\n*Reference Listing*\n");
390
391 // Here we will implement something like `git for-each-ref` simply listing out all available
392 // references and the object SHA they resolve to.
393 git_strarray ref_list;
ab4aa138 394 git_reference_list(&ref_list, repo, GIT_REF_LISTALL);
388f37b3 395
6f2b0a3a 396 const char *refname;
388f37b3
SC
397 git_reference *ref;
398
399 // Now that we have the list of reference names, we can lookup each ref one at a time and
400 // resolve them to the SHA, then print both values out.
401 for (i = 0; i < ref_list.count; ++i) {
402 refname = ref_list.strings[i];
784b3b49 403 git_reference_lookup(&ref, repo, refname);
388f37b3
SC
404
405 switch (git_reference_type(ref)) {
406 case GIT_REF_OID:
bac695b5 407 git_oid_fmt(out, git_reference_target(ref));
388f37b3
SC
408 printf("%s [%s]\n", refname, out);
409 break;
410
411 case GIT_REF_SYMBOLIC:
bac695b5 412 printf("%s => %s\n", refname, git_reference_symbolic_target(ref));
388f37b3 413 break;
d6d877d2
KS
414 default:
415 fprintf(stderr, "Unexpected reference type\n");
416 exit(1);
388f37b3
SC
417 }
418 }
419
420 git_strarray_free(&ref_list);
421
96da90ae
SC
422 // ### Config Files
423 //
424 // The [config API][config] allows you to list and updatee config values in
425 // any of the accessible config file locations (system, global, local).
426 //
427 // [config]: http://libgit2.github.com/libgit2/#HEAD/group/config
428
429 printf("\n*Config Listing*\n");
430
431 const char *email;
54ccc717 432 int32_t j;
96da90ae
SC
433
434 git_config *cfg;
435
436 // Open a config object so we can read global values from it.
784b3b49 437 git_config_open_ondisk(&cfg, "~/.gitconfig");
96da90ae 438
2af1c266 439 git_config_get_int32(&j, cfg, "help.autocorrect");
96da90ae
SC
440 printf("Autocorrect: %d\n", j);
441
2af1c266 442 git_config_get_string(&email, cfg, "user.email");
96da90ae
SC
443 printf("Email: %s\n", email);
444
388f37b3
SC
445 // Finally, when you're done with the repository, you can free it as well.
446 git_repository_free(repo);
6f2b0a3a
KS
447
448 return 0;
388f37b3
SC
449}
450