]> git.proxmox.com Git - libgit2.git/blame - examples/general.c
examples: general: narrow down scope of loop variables
[libgit2.git] / examples / general.c
CommitLineData
6cb831bd
BS
1/*
2 * libgit2 "general" example - shows basic libgit2 concepts
3 *
4 * Written by the libgit2 contributors
5 *
6 * To the extent possible under law, the author(s) have dedicated all copyright
7 * and related and neighboring rights to this software to the public domain
8 * worldwide. This software is distributed without any warranty.
9 *
10 * You should have received a copy of the CC0 Public Domain Dedication along
11 * with this software. If not, see
12 * <http://creativecommons.org/publicdomain/zero/1.0/>.
13 */
14
662eee15
PS
15/**
16 * [**libgit2**][lg] is a portable, pure C implementation of the Git core
17 * methods provided as a re-entrant linkable library with a solid API,
18 * allowing you to write native speed custom Git applications in any
19 * language which supports C bindings.
20 *
21 * This file is an example of using that API in a real, compilable C file.
22 * As the API is updated, this file will be updated to demonstrate the new
23 * functionality.
24 *
25 * If you're trying to write something in C using [libgit2][lg], you should
26 * also check out the generated [API documentation][ap]. We try to link to
27 * the relevant sections of the API docs in each section in this file.
28 *
29 * **libgit2** (for the most part) only implements the core plumbing
30 * functions, not really the higher level porcelain stuff. For a primer on
31 * Git Internals that you will need to know to work with Git at this level,
32 * check out [Chapter 10][pg] of the Pro Git book.
33 *
34 * [lg]: http://libgit2.github.com
35 * [ap]: http://libgit2.github.com/libgit2
36 * [pg]: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
37 */
38
39/**
40 * ### Includes
41 *
42 * Including the `git2.h` header will include all the other libgit2 headers
43 * that you need. It should be the only thing you need to include in order
44 * to compile properly and get all the libgit2 API.
45 */
388f37b3
SC
46#include <git2.h>
47#include <stdio.h>
f9a7973d 48#include <string.h>
388f37b3 49
c313e3d9 50static void oid_parsing(git_oid *out);
29d9afc0 51static void object_database(git_repository *repo, git_oid *oid);
b009adad 52static void commit_writing(git_repository *repo);
15960454
PS
53static void commit_parsing(git_repository *repo);
54static void tag_parsing(git_repository *repo);
55static void tree_parsing(git_repository *repo);
56static void blob_parsing(git_repository *repo);
8b93ccdf 57static void revwalking(git_repository *repo);
c079e3c8 58static void index_walking(git_repository *repo);
f9a7973d 59static void reference_listing(git_repository *repo);
832278bf 60static void config_files(const char *repo_path, git_repository *repo);
986913f4 61
662eee15
PS
62/**
63 * Almost all libgit2 functions return 0 on success or negative on error.
64 * This is not production quality error checking, but should be sufficient
65 * as an example.
66 */
a7ed7460
RB
67static void check_error(int error_code, const char *action)
68{
fbc5661e 69 const git_error *error = giterr_last();
a7ed7460
RB
70 if (!error_code)
71 return;
72
a7ed7460 73 printf("Error %d %s - %s\n", error_code, action,
176d58ba 74 (error && error->message) ? error->message : "???");
a7ed7460
RB
75
76 exit(1);
77}
78
388f37b3
SC
79int main (int argc, char** argv)
80{
e2d1b7ec 81 int error;
c313e3d9 82 git_oid oid;
e2d1b7ec
PS
83 char *repo_path;
84 git_repository *repo;
c313e3d9 85
662eee15
PS
86 /**
87 * Initialize the library, this will set up any global state which libgit2 needs
88 * including threading and crypto
89 */
176d58ba 90 git_libgit2_init();
799e22ea 91
662eee15
PS
92 /**
93 * ### Opening the Repository
94 *
95 * There are a couple of methods for opening a repository, this being the
96 * simplest. There are also [methods][me] for specifying the index file
97 * and work tree locations, here we assume they are in the normal places.
98 *
99 * (Try running this program against tests/resources/testrepo.git.)
100 *
101 * [me]: http://libgit2.github.com/libgit2/#HEAD/group/repository
102 */
e2d1b7ec 103 repo_path = (argc > 1) ? argv[1] : "/opt/libgit2-test/.git";
176d58ba
PS
104
105 error = git_repository_open(&repo, repo_path);
106 check_error(error, "opening repository");
107
c313e3d9 108 oid_parsing(&oid);
29d9afc0
PS
109 object_database(repo, &oid);
110 commit_writing(repo);
111 commit_parsing(repo);
112 tag_parsing(repo);
113 tree_parsing(repo);
114 blob_parsing(repo);
115 revwalking(repo);
116 index_walking(repo);
117 reference_listing(repo);
832278bf 118 config_files(repo_path, repo);
176d58ba 119
662eee15
PS
120 /**
121 * Finally, when you're done with the repository, you can free it as well.
122 */
29d9afc0
PS
123 git_repository_free(repo);
124
125 return 0;
126}
127
c313e3d9
PS
128/**
129 * ### SHA-1 Value Conversions
130 */
131static void oid_parsing(git_oid *oid)
132{
133 char out[GIT_OID_HEXSZ+1];
134 char hex[] = "4a202b346bb0fb0db7eff3cffeb3c70babbd2045";
135
136 printf("*Hex to Raw*\n");
137
138 /**
139 * For our first example, we will convert a 40 character hex value to the
140 * 20 byte raw SHA1 value.
141 *
142 * The `git_oid` is the structure that keeps the SHA value. We will use
143 * this throughout the example for storing the value of the current SHA
144 * key we're working with.
145 */
146 git_oid_fromstr(oid, hex);
147
148 // Once we've converted the string into the oid value, we can get the raw
149 // value of the SHA by accessing `oid.id`
150
151 // Next we will convert the 20 byte raw SHA1 value to a human readable 40
152 // char hex value.
153 printf("\n*Raw to Hex*\n");
154 out[GIT_OID_HEXSZ] = '\0';
155
156 /**
157 * If you have a oid, you can easily get the hex value of the SHA as well.
158 */
159 git_oid_fmt(out, oid);
160
161 /**
162 * If you have a oid, you can easily get the hex value of the SHA as well.
163 */
164 git_oid_fmt(out, oid);
165 printf("SHA hex string: %s\n", out);
166}
167
29d9afc0
PS
168/**
169 * ### Working with the Object Database
170 *
171 * **libgit2** provides [direct access][odb] to the object database. The
172 * object database is where the actual objects are stored in Git. For
173 * working with raw objects, we'll need to get this structure from the
174 * repository.
175 *
176 * [odb]: http://libgit2.github.com/libgit2/#HEAD/group/odb
177 */
178static void object_database(git_repository *repo, git_oid *oid)
179{
180 char oid_hex[GIT_OID_HEXSZ+1] = { 0 };
181 const unsigned char *data;
182 const char *str_type;
183 int error;
184 git_odb_object *obj;
176d58ba 185 git_odb *odb;
29d9afc0
PS
186 git_otype otype;
187
176d58ba
PS
188 git_repository_odb(&odb, repo);
189
29d9afc0
PS
190 /**
191 * #### Raw Object Reading
192 */
176d58ba
PS
193
194 printf("\n*Raw Object Read*\n");
176d58ba 195
29d9afc0
PS
196 /**
197 * We can read raw objects directly from the object database if we have
198 * the oid (SHA) of the object. This allows us to access objects without
199 * knowing their type and inspect the raw bytes unparsed.
200 */
201 error = git_odb_read(&obj, odb, oid);
176d58ba
PS
202 check_error(error, "finding object in repository");
203
29d9afc0
PS
204 /**
205 * A raw object only has three properties - the type (commit, blob, tree
206 * or tag), the size of the raw data and the raw, unparsed data itself.
207 * For a commit or tag, that raw data is human readable plain ASCII
208 * text. For a blob it is just file contents, so it could be text or
209 * binary data. For a tree it is a special binary format, so it's unlikely
210 * to be hugely helpful as a raw object.
211 */
176d58ba
PS
212 data = (const unsigned char *)git_odb_object_data(obj);
213 otype = git_odb_object_type(obj);
214
29d9afc0
PS
215 /**
216 * We provide methods to convert from the object type which is an enum, to
217 * a string representation of that value (and vice-versa).
218 */
176d58ba 219 str_type = git_object_type2string(otype);
e2d1b7ec 220 printf("object length and type: %d, %s\nobject data: %s\n",
176d58ba 221 (int)git_odb_object_size(obj),
e2d1b7ec 222 str_type, data);
176d58ba 223
29d9afc0
PS
224 /**
225 * For proper memory management, close the object when you are done with
226 * it or it will leak memory.
227 */
176d58ba
PS
228 git_odb_object_free(obj);
229
29d9afc0
PS
230 /**
231 * #### Raw Object Writing
232 */
176d58ba
PS
233
234 printf("\n*Raw Object Write*\n");
235
29d9afc0
PS
236 /**
237 * You can also write raw object data to Git. This is pretty cool because
238 * it gives you direct access to the key/value properties of Git. Here
239 * we'll write a new blob object that just contains a simple string.
240 * Notice that we have to specify the object type as the `git_otype` enum.
241 */
242 git_odb_write(oid, odb, "test data", sizeof("test data") - 1, GIT_OBJ_BLOB);
243
244 /**
245 * Now that we've written the object, we can check out what SHA1 was
246 * generated when the object was written to our database.
247 */
248 git_oid_fmt(oid_hex, oid);
249 printf("Written Object: %s\n", oid_hex);
b009adad 250}
176d58ba 251
b009adad
PS
252/**
253 * #### Writing Commits
254 *
255 * libgit2 provides a couple of methods to create commit objects easily as
256 * well. There are four different create signatures, we'll just show one
257 * of them here. You can read about the other ones in the [commit API
258 * docs][cd].
259 *
260 * [cd]: http://libgit2.github.com/libgit2/#HEAD/group/commit
261 */
262static void commit_writing(git_repository *repo)
263{
176d58ba
PS
264 git_oid tree_id, parent_id, commit_id;
265 git_tree *tree;
266 git_commit *parent;
8572e225 267 git_signature *author, *committer;
b009adad
PS
268 char oid_hex[GIT_OID_HEXSZ+1] = { 0 };
269
270 printf("\n*Commit Writing*\n");
176d58ba 271
b009adad
PS
272 /**
273 * Creating signatures for an authoring identity and time is simple. You
274 * will need to do this to specify who created a commit and when. Default
275 * values for the name and email should be found in the `user.name` and
276 * `user.email` configuration options. See the `config` section of this
277 * example file to see how to access config values.
278 */
8572e225 279 git_signature_new(&author,
176d58ba 280 "Scott Chacon", "schacon@gmail.com", 123456789, 60);
8572e225 281 git_signature_new(&committer,
176d58ba
PS
282 "Scott A Chacon", "scott@github.com", 987654321, 90);
283
b009adad
PS
284 /**
285 * Commit objects need a tree to point to and optionally one or more
286 * parents. Here we're creating oid objects to create the commit with,
287 * but you can also use
288 */
176d58ba
PS
289 git_oid_fromstr(&tree_id, "f60079018b664e4e79329a7ef9559c8d9e0378d1");
290 git_tree_lookup(&tree, repo, &tree_id);
291 git_oid_fromstr(&parent_id, "5b5b025afb0b4c913b4c338a42934a3863bf3644");
292 git_commit_lookup(&parent, repo, &parent_id);
293
b009adad
PS
294 /**
295 * Here we actually create the commit object with a single call with all
296 * the values we need to create the commit. The SHA key is written to the
297 * `commit_id` variable here.
298 */
176d58ba
PS
299 git_commit_create_v(
300 &commit_id, /* out id */
301 repo,
302 NULL, /* do not update the HEAD */
303 author,
8572e225 304 committer,
176d58ba
PS
305 NULL, /* use default message encoding */
306 "example commit",
307 tree,
308 1, parent);
309
b009adad
PS
310 /**
311 * Now we can take a look at the commit SHA we've generated.
312 */
313 git_oid_fmt(oid_hex, &commit_id);
314 printf("New Commit: %s\n", oid_hex);
15960454
PS
315}
316
317/**
318 * ### Object Parsing
319 *
320 * libgit2 has methods to parse every object type in Git so you don't have
321 * to work directly with the raw data. This is much faster and simpler
322 * than trying to deal with the raw data yourself.
323 */
324
325/**
326 * #### Commit Parsing
327 *
328 * [Parsing commit objects][pco] is simple and gives you access to all the
329 * data in the commit - the author (name, email, datetime), committer
330 * (same), tree, message, encoding and parent(s).
331 *
332 * [pco]: http://libgit2.github.com/libgit2/#HEAD/group/commit
333 */
334static void commit_parsing(git_repository *repo)
335{
336 const git_signature *author, *cmtter;
337 git_commit *commit, *parent;
338 git_oid oid;
339 char oid_hex[GIT_OID_HEXSZ+1];
340 const char *message;
341 unsigned int parents, p;
342 int error;
e2d1b7ec 343 time_t time;
15960454
PS
344
345 printf("\n*Commit Parsing*\n");
346
347 git_oid_fromstr(&oid, "8496071c1b46c854b31185ea97743be6a8774479");
348
349 error = git_commit_lookup(&commit, repo, &oid);
350 check_error(error, "looking up commit");
351
352 /**
353 * Each of the properties of the commit object are accessible via methods,
354 * including commonly needed variations, such as `git_commit_time` which
355 * returns the author time and `git_commit_message` which gives you the
356 * commit message (as a NUL-terminated string).
357 */
358 message = git_commit_message(commit);
359 author = git_commit_author(commit);
360 cmtter = git_commit_committer(commit);
e2d1b7ec 361 time = git_commit_time(commit);
15960454
PS
362
363 /**
364 * The author and committer methods return [git_signature] structures,
365 * which give you name, email and `when`, which is a `git_time` structure,
366 * giving you a timestamp and timezone offset.
367 */
e2d1b7ec
PS
368 printf("Author: %s (%s)\nCommitter: %s (%s)\nDate: %s\nMessage: %s\n",
369 author->name, author->email,
370 cmtter->name, cmtter->email,
371 ctime(&time), message);
15960454
PS
372
373 /**
374 * Commits can have zero or more parents. The first (root) commit will
375 * have no parents, most commits will have one (i.e. the commit it was
376 * based on) and merge commits will have two or more. Commits can
377 * technically have any number, though it's rare to have more than two.
378 */
379 parents = git_commit_parentcount(commit);
380 for (p = 0;p < parents;p++) {
381 memset(oid_hex, 0, sizeof(oid_hex));
382
383 git_commit_parent(&parent, commit, p);
384 git_oid_fmt(oid_hex, git_commit_id(parent));
385 printf("Parent: %s\n", oid_hex);
386 git_commit_free(parent);
387 }
388
389 git_commit_free(commit);
390}
391
392/**
393 * #### Tag Parsing
394 *
395 * You can parse and create tags with the [tag management API][tm], which
396 * functions very similarly to the commit lookup, parsing and creation
397 * methods, since the objects themselves are very similar.
398 *
399 * [tm]: http://libgit2.github.com/libgit2/#HEAD/group/tag
400 */
401static void tag_parsing(git_repository *repo)
402{
403 git_commit *commit;
404 git_otype type;
176d58ba 405 git_tag *tag;
15960454
PS
406 git_oid oid;
407 const char *name, *message;
408 int error;
176d58ba 409
15960454
PS
410 printf("\n*Tag Parsing*\n");
411
412 /**
413 * We create an oid for the tag object if we know the SHA and look it up
414 * the same way that we would a commit (or any other object).
415 */
176d58ba
PS
416 git_oid_fromstr(&oid, "b25fa35b38051e4ae45d4222e795f9df2e43f1d1");
417
418 error = git_tag_lookup(&tag, repo, &oid);
419 check_error(error, "looking up tag");
420
15960454
PS
421 /**
422 * Now that we have the tag object, we can extract the information it
423 * generally contains: the target (usually a commit object), the type of
424 * the target object (usually 'commit'), the name ('v1.0'), the tagger (a
425 * git_signature - name, email, timestamp), and the tag message.
426 */
176d58ba 427 git_tag_target((git_object **)&commit, tag);
15960454
PS
428 name = git_tag_name(tag); /* "test" */
429 type = git_tag_target_type(tag); /* GIT_OBJ_COMMIT (otype enum) */
430 message = git_tag_message(tag); /* "tag message\n" */
e2d1b7ec
PS
431 printf("Tag Name: %s\nTag Type: %s\nTag Message: %s\n",
432 name, git_object_type2string(type), message);
176d58ba
PS
433
434 git_commit_free(commit);
15960454 435}
176d58ba 436
15960454
PS
437/**
438 * #### Tree Parsing
439 *
440 * [Tree parsing][tp] is a bit different than the other objects, in that
441 * we have a subtype which is the tree entry. This is not an actual
442 * object type in Git, but a useful structure for parsing and traversing
443 * tree entries.
444 *
445 * [tp]: http://libgit2.github.com/libgit2/#HEAD/group/tree
446 */
447static void tree_parsing(git_repository *repo)
448{
449 const git_tree_entry *entry;
450 size_t cnt;
451 git_object *obj;
452 git_tree *tree;
453 git_oid oid;
176d58ba 454
176d58ba
PS
455 printf("\n*Tree Parsing*\n");
456
15960454
PS
457 /**
458 * Create the oid and lookup the tree object just like the other objects.
459 */
460 git_oid_fromstr(&oid, "f60079018b664e4e79329a7ef9559c8d9e0378d1");
176d58ba
PS
461 git_tree_lookup(&tree, repo, &oid);
462
15960454
PS
463 /**
464 * Getting the count of entries in the tree so you can iterate over them
465 * if you want to.
466 */
467 cnt = git_tree_entrycount(tree); /* 2 */
468 printf("tree entries: %d\n", (int) cnt);
176d58ba
PS
469
470 entry = git_tree_entry_byindex(tree, 0);
15960454 471 printf("Entry name: %s\n", git_tree_entry_name(entry)); /* "README" */
176d58ba 472
15960454
PS
473 /**
474 * You can also access tree entries by name if you know the name of the
475 * entry you're looking for.
476 */
176d58ba 477 entry = git_tree_entry_byname(tree, "README");
15960454 478 git_tree_entry_name(entry); /* "README" */
176d58ba 479
15960454
PS
480 /**
481 * Once you have the entry object, you can access the content or subtree
482 * (or commit, in the case of submodules) that it points to. You can also
483 * get the mode if you want.
484 */
485 git_tree_entry_to_object(&obj, repo, entry); /* blob */
176d58ba 486
15960454
PS
487 /**
488 * Remember to close the looked-up object once you are done using it
489 */
490 git_object_free(obj);
491}
176d58ba 492
15960454
PS
493/**
494 * #### Blob Parsing
495 *
496 * The last object type is the simplest and requires the least parsing
497 * help. Blobs are just file contents and can contain anything, there is
498 * no structure to it. The main advantage to using the [simple blob
499 * api][ba] is that when you're creating blobs you don't have to calculate
500 * the size of the content. There is also a helper for reading a file
501 * from disk and writing it to the db and getting the oid back so you
502 * don't have to do all those steps yourself.
503 *
504 * [ba]: http://libgit2.github.com/libgit2/#HEAD/group/blob
505 */
506static void blob_parsing(git_repository *repo)
507{
508 git_blob *blob;
509 git_oid oid;
176d58ba
PS
510
511 printf("\n*Blob Parsing*\n");
176d58ba
PS
512
513 git_oid_fromstr(&oid, "1385f264afb75a56a5bec74243be9b367ba4ca08");
514 git_blob_lookup(&blob, repo, &oid);
515
15960454
PS
516 /**
517 * You can access a buffer with the raw contents of the blob directly.
518 * Note that this buffer may not be contain ASCII data for certain blobs
519 * (e.g. binary files): do not consider the buffer a NULL-terminated
520 * string, and use the `git_blob_rawsize` attribute to find out its exact
521 * size in bytes
522 * */
523 printf("Blob Size: %ld\n", (long)git_blob_rawsize(blob)); /* 8 */
524 git_blob_rawcontent(blob); /* "content" */
8b93ccdf
PS
525}
526
527/**
528 * ### Revwalking
529 *
530 * The libgit2 [revision walking api][rw] provides methods to traverse the
531 * directed graph created by the parent pointers of the commit objects.
532 * Since all commits point back to the commit that came directly before
533 * them, you can walk this parentage as a graph and find all the commits
534 * that were ancestors of (reachable from) a given starting point. This
535 * can allow you to create `git log` type functionality.
536 *
537 * [rw]: http://libgit2.github.com/libgit2/#HEAD/group/revwalk
538 */
539static void revwalking(git_repository *repo)
540{
541 const git_signature *cauth;
542 const char *cmsg;
543 int error;
176d58ba
PS
544 git_revwalk *walk;
545 git_commit *wcommit;
8b93ccdf
PS
546 git_oid oid;
547
548 printf("\n*Revwalking*\n");
176d58ba
PS
549
550 git_oid_fromstr(&oid, "5b5b025afb0b4c913b4c338a42934a3863bf3644");
551
8b93ccdf
PS
552 /**
553 * To use the revwalker, create a new walker, tell it how you want to sort
554 * the output and then push one or more starting points onto the walker.
555 * If you want to emulate the output of `git log` you would push the SHA
556 * of the commit that HEAD points to into the walker and then start
557 * traversing them. You can also 'hide' commits that you want to stop at
558 * or not see any of their ancestors. So if you want to emulate `git log
559 * branch1..branch2`, you would push the oid of `branch2` and hide the oid
560 * of `branch1`.
561 */
176d58ba
PS
562 git_revwalk_new(&walk, repo);
563 git_revwalk_sorting(walk, GIT_SORT_TOPOLOGICAL | GIT_SORT_REVERSE);
564 git_revwalk_push(walk, &oid);
565
8b93ccdf
PS
566 /**
567 * Now that we have the starting point pushed onto the walker, we start
568 * asking for ancestors. It will return them in the sorting order we asked
569 * for as commit oids. We can then lookup and parse the committed pointed
570 * at by the returned OID; note that this operation is specially fast
571 * since the raw contents of the commit object will be cached in memory
572 */
176d58ba
PS
573 while ((git_revwalk_next(&oid, walk)) == 0) {
574 error = git_commit_lookup(&wcommit, repo, &oid);
575 check_error(error, "looking up commit during revwalk");
576
577 cmsg = git_commit_message(wcommit);
578 cauth = git_commit_author(wcommit);
579 printf("%s (%s)\n", cmsg, cauth->email);
580
581 git_commit_free(wcommit);
582 }
583
8b93ccdf
PS
584 /**
585 * Like the other objects, be sure to free the revwalker when you're done
586 * to prevent memory leaks. Also, make sure that the repository being
587 * walked it not deallocated while the walk is in progress, or it will
588 * result in undefined behavior
589 */
176d58ba 590 git_revwalk_free(walk);
c079e3c8 591}
176d58ba 592
c079e3c8
PS
593/**
594 * ### Index File Manipulation *
595 * The [index file API][gi] allows you to read, traverse, update and write
596 * the Git index file (sometimes thought of as the staging area).
597 *
598 * [gi]: http://libgit2.github.com/libgit2/#HEAD/group/index
599 */
600static void index_walking(git_repository *repo)
601{
176d58ba
PS
602 git_index *index;
603 unsigned int i, ecount;
604
c079e3c8
PS
605 printf("\n*Index Walking*\n");
606
607 /**
608 * You can either open the index from the standard location in an open
609 * repository, as we're doing here, or you can open and manipulate any
610 * index file with `git_index_open_bare()`. The index for the repository
611 * will be located and loaded from disk.
612 */
176d58ba
PS
613 git_repository_index(&index, repo);
614
c079e3c8
PS
615 /**
616 * For each entry in the index, you can get a bunch of information
617 * including the SHA (oid), path and mode which map to the tree objects
618 * that are written out. It also has filesystem properties to help
619 * determine what to inspect for changes (ctime, mtime, dev, ino, uid,
620 * gid, file_size and flags) All these properties are exported publicly in
621 * the `git_index_entry` struct
622 */
176d58ba
PS
623 ecount = git_index_entrycount(index);
624 for (i = 0; i < ecount; ++i) {
625 const git_index_entry *e = git_index_get_byindex(index, i);
626
627 printf("path: %s\n", e->path);
628 printf("mtime: %d\n", (int)e->mtime.seconds);
629 printf("fs: %d\n", (int)e->file_size);
630 }
631
632 git_index_free(index);
f9a7973d 633}
176d58ba 634
f9a7973d
PS
635/**
636 * ### References
637 *
638 * The [reference API][ref] allows you to list, resolve, create and update
639 * references such as branches, tags and remote references (everything in
640 * the .git/refs directory).
641 *
642 * [ref]: http://libgit2.github.com/libgit2/#HEAD/group/reference
643 */
644static void reference_listing(git_repository *repo)
645{
176d58ba 646 git_strarray ref_list;
f9a7973d 647 unsigned i;
f9a7973d
PS
648
649 printf("\n*Reference Listing*\n");
650
651 /**
652 * Here we will implement something like `git for-each-ref` simply listing
653 * out all available references and the object SHA they resolve to.
654 *
655 * Now that we have the list of reference names, we can lookup each ref
656 * one at a time and resolve them to the SHA, then print both values out.
657 */
658
659 git_reference_list(&ref_list, repo);
176d58ba 660
176d58ba 661 for (i = 0; i < ref_list.count; ++i) {
5aa10107
PS
662 git_reference *ref;
663 char oid_hex[GIT_OID_HEXSZ+1] = GIT_OID_HEX_ZERO;
664 const char *refname;
665
176d58ba
PS
666 refname = ref_list.strings[i];
667 git_reference_lookup(&ref, repo, refname);
668
669 switch (git_reference_type(ref)) {
670 case GIT_REF_OID:
f9a7973d
PS
671 git_oid_fmt(oid_hex, git_reference_target(ref));
672 printf("%s [%s]\n", refname, oid_hex);
176d58ba
PS
673 break;
674
675 case GIT_REF_SYMBOLIC:
676 printf("%s => %s\n", refname, git_reference_symbolic_target(ref));
677 break;
678 default:
679 fprintf(stderr, "Unexpected reference type\n");
680 exit(1);
681 }
5aa10107
PS
682
683 git_reference_free(ref);
176d58ba
PS
684 }
685
686 git_strarray_free(&ref_list);
986913f4 687}
96da90ae 688
986913f4
PS
689/**
690 * ### Config Files
691 *
692 * The [config API][config] allows you to list and updatee config values
693 * in any of the accessible config file locations (system, global, local).
694 *
695 * [config]: http://libgit2.github.com/libgit2/#HEAD/group/config
696 */
832278bf 697static void config_files(const char *repo_path, git_repository* repo)
986913f4 698{
176d58ba 699 const char *email;
986913f4 700 char config_path[256];
176d58ba 701 int32_t j;
176d58ba 702 git_config *cfg;
832278bf 703 git_config *snap_cfg;
96da90ae 704
986913f4
PS
705 printf("\n*Config Listing*\n");
706
707 /**
708 * Open a config object so we can read global values from it.
709 */
176d58ba
PS
710 sprintf(config_path, "%s/config", repo_path);
711 check_error(git_config_open_ondisk(&cfg, config_path), "opening config");
96da90ae 712
176d58ba
PS
713 git_config_get_int32(&j, cfg, "help.autocorrect");
714 printf("Autocorrect: %d\n", j);
96da90ae 715
832278bf
DS
716 check_error(git_repository_config_snapshot(&snap_cfg, repo), "config snapshot");
717 git_config_get_string(&email, snap_cfg, "user.email");
176d58ba 718 printf("Email: %s\n", email);
388f37b3 719}